Addressability

Protocols and addresses

Protocol addresses are how Hypermake keeps source, data, rendered output, and proof artifacts aligned: every important object gets a stable name that works from the CLI, the graph, templates, and the Inspector. Every address on this page resolves in this project — try them.

Addressable by design

Every useful object gets a name.

Templates, data rows, rendered pages, and graph-owned proof artifacts become stable enough to explain, test, and mutate — without guessing at file layouts.

src:// data:// rendered:// public:// cache://

Source

<set key="campaign"
     value="{{ data://campaign.json }}" />

<h1 id="campaign-title">
  {{ campaign.client }} Campaign
</h1>

src://components/component-bound.html

Data

{
  "title": "Corpus Campaign",
  "client": "Corpus Client",
  "adCount": 2,
  "assets": [ ... ]
}

data://campaign.json

Rendered

<h1 id="campaign-title">
  Corpus Client Campaign
</h1>

rendered://public/components/component-bound.html

Addressable. Composable. Inspectable.

Example from this corpus: explicit, composable, inspectable components/component-bound.html

<set key="campaign" value="{{ data://campaign.json }}" />
<h1 id="campaign-title">{{ campaign.client }} Campaign</h1>

Addresses connect representations

The same page can be inspected through its source, its data, its rendered output, and its graph-owned proof artifacts.

Source addresses

Own author-editable templates, components, CSS, JS, assets, recipes, and queries.

src://docs/protocols.html

Data addresses

Resolve sibling-root structured data: path-owned rows, virtual list discovery, and fragment pointers.

data://campaign.json

Rendered addresses

Identify the rendered effect without pretending the effect is source truth.

rendered://public/docs/protocols.html

Public addresses

Name graph artifacts a recipe publishes — testing digests, evidence, and site projections.

public://_hypermake/testing/latest.json

Proof artifacts

Tape ledgers, rendered spans, and data-read sets are ordinary cache-owned graph targets.

cache://hypermake/lzr/tape-ledgers/rendered/public/scope/lineage.tape-ledger.json

Command subjects

The shared verbs also accept runtime, evidence, and concept subjects — addresses beyond files.

hypermake explain concept://protocol

Protocol table

Protocol	Meaning	Example (resolves here)
`src://`	Source-owned file or span.	`src://docs/protocols.html`
`data://`	Sibling-root structured data: rows, virtual lists, fragment pointers.	`data://campaign.json`
`public://`	Public graph artifact exposed by a recipe.	`public://_hypermake/testing/latest.json`
`rendered://`	Rendered output target.	`rendered://public/docs/protocols.html`
`cache://`	Graph-owned derived artifact, including tape/proof sidecars.	`cache://hypermake/lzr/data-reads/rendered/public/scope/lineage.data-reads.json`
`concept://`	Binary-owned glossary term, resolved by the CLI.	`concept://tape-ledger`
`runtime://`, `evidence://`, `plan://`, `action-pack://`	Command subjects for runtime state, evidence runs, plan slices, and action packs.	`hypermake inspect runtime://route-state`

Which plane an address lives on

Not every scheme:// in Hypermake means the same kind of thing, and the difference is load-bearing. There are four planes, each with its own resolver. An address that is valid on one plane can be meaningless on another — so this is the canonical inventory, and the section below reconciles it with the shorter list used in the architecture overview.

Name	Default directory	Notes
`src://`	`src`	Remappable per project.
`cache://`	`cache`	Remappable.
`build://`	`build`	A default mapping most projects never use; this fixture drops it by declaring its own `protocols` list. Example form: `build://artifacts/bundle.js`.
`rendered://`	`rendered`	Remappable.
`public://`	`rendered/public`	Remappable.
`journal://`	`.hypermake/control/journal-sources`	Core-forced. A project declaration for this name is dropped and the control directory re-imposed. Control-plane lanes address like `journal://origin/lanes/site/head.json`.
`request-projection://`	`.hypermake/control/request-projections`	Core-forced. Request-local virtual targets, e.g. `request-projection://approvals/id.json`; a project may consume them but may never point the authority elsewhere.
`hypermake://`	the Hypermake home directory	Added automatically unless the project declares the name itself.
anything you declare	your directory	`protocols` entries are `{"name", "dir"}` pairs; see the hypermake.json reference.

This plane is the one the CLI canonicalizes against. A name that is not registered is a hard error — which is exactly what makes it useful:

The registry is checkable shell

hypermake protocols list
hypermake resolve src://docs/protocols.html

Scheme	In an expression it means
`src://`, `data://`, `cache://`, `public://`	A filesystem-backed read, with `.json` auto-decode and pointer fragments. Covered in depth on Expressions and pipes.
`rendered://`	A read of rendered output as a dependency.
`inspector://`, `project://`, `request-projection://`	Resolver-provided reads — `inspector://timeline/recent.json`, `project://config/summary.json` — available only where the host supplies that resolver.
`client://`, `projection://`	Browser-owned and projection reads recognized by the render planner; `client://demo/status.json` is declared through `clientGraph.clientProtocols`.

Scheme	Emitted by
`tape://`	The virtual prerequisite scheme for fragment-level freshness: `tape://rendered/public/index.html` names a target's tape, not a file.
`hypermake-matcher://`	Glob prerequisites become fingerprinted matchers, e.g. `hypermake-matcher://src/*/.css` — deliberately not an edge.
`route://capture/`	A route capture consumed by an expression, e.g. `route://capture/name`.
`graph://`	Binding metadata for an expression with no data root of its own, e.g. `graph://campaign#/campaign.client`.

Plane 4 is the command-subject vocabulary already in the table above — concept://, runtime://, evidence://, plan://, action-pack://, and segment:// for a named graph slice. These are arguments to verbs, not things a recipe builds.

Reconciling the two lists on this site

The architecture overview describes ownership using a shorter vocabulary, and one entry in it does not survive contact with the code. Recorded here rather than quietly deleted:

Address	Status
`src://`, `data://`, `rendered://`	Real, and on this page's planes 1 and 2.
`tape://`	Real — plane 3, a virtual prerequisite scheme.
`graph://`	Real, but narrower than the ownership table suggests: it is emitted as binding metadata, not as a general handle on the build graph. Graph ownership is addressed through ordinary targets.
`packet://`	Not a real scheme. No Hypermake source emits or resolves it. AX packets are real; that spelling of their address is not. Use `hypermake agent-brief` and the packet artifacts it names instead.

Address syntax rules

Rule	Effect
Scheme characters	Letters, digits, `-`, and `_` only, before a literal `://`. No slashes or backslashes in the name.
Unknown scheme	Refused, not passed through. Registry membership is the check.
Relative segments	`.` and `..` are rejected outright; nothing can escape its protocol root.
Backslashes and empty segments	Rejected. Paths are slash-separated and clean.
Trailing slash	Meaningful: it marks a directory target and is preserved through canonicalization.
Bare filesystem paths	Mapped back to the longest matching directory, so a physical path canonicalizes to exactly one address.
Fragments	`#/a/b` is a JSON pointer into a decoded document, not part of the path.

Vocabulary, quoted from the system

These definitions are not copied prose: this page quotes the binary-owned glossary at build time (public://_hypermake/site/concepts.json, materialized from hypermake explain concept://<term>), so the words here cannot drift from the system that implements them.

concept://target Target

A target is a stable build identity, preferably a protocol address such as public://index.html or cache://render/state/home.json rather than a bare file path. The path declares ownership, invalidation boundary, and likely recipe family. Ask the graph about a target with inspect, explain, or agent-brief before guessing.

concept://recipe Recipe

A recipe owns a target pattern and defines how matching targets become fresh. Recipes live in path-local.make files (one target family per file); the rule header owns graph facts (target, prerequisites, order-only directories) and the tab-indented commands own the action. Patterns use named captures such as {path}, never %.

concept://protocol Protocol

Protocols map stable graph names onto filesystem trees: src:// for templates and sources, data:// for the sibling domain-data root, cache:// for derived state, public:// and rendered:// for outputs. Protocol addresses survive directory reshuffles and tell both agents and recipes which invalidation domain an artifact belongs to.

concept://freshness Freshness

A target is fresh when its recorded proof matches reality: recipe, action, and source fingerprints, not just mtimes. explain reports freshness with a reason (for example prereq-missing or input-changed); dirty targets can be rebuilt with build TARGET --summary. Recipe changes invalidate affected targets without.force files.

concept://tape-ledger Fragment Tape Ledger

The tape ledger is LZR's record of a rendered target as a stream of fragment tape segments: components expand into segments, slots are splice boundaries, control frames choose tape shape. It is what makes addressed fragment patching possible — a browser edit maps to tape segments instead of re-rendering the page.

concept://source-map Source Map

A graph-owned projection mapping rendered output ranges back to source template and data ranges. Source maps route and explain edits but never authorize them; the backend validates map epochs before committing any proposed change.

Verify this yourself shell

hypermake protocols list
hypermake resolve src://docs/protocols.html
hypermake explain rendered/public/docs/protocols.html
hypermake explain concept://protocol
hypermake affected-by src/docs/protocols.html

Protocols and addresses

Every useful object gets a name.

Addresses connect representations

Source addresses

Data addresses

Rendered addresses

Public addresses

Proof artifacts

Command subjects

Protocol table

Protocol vocabulary in this project

Which plane an address lives on

Plane 1 — the graph protocol registry (maps names to directories)

Plane 2 — expression read schemes (resolved by the renderer)

Plane 3 — synthetic addresses (identity only; nothing to open)

Reconciling the two lists on this site

Architecture-page vocabulary, checked against the engine

Address syntax rules

What canonicalization enforces

Vocabulary, quoted from the system