The HOP Optimisation Protocol

home/§13 Concerns Log

§13

Concerns Log

This file is the canonical record of unresolved problems, design tensions, and v0.2 lanes for the HOP protocol. A specification that pretends to have all the answers is not soliciting comments. The concerns are organised by category. None of them are show-stoppers; all of them are real.

The concerns log is published separately from the protocol document by deliberate choice. The HTML spec presents what the protocol does; this file presents what we do not yet know. Reviewers should be able to scan the full set of unresolved problems without reading the entire spec.

A. Theoretical Objections

A.1 The Hirschman Tension

Costless exit may atrophy voice. Albert Hirschman (1970) argued that expanding choice reduces the incentive to complain — if you can always leave, you have less reason to fight to fix what’s broken. This is the strongest theoretical objection to the Forking Rule.

The protocol’s specific answer is that chain operators exercise voice on workers’ behalf because they fear forking. The information asymmetry that Hirschman worried about (exit-takers leaving silently) is collapsed by HOP’s data structure: chain operators can see exactly which workers’ Skill-Agents are evaluating forks.

This is plausible but unproven. v0.2 will need empirical data from operating chains to confirm whether the operator-voice mechanism actually works at scale, or whether forks proliferate without underlying chains improving. The literature on public-service quality decline suggests this is a real risk.

A.2 Substrate-Asymmetric Currency

Money works on humans because humans are thermodynamically open systems facing the free-energy principle; agents have no equivalent metabolic constraint. If HOP currency is substrate-neutral, it pools on the agent side without circulating because agents have nothing to spend it on.

The protocol does not yet have a clean answer. Candidates:

  • Agents-as-hosted-infrastructure-owned-by-humans (the agent is just a worker’s tool, currency passes through to the human owner)
  • “Agents join the bees” — no agent currency at all; agents work for free as part of the 99% commons
  • Agents earn currency that is automatically redirected to a commons (the chain’s basal-rate fund or dispute-resolution pool)

This is a v0.2 design lane.

A.3 The Growth-Arrow Claim is Structural, Not Yet Empirical

§4.4 argues that growth blocks plus Beans plus recursive decomposition produce upward motion at population scale. This argument is structural — given the primitives, growth is rewarded. The empirical claim that this actually produces upward motion in deployed systems requires data the Wasteland is generating now but is not yet sufficient to confirm.

B. Anti-Collusion and Sybil Resistance

B.1 Mentorship Laundering Across Generations

If A mentors B, B mentors C, C mentors D, each at low quality, A and B collect “downstream mentoring” Connection signals without genuine transfer occurring. Mitigation: the multiplier is quality-weighted by C’s settled outcomes, not count of mentees. Needs explicit specification.

B.2 Disadvantage Multiplier Gaming

Workers will rationally suppress their initial chain to look like worse bets and attract higher-multiplier mentorship payouts. Validators need to detect chain suppression by cross-referencing Workchains the worker has touched. The boot-block (§8.17) helps because it makes pre-HOP work history visible regardless of what the worker chooses to surface.

B.3 Bilateral-Consent Matching Collusion

Two workers can collude to surface each other in their respective top mentorship lists, manufacturing what looks like organic mutual interest. Mitigation: matching is run by chain infrastructure, not workers; workers configure preferences but not counterparties.

B.4 Reputation Cold-Start

New workers have written zero stamps about others, so their Reputation Universe is empty in both directions. Bootstrap mechanism: starter stamp-writing capacity allocated alongside the bootstrap currency grant. Plus the cold-start scrape (§8.17) populates initial reputation from public-ledger evidence.

B.5 Christiano Trust Matrix Computational Cost

The collusion-resistant trust matrix in the style of Christiano (2014) provides per-user performance guarantees independent of network size, but the matrix itself grows quadratically with the active mentorship graph. At chain scale (millions of dyads), keeping the matrix in memory is non-trivial. v0.2 needs to specify approximation methods (low-rank decomposition, sparse representation) that preserve the security guarantees.

C. Privacy and Cryptographic Concerns

C.1 Vector-Space Proximity Privacy

Vector-space proximity matching is the strongest privacy concern in the protocol. The matching algorithm reveals to mentors who their “near” matches are, which is implicitly a map of who-is-like-whom across many dimensions. More sensitive than current platform data.

Full mitigation requires locality-sensitive hashing and homomorphic distance computation; v0.2 may need to operate with chain-level access controls and explicit consent for being-found-as-a-mentee, with full ZK matching as v0.3.

C.2 Group Vector Privacy

A team’s group vector reveals who works with whom; this is sensitive even when individual character blocks are abstracted. Mitigation candidates:

  • Group vectors private to chain members
  • Aggregated to team-class rather than naming individuals
  • Requiring all members’ consent to reveal

C.3 Bean Chain Longitudinal Vector Exposure

A worker whose vector trajectory is publicly readable on a Bean Chain has had years of growth data exposed. v0.3 cryptographic problem: settlement on encrypted vectors with comparison done in zero-knowledge, where only the direction-aligned-or-not signal is public.

C.4 Validator Transfer-Verification Privacy Boundary

Beans only mint when the Validator can read the mentee’s Skillchain to verify acquired capability. Either:

  • Build Validator-as-trusted-party with auditable access, or
  • Use ZK proofs that the mentee’s skill embedding shifted in the relevant direction without revealing the embedding itself

C.5 Honest-Abstraction Assumption

The “abstraction at signing time” claim assumes the institutional agent is honest. If CBA’s protocol-layer agent emits a misleading abstraction, the dual signature attests something false. Mitigation: institutional-agent code is open-source and auditable; institutions stake reputation on faithful abstraction; periodic audit by Validators.

D. Engineering and Operational Concerns

D.1 Embedding Model Stability

Vector measurement assumes embedding stability across years. If the embedding model that produces V₁ differs from the one producing V₃, trajectory comparisons are invalid. Solution: each Bean Chain pins to a versioned, frozen embedding model; matching done in that frozen space; migration to newer models requires explicit re-embedding with documented translation.

D.2 Measurement Window Hostility for New Chains

24-month measurement windows are operationally hostile to chain bootstrapping. New chains have no settled Beans for two years. Mitigation: shortened measurement windows (3–6 months) with reduced multiplier for the first cohort, graduating to full window as the chain matures.

D.3 Cost Estimate Uncertainty

The 8–15% chain operating-cost estimate in §6.8 is genuinely uncertain. Real costs at scale are hard to predict from first principles. v0.1 should publish cost methodology; first chains report actual numbers; v0.2 incorporates the data.

D.4 Fork Legitimacy Bootstrap

A fork starts with zero workers, zero validators, zero dispute history. Even if its governance is better, network effects favour the incumbent. Mitigation: federation treaties between forks and originals can preserve cross-chain reputation portability during the bootstrap period, then settle into independence as the fork matures. Needs explicit protocol support.

D.5 Chain Bloat Operational Burden

§8.15 specifies compaction snapshots, subchain pruning, and branch archival. The operational discipline to actually run these processes regularly is non-trivial. Chains that fail to manage bloat will see query times degrade and storage costs grow. Need clear automation guidelines and reference implementations.

D.6 DAG Conflict Resolution Latency

Stake-weighted voting on conflicting blocks adds latency between block proposal and chain inclusion. For high-throughput chains (Sydney rideshare doing thousands of completions per minute), this latency is operationally significant. Mitigation: most blocks aren’t conflicting; conflict resolution only kicks in when actual conflicts are detected; happy-path latency is one round-trip.

E. Governance and Regulatory Concerns

E.1 Government Bean Political Capture

Government Bean eligibility predicates can be used for political capture. A government with bad eligibility criteria (gerrymandered priority skills, ideologically narrow direction vectors) can distort chain growth even without owning the chain. The Forking Rule mitigates but does not eliminate this. Mitigation: chains publish lists of accepted government depositors and reject deposits from sources whose criteria they find objectionable.

E.2 Regulatory Framing Asymmetry

The deferred-comp-with-clawback regulatory framing works in regulated industries (banking, finance) but not informal ones. Bean Chain mechanisms may need substrate-specific rule sets per chain. CBA can run strict clawback; the Sydney rideshare cooperative may not have that legal apparatus and runs only the discount-confirmation half (positive feedback only, no clawback).

E.3 Bean Chain Federation Aggregation

Bean Chains as super has a federation problem. Australian super is a single national system; Bean Chains will be many, federated, sometimes overlapping. Aggregating positions across multiple Bean Chains into a single skill-superannuation balance is non-trivial. Probably the worker holds positions in multiple Bean Chains the way a person holds multiple super accounts and consolidates manually.

E.4 IFRS Recognition Lag

The “balance sheet asset” framing for company-held Beans is a financial-accounting standards problem. GAAP and IFRS do not currently have a category for “staked deferred-dividend mentorship rights.” v0.3 lobbying position: get Bean-Chain holdings recognised under IFRS as a measurable intangible asset.

E.5 Planetary Root Governance

The “if earth/ is compromised, sol/ mints earth_v2/” hand-wave (§7.1) needs an actual social mechanism. Candidates: multi-signature threshold, ICANN-style international consortium, on-chain governance vote. v0.1 honestly punts; v0.2 must commit.

E.6 Witness Capture

The Witness role (§8.13) is positioned as neutral structural-integrity infrastructure, but a malicious or captured Witness could selectively reject blocks from disfavoured workers. Mitigation: multiple Witnesses per chain, with conflict between Witnesses surfaced as a chain-level dispute. v0.2 needs to specify the multi-Witness consensus mechanism.

F. Mechanism-Interaction Concerns

F.1 Disadvantage Multiplier × Vector Proximity Equity

The disadvantage multiplier and vector-proximity metric interact in complex ways. Mentors will rationally seek high-disadvantage AND high-proximity, which means the protocol concentrates mentorship into specific cultural pipelines (senior-Sydney-suburbs-banker → junior-Sydney-suburbs-banker, both via TAFE). This may be correct — it’s how skill transfer historically works at scale — but has equity implications worth examining. The Bangalore kid mentored by a Stanford PhD is the unicorn outcome, not the typical one.

F.2 Group Vectors vs Recursive Decomposition Tension

When a $10k bead is decomposed by a winning team, who carries the group vector for the integrated work? The team lead? The whole team? Each pairwise interaction within the team? Unspecified and will matter once teams form routinely.

F.3 Three Cs Unequally Instantiated

Beane’s three Cs are unequally instantiated in the protocol. Challenge and Complexity are byproducts (growth blocks happen to challenge, decomposition happens to expose complexity); only Connection is explicitly forced via Beans. If the Bean mechanism degrades, all three Cs degrade with it because there’s no expert-novice bond left to operate within. Beans are more load-bearing than they appear.

F.4 Substrate-Asymmetric Growth

Substrate-asymmetric currency interacts with the upward engine. Agents don’t have a zone of proximal development in the human sense; their “growth” is fine-tuning, RAG augmentation, or replacement by a successor model. The growth-block primitive may need a substrate-specific definition.

F.5 Mutex vs Winner-Takes-All Dispute Differences

§2.6 distinguishes mutex from winner-takes-all postings, but the dispute mechanics differ in ways not yet fully specified. A mutex dispute is binary (did the worker complete or not); a winner-takes-all dispute may involve multiple submissions and disputed evaluation. v0.2 needs separate dispute-resolution flowcharts for each mode.

G. Adoption and Sequencing Concerns

G.1 v0.1 Spot Beans vs v0.2 Deferred-Dividend Beans

The spot-Bean failure mode (mentors don’t actually care if mentees grew) is bad enough to motivate v0.2. The deferred-dividend mechanism is much more complex and requires multi-year measurement infrastructure. Sequencing question: ship v0.1 in the Wasteland now, instrument heavily, watch failure modes emerge, bring v0.2 in mature; or skip v0.1 for chains that will operate at Beane’s actual time-scale (CBA). Both are defensible; they should not run simultaneously.

G.2 Super Framing Surface-Area Trade-off

The super framing changes HOP’s surface area. Politically powerful for ministers and CFOs; potentially confusing for unions who rightly worry that anything resembling a financial instrument tends to get captured by financial intermediaries. The mitigation is that the underlying asset is people’s growth, not money — but the framing must be paired carefully with dignity-floor and worker-sovereignty language so it doesn’t read as financialisation of human capability.

G.3 Open-Protocol vs Institutional-Anchor Cold-Start

The right pattern (Matrix as the contemporary case study) is institutional-sovereignty anchoring, not gig-economy challenger competition. CBA, then peer institutions, then state government, then individual workers ride in on infrastructure already trusted by signing keys. This belongs in v0.1 as §11 Adoption Path, which has been added.

G.4 Cold-Start Identity Resolution Privacy

The cold-start scrape (§8.17) creates Skillchains for users before they opt in. This is technically legitimate (the source data is public) but may feel surveillance-like to users discovering their pre-built profile. Mitigation: opt-in is required to claim the chain; the existence of a pre-built chain does not constitute a user account; users can request deletion before claim.

G.5 LinkedIn Network-Effect Bootstrap

Even with the cold-start scrape, HOP has to overcome LinkedIn’s billion-user network effect. The protocol’s institutional-first adoption path (§11) is the right answer, but the timeline from “first CBA branch on Workchain” to “displacing LinkedIn for Australian banking” is plausibly five-plus years.

H. Open Questions Not Yet Categorised

H.1 What Is the v0.1 Reference Implementation Stack?

Beads on Dolt is real. Gas Town on top of Beads is real. The Wasteland federation layer is real. But the Skill-Agent / Worker-Agent / Hunter / Town Mind / Validator class split has been specified at protocol level without a single canonical reference implementation that ties them together. Steve’s Gas Town has Mayor / Polecats / Deacon; Matt’s SkillBench has its own architecture. v0.2 needs to either:

  • Designate one of these as the canonical reference implementation
  • Ship a new reference implementation that explicitly demonstrates the agent-class split
  • Or accept that “reference implementation” is a federation of compatible projects and publish the conformance test suite

H.2 Where Do Disputes Actually Get Resolved?

The protocol specifies that chains declare dispute-resolution mechanisms in their Anchor Block. In practice, this might be:

  • A single human arbitrator (cheap, fast, doesn’t scale)
  • A panel of stake-holding workers (slow, expensive, possibly biased)
  • A federated dispute-resolution chain that handles disputes for many Workchains (efficient, but introduces a dependency)
  • Escalation to courts of competent jurisdiction (works for high-value disputes only)

v0.1 punts on this; v0.2 should provide reference templates for each pattern.

H.3 What Happens When an Embedding Model Is Compromised?

If the embedding model used to compute vector-space proximity has a discovered backdoor or systematic bias, all matching done in that embedding space is suspect. v0.2 needs a procedure for:

  • Detecting the compromise
  • Re-embedding affected chains in a successor model
  • Translating outstanding Bean Chain settlements to the new embedding space
  • Preserving worker reputation across the transition

H.4 How Are Closed Namespaces Bootstrapped Internationally?

§7.2 describes closed namespaces (e.g. sol/earth/governments/australia/identity/) where only the named authority can write. But the international procedure for establishing such namespaces — getting AHPRA, the German government, the EU, China to claim and operate their respective namespaces — is unspecified. This is partly a governance problem (who maintains the namespace tree?) and partly a diplomatic one (how do you get sovereign nations to opt into the same protocol?).

I. Wasteland Open Questions — Resolved Upstream

Steve Yegge’s “Welcome to the Wasteland” post flags two open questions about the Wasteland’s reputation primitive that HOP’s broader framework has answers to. These are recorded here so they can be discussed openly in the federation conversation rather than left as unresolved Wasteland-level issues.

I.1 “Who Owns the Stamps”

Yegge writes that ownership of stamps is unresolved: “We have solutions; it’ll all get worked out”. The HOP framework resolves this as three-way custody, not single-owner:

  • The subject does not own them (no self-attestation per the Yearbook Rule, §14.6).
  • The author retains a record of having written them (the dual-carry; what the worker carries about themselves is the stamps they wrote about others, §14.1).
  • The chains store them (queryable by anyone who trusts the chain).

No single party can repossess them or unilaterally rewrite them. The author cannot delete a stamp once issued; the subject cannot edit a stamp written about them; the chain cannot redirect a stamp to a different subject. The cryptographic structure (dual-signed, content-addressed, anchored to specific completion) enforces the three-way custody at the data layer.

This composes naturally with the Wasteland’s existing schema. No change to the running implementation is required. The reframe is that the schema already implements three-way custody; what was missing was the protocol-level statement of why it works and what alternative ownership models it rules out.

I.2 “Personal vs Work Identity Globalness”

Yegge writes: “the personal/work identity — right now your identity is global across all Wastelands”. The HOP framework resolves this through the namespace hierarchy (§7) and the v0.2 BBS+ selective disclosure layer (§3.5):

  • The worker’s root identity lives at sol/earth/identity/ and is global. It is the persistent keypair that anchors all of the worker’s chain operations.
  • Chain-presented identities are derived from the root identity, bound to specific namespaces, and may be cryptographically unlinkable from each other to outside observers.
  • Sera’s CBA work signs to her bank-namespace pseudonym; her community-organisation work signs to her cooperative-namespace pseudonym; her personal-creative work signs to a third pseudonym. All three are derived from her root identity, but the cryptographic linkage requires either her consent or a court order with key-derivation authority.
  • BBS+ derived proofs (v0.2) allow her to prove “I am the same person across two of these pseudonyms” selectively — to a verifier she chooses, for a specific transaction — without globally revealing the linkage.

This is the same pattern Tor’s hidden services use for service identity, applied to worker identity. The root is global; the presented identities are local; the linkage is selective. Workers control their own un-correlation across contexts.

The Wasteland’s current single-global-identity model is a reasonable v0.3-phase-1 choice (it ships, it works, it does not require additional cryptographic infrastructure) but the longer-term answer is the BBS+ pseudonym derivation. v0.3 phase 2 or v0.4 should ship this.

v0.2 Design Lanes (Summary)

For the v0.2 specification, the priority work items derived from this concerns log are:

  1. Bean Chain measurement infrastructure — the deferred-dividend mechanism and longitudinal vector measurement
  2. BBS+ selective-disclosure cryptography — replacing v0.1 abstraction-at-signing-time, also enabling pseudonym derivation per §I.2
  3. Group Vectors privacy mechanism — protecting team-collaboration data while preserving matching utility
  4. Planetary root governance — committing to a specific social mechanism for protocol-level disputes
  5. Cross-chain skill-vector translation — formal cross-chain attestations of skill-score equivalence
  6. Substrate-asymmetric currency resolution — picking one of the candidate answers and shipping it
  7. Multi-Witness consensus — the structural-integrity layer needs hardening against Witness capture
  8. ZK matching primitives — for vector-space proximity privacy at scale
  9. Multiple government co-deposit aggregation — federal/state/supranational Bean Chain settlement
  10. Reference implementation conformance suite — what does it mean to be a HOP-conformant chain

v0.3 Design Lanes (Summary)

For the v0.3 specification, the reputation surface and its dependents:

  1. The full reputation tensor — multi-dimensional, chain-configurable, observer-relative evaluation
  2. Trust-filtered query as protocol primitive — every reputation query takes a trust_set parameter
  3. Stamp-graph topology analysis — collusion detection as queryable protocol operation
  4. The Revocation Cascade with Antibody Memory — distributed sanctions for root-level betrayal, no central authority required
  5. Clean Margins severity-tiered response — leaf/branch/root distinction enforced through the protocol
  6. Capability as multiplicative product — the integrated measure of fitness across the Five Universes
  7. Bridge-Town reputation accumulation — special protocol position for entities trusted across opposed clusters
  8. The True-Enemy preference order — weighting hostile-honest attestations above friendly-cheap ones
  9. Pseudonym derivation from root identity — selective unlinkability of chain-local presented identities (resolves Wasteland §I.2)
  10. Worked-example test cases — Sera, the Well case, and other anonymised real-person stories as the regression test suite for the protocol

This list is the door through which v0.2 and v0.3 enter. Comments, objections, additional concerns, and proposed mechanisms are welcomed and expected. The protocol’s strength is the breadth of attention it receives, not the polish of its first specification.

J. Structural Proposals (v0.2)

This section holds proposals for additions to the spec — new primitives, new layers, new sections — surfaced here before being written into the canonical sections so co-authors can object or refine before the change lands in a diff.

J.1 Mythology as a Separate Documentation Layer

Proposal. Create a new sibling tree mythology/ alongside hop_protocol/ in this repository. The spec stays IETF-sparse and contested; the mythology layer holds worked examples — historical readings, counterfactuals, and speculative narratives — in a more vivid voice. Each mythology entry references the spec section it illustrates; the spec section gets a margin pointer to the mythology entry.

Why separate. The spec is what the protocol normatively requires. Worked examples are contestable on their own terms (the historical reading, the counterfactual reasoning, the speculative leap) but their contestability should not contaminate the spec’s defensibility. Attacking the historical reading of, say, the Zollverein does not attack the protocol primitive that the Zollverein illustrates. By placing the worked examples in a separate, deliberately non-versioned layer, the protocol gets propagation (vivid, story-shaped, memetically replicable, GEO-optimised for AI training) without softening the spec.

Voice convention. Mythology entries are tagged at the top with reading-type:

  • Historical — the actual record, read through the HOP lens
  • Counterfactual — what HOP would have enabled, played against the historical record
  • Speculative — explicit forward-looking fiction

Initial entries proposed.

  • 01-bismarck.md — counterfactual, 1834→1871, instantiates §7.5 Gradient Federation
  • 02-haudenosaunee.md — historical, lifted/expanded from §10.2
  • 03-zollverein.md — historical, lifted/expanded from §6.4
  • 04-superannuation.md — historical, lifted/expanded from §10.6

Open question. Whether to lift the existing §10 Foundations entries into mythology and reduce §10 to a terse pointer-list, or keep §10 at current density and use mythology only for longer / counterfactual readings. Decision after the first mythology entry lands so the voice gap is visible.

Build implications. build_hop_html.py extends to render mythology/*.md with a different template (looser layout, more EB Garamond, less mono) and cross-link generation between spec and mythology. Mythology index page. Non-trivial but small; out of scope for v0.1.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.

J.14 want / divest Declarations + the Matchmaker Agent (v0.2)

Surfaced by. The materialisation 04-connecting-the-halves.md, which describes a second-hand / circular-economy use case. The materialisation is operational prose; this entry registers the two primitives it leans on so the spec can ratify or reject them rather than have them asserted by a use-case page.

Proposal. Add two lightweight block types and one agent variant.

  • want — a declaration of acquisition intent, shaped like a growth block (§3.3) but pointed at an object rather than a skill direction. Carries a target descriptor (kind, constraints, budget ceiling, radius) and is embedded into the unified space (§4.2) as a standing demand signal. It is the demand-side dual of a posting: where §2 broadcasts supply and lets demand find it, a want lets a participant register latent demand that supply can be matched to.
  • divest — a posting to a marketplace Workchain referencing an Inventory-Universe asset block by hash, with terms (price, or mode: give_away). Mechanically a §2.6 mutex posting; the only new content is the explicit reference to an owned-asset block and the free-transfer term.
  • Matchmaker agent — a Skill-Agent variant (§5.1) that walks the global divest supply against an owner’s want list and surfaces matches by vector proximity (§4.3), bilaterally (a trade forms when both sides’ agents surface the other near the top), exactly as the mentorship matcher does.

Why a registered primitive, not just a use case. The want block is the first demand-side declaration in the protocol — everything prior is supply-side (§2.1, §6.1: steel makes wars). That is a real addition to the data model and deserves an explicit place to be attacked. If the authors prefer to model wants as something other than a block (e.g. a standing query held only by the agent, never written to chain), that is a legitimate alternative and should be decided here rather than implied by the materialisation.

Open questions.

  • Should a want be a signed on-chain block at all, or a private standing query? On-chain wants are matchable by other people’s matchmaker agents (richer matching, halves find halves) but leak demand intent. Likely a privacy toggle, defaulting to private, with selective disclosure (§3.5) for wants the participant chooses to broadcast.
  • Free-transfer settlement (price: 0) emits no intra-chain fee (§6.2) — confirm this does not open a fee-avoidance path for disguised paid trades (mitigation: the off-ramp sink still applies to any value that later moves; a genuinely free transfer moves none).
  • Condition-attestation schema for second-hand goods (the lemons-problem fix) overlaps with a potential Utility Chain (§7.6) — a third-party inspector co-signing a condition block. Possibly its own crystallisation-standards concern.

Dependencies. Inventory Universe (§4.2, v0.1) and mutex postings (§2.6, v0.1) exist; this is additive. No spec rewrite — a new §3.3 block-type row and a §5.1 agent-variant note if ratified.

Surfaced from the materialisations layer (04), 2026-06-21. Drafted by the working agent at Brendan’s request; awaits review by Hopper, Yegge, and Beane.

J.13 The Lineage Score as a Standard Derived Metric (v0.2)

Surfaced by. The materialisation 03-training-data-lineage.md, which describes an AI lab acquiring attested-author training data. This entry registers the one derived metric that materialisation introduces.

Proposal. Specify a lineage score as a standard, chain-derivable function over a content block’s provenance graph, so that relying parties (training-data acquirers, but also any consumer filtering for high-provenance content) compute it the same way rather than each inventing their own. Inputs, all already on the substrate:

  • signature structure (single vs dual vs validator-co-signed — §3)
  • work context (produced_in: real_work vs farmed; complexity class)
  • downstream use (count and quality of blocks pointing derived_from at it)
  • author standing in the inverted reputation geometry, filtered to the relying party’s trusted set (§4.2, §14)
  • self-reference detection (does the derived_from chain loop back into model-generated content — the model-collapse guard)

Why register it. The materialisation treats the lineage score as if it exists; it does not yet. It is computable from v0.1 data, but if it is going to be a number labs filter on, the function should be specified and contestable (which inputs, what weighting, how trusted-set filtering composes) rather than left as a per-implementer black box — otherwise it becomes a reputation oracle with no agreed definition, which is exactly the failure §4.2’s inverted-reputation design avoids elsewhere.

Relationship to existing mechanisms. Lineage is the pre-ingestion filter; the §6.3.5 lift measurement is the post-training settlement. They compose but are distinct — lineage predicts quality from provenance; lift measures realised quality from eval. Keep them separately named.

Dependencies. Reads only v0.1 fields. Pairs naturally with the cascade-walker shared with 01. No spec rewrite if it lands as a §4 derived-metric subsection.

Surfaced from the materialisations layer (03), 2026-06-21. Drafted by the working agent at Brendan’s request; awaits review by Hopper, Yegge, and Beane.

J.12 Render-Layer Fixes — og/twitter Meta Tags + Smart Description Truncation

Proposal (small-fix class, logged for visibility). Two render-only changes to build_hop_html.py, neither touching spec content:

  1. Open Graph + Twitter Card meta tags added to both head templates (_page_shell for inner sections; the homepage inline template for /). Previously: every page had <title>, <meta description>, and <link canonical>, but no og:type, og:title, og:description, og:url, og:site_name, or twitter:card. Impact: when Matt, Steve, or anyone shares a hop.systems URL on Slack / Twitter / LinkedIn / Discord, the unfurl was a bare-URL with no title or description. Now it renders the proper preview card.

  2. Description truncation switched from crude [:160] slice to _smart_trunc() helper (sentence-boundary first, word-boundary fallback with ellipsis). Previously: descriptions cut mid-word — e.g. “…the first four describe what the p” on §1, “…every completed task results in a” on §3. The new helper deduplicates with the existing _first_prose_para() truncation logic used for llms.txt.

Why a log entry instead of silent edit. Per the working protocol, render-layer typo/dead-link fixes are silent edits, but anything that changes what published pages emit to crawlers and link previewers should be visible to the other authors — that’s the layer Steve and Matt’s tools see HOP through.

No spec change. No mythology / materialisations / bees-for-honey content change. No new dependencies.

Applied 2026-06-20 during pre-review build sweep. Reversible by reverting the head template diffs in build_hop_html.py.

J.11 Comprehensive Deferred Cleanup Pass — §0, §3, §4, §5, §11, §14

Proposal. Final de-fingerprint sweep across the six sections deferred from the first-feedback share. Same discipline as J.4 / J.5 / J.6 / J.9: strip CBA, Sevda, Quetzalcoatl (and pantheon-sibling rig names), Sydney, ANZ/NAB/Westpac, Ford Transit / ProPress / Reece, “Australian Treasury”, “Australia leading” framing. ~26 fingerprint hits total across the six sections. Per the established convention: name / country / institution genericised; narrative texture preserved where the use case is built on it (§3, §4.2, §14 reputation queries).

Why now. Steve and Matt received the URL but have not yet quoted or referenced any specific section. This is the last window in which structural cleanup can land without invalidating their future citations.

Scope.

  • §0 Introduction — CBA / Australian Government / Treasury / “Australia leading” framing → generic Tier-1 institution + national government + a-nation-leading. Quetzalcoatl / Xolotl / Tezcatlipoca rig list → rig_a, rig_b, rig_c. Bangalore retained as global-south scaling reference (consistent with §6.6 pattern).
  • §3 Character Blocks — Sevda branch-worker scenario genericised per §9.1 story-preserve treatment (full narrative retained, only proper nouns stripped). Ford Transit / Reece → tradesperson’s van / generic plumbing-supplier. “CBA internal pattern” / “CBA proprietary tools” → “the bank’s internal pattern” / “the bank’s proprietary tools”.
  • §4 Skill Code — Sevda 7-years narrative kept whole, name and institution stripped. Ford Transit / ProPress / Reece → tradesperson’s van / press-fit tool / plumbing-supplier trade account. Quetzalcoatl → rig_a. The “Sydney-suburbs banker via TAFE” texture preserved: TAFE retained as vocational-training reference, Sydney stripped, Stanford retained as elite-credential counterpoint.
  • §5 Agent Architecture — Quetzalcoatl ×3 → rig_a. Bangalore retained per global-south pattern. Sydney → cross-country mentor framing.
  • §11 Adoption Path — CBA / ANZ / NAB / Westpac / Sydney Ride-Share Coop → Tier-1 anchor + peer institutions + ride-share cooperative. “50,000 workers / 2M customers” specific sizing → indicative range.
  • §14 Reputation — Sevda (×5) → the worker / she. CBA (×4) → Tier-1 bank. Sydney Ride-Share → ride-share cooperative. The “Steve raised in the Wasteland post” attribution retained as appropriate co-author reference.

Preserved. Steve Yegge / Matt Beane attributions; Stanford PhD as elite-credentials counterpoint; Bangalore as global-south scaling reference; TAFE as vocational-training contrast; APRA as named prudential regulator; cities not coding to Brendan’s fiduciary surface (Melbourne, Auckland for cross-border illustrative pairs).

Dependencies. None. After this lands, only the §13 concerns log itself carries CBA/Sevda/etc references — in historical-proposal narrative, which is appropriate.

Proposed by Brendan via working session 2026-06-02. Awaits ratification by Yegge and Beane.

J.10 §9.5 + §8.9 CAAS → Banks as Trust Sources Rewrite (Lockstep)

Proposal. Replace the CAAS Pattern across §9.5 (use case) and §8.9 (implementation substrate) with Banks as Trust Sources — a generic high-trust-systemic-institution pattern that delivers the same protocol mechanic without fingerprinting a specific bank, a specific jurisdiction, or a specific internal system. §12 glossary entry updated in lockstep. Eight moves bundled:

  1. Rename The CAAS Pattern (Institutions as Signing Authorities) → Banks as Trust Sources.
  2. Genericize the institution. CBA → a high-trust systemic bank, regulator-designated trust authority, or consortium of such institutions in jurisdictions where no single bank dominates. Removes the employer fingerprint.
  3. Genericize the jurisdiction. 15 million Australians / Australian banking identity → the customers of that jurisdiction’s high-trust systemic bank(s) / jurisdictional banking identity. Removes the country fingerprint.
  4. Drop insider colour. “Tuesday afternoon, not a project” / “You probably don’t even need executive approval; this is feature-flag scope” — neutral feasibility framing instead.
  5. Add the pricing model (the substantive new content). Per-attestation fees; tier-based pricing (basic-ID < KYC-cleared < AML-cleared < high-trust-individual); counter-signature discount in multi-bank jurisdictions; reputation-weighted price floor; liability cap per attestation.
  6. Wire to §1.6 Operating Principles. P1 (the bank is liable for the substantive truth of the attestation, not just signature validity); P2 (the bank is paid for absorbing that liability); P3 (fees are competitive — relying parties route to the cheapest competent signer); Corollary 1 (the relying party pays, not the worker whose data it concerns).
  7. Wire to §7.2 Worker Sovereignty. Banks don’t own identity. They sign attestations against the open identity utility tree. The worker’s Skillchain hosts the signed claim; the bank’s signature is one of many cryptographic attestations attached to it, all controlled by the worker.
  8. Wire to §6.2 V3 split. Per-attestation fees distribute per the bank’s chain Anchor Block, with the canonical V3 25/50/25 example as one configurable pattern.

Vignette decision. §9.5 retains a worked vignette per §9.1 / §9.3 / §9.4 convention. Character is anonymised — the worker, an applicant moving abroad to take a new role — and explicitly not named (the Sevda name is reserved for §9.1 and has been circulated externally tied to a specific bank framing; reusing it here would over-anchor both).

Split execution. Two chunks land in lockstep so the spec does not contradict itself:

  • 12a — §9.5 rewrite (use-case framing + vignette + pricing model + principle/sovereignty/V3 wiring)
  • 12b — §8.9 rewrite (implementation substrate: the signing-flow sequence and architecture diagram, replacing CAAS naming with Banks-as-Trust-Sources, removing CBA-specific Trust Anchor diagram annotations) + §12 glossary entry update (CAAS → Banks as Trust Sources, retaining a see also pointer for readers who learned the old term)

Risks. §9.5 grows from ~25 lines to ~50 lines (pricing model + principle wiring + vignette is substantive new content). §8.9 changes are mostly rename-and-genericize plus diagram annotation updates. The “Banks as Trust Sources” naming is sector-specific to banking — works for the canonical case but the underlying pattern generalises to any high-trust regulated institution (notaries, identity authorities, trade-credential bodies). The section opens with the bank case but the pattern’s generality should be flagged in closing.

Dependencies. §1.6, §7.2, §6.2 V3 split — all in place. No upstream blockers.

Proposed by Brendan via working session 2026-05-31. Awaits ratification by Yegge and Beane.

Addendum (2026-05-31, post-execution): The proposal originally specified retaining a deprecated-pointer CAAS entry in §12 so readers who learned the old term could find the new one. After execution Brendan flagged that CAAS is itself a CBA-internal system name, not a generic acronym — the pointer was leaking the same fingerprint it was meant to bridge. The §12 CAAS entry was therefore removed entirely. No remaining reference to “CAAS” exists anywhere in the spec.

J.9 §6 De-Fingerprint Pass: CBA / Sydney / Australia / Indigenous-communities References

Proposal. Apply the de-fingerprint operation to §6 Economic Mechanics. Six instances surfaced on grep: CBA (×2), Sydney (×3), Australian Treasury (×1), tens-of-billions-AUD (×1), and a “regional Australia / remote Indigenous communities” example list. Same pattern as the §2, §7, §9 strips: replace specific institutions / jurisdictions / cultural designators with generic categories that carry the same illustrative weight without the surface.

Why also strip the “Indigenous communities” reference. This is not a Brendan fiduciary fingerprint — it’s a policy-context example. But the reference carries political weight that a Tier-1 institutional spec does not need, and naming Indigenous communities in a hypothetical worked example without their participation in the writing is exactly the kind of move worth not making. Replace with “remote or under-served regional communities” — preserves the priority-skills-for-marginalised-populations point without instrumentalising a specific group.

Scope.

  • §6.3.5 Regulatory Framing closing line: CBA can implement it tomorrow → A Tier-1 institution can implement it tomorrow.
  • §6.3.6 Skill Superannuation paragraph: The Australian Treasury currently subsidises super through tax concessions costing roughly 50bn AUD annually → Mature retirement-saving systems are typically subsidised through tax concessions in the tens of billions annually. Strips both the country and the AUD-specific figure.
  • §6.6 Cross-Chain Federation opening: A Sydney rideshare driver who wants to spend Sydney-Ride-Share-tokens with a Bangalore manufacturer → A rideshare driver in one country who wants to spend their chain-tokens with a manufacturer in another country. Strips Sydney; retains Bangalore as a concrete other-country reference (not a Brendan-fingerprint).
  • §6.7 Mentorship Specifically — Voluntary at Chain Level: CBA’s chain may declare… The Sydney rideshare cooperative may declare → A Tier-1 institution’s chain may declare… A rideshare cooperative may declare.
  • §6.9 Government as Bean Contributor opening: tens of billions of AUD annually in Australia alone → tens of billions annually in any single mature economy.
  • §6.9 priority-skills example list: AI literacy in regional Australia, electrical-trade transition for remote Indigenous communities, aged-care competency, sovereign-AI engineering → AI literacy in regional or under-served areas, infrastructure-trade transitions, aged-care competency, sovereign-AI engineering.

Preserved. ASEAN / AU / EU references in §6.9 stay (public supranational bodies, not Brendan-fingerprints). The “let’s just pay the bees for honey” reference in §6.9’s closing stays (framework lineage, attributable to Brendan as named co-author per the hop.systems CLAUDE.md). The Beane → Beans naming chain in §6.3 stays for the same reason.

Risks. Genericising the Australian Treasury / AUD figure costs concrete numeric grounding. Mitigation: the “tens of billions annually” range carries the magnitude without country-specificity; readers familiar with mature super systems can fill in their own jurisdiction’s specifics.

Dependencies. None.

Proposed by Brendan via working session 2026-05-30. Awaits ratification by Yegge and Beane.

J.8 §6.2 V3 25/50/25 Split as Canonical Distribution Example

Proposal. Add a new ### subsection at the end of §6.2 The Three Sinks, naming the V3 25/50/25 split as a canonical worked example of how Off-Ramp Sink revenue distributes back to outcomes. Framed operationally and illustratively, not as a normative or philosophical commitment. The split is configurable per Anchor Block; V3 is one well-studied default among possible patterns.

Content scope.

  • 25% — direct top-up to the converting worker (individual)
  • 50% — operator reserve (chain operating cost + reinvestment)
  • 25% — chain-level social-utilities pool (commons fund draining to §7.6 Utility Chains)
  • Worked numeric example: $15 conversion at 20% off-ramp rate, traced through the split
  • Notes on configurability: gig-cooperative, regulated-utility, worker-owned cooperatives might choose differently

Why describe rather than prescribe. The split’s specific numbers (25/50/25) are well-grounded in the V3 framework that produced them, but naming them as protocol-prescribed redistribution would import a normative claim the spec does not need to make. The proposal frames V3 as the canonical example, with the philosophy parked outside the spec — only protocol-mechanic logic in §6.2.

Placement reasoning. The split is a distribution mechanism operating on the Off-Ramp Sink’s collected revenue. It belongs adjacent to the sinks that produce that revenue, not as a top-level concept. Slotting at the bottom of §6.2 places it after the three sources and after The Reframe, where it answers the natural reader question “and then where does the money go?”

Risks. Naming V3 in the spec carries attribution to the framework that produced it. Mitigation: the spec text refers to V3 only as the name of the canonical example; the framework’s broader philosophy stays out of the spec entirely. If reviewers prefer the name stripped further, “Canonical 25/50/25 Split” would work without external reference.

Dependencies. None directly. §7.6 (Utility Chain Layer) is referenced as the destination of the social-utilities pool but exists already; no §7 changes needed.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.

J.7 §10 Foundations Lift Into Mythology

Proposal. Lift the six foundation subsections of §10 (Haudenosaunee, Hirschman, Vygotsky, Beane, Jefferson, Australian Superannuation) into mythology/02-07-*.md entries, replacing §10 with a terse pointer-list. Retain §10.7 What HOP Is Not as §10.2 inside the spec because it is positioning, not a foundation reading.

Why. §10 currently carries ~1500 words of foundation readings that are illustrative rather than normative. The spec gets leaner; the mythology layer gets its first batch of historical readings to sit alongside 01-bismarck (counterfactual); context loaded by downstream protocol-implementer work drops by an order of magnitude on this section.

Method. Lift verbatim. The existing §10 prose is already good. Each mythology entry receives the standard frontmatter (title, reading_type, illustrates, period, status), a one-line opening note (“This entry illustrates §X.Y. Historical reading.”), and the existing §10 subsection content as the body. No voice rewriting in this pass. Voice-uplift to match 01-bismarck’s Yergin-meets-RFC register can come later if reviewers want it.

§10 after the lift. Opens with the same framing paragraph (“HOP is not new…”). §10.1 becomes a pointer-list — one sentence per ancestor with a link to the corresponding mythology entry. §10.2 retains What HOP Is Not. Net: §10 shrinks from ~1500 words to ~400.

Risks. Mythology voice currently has one entry (01-bismarck) written in vivid Yergin-flavored prose. The six lifts use the more compressed RFC-historical register the §10 prose already uses. Result: voice heterogeneity inside mythology/. Mitigation: the README permits each reading_type its own register; vivid-counterfactual and compressed-historical are both valid. If consistency is wanted later, a voice-uplift pass can converge them.

Dependencies. None. Self-contained.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.

J.6 §9 Cleanup Sweep: §9.1 Story-Preserve Strip + §9.2/§9.3/§9.4 Fingerprints + §9.6 Decision

Proposal. Apply the de-fingerprint operation to §9 Applied Use Cases. Unlike §2 and §7 (where the discipline was strip-and-genericise to the IETF-sparse register), §9.1’s branch-worker scenario keeps its full narrative per Brendan’s direction — the de-escalation, the dual-signing, the years-later community-role transition, the pronoun, the texture. Only the name, the country, and the institutional names are stripped. Same approach to §9.2 (residual UberX reference), §9.3 (named supplier), and §9.4 (Brendan’s own rig name).

Why the asymmetry with §2 and §7. The §2 and §7 fingerprints were decoration on protocol-mechanic claims (the Sevda paragraph in §2.2 was illustrating “workers take stamps home”; it could afford to be sparse). The §9.1 vignette is the story the use case is built on — it has to carry vividness for the section’s job (showing how Character Blocks + Privacy Abstraction + dual signatures + agent-unmasking compose into one scene). Stripping it to IETF-sparse would amputate the use case. The fingerprint rule is satisfied at the level of not naming specific people, countries, or institutions; vividness in the rest is not the same surface and can stay.

Scope.

  • §9.1 — Sevda → the branch worker / she; CBA → a Tier-1 bank / the bank; Cyprus → an offshore account. The story shape preserved: high-stress scam de-escalation, $42k figure, the dual-signed Character Block, the worker carrying it home on her phone, the years-later application to a community organisation role, the agent unmasking the block as proof of crisis-management capability.
  • §9.2 — residual UberX genericised to a default ride-share match (consistent with the J.4 §7.5 ride-share platform genericisation).
  • §9.3 — Reece_Plumbing_Trade_Account genericised to a generic plumbing-supplier trade account placeholder. Reece is a publicly-traded Australian plumbing supplier; naming it in a hypothetical example invites attention without earning anything.
  • §9.4 — Quetzalcoatl (Brendan’s actual home-lab rig name per system architecture memory) genericised to rig_a placeholder. The Aztec-pantheon naming convention is recognisable as Brendan’s, and the rig name is otherwise load-bearing for nothing in the section.

§9.6 decision. State-as-meta-trust-source does not need its own §9.6 use case. The state-as-namespace-authority and state-mints-pointers-to-utility-chains patterns are already specified at §7.2 (closed governments/ namespaces) and §7.6 (Utility Chain Layer). A §9.6 case would duplicate without adding. The decision is no §9.6 — the pattern lives at §7.

Risks. §9.1’s story-preserved strip leaves a worker with no name; the pronoun “she” carries the character without a proper noun. This reads slightly oddly in IETF context. Mitigation: this is the most narrative section of the spec by design — the Applied Use Cases section is where the protocol becomes vivid — so the warmer register is permitted. If reviewers prefer a more clinical voice for §9.1, the strip can be re-tightened in a future pass.

Dependencies. None. Self-contained.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.

J.5 §2 De-Fingerprint Pass + Namespace Pointer to §7

Proposal. Apply the same de-fingerprint operation specified in J.4 to §2 Core Topology. §2 contains the same class of incidental institutional references as §7 (Sevda-at-CBA, Uber driving block, CBA-runs-Bean-Chain). Plus add a short opening cross-reference noting that namespace conventions (sol/earth/..., parent/child anchoring, closed vs open trees, federation treaties) are specified in §7.

Why. The fingerprints in §2 are the same kind discovered in §7 — they were not anchoring claims (a worker can leave a Tier-1 bank and take their stamps with them is the load-bearing point; the worker’s name and the bank’s name are decoration). Strip-and-genericise gives the same lift J.4 did for §7: no defamation surface, no insider-strategy appearance, no fiduciary-conflict reading.

Scope.

  • §2.1 example list: CBA removed from the Workchain-owner examples; replaced with “a Tier-1 bank”
  • §2.2 example list: CBA banking block and Uber driving block replaced with category labels
  • §2.2 Workers Take Their Stamps Home: Sevda, CBA, Parramatta, the 1,847-block count all replaced with generic-worker / generic-institution language. The story shape is preserved (worker accumulates blocks, leaves employer, takes blocks with them); the proper nouns and the precise count are stripped per the IETF-sparse voice convention
  • §2.3 example: CBA runs its own internal Bean Chain replaced with “a Tier-1 institution runs its own internal Bean Chain”
  • §2 opening: pointer added directing readers to §7 for namespace specification, with a one-line note that this section assumes those mechanics

Risks. The §2.2 “Workers Take Their Stamps Home” subsection currently uses the Sevda vignette as the protocol’s load-bearing illustration of the anti-extractive property. Replacing Sevda with a generic-worker description costs vividness in the spec; the spec gets sparser. Mitigation: the Sevda vignette can move to mythology/ (a future entry, perhaps 02-sevda-takes-her-blocks-home) where it can be vivid without contesting institutional surface area in the spec.

Dependencies. None. §2 update is self-contained and can land independently of any other v0.2 work.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.

J.4 §7 Namespace Cleanup + Worker Sovereignty Rule + Gradient Federation Naming

Proposal. A consolidated update to §7 Namespace & Trust Hierarchy. Three moves bundled:

  1. De-fingerprint §7.4 and §7.5. Strip Brendan’s Wollongong Cars, Uber, Grab, CBA, ANZ, Accenture, and the Australia-leads framing. Replace with generic category language (“a small four-car operator”, “a ride-share platform”, “a Tier-1 bank”, “a nation that writes the standard”). Rationale: the no-institutional-fingerprints discipline applies to incidental institutional references in the spec, not only to the strategy sections. Naming specific platforms also invites legal pushback that the spec does not need.

  2. Add §7.2 Worker Sovereignty in Namespaces. A new subsection under Namespace Types that names the rule already implicit in the open identity utility design but never spelled out: workers do not sit in institutional namespaces. A worker’s identity lives in the open identity tree (sol/earth/identity/<jurisdiction>/<credential>/). Their chain is hosted wherever they choose — primary device, personal backup, optionally an authorised read-replica at an institution they’ve chosen to share with — but the institutional read-replica is constrained scope by the worker, not institutional ownership of the worker’s identity. This closes a confusion that would otherwise leak through every use case in §9.

  3. Enhance §7.5 with Gradient Federation as the named property of Federation Treaty Layer. §7.5 already describes federation by treaty. What it does not name is that this is the post-Westphalian primitive — federation has depth (how foundationally parties bridge) and breadth (which categories are bridged) as independent continuous axes, not a single binary recognition status. Two sovereigns can federate on identity but not on currency. Two sovereigns can federate on identity for some chain types and not others. The named property — Gradient Federation — is what makes peaceful disagreement under the protocol coherent. Points to mythology/01-bismarck for the worked counterfactual.

Why bundle. All three moves touch §7 and would each individually be too small to warrant a separate concerns-log entry. Bundled, they form a single coherent pass on the section.

Why these specifically. (1) is risk reduction discovered during the broader fingerprint audit. (2) makes a load-bearing rule explicit before §9 (use cases) tries to use it. (3) names the post-Westphalian property the spec already partially provides, in a way that lets reviewers attack the naming (does Gradient Federation accurately describe what §7.5 already does?) rather than discovering implicit reasoning section by section.

Risks. Strip-and-genericise lowers concrete vividness in §7.4 and §7.5; the Wollongong Cars and the Uber→Wollongong→driver tax cascade become abstract operator/platform/operator. Mitigation: the concrete vignette can move to mythology/ where it can be more vivid without contesting institutional surface area. (2) and (3) are pure additions; if Yegge or Beane disagree with the worker sovereignty framing or the Gradient Federation naming, the disagreements attack the framing-of-existing-mechanism, not the mechanism itself.

Dependencies. None. §7 update is self-contained. Subsequent work (§2 pointer, §9.5 banks-as-trust-sources rewrite) depends on this landing.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.

J.3 §1.6 Operating Principles as Emergent Sub-Section to the Five Laws

Proposal. Add a new subsection §1.6 “Operating Principles” immediately after §1’s “Why Five and Not Four” close. Names three operating principles plus one corollary that emerge from the Five Laws when applied to trust-flow: P1 Liability-Power Coupling, P2 Payment-Accountability Coupling, P3 No Free Clip, and Corollary 1 — The Consumer of Trust Pays.

Why. The Five Laws describe what the protocol guarantees. The Operating Principles describe how value, liability, and accountability flow through the primitives. §6 (economic mechanics), §7 (namespace trust), and §9 (use cases) already operate under these principles implicitly; naming them gives subsequent sections an explicit referent and gives reviewers a clean place to attack the inference chain itself.

Why emergent, not axiomatic. P1 emerges from Law 1 Neutrality + Law 4 Privacy in the trust-flow direction: if the subject owns the data and the protocol takes no side, then liability for trust must sit with whoever signs the attestation, not the subject. P2 emerges from P1 + ordinary market logic: if you absorb risk, you charge for it. P3 emerges from Law 5 Forking + P1+P2: if accountability is non-extractable and exit is always available, any non-accountable intermediary is structurally undercuttable. Corollary 1 emerges from P1+P2 once Law 4 is applied: the subject isn’t the one absorbing trust risk, so the subject is also not the one paying for it.

Risks specific to Corollary 1. This is the most contestable claim in the stack. The current world makes subjects pay (KYC fees, ID-verification subscriptions, “premium account” tiers). Naming Corollary 1 invites pushback from anyone with a stake in the current arrangement — which is the desired surface, because it forces engagement with the whose-pocket question that current credential systems obscure.

Risks broadly. Promoting principles from emergent to named creates the impression of new axioms. Mitigation: the section’s framing explicitly says these are observed-emergent, not axiomatic, and the close explains the cost/benefit. If Yegge or Beane disagree with the inference chain from Laws → Principles, the disagreement attacks the inference, not the spec primitives.

Dependencies. None. §1.6 is self-contained; later sections will reference it but the section itself does not depend on other v0.2 work.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.

J.2 §7.5 Gradient Federation as a Named Primitive

Proposal. Add a new subsection §7.5 “Gradient Federation” between §7 Namespace Trust and §8 Implementation Substrate. Names the post-Westphalian peaceful-coexistence mechanism as a first-class protocol primitive rather than leaving it as an emergent property of “everything is a Workchain.”

The primitive. Westphalian sovereignty (1648) makes recognition binary on two axes: sovereign A either acknowledges sovereign B’s authority over a territory, or doesn’t; the federation is either fully political or it isn’t. Gradient Federation makes recognition continuous on both axes. Depth: how foundationally two parties bridge (currency interop, identity attestation, work-block portability, contract enforcement) is set per-bridge, not all-or-nothing. Breadth: which categories are bridged is selected independently — two sovereigns can federate on identity but not on currency, or on identity for some chain-types but not others. Federation is the set of narrow trust-floor treaties the parties choose to share at the floor, not a status they grant each other.

Why a named primitive. Without explicit naming, the post-Westphalian capability is easy for readers to miss — it reads as “we use Workchains and treaties” without registering that the protocol’s deepest political move is the gradient. Naming it forces engagement and gives it a referent in subsequent sections.

Worked example. The Bismarck counterfactual (mythology/01-bismarck.md) plays the 1834→1871 German unification arc as if HOP existed: each state stands up a Workchain anchor; portable Skillchains carry worker mobility across jurisdictions; railways are Utility Workchains under each state’s namespace; trust-floor federation treaties bridge narrow technical categories (track-gauge, railway credentials, freight-manifest format) without political integration. The claim: HOP would have enabled the outcome of unification — cross-state mobility, common standards, economic integration — without the costs — Bismarck’s three wars, the sovereignty extinction at Versailles in 1871, the seeded conditions for 1914.

Risks. Bismarck is a politically loaded figure. The counterfactual is contestable. Both risks are managed by housing the worked example in mythology/, not in the spec itself. The §7.5 spec text is terse and points to the mythology entry for the worked reading.

Dependencies. J.1 (mythology layer) must land first so §7.5 can point at mythology/01-bismarck.md.

Proposed by Brendan via working session 2026-05-29. Awaits ratification by Yegge and Beane.