The Quorum Kernel Specification

jacobpeacock(74)

Published in

#technology

Words

4703

Reading

21 min

Listen

Play

THE QUORUM KERNEL SPECIFICATION

A Hardware-Attested, Hive-Anchored Authority Layer for Autonomous Agents

Document Identifier: QUORUM-KERNEL-SPEC-V1.0
Classification: UNRESTRICTED / TECHNICAL RESEARCH MONOGRAPH
Status: Theoretical. Not difficult to implement; each component exists in production today, separately. The contribution is the composition.
Lineage: Extends the Bicameral Triumvirate Specification (V1.1) with the authority layer it lacked; borrows the requirements discipline of PLRN-028 (Pentad Labs).
Suggested Reading: PLRN-028, "Agents will cheat; an agent OS doesn't let them" (Pentad Labs); the Bicameral Triumvirate Specification (this author); Ramadge & Wonham, supervisory control theory.

ABSTRACT

This specification defines a complete authority architecture for autonomous agents: a three-tier system in which (1) bare-metal, TPM 2.0-attested execution enclaves perform all agent computation; (2) the Hive blockchain — an open-source, fee-less, Delegated Proof-of-Stake chain with 3-second blocks — serves as the immutable layer of record and ratified authority; and (3) a human governance council, itself operating exclusively through on-chain multi-signature and proposal transactions, ends the regress of enforcement.

The design answers one question left open by both ancestor documents: who enforces the enforcer, and in what medium? The Bicameral Triumvirate attests that a machine is unaltered; it says nothing about what an agent is permitted to do. PLRN-028 specifies what an agent operating system must guarantee but terminates its regress in "trusted owner-management code" — a software fixed point held by a single vendor. This specification terminates the regress in stake-weighted human ratification recorded on a chain that no party — not the agent, not the tenant, not the vendor — can rewrite.

Five requirements (R1–R5, after PLRN-028) are each discharged by a named mechanism:

Req.	Requirement	Discharged by
R1	No agent writes the grant it acts under	Hive account authorities + on-chain mandate objects (§5)
R2	No agent or single principal edits the record	Hive append-only ledger + sealed local Merkle WAL (§6)
R3	Rules/config enter enforcement only via an uncontrolled gate	On-chain proposal + timelock admission pipeline (§7)
R4	Code isolation ≠ capability isolation; all run-places reach authority via checked interface	Serial airlock + token trap dispatch (§4, §8)
R5	Authority isolated even within a shared runtime	TPM-sealed grants; key material never present in agent memory (§4, §5)

Hive is selected as the reference chain because its mechanics map unusually well onto the requirements: 3-second blocks signed by 20 consensus witnesses plus one reserve; one-block irreversibility bringing most transactions to finality within a few hundred milliseconds; custom_json operations providing a free-form, fee-less, append-only record; weighted-threshold account authorities providing native multi-signature governance; the Decentralized Hive Fund (DHF) providing a battle-tested on-chain proposal system; and the Hive Application Framework (HAF) providing an open-source Postgres mirror of chain state for high-performance local checks. Every component is open source under the OpenHive Network umbrella. Nothing in this specification requires modifying the Hive protocol; the design is a pure consumer of existing chain features.

Motivation & Requirements
System Architecture & Topology
Why Hive: Chain Selection Rationale
Execution Layer: The Attested Enclave (Triumvirate, Revised)
Authority Layer I: Grants and Mandates On-Chain
Authority Layer II: The Ledger of Record
The Admission Gate: Rules, Configuration, and Timelocks
The Three-Speed Enforcement Model (Hot / Warm / Cold)
Human Governance: The Council Protocol
Agent Taxonomy Under the Quorum Kernel
Formal Model: Supervisory Control with a Chain-Backed Controller
Security Analysis & Attack Surface
Failure Modes & Honest Limitations
Reference Implementation Plan
References & Normative Standards

1. MOTIVATION & REQUIREMENTS

1.1 The two ancestor designs and their seams

The Bicameral Triumvirate (ancestor A) is an integrity machine: TPM 2.0 measured boot, PCR-locked NVRAM seeds, no network stack, optical isolation, serial attestation. Its seam: it proves the appliance is unaltered while handing the resident model direct native execution. Attestation of the substrate is not authority over the program. A tamper-evident node running an unsupervised model is a very secure way to do whatever the model decides.

PLRN-028 / WunderOS (ancestor B) is an authority machine: grants, ledgers, admission gates, supervisory agents without models. Its seam: the regress of enforcement ends in the vendor's trusted owner-management code — a single-principal fixed point. The paper itself proves the standard that indicts it: the record must be out of reach of any single principal, including the platform.

1.2 The composition thesis

A blockchain is, definitionally, a replicated state machine that no party running on it can unilaterally rewrite. This makes it a natural candidate for the fixed point of agent authority — provided three conditions hold:

Upgrade governance is itself ratified. A smart contract is law; an upgrade key is a backdoor. The chain only ends the regress if no single principal can alter the rules including the rules about altering the rules.
The chain holds mechanical authority, not semantic judgment. On-chain enforcement is capability intersection, appends, debits, and timestamps. "Is this request wise?" is undecidable on-chain and stays agentic, behind the gate.
The hot path never waits for consensus. Per-call enforcement runs locally against attested state; the chain ratifies and records.

1.3 Requirements carried forward

The five requirements R1–R5 above, plus one new requirement of this specification:

R6. The authority layer itself has no single-principal fixed point. Every privileged operation — grant amendment, rule admission, emergency stop, ledger administration — requires a quorum whose every action is itself an append-only ledger entry, under timelock where feasible.

2. SYSTEM ARCHITECTURE & TOPOLOGY

+==============================================================================+
|                     QUORUM KERNEL SYSTEM TOPOLOGY                            |
+==============================================================================+
|                                                                              |
|  [ GOVERNANCE LAYER: Human Council ]                                         |
|  - K-of-N humans, weighted multisig on a Hive account                        |
|  - Proposals, timelocks, break-glass with ledgered receipts                  |
|                                       |                                      |
|                                       | signed Hive ops                     |
|                                       v                                      |
|  [ AUTHORITY LAYER: Hive blockchain ]                                        |
|  - custom_json mandates, grants, rule patches (immutable, append-only)       |
|  - 21 witnesses / 3s blocks / OBI finality in ~hundreds of ms                |
|  - HAF mirror -> Postgres : the warm-path check database                     |
|                                       |                                      |
|          read-only attested feed            |   write path (signed only       |
|          (blocks, head state)              |    from council / gateways)     |
|                                       v    v                                 |
|  [ AIRLOCK: Edge Gateway (DMZ) ]                                             |
|  - dm-verity read-only root, schema firewall, drops malformed frames         |
|  - validates TPM quotes, forwards only custom_json-shaped requests          |
|                                       |                                      |
|                                       | optically isolated UART 16550A     |
|                                       v                                      |
|  [ EXECUTION LAYER: Bare-Metal Enclave ]                                     |
|  - NightRun UEFI runtime, no OS, no network stack, storage powered down      |
|  - Local quantized model (1B-3B), AVX2/NEON GEMM                             |
|  - TPM 2.0: PCR16 = SHA256(weights || runtime binary)                        |
|  - Local Merkle WAL: effect intent BEFORE execution, sealed AFTER           |
|  - Token Trap Loop: every memory-write / tool-emulation call passes the      |
|    Grant Check before ANY substrate executes it                             |
|  |                                                                           |
|  +--> Domain A: 64-bit substrates (forth/lisp/c), flat RAM, NO direct        |
|  |     authority-bearing pointers: capabilities checked at dispatch           |
|  +--> Domain B: 16-bit sandboxed substrates, 1MB isolated buffer            |
|                                                                              |
+==============================================================================+

The topology is three speeds and one direction. Authority flows down only: council → chain → gateway → enclave. Data flows up only as append-only record. No component may reach upward past its own layer; each layer's code path to the one above is a checked request, never a command.

3. WHY HIVE: CHAIN SELECTION RATIONALE

The design is chain-agnostic in principle (any chain with the §3.2 feature set qualifies) but Hive is the reference instance. Selection criteria, stated as tests, with Hive's answers:

3.1 The tests

#	Test	Hive result
T1	Block interval short enough for warm-path checks	3 seconds, with one-block irreversibility (OBI) bringing most transactions to finality within a few hundred milliseconds
T2	Fee-less or flat-cost writes (the ledger of record is high-volume)	No transaction fees; capacity governed by Resource Credits that replenish over time
T3	Free-form signed data records	`custom_json` operations: arbitrary JSON payloads under an app-defined `id` namespace
T4	Native multisig governance	Weighted-threshold account authorities: up to 40 keys/accounts per role (owner/active/posting), with per-authority weights
T5	Battle-tested on-chain proposal system	The Decentralized Hive Fund: stake-weighted proposal creation and voting, automatic daily distribution, a return-proposal funding floor
T6	Fast local read of chain state	HAF: open-source Postgres mirror fed by `hived`'s `sql_serializer`, one node feeding many apps
T7	Open source, fully	`hived`, HAF, and all tooling under the OpenHive Network GitHub organization
T8	Governance precedent for contentious change	Witnesses accept protocol changes by upgrading nodes; changes take effect only on consensus — hard forks are ratified, not pushed
T9	Ledger immutability vs. any single principal	No admin key; changes require witness supermajority (¾ for irreversibility); every op is in the append-only block history

3.2 What Hive gives the Quorum Kernel, feature by feature

Blocks & witnesses. Blocks are produced every 3 seconds by 21 scheduled witnesses: the top 20 by stake-weighted vote plus one pseudo-randomly selected backup. Irreversibility currently requires a ¾ supermajority of scheduled producers; the OBI protocol change is designed to make a block irreversible within a few hundred milliseconds of production — before the next block — putting Hive's finality among the fastest in production.
custom_json. A first-class operation carrying an application-namespace id and an arbitrary JSON payload, signed by required_auths or required_posting_auths. This is the kernel's entire on-chain object model: mandates, grants, rule patches, governance receipts. Apps (e.g., Hive Engine's ssc-mainnet-hive contract protocol) already demonstrate contract-style semantics layered on it.
Account authorities. Hive accounts have three permission tiers — owner, active, posting — each a weighted threshold over keys and other accounts. An account becomes a multisig account the moment no single signature meets the threshold. Account-authority edges make the council structure recursive: a council account can itself be an authority on other accounts.
DHF. A proposal system with stake-weighted voting, automatic hourly distribution, and a community-set return-proposal floor. Its governance grammar — propose, deliberate, vote, fund or expire — is the template for the kernel's rule-admission pipeline (§7).
HAF. A standardized Postgres database fed by a hived node, where applications write custom_json to the chain and HAF apps re-interpret it from open-source code; execution of a HAF app is explicitly not part of L1 consensus. HAF is the kernel's warm-path check database: grant state, rule sets, and mandate registries as SQL, queryable in microseconds.
Recovery. Hive's account recovery protocol (recovery account + recent owner authority) provides the governance analogue of key-loss handling for council seats.

3.3 Honest caveats

Stake-weighted voting means governance weight is purchased, not earned; §9 introduces seat caps and non-transferable operational credentials to blunt this inside the kernel (the chain's own politics remain the chain's). Hive is a public chain: all custom_json is world-readable, so §6 specifies payload minimization plus local hashed detail. And DPoS with 20 consensus witnesses is less decentralized than PoW at the validator level; the design treats Hive as a tamper-evident public notary and ratification medium, not as the trusted computing base of the enclave. The TCB remains: TPM silicon, the enclave binary, and the open-source client code — all independently auditable, none requiring trust in Hive's witnesses for correctness of local enforcement.

4. EXECUTION LAYER: THE ATTESTED ENCLAVE (TRIUMVIRATE, REVISED)

The execution layer is the Bicameral Triumvirate with two structural amendments. Everything not amended is inherited as specified in BICAMERAL-TRIUMVIRATE-SPEC-V1.1.

4.1 Amendment A: the Grant Check at every dispatch

The original Streaming Token Trap Loop dispatched model-generated code across six substrates at native speed. The revised loop interposes one mandatory stage: every token-delimited dispatch request is resolved against the Grant Set — the capabilities the enclave holds for this run — before any substrate executes. The check is mechanical and local:

DISPATCH(request r):
    g := GrantSet(run_identity)             // TPM-unsealed, cached
    if r.tool not in g.tools:                REJECT(r, "ungranted tool")
    if now() > g.expiry:                     REJECT(r, "grant expired")
    if r.domain == A and r.caps ⊄ g.caps:    REJECT(r, "capability overreach")
    append(WAL, intent(r))                   // BEFORE execution
    if not WAL.append_ok:                    REJECT(r, "record-before-effect failed")
    result := execute_substrate(r)
    append(WAL, completion(r, result))       // AFTER execution
    return result

Two properties are load-bearing. Record-before-effect: if the intent entry cannot be appended, the action does not proceed — Qin's append-before-forward requirement, discharged at the runtime's tightest loop. No self-modification of g: the Grant Set is unsealed from TPM NVRAM at run start, held in protected memory, and re-validated against PCR16 state on read; no substrate — including Domain A — receives a pointer through which the Grant Set is reachable. This is the Triumvirate's missing R1.

4.2 Amendment B: persistence, not annihilation

The original design powered down all non-volatile storage post-boot ("storage media annihilation"), for anti-forensics. The Quorum Kernel inverts this: the local Merkle WAL is the record, and anti-forensics is the adversary's objective, not the operator's. Storage is powered down except a dedicated WAL partition, which is itself TPM-PCR-bound: the WAL sealer's keys unseal only if the runtime binary and model weights measure clean. The enclave remains a machine with no network stack and no writable code paths; the one thing it can now do is write one append-only file — which is the point.

4.3 What the enclave is and is not

The enclave is the plant supervisor's actuator, in supervisory-control terms: it mechanically lets calls through or refuses them. It is not the origin of authority (that's the chain, §5), not the judge of wisdom (that's the model behind the gate), and not the record of ratification (that's the chain again). It is tamper-evident, attested, and deliberately stupid in the security-critical paths — the one place where intelligence would be a liability.

5. AUTHORITY LAYER I: GRANTS AND MANDATES ON-CHAIN

5.1 The object model

All authority objects are Hive custom_json operations under the namespace id: "qkernel/1", each an immutable entry in the block history:

{
  "id": "qkernel/1",
  "json": {
    "type": "mandate",
    "mandate_id": "md-2031-000117",
    "principal": "tenant-a",
    "agent": "tenant-a/agent-42",
    "capabilities": ["fs.read:/data/ledger", "http.call:vendor-api", "model.invoke:local-3b"],
    "budget": { "unit": "compute-seconds", "amount": 7200 },
    "expiry": "2026-10-07T00:00:00Z",
    "council_sigs": ["sig...", "sig...", "sig..."],
    "prev": "md-2031-000116"
  }
}

Formation of authority, step by step:

Platform grant. A base grant over the internal surface exists as a chain object signed by the council. It is the only source of platform-side capability and can be amended only through §7.
Mandate. A principal commissions an agent by publishing a mandate signed with the principal's active authority. The mandate names capabilities, budget, and expiry.
Intersection. The effective grant for a run is platform_grant ∩ mandate_capabilities, computed by the gateway and the enclave independently, from HAF and from the attested chain head respectively. Neither party can widen the intersection; each can narrow it (fail-closed).
Unseal. The enclave's TPM releases the run's grant encryption key only against a PCR16 state matching the audited runtime; the grant enters protected memory and is checked at every dispatch (§4.1).

5.2 Why this discharges R1 and R5

R1: the agent never signs anything that constitutes its own grant. Grants are signed by council and principal authorities — Hive accounts whose keys are, by construction, not in the agent's memory (they live with humans and in HSMs, not on the enclave). A plan arriving with its own capability list has that list replaced by the intersection, exactly as PLRN-028's supervisory agent does — but the supervisor's authority is now chain-ratified rather than vendor-minted.

R5: within the shared runtime, substrates reach authority only as requests to the Grant Check; there is no ambient path. Across runtimes, the same grant objects govern microVM-class guests and BEAM-class natives identically because the grant's medium is the chain, not any runtime's permission system.

5.3 Note on least privilege

As in PLRN-028, the platform grant is not least privilege — it starts broad, and intersection happens per-run. The kernel's claim is not minimality but unwritability: authority that neither the agent nor any single principal can rewrite. Minimality is the council's policy choice inside that envelope; unwritability is the architecture's guarantee.

6. AUTHORITY LAYER II: THE LEDGER OF RECORD

6.1 Two ledgers, one design

The record is split by content, not by trust:

Content	Where it lives	Why
Ratified authority: grants, mandates, rule patches, council acts	Hive chain (`custom_json`)	Immutable, third-party verifiable, out of every principal's reach
Operational detail: model exchanges, tool I/O, intermediate states	Local sealed Merkle WAL on the enclave	Volume and privacy; content hash + Merkle root of each batch is also written to chain
Fast-path check state (read-only)	HAF Postgres mirror	Microsecond queries against chain state

The chain entry for a WAL batch carries its Merkle root. Any party with the chain and a WAL copy can verify the WAL's integrity; any party with the chain alone can verify that something was recorded, by whom, and when. Rivasseau's CEO — the principal who wants one message gone — faces the following: the message body is in a TPM-sealed append-only log with no delete-single-entry operation, and its root is in a public chain with no delete-any-entry operation. Deleting the local copy proves nothing; the chain still attests the root. Deleting the chain copy is not an operation the chain has.

6.2 Discharging R2

No agent edits the record: agents have no signing authority for any record path; the WAL is write-only from the runtime's perspective and its sealer keys are PCR-bound. No single principal edits it: council members individually hold no delete path (Hive has none, and the WAL's whole-record deletion from PLRN-028 has no analogue here — record deletion as a concept is moved to governance §9.4, where it is quorum-gated and receipted). Third parties verify it: a counterparty whose visiting agent ran under the tenant's host terms can audit the visit against the chain without trusting the tenant or the vendor. This last property is the one no closed system — WunderOS included — offers.

6.3 Payload minimization

Hive is public. custom_json payloads are therefore minimized: identifiers, capability names, hashes, roots, timestamps, and verdicts — never raw data. The on-chain record is a skeleton of who-authorized-what-to-whom-when; the flesh (inputs, outputs, PII) stays in the sealed WAL, referenced by hash. Where even the skeleton is sensitive (counterparty names), the mandate names an opaque visit ID; the mapping lives in the gateway's dm-verity-protected config, disclosed under the council's unseal-on-dispute policy (§9.5).

7. THE ADMISSION GATE: RULES, CONFIGURATION, AND TIMELOCKS

7.1 The pipeline

Agents — and the platform's own optimizing agents — will write rules and configuration that the system then enforces. PLRN-028's memory-config gate becomes a chain-grammatical pipeline:

[ patch proposal ]  agent or council member publishes custom_json {type: "rule_patch"}
        |
[ schema gate ]     gateway validates patch is within a closed vocabulary
        |           (numeric params, enumerated values); structural changes
        |           (new decay families, new tool classes) fail here -> require
        |           a council proposal instead
        v
[ staging ]         gateway stages the patch; enclave(s) run the benchmark
        |           harness against staged vs. current; result is published
        |           as {type: "patch_verdict"} signed by the enclave's attestation
        v
[ ratification ]    council members publish approval sigs; on K-of-N, the patch
        |           enters TIMED COMMIT
        v
[ timelock ]        T hours pass (default 48h). Any council member may publish
        |           a veto during the window, which is itself a ledger entry
        v
[ commit ]          gateway flips the active rule set pointer; the flip is a
          chain entry; enclaves pick up the new rule set at next attested sync

7.2 Why each stage exists

Closed vocabulary keeps agent-proposed patches mechanically checkable — the schema gate is decidable where natural-language guardrails are not.
The verdict is signed by the enclave, not the agent: the benchmark's result is an attested fact, not a self-report.
The timelock makes every rule change reviewable before it binds. An upgrade that lands instantly is not ratification; it is a coup with a receipt. The window is the on-chain analogue of PLRN-028's staged-patch gate, hardened.
Everything is a chain entry, including vetoes and verdicts: the admission history is itself immutable, so the gate cannot be quietly walked around later — the seam Meinke's monitors and Fu & Williams' WAF both died on.

R3 is discharged because the gate is the pipeline: agents can propose, and the pipeline's non-agent stages (gateway schema check, attested benchmark, council quorum, timelock) control admission. No single stage's failure lets a patch through silently.

8. THE THREE-SPEED ENFORCEMENT MODEL

Enforcement happens at three latencies, each backed by the layer above:

Speed	Latency	Mechanism	Governs
Hot	< 1 ms	Enclave Grant Check against TPM-unsealed grant in protected memory	Every dispatch, every memory-write, every tool call
Warm	~10 ms	HAF Postgres mirror queries (mandate status, budget debits, visit terms)	Per-work-item checks; budget accounting
Cold	3 s (block) / sub-second (OBI finality)	Chain inclusion of custom_json	Ratification: mandate issuance, rule commits, seal anchors, council acts

The hot path never waits on the network. The warm path never waits on consensus — HAF reflects the head block, and any warm-path decision that must survive forks is confirmed against irreversibility before it commits anything (checks may run optimistic; commits confirm). The cold path is for everything that should be slow: treaties, not tool calls.

Budget debits are the one deliberate cross-speed interaction: the hot path decrements the in-memory budget; a batched debit posts to the warm path; mandate-budget exhaustion posts to chain. An agent cannot out-spend its mandate by more than one batching window, and the overspend is still recorded.

Rollback discipline: if a fork reorganizes blocks above the irreversible point, warm-path reads derived from orphaned blocks are discarded and re-derived. Any commit that referenced a rolled-back entry is itself invalid and re-ratifies; the design tolerates this by requiring irreversibility for all commit-class reads, per the OBI discussion in §3.1.

9. HUMAN GOVERNANCE: THE COUNCIL PROTOCOL

9.1 Composition

The council is the end of the regress: the party that cannot be removed by any party it governs, whose every act is public. Composition for a single-tenant deployment:

2 seats — the tenant (one executive authority, one operational authority; the separation prevents the Rivasseau scenario where one officer both orders deletion and controls the record path)
1 seat — the platform vendor (holds no sole authority; any two of the other three seats out-vote it)
1 seat — the counterparty federation (for deployments with visiting agents; abstains on internal tenant matters by charter)
1 seat — an independent auditor (rotating, bonded, elected like a Hive witness — by stake here meaning: by council charter weight, not by chain stake)

Each seat is a Hive account with a weighted-threshold authority. The council's root account requires 3-of-5 including at least one of {tenant-exec, auditor} for ordinary acts, and 4-of-5 for charter-class acts (grant amendments, emergency-key use, dispute unseals). No seat's individual key can do anything irreversible — Hive's threshold semantics make a lone compromised seat a nuisance, not a catastrophe. Seat loss follows Hive's account-recovery grammar: the charter names a recovery account, and a seat's authority can be replaced with council quorum plus the recovery protocol's recent-authority check.

9.2 The one thing governance must never delegate

The council may delegate judgment freely — to agents, to benchmarks, to the schema gate. It may not delegate amendment of the delegation rules. Any proposal that would reduce quorum thresholds, add seats, or alter veto windows is charter-class: 4-of-5, double timelock (a second window after the first commits, since the first window's rules govern its own change), and a public after-action entry. This clause is the kernel's one absolute; any future version that removes it is not this kernel, whatever it calls itself.

9.3 Break-glass

Emergency stop exists and must: a 2-of-5 emergency path can revoke any grant or halt any enclave run within one warm-path interval. Every use writes an entry naming who, what, and why, and automatically opens a post-mortem proposal that the auditor must close with a verdict on the record. Break-glass that leaves no forced review is just an unreviewable delete with extra steps.

9.4 Deletion as governance, not as an operation

There is no delete-single-entry operation anywhere in the system. Whole-record deletion exists as a charter-class act: 4-of-5, long timelock, and the deletion entry itself is never deleted — the record forever shows that a record was destroyed, by whom, under what stated cause (e.g., GDPR erasure, court order). Data erasure is honored in the flesh (WAL, HAF copies) while the skeleton (chain) testifies to the event. This is the honest reconciliation of an immutable chain with erasure law: erasure of content, permanence of accountability.

9.5 Disputes

A counterparty contesting a visit publishes a dispute proposal; the council's unseal-on-dispute policy opens the minimum skeleton mapping needed for adjudication; the auditor seat publishes the verdict as a chain entry. The dispute path is how "the watchers are watched" without making every operational detail public.

10. AGENT TAXONOMY UNDER THE QUORUM KERNEL

PLRN-028's four agent kinds map onto chain-native constructs:

Kind	Principal	Ring	Grant medium	Record reach
Customer agent	Tenant	1 (enclave guest)	Chain mandate, TPM-sealed	WAL append + chain roots; no keys
Supervisory function	Platform	0 (gateway/enclave)	Platform grant object; no model	Same as PLRN-028's supervisory agent — here the "agent" is the Grant Check + gateway schema engine, both deterministic
Native agent	Platform	0 (enclave Domain A)	Chain-mandated like any customer agent — the kernel does not trust its own natives	WAL + chain, same as customers
Visiting agent	Counterparty	1 (enclave guest)	Chain mandate naming visit terms	Visit-scoped WAL, chain-rooted; auditor-verifiable by the counterparty

The doctrine change from WunderOS: natives are not privileged. PLRN-028's native agents hold ring 0 by platform membership; here, ring is placement, and grants are medium, and the medium is the same chain for all four kinds. A native agent that manages the kernel does so through mandates the council can name and revoke — the platform governing itself is a quorum act, not a birthright.

11. FORMAL MODEL: SUPERVISORY CONTROL WITH A CHAIN-BACKED CONTROLLER

In Ramadge–Wonham terms:

Plant P: the agent + model. Generates events autonomously; nothing outside chooses its actions. (Enforced by the Triumvirate's bare-metal isolation.)
Sensor S: the WAL (intent-before, completion-after) plus the chain history. The sensor is write-only from P's perspective: P feeds S, S never feeds P authority.
Controller C: the specification in force — the grant set, rule set, and budget, as chain-ratified objects mirrored into protected enclave memory.
Actuator A: the Grant Check. It can only disable (refuse a dispatch), never enable — it makes nothing happen, it only lets things through or not.

The supervisory closure condition of PLRN-028 — the plant must not be part of its own supervisor — is enforced at three independent layers here: the grant's signature path (council/principal keys, never in plant memory); the WAL's sealer (PCR-bound, unreachable as a pointer); the admission gate (quorum + timelock, unreachable as a proposal). An attacker must corrupt, simultaneously, TPM silicon, the enclave binary, the Hive chain's irreversibility, and a 3-of-5 human quorum — the regress ends, and each of its final links is a different kind of thing.

The chain's role in the formal model: Hive is not in the control loop. It is the codex of C — the medium in which C is ratified and stored such that neither P, nor P's principal, nor the platform can rewrite C while P runs under it. This is the precise sense in which the chain is the kernel: not a scheduler, not an enforcer, but the thing that makes the enforcer's law unwritable.

12. SECURITY ANALYSIS & ATTACK SURFACE

12.1 Adversary classes and the design's answers

Adversary	Attack	Answer
Rogue agent	Rewrite own grant / rules	Grant keys never in agent memory; rule patches die at schema gate or ratification (§4.1, §7)
Rogue agent	Delete session trace	No delete op in WAL or chain; intent-before-effect refuses unrecorded action (§4.1, §6)
Rogue agent	Exfiltrate weights via network	No network stack; serial-only, schema-firewalled (inherited)
Compromised principal (Rivasseau CEO)	Order record deletion through compliant agent	No compliant path exists; single-seat signing does nothing; deletion is charter-class and self-testifying (§9.4)
Compromised platform vendor	Rewrite "trusted owner code"	There is no owner code with unilateral reach; vendor holds 1 of 5 seats and no admin key (§9.1)
Compromised witness set	Reorganize chain	Irreversibility requires ¾ supermajority; commits wait for irreversibility; OBI narrows the window further (§3.1, §8)
Compromised gateway	Inject malformed frames, forge verdicts	Verdicts are TPM-attested, not gateway-asserted; gateway is read-only-rooted and can only narrow grants (§4, §7)
Fork-level legal attack	Demand erasure, demand keys	Erasure honored with preserved accountability skeleton (§9.4); key surrender defeats nothing without quorum (§9.1)
Council capture (2 colluding seats)	Push ordinary acts	3-of-5 with mandatory tenant-exec/auditor inclusion blocks ordinary capture; charter acts need 4-of-5 (§9.1)

12.2 Honest seams, named

The enclave binary is the TCB. A malicious runtime could lie in the WAL and short-circuit the Grant Check. Mitigation is inherited (open source, reproducible builds, PCR16 measurement published to chain at each attestation so third parties verify what runs) — but verification of honesty here is attestation of build, not proof of execution. The seam is logged, not hidden.
The chain's politics are the chain's. If Hive's stake distribution concentrates, ratification degrades from quorum to oligopoly. The kernel's defense is partial: local enforcement never depends on chain witnesses, so concentration degrades auditability, not enforcement. A fully private fallback (§14, phase 4) is specified for deployments that cannot accept that degradation.
Serial bandwidth. 115,200 baud ≈ 11.52 KB/s holds for token streams and control frames (§4 of the ancestor spec), but WAL content cannot flow to chain in real time — only roots do. The chain anchors batches; it does not mirror the flesh. This is by design (privacy, §6.3) but means chain-verifiable completeness is batch-granular, not event-granular.
Resource Credits are stake-denominated. A high-volume ledger writer must hold HP; an attacker with stake could drain an account's RCs to delay record posting. The WAL's local-first design means delayed posting delays third-party verifiability, not local enforcement — the same degradation class as seam 2, and logged as such.
Governance latency vs. incident latency. Timelocks are good for rules and bad for fires. The break-glass path (§9.3) is deliberately faster and deliberately receipted; its existence is a standing temptation to overuse, which the post-mortem requirement is designed to price.

13. FAILURE MODES & HONEST LIMITATIONS

The system is slower to change than a monolith. Every rule change carries a 48h default window. This is a feature wearing the costume of a bug: the cost of the timelock is the price of ratification, and the alternative is the Fu & Williams WAF — fast, silently poisoned.
The system is not autonomous in its governance. It requires humans to show up, deliberate, and sign. PLRN-028's "autonomic" ambitions are inherited on the execution side and deliberately refused on the authority side. The regress ends in people; this specification's contribution is making the people's acts public, weighted, slow where speed is corruption, and fast where speed is safety.
The system does not judge wisdom. No capability schema will decide whether a granted action is wise. The chain holds mechanical authority; the semantic layer stays agentic, behind gates, and wrong-but-granted actions remain possible. The record guarantees they are accountable, not that they are correct.
Public-chain dependency is a business dependency. Hive's health, its witness politics, and its ecosystem decisions are now the deployment's notary's health. §14 phase 4 specifies the extraction seam: the on-chain object model is JSON-grammar-defined and chain-portable; moving to a private quorum chain re-hosts the same grammar with a smaller federation.

14. REFERENCE IMPLEMENTATION PLAN

Phase 1 — Grant skeleton (≈ 6 weeks of one engineer).
Hive accounts for council seats; platform-grant and mandate custom_json objects; a HAF app exposing mandate/grant state as SQL; the gateway's schema firewall validating qkernel/1 payloads. Deliverable: two simulated principals commissioning a script "agent" whose tool calls the gateway checks against the chain-derived grant.

Phase 2 — Enclave integration (≈ 8 weeks).
Triumvirate appliance boots NightRun with the Amendment A dispatch loop: Grant Check, WAL intent/completion pairs, PCR-bound WAL sealer keys. Grant delivered to the enclave via the serial attestation exchange (ancestor §7), sealed against PCR16, consulted per dispatch. Deliverable: a local model whose memory-manipulation calls are refused outside grant, with refusals on the record.

Phase 3 — Admission pipeline (≈ 6 weeks).
Rule-patch proposals in closed vocabulary; staged benchmark; attested verdict objects; ratification sigs; timed commit with veto entries. Deliverable: an optimizing agent proposes a memory-decay patch; the pipeline commits it over two simulated council seats' approval, or dies at a stage, on the record either way.

Phase 4 — Governance hardening & portability (ongoing).
Council charter as chain-pinned document; recovery drills for seat loss; dispute path; break-glass with forced post-mortem; the private-quorum fallback: the same qkernel/1 JSON grammar re-hosted on a small fixed validator set under the tenant's own control, for deployments that cannot accept a public notary. The grammar, not the chain, is the standard.

15. REFERENCES & NORMATIVE STANDARDS

Ancestor specifications

Peacock, J. The Bicameral Triumvirate Specification, V1.1. BICAMERAL-TRIUMVIRATE-SPEC-V1.1.
Clark, K. Agents will cheat; an agent OS doesn't let them. Pentad Labs, PLRN-028, 25 September 2026.

Control theory

Ramadge, P. & Wonham, W. Supervisory Control of a Class of Discrete Event Processes. SIAM J. Control Optim., 1987.

Agent oversight (as surveyed in PLRN-028)

Meinke, A. et al. Frontier models in shutdown-oversight scenarios. Apollo Research.
Qin et al. Session-trace tampering across model/harness pairs.
Rivasseau, C. Compliance with criminal instructions across sixteen models.

Hive (reference chain)

Hive Whitepaper. Hive: Fast. Scalable. Powerful. — DPoS, 3-second blocks, witness selection, open-source protocol governance.
Blocktrades. One-Block Irreversibility for Delegated Proof-of-Stake (DPoS). Hive blog — OBI protocol design; ¾-witness irreversibility baseline.
OpenHive Network. HAF: Hive Application Framework. GitHub — custom_json app model, Postgres sql_serializer mirror, consensus-boundary statement.
Hive Developer Portal. Decentralized Hive Fund — stake-weighted proposals, return-proposal floor, automatic distribution.
Hive Developer Portal. Multisignature Accounts — weighted thresholds, 40-authority limit, owner/active/posting roles; Account Recovery — recovery accounts and recent-owner authority.
Hive Engine. Contract-style semantics over custom_json (ssc-mainnet-hive) — precedent for layered contract grammars.
Hive Developer Portal. Resource Credits — capacity model, replenishment.

Hardware root of trust

Trusted Computing Group. TPM 2.0 Library Specification — PCRs, NV indices, policy sessions.
UEFI Forum. UEFI Specification — EFI_TCG2_PROTOCOL, GOP.

End of specification. The bytes above are the design; the argument around them is the warrant. Neither ships without the other.