Materialisations

The materialisations layer holds operational use cases. Each entry takes a present-tense problem in the world — one a Tier-1 CTO, a senator, or a journalist would recognise inside the first paragraph — and shows what HOP does to it.

Sibling to mythology/, with a different job. Mythology illustrates what the spec means by walking historical or counterfactual readings. Materialisations show what HOP does for you, today, in production.

What a materialisation is

Each entry answers three questions:

1. What’s the situation? — the world-as-it-is, the problem the reader recognises immediately.
2. What does HOP do? — the mechanism, in operational language. What gets signed, what gets queried, what flows, what gets paid. Not philosophy.
3. What’s different? — the world-after, with real numbers and the smallest possible end-to-end story.

What a materialisation isn’t

• Not a spec extract. The spec lives in hop_protocol/sections/ and a reader who only has the materialisation should not need to read the spec to understand the use case.
• Not philosophy. The philosophical framing lives in mythology/ and on swarmalignment.com. Materialisations point to those layers when relevant, then keep going.
• Not vaporware. If an entry uses a v0.1 primitive, it works today. If it uses v0.2 or v0.3, the entry says so explicitly. Honesty about what’s in the Python reference implementation and what isn’t.

Voice convention

Closer to Stripe’s engineering blog than to mythology’s Yergin-meets-RFC. Concrete numbers, runnable mechanisms, real before/after. Vivid where the human matters; mechanical where the mechanism matters. The reader leaves knowing exactly what would change for them if HOP shipped at their company tomorrow.

Add a new entry

Number it with the next prefix (02-, 03-, …). Title is a phrase a reader would search for, not a label. Each entry’s body opens with a one-paragraph italicised summary so the reader knows whether to keep reading.

The pages

• 01 — Crystallised Labour, Paid Forever (v0.1 primitive + v0.2 royalty cascade + Bean-Chain-style lift bonus) — the sound engineer’s snare hit ends up in a Kanye song; a billion people hear it; HOP makes the trillion sub-cent payments back to the engineer tractable, and the lift mechanism rewards the engineer who made the world’s best snare proportional to how much it actually moved the needle on the work that used it.
• 02 — Walking the Tree (v0.1 primitive + v0.2 dissent block type) — a managing director at a Tier-1 institution asks three questions whose answers currently take a quarter to discover. HOP turns them into queries that resolve in under a minute, with signatures, sources, and preserved dissent.
• 03 — Training Data with a Lineage (v0.1 primitive + v0.2 royalty cascade + lift measurement + lineage score) — the open web fills with model output and labs can no longer tell honey from slop. HOP attaches a verifiable lineage to work at the moment it’s made, lets a lab find exactly the data it needs by vector proximity, ingest only attested-author content, and pay each author per token included — more when the data measurably improved the model. The operational answer to Paying the Bees for Honey.
• 04 — Connecting the Halves (v0.1 primitive + v0.2 want/divest block types + matchmaker agent) — you bought something expensive and inconvenient and no longer need it; selling it is more friction than it’s worth, so it goes to landfill. HOP asks only that you keep a list of what you want and what you’d let go; agents that already know what people want match haves to wants by vector proximity, attested provenance dissolves the lemons problem, and waste falls out of the economy because matching it back in finally costs less than discarding it.

More to come.