This document is non-normative. It explains why the Murmur specification is shaped the way it is: the motivating vision, the design principles, the reasoning behind the contract model's less obvious decisions, the relationship to neighbouring systems, and the demonstration roadmap. Where this document and the specification appear to disagree, the specification wins.
Readers new to the project should start with the README, which explains the idea in plain language. This primer sits between the two: it assumes the README's framing and supplies the rationale the specification deliberately keeps out of its own way.
- The names
- The grandfather's axe
- Design principles
- Why discovery and authority are split
- Why attestation and exclusion are coupled
- Why there is no consortium
- The incentive engine, applied
- A worked quorum: settlement over ephemeral nodes
- The threat model: abandonment, obsolescence, poison
- Canarying without a coordinator
- Why declared failure semantics are the core
- Lessons borrowed from elsewhere
- The witness
- The ladder
- The datacenter case
- A second witness: pure software
- How to read the specification
- Murmuration is the system: the emergent whole that no node coordinates.
- Murmur is the protocol: the local rules each node speaks to its neighbours.
murmurdis the reference daemon that speaks Murmur.
The names are load-bearing, not decorative. A starling murmuration is the canonical case of global coherence arising from purely local rules with no central coordinator, and that is the architecture's central claim. Wherever someone is tempted to add a coordinator-of-the-whole, the name itself should push back.
The lineage is MANET (mobile ad-hoc networking) and swarm robotics: no infrastructure, dynamic membership, route around partition, no required central ground. That posture is inherited deliberately. What is not inherited is MANET routing: Murmur is a contract, identity, and authority layer above whatever moves bytes, not a multi-hop routing protocol. A transport underneath it may itself be a mesh; Murmur is not in that business.
The reference implementation follows a per-language naming convention (specification, question 10, resolved): murmur-rs first, then murmur-go, murmur-haskell, and so on, so that no single implementation wears the protocol's bare name. The daemon binary stays murmurd, the shared library is murmur-core, and the relay is murmur-bridge. The bare token murmur is deliberately kept off the command line. It carries a residual association with Mumble's VoIP server (historically named "Murmur"), and that echo would surface only where a binary name travels context-free. The per-language repos and prefixed artifacts avoid putting it there.
The success criterion for the whole design is the grandfather's axe: an axe that has had three new heads and four new handles is the same axe. A system should retain its identity and keep functioning across the complete replacement, several times over, of every physical component, with no single part, and no absent vendor, load-bearing for its continued life. Concretely: a home battery, inverter, and grid connection still working in two decades, having outlived three generations of swapped hardware and possibly every company that made any of it.
This is the murmuration in the name: the flock persists while every starling in it is replaced. Everything in the specification, and the whole of its resilience apparatus, serves this. Even authority is treated as a replaceable component: the mechanism that lets a dying vendor hand its attestation authority to a community is the axe applied to trust itself.
The promise is to the owner (continuity), not against the manufacturer. Friction with replacement-dependent business models is a side effect of keeping the promise, never its purpose. A good manufacturer can sell on this ("interoperates and stays alive for thirty years, even if we are gone"); only a business model that depends on the opposite of longevity will route around it, and that is its choice to make, visibly.
A mechanism that can only be understood, repaired, or reimplemented by its original author is already abandoned. The classic-car lesson: a carburettor, a vacuum-advance, a washer-bottle squirt pump last fifty years because they are legible. A competent stranger can inspect them, understand them, and repair them with ordinary tools; there is no hidden dependency, no phone-home, and degradation is gradual and diagnosable.
The honest counterweight, with no romanticism: legibility trades against capability. Fuel injection genuinely beats a carburettor on efficiency, emissions, and cold-start, so simplicity alone loses. The point is that legibility and serviceability form a first-class design axis that capability-optimization systematically under-weights. The axe requires weighing it explicitly: prefer the simplest mechanism that meets the requirement, and treat "could a competent stranger reimplement this from the specification alone, twenty years from now" as a requirement rather than a nicety.
This is a live tension in the specification itself. The model has accreted real sophistication, and each clever mechanism is a future black box unless kept legible. The open specification and the reference daemon are necessary but not sufficient; the specification must also stay simple enough to reimplement. Its eventual narrowing pass must apply a legibility budget, not only a feature ceiling (open question 21).
Murmur is to its products what a core banking ledger is to a bank: a commoditized middle that specifies how value moves and verifies that it moved, knowing nothing of branches, apps, or brands. The protocol normatively specifies the contract and its verification, plus the requirement that such state be inspectable. The product (a manufacturer's app, a fleet console, a cross-domain key wallet) owns everything else: onboarding, key custody, recovery, support, brand. Products compete on experience; the protocol does not specify it. Custody is the product's to provide; whether custody quietly becomes permanent capture is the protocol's to expose.
The analogy has a stated limit: it holds for build-versus-specify, not for trust topology. A bank is a trusted central custodian; Murmur is local-first and anti-central-party, so the "bank" here is one of many competing vendors, each subject to owner sovereignty and the protocol's legibility, never a trusted middle holding everyone's assets. Borrow the layering, not the centralization.
Drivetrain motion control and grid anti-islanding must not depend on a cloud round trip. Resilience and safety are derived from local reasoning plus declared safe defaults, never from the reachability of a central authority. This is also, structurally, the anti-obsolescence stance: a system with no required centre has no centre to switch off.
Two needs with opposite requirements must not share one mechanism. A mechanism tuned for one is wrong for the other, and sharing it couples two things that should be free to fail and change independently. Live events want low latency and tolerate loss, while identity and configuration want reliability and tolerate delay, so they run as two planes with no shared machinery (specification, Section 5). The same cut recurs throughout: discovered feature against granted authority (the split below), the operational record against the forensic one, the artifact a human writes against the bytes a machine verifies, and a principal's continuity against its authorization. Each reads as a separate rule and is one law, named in the specification as the separation law (Section 1). Most of the model's "must not collapse these" requirements are that single principle applied to a new pair.
The model is defined at its general shape, and the simple case is recovered as a limit of it, never the other way round. A slot is a topic with one steward and one binding, a lone node is a virtual principal with one member, and the witness's single steward is exclusive failover at a population of one. Defining the simple case as the base would bake its assumptions (one owner, one failure root, one key) into everything above it, and each would have to be torn out when a second participant arrived. Defined as a limit instead, the simple case exercises the real mechanism with the contended parts dormant. The witness is then the abstraction running at population one, not a special path that later needs replacing (specification, Section 1, the degenerate-case law). It is also the strongest evidence the abstraction is real: the day a second contender appears, the same code produces a higher fencing term and refuses the stale actor, with nothing new written.
Nodes interact with the physical world through channels Murmur neither owns nor mediates: a speaker and a microphone, heat and a thermal sensor, voltage on a shared bus. Emergent coordination through those channels is legitimate and expected. Applause is the canonical human example: a wave of synchronized clapping ripples through an audience with no conductor, through a channel nobody administers. The protocol does not try to bring such coordination inside. Doing so is impossible (nodes cannot be stopped from sensing each other physically) and would violate the legibility budget.
At the edge of its own authority, the protocol's role is to witness, not control: to record that something happened where it cannot or should not mediate how. A protocol that claims total control is either lying or tyrannical; one that knows the limit of its authority and chooses accountability at that limit can be trusted. The same posture governs the physical override (below): cede control of what the protocol cannot legitimately own; retain an honest record of it.
This is the protocol's deepest scope boundary, stated once. Murmur bounds consequences and attributes actions, and it never evaluates correctness. The stance is borrowed from functional safety, not invented here. ISO 26262 and IEC 61508 do not try to prove a controller correct, because for a complex system that is in general undecidable. They assume it will fail, and they architect so the failure is survivable whatever its cause. The relief valve, the watchdog, and the independent monitor that trips to a safe state without trusting the main controller each bound the worst case rather than verify the command. The emergency stop does not ask whether a command was poison or legitimate. It makes that distinction irrelevant by making any command's worst case survivable.
Murmur's declared safe state is the same move. It was never checking whether a torque command was right. It ensures that on a dropped link or a wrong command the wheel reaches a bounded state. So the protocol has been consistent across every domain: identity, authority, provenance, and consequence-bounding, never correctness. The physical examples hid this, because the actuator floor was so natural there that bounding looked like safety and safety looked like a correctness check.
Strip the physics away and the boundary becomes visible. In pure software there is no actuator floor. A distributed version-control ecosystem, a fleet of collaborating agents, and payments between devices all share this: consequences cannot be made moot by a physical limit, and correctness cannot be deferred to physics. The bounding that remains is weaker, made of reversibility, trust-tiered gating, and tamper-evident provenance. This is exactly why software correctness still needs review, tests, or proof. Those are the external authority the protocol can require but never replace. A distributed version-control system built on Murmur is the clearest case. It governs who may contribute what: cryptographic identity, revocable capability-scoped authority, and tamper-evident provenance of every agent's contribution. It cannot certify that the code is right. That stays with review, tests, and proof, which the trust tier can require and the protocol can witness.
That external authority is the unifying object. A test suite, a ledger, a safety monitor, a human reviewer, and the physical floor are one thing seen in different domains: the pluggable authority a capability defers to before it acts. The protocol carries the requirement ("X must assent before this acts"), enforces that the assent was given and recorded, and bounds the outcome when it is absent. It does not, and cannot, know what X checks or whether X was right. The test can be inadequate, the ledger compromised, the monitor miscalibrated. The protocol attests that the gate was satisfied, never that the gate's judgement was sound.
This is why a universal or pluggable test of correctness is rejected rather than deferred. A universal one is forbidden by Rice's theorem, the same wall as the halting problem. A pluggable one, looked at closely, is not a correctness check at all. It is the stake-scaled authority ladder (specification, Section 4.2) under a more honest name. Calling it correctness would re-import the claim the whole design refuses, that the protocol knows something it cannot. The honest version is already in the specification.
The boundary above says what the protocol does not do: it constrains declared and attested claims, never real-world effects. The constructive corollary says what the design must therefore do. A requirement the protocol cannot verify is not a requirement, it is a wish, so wherever such a property is wanted, the design re-architects until it no longer depends on it.
Device identity is the worked example. The specification once leaned on on-device key generation to stop a manufacturer holding a device's key, and on per-device attestation to name a unique part. Neither is attestable: on-die generation is a manufacturing fact no signature reveals, a key is copyable information, and the industry's own per-device attestation is often deliberately non-unique (FIDO's basic attestation shares one attestation key across a whole batch of authenticators, precisely so an individual device cannot be fingerprinted). So uniqueness was dropped as a requirement, and the property actually wanted turned out not to need it. Bounded, owner-controlled authority lives in a key-bound grant the owner issues and can expire, not in the uniqueness of the part. A cloned key buys impersonation, never authority, and the residue, anti-counterfeit, is handed honestly to the secure-element regime and to deployment-time witness, neither of which the protocol pretends to provide.
The rule generalizes. Any design step of the form "and then the part generates or guarantees a unique X" should be read as a wish until something attestable backs it, and re-architected until the wish is not load-bearing.
What can back such a claim is itself a short, specific list, and naming it turns the rule from a caution into a checklist. The protocol attests a handful of things.
- Authorship. Who signed a given artifact.
- Integrity. That a set of bytes is the artifact its content address names. This holds even for an unsigned definition referenced by hash from a signed grant.
- Delivery. What was sent and acknowledged.
- Freshness. What is live rather than stale, by the liveness machinery.
- Relational legality. That a claim is consistent with a declared relation, such as one fencing term outranking another, or a transition being legal in a declared graph.
It attests nothing else. Not physical state, not sensor truth, not implementation correctness, not another principal's honesty. One boundary inside the list is easy to lose. Relational legality attests that an action is consistent with a declared relation, never that a resource honoured the relation in the world. That compliance is the resource's own claim, witnessed and backstopped by the physical floor (below), never protocol-verified. The list is the attestable surface as currently understood, not a closed proof, so a sixth kind may yet earn its place. A design sentence of the form "the protocol ensures X" is sound only when X reduces to these few claims, and is a wish wearing a guarantee's clothes otherwise.
Most of the specification's seemingly separate decisions are one thing: an engine that makes the selfish choice and the social good inseparable, rather than enforcing virtue. The mechanism is a single stance: the burden falls on the party that gains the most from a decision.
Anti-social behaviour in connected systems is almost always externalization: capturing a benefit while pushing the cost onto someone else. Lock-in externalizes the cost of replacement onto the owner; abandonment externalizes orphaning onto the owner; a consortium externalizes the cost of exclusion onto everyone outside it. The engine re-internalizes those costs onto whoever captures the benefit. Once a party can no longer externalize, its own selfish optimization must account for the cost it would otherwise dump on others, and selfish and social converge. Worked instances: the party that wants exclusion must build theft-resistance and bears the abandonment liability; the owner who gains autonomy bears the trust decision; the steward who owns the contract owns the safe state.
Two disciplines keep this from curdling into its opposite:
- Alignment, not enforcement. The protocol couples selfish to social and makes harm legible; it never compels virtue. Enforcing "good" behaviour re-imports the central arbiter and the unoverridable constraint the rest of the design refuses. Make the good path the path of least resistance; make the harmful path visible; let external consequence (market, regulation, forking) act. The protocol accounts; it does not adjudicate.
- Align only around structural, near-universal goods: theft-resistance, longevity, honest accounting, interoperability. For contested values, the protocol witnesses and makes legible, and lets owners and the outside world judge. A protocol that encodes contested values is an arbiter, which is the tyranny failure mode.
A caveat in the same spirit: "the party that gains most" is not always measurable, and deciding it can itself become contested. The principle is a design heuristic for the specification's authors; where the protocol cannot know who gains most, it falls back to legibility. Record, don't adjudicate.
Every mechanism in the specification (signatures, fencing, canaries, behavioural envelopes) raises the cost of casual, remote, and accidental failure, and every one is circumventable by a sufficiently capable, physically present actor. This is intended. An unbreakable constraint with ill-conceived parameters is its own catastrophe; it must always remain possible to turn Skynet off. So no software layer is the final safety authority. The stack terminates not in an ever-smarter check but in a dumb, physical, out-of-band override (an emergency stop, a manual disconnect, a fuse) that makes no decisions and therefore cannot be tricked into the wrong one, that the protocol neither mediates nor can disable, and that a physically present authorized actor can always reach. The emergency stop cannot be poisoned precisely because it verifies nothing.
The physical override is the strongest instance of a more general rule: the final authority lives in a layer the protocol cannot reach. The second witness (below) shows the rule's software-only form.
The asymmetry is the safety property: a remote attack faces the full smart stack; physical presence can always override. A system that fights its own emergency stop has missed the point, so the protocol is designed to detect a legitimate override, yield to it gracefully, and log it, rather than resist it as an attack.
The split between discovered feature-capability and granted authority resolves a real tension. On one side, the upgrade story: adding a fourth motor module to a vehicle, or a new battery to a home system, should be "no software update, just discovery". On the other, safety during failure: nothing discovered should be able to walk into a certified control loop. The resolution: discovering the fourth motor is free; admitting it into the motion-control loop is a deliberate, non-discoverable, verifiable act. Hazard analysis attaches to the slot and its required interface, fixed at design time, so the identity filling the slot can change at runtime without reopening the safety case. Discovery proposes; binding disposes.
The reason ambient (presence-based) authority is named, ranked lowest, and distrusted by default is that it is the model systems fall into accidentally, and it fails catastrophically in the physical world. A car that trusts its internal bus because physical access is the entitlement means that smashing a window, plugging into the diagnostic port, and enrolling a new key is the system working as designed: presence was the grant, the thief obtained presence, the thief is "authorized". The networked version is the breached perimeter; the pre-zero-trust VPN failure. Presence may contribute evidence; it must never be the decision.
Ambient authority is legitimately sufficient only when two factors are both high: the difficulty of illegitimate presence, and the lowness of the stake. Applause qualifies: it is hard to fake being in the auditorium, and a wrongful clapper costs nothing. A car's diagnostic port fails the first factor; commanding torque fails the second.
One subtlety repays attention: the protocol constrains on declared and attested claims, never on real-world effects. A rule like "ambient authority may not command an actuator" sounds right and is unenforceable, because in an open-interface world the protocol cannot know what a capability does physically; an actuator driver can declare itself a status reporter. So the guard is placed where it can hold: ambient authority is valid only for capabilities declared and attested lowest-stake, and high-stake authority requires attestation to act. Under-claiming becomes self-defeating: declare low stake to dodge attestation and that capability genuinely gets only low-stake authority, so the high-stake action stays unreachable.
Attestation (a manufacturer's ability to require that parts prove themselves) and exclusion (its ability to refuse third-party parts) are two ends of one lever, and the specification makes them inseparable on purpose. To exclude a part by attestation, a system must cryptographically bind every part to an identity and reject parts that cannot prove themselves. That same binding is theft-resistance: a stolen or swapped part cannot attest into a system it was never enrolled in, so the smash-window-and-enrol attack stops working.
The framing is incentive, not finger-wagging. A manufacturer who insists on locking down is thereby required to deliver the socially good thing (hard-to-steal products) it otherwise has little incentive to build. A manufacturer who skips attestation forfeits in-protocol exclusion, and the aftermarket is open by default. The lazy path is the open path; the locked-down path is the secure path. What the coupling forbids is only the contradictory both-at-once that is today's default abuse: excluding competitors without securing the product. Every coherent position remains available, and every one is acceptable.
The obvious governance model for "who may attest" is a consortium that lists blessed attesters. It is rejected outright, because it is the single centralization the whole architecture exists to avoid: the coordinator, the capturable point, and the party that orphans devices on its schedule rather than the owner's. It is also precisely why existing smart-home ecosystems cannot do the grandfather's axe: when the consortium or its cloud is gone, so is the device's standing.
In its place: anyone can attest, and anyone can require attestation. "I accept attestations from X" is a local, owner-held edge, not a global registry entry, so there is no central list to capture, by construction. Trust is a relationship, not a registry.
The headline consequence is that trust authority itself transfers by attested update. A bankrupt vendor's last act (or a court's, or a successor's) can attest a transfer of attestation authority to a community, and devices that trusted the vendor now trust the community by the same mechanism that always governed them. No special abandonment mode, no consortium re-listing. No consortium model can express "the manufacturer is dead, long live the community" without a central blessing; this can, because succession is an ordinary attested edge-rewrite.
The cost is named honestly: owner sovereignty relocates the attack surface onto the owner, who is socially engineerable in ways a defended chokepoint is not (the fake successor community after a bankruptcy; "install our helper to keep your device working"). The mitigations are mitigations, not cures: re-rooting trust must be conspicuous, reversible, and forensically logged, never silent; and the behavioural floor bounds what even a maliciously trusted attester can do at the actuator. The floor is what makes owner sovereignty safe against the owner's own mistakes, the same role it plays against poisoned updates.
Three worked mechanisms show the engine doing its job:
- Graceful exit as the path of least resistance. Abandonment is the default today because disappearing is the cheapest act available to a dying company; graceful handoff costs effort nobody is incentivized to spend. The fix is to make attested transfer of trust authority a one-action, default, well-trodden end-of-life path, genuinely easier than switching off the servers. Then the lazy choice at wind-down is the responsible one. Nobody is forced to be a good citizen at death; good citizenship is simply made the route of least resistance. This is the mechanism that most directly delivers the axe: devices outlive vendors because the cheapest way to die is to hand off. Whether handoff can actually be made cheaper than disappearing is open question 24, and it is the one the incentive story stands or falls on.
- Witness becomes settlement. In shared-resource domains, money already flows for the social good: parties are paid to shed load, share capacity, and stabilize the grid. The forensic plane is already the accounting substrate: a tamper-evident, per-party-signed, owner-held record of who contributed what, when. That turns the witness into a settlement layer without the protocol becoming a market; the record is carried in-protocol, and the payment lives outside, on top. The selfish reason (getting paid) and the social good (grid stability) become inseparable byproducts of the same record.
- Participation hardens the commons. Every honest node adds attesters to cross-check, implementation diversity, and peers to quorum against. Named as a property, not leaned on as an incentive: positive externalities are under-provided precisely because the individual does not capture the collective benefit.
And two named traps the design refuses to build:
- Reputation as a gate. Owner-held attestation plus the forensic record make verifiable track records possible, but a required or central reputation score re-monopolizes (incumbents accrue reputation new entrants cannot), invites gaming, and rebuilds the consortium by the back door. Reputation is admissible only as one owner-evaluable signal among many, never a gate.
- The morality engine. Aligning around contested values turns the protocol into an arbiter. The line is held: align around structural, near-universal goods; witness everything contested.
A settlement transfer is the clearest illustration of the attestation model (specification, Section 4.8), because it stresses every part of it at once. A transfer needs two assents, the sending institution and the receiving one. That is a two-of-two quorum with non-interchangeable roles, the named-few end of the membership spectrum. A public blockchain is the same gate at the open, sybil-resistant end, where the members are anonymous and work or stake is what keeps the set from being faked.
The institutions are the members, not the machines. A bank is a durable principal and holds a seat, while the node that actually signs may be one of hundreds of ephemeral pods that restart and take a fresh identity each time. The pods are not in the quorum. Each carries a short-lived delegation from its institution's key, so a vanished pod's authority simply lapses and the bank delegates afresh, with no change to the quorum contract. A quorum of stable principals runs, unchanged, over a churning fleet beneath it. This is the grandfather's axe applied to a quorum member, and it is the concrete shape of settlement without a central clearing house (open question 25): the seats are stewarded, and the steward of who-is-in can itself sit off the data path.
The gate is assent, not outcome, and that distinction is where real systems live. A sender short of funds declines, and the refusal is not silence to be timed out but a signed negative that travels back and unstages whatever the other side had prepared. Even two assents settle nothing on their own, because agreement that a transfer should happen is not the durable fact that it did. Finality is a write to the ledger the protocol defers to, and a lost confirmation is resolved by reading that ledger, never by re-running the quorum. The protocol carries the requirements, witnesses the record, and yields the truth of the balance to the source of truth, exactly as it yields physical safety to the actuator floor.
The teeth in this gate come from conservation, not from the quorum alone. A transfer moves a conserved quantity, so every credit is someone's debit. The party on the losing side is present, and motivated to refuse a false assent, and that adverse signer is what makes the attestation worth trusting. Run the same quorum machinery over a quantity that is not conserved, a reputation or a cooperation score, and the teeth are gone. Nobody is out of pocket when the number is inflated, so a colluding ring can mint it for nothing. The parties it harms are whoever later trusts the score, and they are not present to object. The protocol can still carry such a counter and make it legible. It cannot make it true. This is the deeper reason reputation is never a gate, named among the traps above, and the reason settlement stays scoped to conserved-value domains. Conservation is what supplies the adverse counterparty. Without one, a signed number is a claim, not a fact.
Three longevity threats, deliberately kept distinct because their defences are different, and a design that conflates them handles none:
- Abandonment is passive: the maker stops, nobody obstructs, the device orphans and bit-rots. The defence is openness. The definition commons outlives any vendor; content-addressed, signed definitions keep verifying with no origin server alive; and the open specification plus the open reference daemon are the ultimate abandonment insurance, because an openly specified protocol can always be continued. Proprietary undocumented protocols are what truly kill orphaned devices.
- Obsolescence is adversarial and external: the maker deliberately engineers the device to stop, often weaponizing the very trust machinery (signed-firmware locks, attestation, cloud kill-switches) that protects against malware. The defence is owner sovereignty: the owner, not the manufacturer, is the ultimate root of trust for their own device, trust anchors are owner-re-rootable, and there is no vendor-only revocation of the owner's own grants. Local-first forecloses the most popular obsolescence lever structurally.
- Poison is adversarial and inside the trust boundary: a validly signed, correctly versioned update that is malicious or bricking, from a compromised or coerced publisher. Verification is defenceless here by construction; it checks provenance, not intent, and a correctly signed lie is still correctly signed. So poison is contained and recovered from, never prevented: canaried activation with automatic halt catches poison at the canary, because poison and incompetence fail the same way there; reversibility survives it; implementation diversity reduces the monoculture blast radius. Recovery has a ladder as well as a reflex. The automatic halt is followed, where needed, by a steward's hold on its topic, an owner's signed reversal across their domain (apply has an unapply, and the owner holds the lever too), and finally revocation of the compromised publisher's authority, by the same attested-transfer machinery that survives a dead vendor.
Seen together, the three threats are one observation made three times: the update path is where longevity is won or lost. Abandonment is the update path going dark; obsolescence is the update path weaponized against the owner; poison is the update path betrayed from inside its own trust boundary. A protocol that promises decades therefore cannot treat update dissemination as vendor plumbing. It is the load-bearing mechanism behind the trust back-stop: the core fixes the coupling to failure semantics (specification, Section 7.2), and the dissemination machinery is the updates extension. The rule that carries the design: there is no separate rollout-safety subsystem. An update that cannot be verified or completed leaves the device in its declared safe state; a breaking change is a semantic disconnection, handled by the same machinery as a dropped link; activation is canaried with automatic halt and keeps the old definition hot, so apply has an unapply. The failure core is not adjacent to the update story; it is what makes the update story safe. The genuinely hard mechanics stay open and visible (open questions 14 to 17): the compatibility relation, delivery to constrained devices, canarying without a coordinator, and updates with physically irreversible effects.
All three defences feed the axe. They are not threat-defence for its own sake; they are how a system keeps its identity and keeps working across total component churn, with no part and no vendor load-bearing for its life.
Canarying an update means a few devices run the new definition first, everyone watches what happens to them, and the rest follow only when nothing goes wrong. The specification appears to demand a contradiction here: activation must be gradual and canaried with automatic halt (the updates extension), yet the central rollout coordinator that conventionally arranges all of this is forbidden (the same extension). The contradiction dissolves the way it does everywhere else in the design that a coordinator is missing: the canary stops being a group somebody selects and becomes a set of rules each node applies to itself. The shape under consideration (specification, open question 16, where the mechanics live):
- Wave membership is derived, not commanded. No server tells a node when its turn comes. The publisher signs a staging plan into the update artifact itself, and each node computes its own place in the rollout from that plan plus facts it already holds: its own identity and the update's content hash. The schedule therefore travels with the update, and nothing central exists to consult. A wave is an ordering, not a timetable: it grants permission to be early, and later waves do not advance on elapsed time alone (two bullets below). The computation is deliberately repeatable rather than a private dice-roll, because after an incident "was this node entitled to activate early" must be checkable by anyone. Genuine randomness keeps one job: a small random delay within each wave, so that a well-connected fleet does not act in perfect lockstep. A thousand inverters tripping at once is a grid event, and the same arithmetic applies to a thousand inverters activating at once.
- Health is inferred from silence; only distress is broadcast. Good news is easy to fake and bad news is hard to fake, so only bad news is sent. A compromised publisher could flood the network with forged "all healthy" reports, which is why health is never asserted positively. A distress report runs the other way: "I activated this definition and my safe state fired" is signed by the node it happened to, and it travels exactly like the signed revocations the trust model already requires. The victim does not need to survive to be heard. An update that kills its canary outright also kills the witness, but the canary's steward (the owner of the contract it was bound into) is already watching its liveness. The steward sees the death as an ordinary stale binding and signs the distress on the victim's behalf. Bad news also travels fastest: distress and revocations move at higher priority than updates on the same paths, so a poisoned update racing outward is chased, and overtaken, by the alarm it raised.
- Only live silence counts. Everywhere else in the design, silence means failure: the heartbeat is a dead-man's switch, and a severed link fails safe. Health-by-silence points the other way (silence means go), which is only sound if "I heard nothing" can be told apart from "nothing could reach me". Heartbeats alone cannot tell them apart. A heartbeat confirms a node's own links, while a distress report may need to cross the whole network from a victim several hops away, and healthy connections to the neighbours say nothing about that longer route. So observers periodically sign brief, quickly expiring statements saying "nothing bad seen so far for this definition"; stewards do this for their topics, early activators for themselves. A waiting node counts only this fresh, attested silence. An attacker can suppress the bad news, but cannot forge the continuing stream of fresh all-clear statements. Suppression therefore shows up as the all-clears going stale, and the node holds. This is the standard defence against the freeze attack (being pinned, unknowingly, to old information), the job TUF's short-expiry timestamp role exists to do, recurring one layer up.
- An empty all-clear is no all-clear. Wave membership orders activation; it must not be conflated with arrival. If dissemination is slow, an update may reach a later-wave node before any earlier-wave node has actually run it, and the silence that follows is vacuous: a population that never activated attests nothing. So the all-clear statements carry exposure as well as quiet ("N of my bound providers run this definition, with no distress"), and a later wave activates only behind attested evidence that an earlier wave genuinely went first, where one exists. Exposure claims are policed by the same relevance test as distress, so a publisher cannot conjure a phantom canary population to hurry the fleet. And where no earlier wave exists at all, the node knows it is first: a deliberate canary, never an accidental one, governed by the evidence-bar rules below. The converse also holds: a hold is a bet that information will arrive, never a virtue in itself. A lone node whose configuration has no peers would wait forever for exposure that cannot exist, so it does not wait for it. It weighs the evidence that can actually reach it (partial exposure from related configurations, the evidence carried with the artifact, its own rehearsals) against its stake bar, and decides. Delay that cannot name the information it is waiting for is not caution; it is theatre.
- The partition case is already handled. A node whose all-clear evidence goes stale before its window closes cannot confirm the fleet's health, so it does not activate; it stays on the old definition, which is operationally safe by construction: the safety case the device shipped with still holds, and staying put creates no new hazard. It is not indefinitely secure once a remedial fix against a named defect exists, but that axis is carried by the bounded remedial hold, below. The asymmetry is what makes the decentralized version sound: failing to learn "it is safe" merely delays an upgrade. In a total loss of connectivity, the scheme degrades to every node being its own canary, with reversibility as the backstop. That is exactly what the updates extension's per-node machinery already provides.
- The isolated system is the permanent partition, acknowledged rather than solved. A vehicle with no broader connectivity, updated from a thumb drive, is a canary population of one, forever: every such system meets a bad definition fresh, fails alone, and its distress reaches no one in gossip range to hear it. Some of the discipline still works. Evidence can travel the same sneakernet as the artifact (the network whose transport is a person carrying the stick): the stick carries the fleet's accumulated signed evidence alongside the bytes, and verification is byte-identical from a USB stick by design. The isolated system then activates on that learning, frozen at the moment of export. Accepting the staleness is the explicit price of isolation, and it is an owner decision rather than a silent default. The system's own canary discipline still applies internally: its components take their turns ordered by how much harm each can do, rehearse where rehearsal is safe, and can always roll back. And distress is still written to the local forensic log, so the return path of the next physical round-trip (a service visit, the same stick) carries the screams out late rather than never. The honest residue: a system that never reconnects never reports, and fleet learning keeps a permanent shadow in the shape of its isolated members.
- The halt domain is the contract graph, not the network graph. When an update must be stopped, the boundary that matters is the set of devices sharing a physical consequence (one vehicle, one site, one grid segment), and the model already has a name for that boundary: the steward's topic. A steward that watches one of its bound providers trip after activating can sign a hold for that definition across its own topic. The steward is the natural watcher (it already monitors the liveness of its bindings, and it is the party that tolerates a range of versions), and its topic is the natural blast radius.
- Stake sets the evidence bar, not the queue. Sending low-stake capabilities first (the keyboard canaries for the substation) is a proxy for the real rule: a node activates only behind accumulated evidence proportional to its declared stake, the harm its failure can do. The proxy fails in two ways. In a fleet where everything is high-stake, every node deferring still produces a first activator: whoever's bounded hold expires first. Only now it is unchosen, unobserved, and the rest of the fleet's windows expire close behind it. Deferral does not remove the first activation; it removes the observation of it. And a population canary is only as informative as it is representative: a bespoke component, or a one-of-a-kind combination of component versions in a fleet where versions are always mixed, has no lower-stake stand-in anywhere, however large the fleet. Someone is always the canary; the only design freedom is whether it is deliberate.
- Where the cheap evidence is missing, other kinds fill the bar. Three substitutes exist. The first is shadow activation: the new definition runs on live inputs, but its outputs are fenced away from the actuator. It computes, it is compared with the running version, and it controls nothing. Any divergence is reported exactly like distress. This is safe because fencing already separates computing from the authority to act. It is also honestly weak, because some failures only appear when the new code is really in control; a rehearsal is not a performance. The second is publisher-funded evidence: the publisher proves the update on test rigs built to resemble the field, on hardware-in-the-loop benches, or on a paid canary fleet, and the signed results travel with the update. That burden lands on the publisher deliberately. The party that gains from a rollout pays for its proof. The third is offline qualification: certified domains will never trial fixes on the live system, and should not, so their evidence is an attestation that the update passed qualification elsewhere. The protocol witnesses what evidence preceded activation. It does not mandate a rollout style. "Demonstrated on a keyboard, sized for a substation" keeps its operational meaning, but only for the code paths the keyboard and the substation share.
- "Too important to canary" is therefore self-defeating, legibly. The specification already makes under-claiming stake self-defeating (declare low stake, receive only low-stake authority); declaring exemption from canarying is the symmetric over-claim and gets the same treatment. Exemption from contributing evidence is exemption from having it. "Activated on zero accumulated evidence" becomes a recorded, attestable fact on the forensic plane, and that is the kind of fact markets, insurers, and regulators price. The fleet that always activates last also holds the known-vulnerable old version longest. The protocol accounts, it does not adjudicate: it cannot force a manufacturer to canary, but it makes "blindly too important" legible as "unevidenced".
The honest tension is stated rather than resolved. A distress hold is a freeze-attack surface: whoever can forge credible distress, or manufacture it from a crowd of fake identities (a sybil attack), can delay a security fix fleet-wide. So distress must count only from identities that can demonstrate relevance: a current or recent binding for the capability, or a steward's countersignature. Even then, the contain-the-poison and ship-the-fix forces pull in opposite directions, and the balance must be struck per stake tier, never globally. The publisher-signed schedule has the dual problem: a malicious publisher writes "everyone at once, no window", so minimum canary discipline is device-side and steward-side policy with a stake-tier floor, never publisher courtesy. The incentive engine applies here as everywhere: a publisher who wants a faster rollout bears the burden of earning it with evidence from the early population.
The same two-sidedness governs how long a node may hold. "Stay on the old version" is safe on only one axis. Operationally, it is safe by construction: the shipped safety case still holds, and a failed or unverifiable application falling back to it can never create a new hazard. Adversarially, it decays: once a publisher declares an update remedial against a named defect, exposure accumulates with time, and the hold becomes a slowly worsening position rather than a resting state. So updates split into two declared classes. A routine update may be held forever; the wavefront never finishing is the designed-for steady state. A remedial update starts a clock. The remedial claim is gameable only in the legible direction, because declaring urgency raises the publisher's evidence burden: the rush attack (every update an urgent fix, activate now) is the freeze attack's dual, and both are claims to be witnessed, not trusted. When a remedial hold expires un-applied, the escalation is scoped to the capability, never the system. The affected capability sheds high-stake authority first and function last, toward its own declared safe state, while the rest of the system continues. A tractor is not bricked because its charging cable could not take a fix; the blast radius of a stuck update is the capability it is stuck on.
Survey the neighbouring systems and a pattern appears. Transport and publish-subscribe are well served (Zenoh, DDS). Identity is well served (SPIFFE, DIDs). Delegable authority is well served (UCAN, Keyhive). Declared behaviour on failure is served by nobody: every cyber-physical domain needs it, and each one that has it at all has hand-built it, vertically, inside its own stack. The due-diligence pass behind this claim is published as a research note (June 2026).
Murmur makes it a first-class contract property. Every capability edge declares its safe state on loss of liveness; the heartbeat is a dead-man's switch that fires it; fencing at the resource ensures a deposed or returning component cannot act on stale authority. The mechanism is identical across wildly different stakes: the same declaration that releases a held MIDI note on a dropped Wi-Fi link is a freewheeling drive motor on a lost link, anti-islanding on a dropped inverter, and load-shedding on a datacenter coordinator loss. One contract, demonstrated on a keyboard, sized for a substation.
Declared failure semantics is the headline instance of consequence-bounding (see "Bound consequences, do not evaluate correctness"). The floor it bounds against is physical, which is what makes it both the protocol's crown jewel and the part that weakens when the physics is removed. In a pure-software domain the same declaration still bounds, but it bounds against reversibility and gating rather than an actuator, so it carries less weight there than it does at a substation.
The design detail that carries the most weight: the safe state belongs to the role, not the device. An identical motor controller must freewheel in a drive slot (a held wheel on a lost link is uncommanded propulsion or single-wheel braking) and hold torque in a hoist slot (freewheeling drops the load). Making the safe state a property of the slot, armed at binding, means the device carries no knowledge of where it is installed, and the same part is safe in both places.
A second pressure on the same design detail: is a single, context-independent safe state even definable? A robot arm's safest move is to return to its home position while its light curtain is untripped and it knows where everything around it is, and to freeze in place the moment the environment may be compromised. The resolution is that a named safe state may be conditional inside its name ("return home unless the environment is compromised; otherwise freeze"), under two constraints that keep the name honest. The condition must be decidable by the device alone, from its own sensors, at the moment the network is gone: a hardwired light curtain qualifies; a part-position table held by the coordinator that just died does not. And when the condition itself cannot be evaluated, the state falls to its most conservative branch, never the most convenient one. What stays fixed is that binding arms exactly one name, whose full set of branches was visible to the safety analysis when the role was designed: choosing between safe states at failure time is forbidden, because that choice needs exactly the information the failure may have destroyed. How expressive these conditions may grow before they stop being certifiable, or stop being reimplementable from the specification alone, is open question 30.
And the honest boundary: the protocol's job is fast, trustworthy detection plus a declared safe default. The response (redistributing torque across three live corners, re-deriving grid dispatch) belongs to the certified domain controller. Safety logic is never smuggled into the communication layer.
The specification leans on other systems' scar tissue. The load-bearing borrowings, and what each one taught:
- RTP-MIDI's journal taught the two-planes split: run the live stream lossy and low-latency, and recover loss by journaling, never by trading latency for ordered-reliable delivery.
- Go modules taught that decentralized identity needs a provenance-and-availability layer over it. URL-as-import was elegant and decentralized, and bare decentralization produced vanishing sources, broken builds, and no trust signal, which Go had to retrofit with a module proxy and checksum database. The definition commons takes the lesson up front: self-certifying decentralized identity for definitions, with the cache, checksum, and attestation layer designed in rather than bolted on.
- TUF and Uptane supply the update-trust decomposition: a received update raises four separable questions (integrity, authorization, freshness against rollback, availability against withholding), and a genuinely signed but stale artifact is an attack, not a curiosity. The specification adopts that discipline directly and adds the question those frameworks deliberately leave out of scope: what the device does, physically, when an update cannot be verified or completed. The answer is its declared safe state.
- Kubernetes leader election taught what not to copy. It looks easy because it cheats: it is a compare-and-swap lock on an already-consistent store. Local-first and partition-prone means no such store exists, so election degrades honestly: when a node cannot safely elect, it fails to the declared safe state it already has.
- The fencing-token argument (Kleppmann's stalled-leader case) supplies the load-bearing safety mechanism: a deposed leader that wakes and acts is made harmless at the resource, which rejects anything below the highest token it has seen. Split-brain becomes safe at the actuator even while election is ambiguous, which is the property actually needed, cheaper and stronger than global consensus.
- Zero-trust networking (the post-perimeter lesson) supplies the ambient-authority rule: location and reachability are signals, never grants.
- The aviation security model supplies transitive trust: a small set of named regime tiers, a trust floor carried with the payload and lowered by the weakest hop, and re-screening at the destination's discretion. Named tiers, not a continuous trust score, because a score is illegible and gameable.
- PKI's revocation problem supplies the grant lifecycle: offline-verifiable delegation and timely revocation are in fundamental tension, so in safety contexts short-lived grants that must be renewed beat long-lived grants that must be revoked. Expiry is a connectivity-free dead-man's switch.
- Blockchain is mined for primitives and refused as architecture: hash-linked logs (tamper-evidence without consensus), threshold signatures (one stable verification key over a churning committee), self-certifying identifiers. Global total-order consensus in a dispatch path is a category error; resource-side fencing gives a stronger local guarantee instantly.
- JOSE's
algattacks (alg: none, and the RS256-to-HS256 key confusion) supply the algorithm-agility discipline: an algorithm field a token can set is the vulnerability, not the hedge. The specification keeps agility but takes the choice off the artifact, binding the algorithm to the trusted anchor (the signer's key, the content address) and leaving the verifier an allowlist. That is PASETO's anti-negotiation posture, reached here through identity-binding rather than versioned cipher suites. - libp2p is the closest existing substrate (peer identity as key hash, modular transports, mDNS and DHT discovery, protocol negotiation), but it was declined as the base: it is welded to protobuf peer identifiers, which the canonical-encoding mandate rules out, so the substrate machinery is reimplemented behind a thin port instead (question 11, resolved).
The deliberate posture throughout is compose, not replace. Zenoh, DDS, SPIFFE, DIDs, UCAN, TUF, Zigbee, Matter: every incumbent named in the specification is a potential host or component, not a competitor. The project admires them; the contract layer exists because no one of them spans the four concerns, not because any of them is wrong.
The first demonstration is deliberately the smallest honest one: a Raspberry Pi with a MIDI controller, over Wi-Fi, to a Mac running murmurd presenting a virtual CoreMIDI source into MainStage. Discovery via mDNS/DNS-SD, with the service record bound to the public key so a spoofed name fails verification.
The build's job is not to beat RTP-MIDI at moving notes; existing tools already move MIDI over Wi-Fi. It is to witness the contract model on a latency case a musician judges instantly:
- Identity: this keyboard is cryptographically this keyboard.
- Discovered versus bound: the keyboard is discovered (interface satisfied) but silent until bound into the
keys-primaryslot; then notes flow. - Authority, live: revoke the grant and MainStage stops receiving, distinctly from a network failure.
- Failure: pull the Wi-Fi mid-chord; the slot goes stale, the declared safe state fires (all notes off), and nothing sticks.
- Pool and contention: a second identical-feature, distinct-identity keyboard contends for the slot (the four-motor case in miniature); the held-note ledger lives at the consuming endpoint, and promotion replays or patches the seam.
- Steward death: kill the Mac and every slot fails safe, to clean silence. The honest demonstration of steward death; no transparent failover is pretended.
- (Optional) Fencing: grants carry fencing tokens, and the virtual source drops a deposed keyboard's late packets: safety under split-brain, audible in seconds.
MIDI is a witness, not the reference domain. It occupies the easiest corner of every axis: single trusted steward, single owner, fully stream-observable state, soft real-time, failure that annoys rather than injures. Murmuration is sized for the hard ends: multi-party grid, certified drivetrain, hidden state, hard real-time, fatal failure. Every place the demonstration is easy is a place the specification must not generalize from, and the specification flags each one where it matters. Two examples of the discipline: the witness's state is fully reconstructible from the stream, which is the exception rather than the rule (most real capabilities carry hidden state, and that set forces member-side checkpointing); and the witness broadcasts its capabilities over mDNS, which is the ambient end of discovery visibility and demonstrates nothing about the confidential end.
Each rung of the demonstration ladder lights up one hard property the witness leaves dark, in the same cheap, instantly judgeable setting. Each doubles as a roadmap item, done when its corresponding open question closes. The two directions out of the easy corner are resilience under loss (something live goes away gracefully) and growth under addition (something new arrives gracefully); the same two motions reappear, unsafe and expensive, at the dangerous ends.
These rungs are an aspirational roadmap, not built. They are listed to show that the witness is the smallest slice of a planned progression.
| Rung | Demonstration | What it lights up | Open question it closes |
|---|---|---|---|
| Today | The MIDI witness | the friendly baseline: the contract model is real | (baseline) |
| Next: loss | Roadie hot-swap: pull the active keyboard mid-performance; the sustained chord rides through the swap | redundancy pool, pre-warmed standby, consuming-endpoint state | 1, 4 |
| Next: growth | Expression-pedal hot-add: a different kind of device appears, is discovered, binds into a mod-source slot, and works, with no restart or update |
growth by discovery; admission by interface satisfaction alone | 5 |
| Next: bidirection | Control surface with motorized faders: produces gestures, consumes feedback | per-edge direction; two ports, two safe states | 9 |
| Next: fan-out | Network MIDI clock to many slaved devices; pull the source | rootless failure: each subscriber fires its own local safe state, with no central death signal | 7 |
| Far: loss | Grid inverter or redundant IMU failover | loss where re-observation is impossible: hidden state, member-side checkpointing | 2, 4 |
| Far: growth | A new home battery joins a virtual power plant | growth across mutually distrusting principals; revocable delegation; multi-principal arbitration | 3, 6 |
| Far: physical, single-owner | Datacenter supervisory power and thermal coordination | the VPP pointed inward; safe state = shed; fencing at the device's own power floor | 12 |
| Far: physical, multi-tenant | Multi-tenant shared-resource coordination in a datacenter | shared physical constraints across customer trust boundaries | 2, 7, 12 |
The pedal rung is worth singling out: because the device is obviously not a keyboard, it makes the structural-typing claim concrete. It binds into mod-source because it satisfies that slot's required interface, full stop, not because of what kind of thing it is.
The AI datacenter appears on the ladder as a far rung, and its status is stated plainly: unvalidated, pending diagnostic enquiry. It is best understood not as a beachhead but as a proof that the model generalizes, and as the densest concentration of the specification's hard open questions in one operational environment.
Where the model does not fit, and says so: the training hot path. Distributed training's collective operations (all-reduce over RDMA-class fabrics, sub-microsecond, bulk-synchronous, compile-time-static topology) are the most hostile possible environment for this design: no discovery, no negotiation, no latency budget for per-message identity or authority, and, decisively, no locally degradable safe mode, because a dropped rank kills the training step. The superficial resemblance to the drivetrain (many identical modules, one job) is a trap; it lacks the degradability the whole failure model depends on. That is someone else's data plane.
Where the model fits: the supervisory and physical planes, everything at millisecond pace or slower. Fault-tolerance supervision at scale (spare-node promotion is the redundancy pool, with the recovered state hidden, forcing checkpointing). Disaggregated inference fleets (live discovery, capability typing, and dynamic binding at a pace a control plane can breathe at). And the sleeper, the literal cyber-physical layer: power and thermal coordination, where per-node power-cap agents with declared envelopes operate under a rack or facility ceiling and fail safe by shedding, with fencing at each device's own power floor rejecting a deposed coordinator's stale instruction to draw more. A datacenter is a microgrid with starlings; the virtual-power-plant design already covers most of it, pointed inward.
One boundary must be drawn before any test (open question 12): power coordination splits into a fast regime (correlated load transients that can trip protection: real-time, firmware, hardware, not Murmur) and a supervisory regime (facility-wide envelope coordination, fail-safe: Murmur). Misplacing that boundary is either safety logic in the communication layer or a missed trip, so any trial belongs in the supervisory plane, well away from the trip path.
Whether a real gap exists at all, versus coverage by existing DCIM, hyperscaler-internal power management, and power-aware schedulers, is an empirical question, and "the gap isn't real" is a successful outcome of asking it: it would confirm the datacenter as a generality proof rather than a market.
The contract model was shaped by cyber-physical stakes, but most of its load-bearing mechanisms were borrowed from software distributed systems: fencing tokens, leases, quorum rules, content addressing. A fair test of the abstraction is whether it survives the return journey. Systems of collaborating AI agents, spanning organizations and tools, are the sharpest version of that test, and field accounts say the pain is live there today.
The mapping is direct. An agent discovers tools and peers (feature-capability), is granted scoped authority over them (binding), and routinely goes silent mid-operation. The held MIDI note has exact software analogues: the orphaned lock, the half-completed multi-step operation, the spend that continues on stale authority. The design that answers it transfers unchanged. The safe state is declared at the resource (the tool server), armed at binding, fired by lease expiry, and fenced against the returning agent's stale grant. The steward names a hole nobody currently fills: when agents from different organizations share a contract, somebody must own its schema, quorum rule, and failure semantics, off the data path. And the grandfather's axe is not an edge case there. Model deprecations replace every starling on a quarterly cycle, which is open question 20 played at speed.
A faithful witness should exercise more than leases, because the software realm is where this specification's authority and attestation machinery does its real work, the physical floor having dimmed (see "Bound consequences, do not evaluate correctness"). Three additions make the demo witness Section 4.8 rather than only the held-note reflex. First, a high-stake agent action gated on a tool server's per-event assent, where a refusal travels back as a signed negative and unstages whatever was prepared, is the negative path in software clothes. Second, a dangerous action ("delete the production dataset") placed behind a k-of-n quorum of approvers surfaces per-event attestation, partial assent, and the difference between an approver who declines and one who is merely unreachable. Third, agents from two organizations carrying different trust tiers force the cascade to re-screen the less-trusted one's actions rather than trust it by reachability. None of this needs hardware, and all of it fails harmlessly.
Even the physical floor survives, generalized rather than lost. The final authority lives in a layer the protocol cannot reach. In a cyber-physical system that layer is physics; in a software-only system it is the substrate: the process supervisor, the key infrastructure, the spending cap. "It must remain possible to turn Skynet off" was never really about actuators. The honest difference, which the witness should show rather than hide, is that this floor is weaker. A physical actuator floor is un-circumventable; a software floor is itself more software, so the bounding it gives is reversibility, gating, and provenance rather than a copper switch. That is consequence-bounding with a softer floor, exactly the dimming the principle predicts: when an agent goes rogue, the bound is its grant revoked, its staged actions unstaged, and its spending cap held, not an emergency stop.
Such a witness would be as cheap as the MIDI one: no hardware, no safety case, failure that annoys rather than injures. And it would light exactly what the keyboard leaves dark: contracts that change while the system runs, and collaboration across trust boundaries.
Agents are the witness, but they are not the only software domain the abstraction was tested against, and the others place it rather than rival it. A distributed version-control ecosystem shows the authority column more cleanly than agents do: cryptographic identity, capability-scoped revocable authority over parts of a tree, cascade trust tiers for contributors of varying trustworthiness, and tamper-evident provenance of every contribution, with correctness left to review and tests. It governs contribution, it does not certify code, and it is the natural companion demonstration or ladder rung. Payments are the sharpest stress of the per-event attestation, quorum, and finality machinery, and for exactly that reason the worst witness: money cannot be made low-stakes, so it fails the annoys-not-injures test. It stays a worked example (the settlement quorum above), never the friendly demo. The network-fabric case recombines the payments boundary with consequence-bounding rather than revealing a new corner, which is itself the sign the core has converged.
The places the abstraction creaks are named rather than hidden, because finding them is the point of running the test:
- Attesting stochastic capability. A motor's torque curve is a datasheet claim a regime can certify. An agent's capability is behavioural and probabilistic, and drifts with every model update beneath it. Attestation regimes become evaluations, and evaluations are continuous and gameable, in direct tension with the named-tiers-not-scores rule (specification, Section 4.4).
- Contract churn rate. A cyber-physical steward updates its contract rarely. Agents renegotiate at conversational pace, which threatens to pull the steward onto the hot path the design deliberately keeps it off.
- The column is not empty there. Within one runtime under one administrator, declared per-component failure behaviour has existed for decades: Erlang/OTP supervision trees are exactly that, and compensation has a name (sagas). The gap that survives is the same shape as in the cyber-physical survey: nobody makes failure semantics a declared contract property across trust boundaries, composing over the agent transports rather than replacing them. That narrower claim has been through a due-diligence pass (research note, June 2026). It survives, narrowed once more by a counterexample in kind from payment channels.
The status matches the datacenter case: unvalidated, and not the wedge. Cyber-physical systems remain the specification's scope and the project's first audience. The software witness, if built, would prove one thing the keyboard cannot: that the contract model does not secretly depend on physics. That is the same job the applause example does for coordination, run in the other direction.
The specification is written to be objected to. Its open questions section is not an appendix of loose ends; it is the working surface, and several of its entries (persistent system identity through total churn; owner re-rooting versus certification; the fast-versus-supervisory boundary; making graceful exit cheaper than disappearing) are the deepest design problems in the project. Where prose elsewhere touches one of them, it is presented as open and inviting objection, not as solved.
The model is deliberately maximal up to a named ceiling (specification, Section 15.2) and minimal in what the witness actually builds, which is the degenerate-case law at work (specification, Section 1). The discipline for growth is fixed: new needs should arrive through the reserved seams (predicate subscriptions, the capability shape type, the steward-of-stewards recursion), not by reopening the spine.
The most useful contributions at this stage are objections to the open questions, field accounts from domains that feel the underlying pain, and demonstrations that extend the witness into a harder corner.