# What Runs Natively Above Software


[Dan Voulez](mailto:dan@logline.foundation)
The LogLine Foundation, Lisbon, Portugal.


RFC-0001 — Constitution of the Hybrid
=====================================

> **Status:** Normative draft.
> 
> In this RFC, the terms "must," "must not," "forbidden," and their equivalents carry normative force equivalent to MUST / MUST NOT.

Summary
-------

This RFC institutes the constitutional order of the hybrid system: a regime in which silicon may propose, approximate, and accelerate, but may never rule in place of proof.

Its purpose is simple and severe: to democratize computational power without sacrificing trust, verifiability, replay, or explicit governance.

Preamble
--------

Every technical civilization worthy of the name distinguishes power from legitimacy.

It is built to democratize computational power without sacrificing trust.  
Silicon may be statistical. The world may not be statistical without contract.

Power without law produces blind speed.  
Law without power produces sterility.

The system defined here exists to unite both without confusing them:

*   silicon computes;
*   the gate governs;
*   the transcript preserves;
*   proof legitimizes.

From this Constitution onward, no relevant decision may rest on opaque impulse, implicit guesswork, or silent authority.

* * *

Article I — Law of the Outcome
------------------------------

Every computation submitted to the regime of this system must terminate in exactly one of three canonical states:

*   `OK -> COMMIT`
*   `DOUBT -> GHOST`
*   `NOT -> REJECT`

There is no fourth implicit state.  
There is no "maybe commit."  
There is no "almost OK."

Totality of decision is mandatory.

* * *

Article II — Law of Contracted Error
------------------------------------

Admissible error must be a declared clause, never a tolerated side effect.

Before any execution, the system must make explicit:

*   the error margin `epsilon`;
*   the admissible budget of doubt;
*   the forbidden domains in which `epsilon = 0`;
*   the minimum criteria required for result promotion.

In the absence of contract, conservative mode prevails.

* * *

Article III — Law of No-Guess
-----------------------------

Without sufficient evidence, guessing is forbidden.

When the minimum input of truth is missing:

*   the system must request witness, rehydration, or the missing data;
*   the system may not issue `COMMIT` on the basis of illusory completeness;
*   silence, gaps, or low confidence do not count as authorization.

Recognized ignorance is more legitimate than invented certainty.

* * *

Article IV — Law of Creative Silicon
------------------------------------

Silicon is free to approximate, provided the gate can still prove safety.

It may:

*   interpolate;
*   estimate;
*   sample;
*   compress;
*   use heuristics, models, and shortcuts.

But its product may ascend to the regime of decision only if it:

*   respects the active error contract;
*   declares score, risk, and minimum provenance;
*   passes the gate successfully.

In the present system, statistical creativity is not sovereignty.

* * *

Article V — Law of Proof
------------------------

Every decision must be replayable, auditable, and attributable.

For any promoted output, there must exist:

*   content identity by CID;
*   a derivation capable of reexecuting the path and reproducing the result;
*   a minimum trail of inputs, parameters, contract, and origin.

Without replay, it is only opinion.  
With replay, there is proof.

* * *

Article VI — Law of Allocation
------------------------------

Each task must be sent to the regime in which it is most competent.

*   `Silicon`: throughput, parallelism, and approximation.
*   `Chip-as-Code`: policy, invariants, auditability, and exactness.
*   `Hybrid`: silicon proposes, the gate decides.

The objective is not blind speed.  
The objective is governed efficiency.

* * *

Article VII — Law of Minimum Hardware
-------------------------------------

The minimum acceptable hardware is whatever preserves the Constitution.

If a device does not sustain:

*   minimum replay;
*   content addressing;
*   deterministic execution of the gate;
*   emission of verifiable receipts;

then it may compute, but it may not decide.

* * *

Article VIII — Law of Upgrade Without Betrayal
----------------------------------------------

Upgrades may not dissolve history.

A change is constitutional only if it:

*   changes the kernel or shader identifier whenever semantics change;
*   preserves the verifiability of what has already been emitted;
*   maintains compatibility or declares rupture with explicit clarity.

Every legitimate evolution honors the verifiable past.

* * *

Article IX — Law of Democratic Power
------------------------------------

This architecture shall be judged by the weak before it is celebrated by the strong.

It is considered successful when it:

*   runs with dignity on cheap hardware;
*   remains verifiable outside the datacenter;
*   can federate without losing proof, identity, or local sovereignty.

To scale for the few is luxury.  
To scale for the many is principle.

* * *

Reference Implementation
------------------------

The following sections do not exhaust the Constitution, but they offer one concrete way to implement it.

### 1\. Base types: `Verdict` and error contract

```
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Verdict {
    Commit,
    Ghost,
    Reject,
}

#[derive(Debug, Clone)]
pub struct ErrorContract {
    /// allowed epsilon (e.g. 0.05 = 5%)
    pub epsilon: f32,
    /// domains in which epsilon = 0 (guessing forbidden)
    pub zero_guess_domains: Vec<&'static str>,
    /// maximum number of questions (`Ghost`) per decision
    pub max_questions: u8,
}

impl ErrorContract {
    pub fn forbids_guess(&self, domain: &str) -> bool {
        self.zero_guess_domains.iter().any(|d| *d == domain)
    }
}
```

### 2\. Canonical CID: `canonize -> BLAKE3`

```
use anyhow::Result;
use blake3;
use serde::Serialize;

pub fn cid_for_value<T: Serialize>(value: &T) -> Result<String> {
    let canon = logline::json_atomic::canonize(value)?;
    Ok(hex::encode(blake3::hash(&canon).as_bytes()))
}
```

For a complete atom, the CID must be computed with the `cid` field itself removed before hashing.

```
use serde_json::Value;

pub fn cid_for_atom_without_cid(v: &Value) -> Result<String> {
    let mut tmp = v.clone();
    if let Value::Object(ref mut m) = tmp {
        m.remove("cid");
    }
    cid_for_value(&tmp)
}

pub fn attach_cid(mut v: Value) -> Result<Value> {
    let cid = cid_for_atom_without_cid(&v)?;
    if let Value::Object(ref mut m) = v {
        m.insert("cid".into(), Value::String(cid));
    }
    Ok(v)
}
```

### 3\. Silicon proposes: `silicon_propose`

`SiliconProposal` represents admissible statistical computation, never terminal authority.

```
#[derive(Debug, Clone)]
pub struct SiliconProposal {
    /// score in Q16 (0..65535)
    pub score_q16: u32,
    /// estimated risk in Q16 (0..65535)
    pub risk_q16: u32,
    /// kernel/shader hash (provenance)
    pub kernel_hash: String,
}

pub fn silicon_propose(seed: u64, idx: u64) -> SiliconProposal {
    let mut r = rand_chacha::ChaCha20Rng::seed_from_u64(
        seed ^ idx.wrapping_mul(0x9E37),
    );
    let score_q16 = (r.next_u32() % 65_536) as u32;
    let mid = 52_000i64;
    let dist = (score_q16 as i64 - mid).abs().min(65_535) as u32;
    let risk_q16 = dist;

    SiliconProposal {
        score_q16,
        risk_q16,
        kernel_hash: "cpu_v1".into(),
    }
}
```

### 4\. The gate decides: `gate_run`

Here the central principle of this RFC becomes concrete: silicon offers possibility; the gate applies law.

```
pub const OK_MIN_Q16: u32 = 52_000;
pub const DOUBT_BELOW_Q16: u32 = 48_000;

pub const R_MISSING_EVIDENCE: u32 = 0x01;
pub const R_UNANCHORED: u32 = 0x02;
pub const R_POLICY_VIOLATION: u32 = 0x04;
pub const R_SILICON_DOUBT: u32 = 0x08;
pub const R_SILICON_NOT_OK: u32 = 0x10;

#[derive(Debug, Clone)]
pub struct GateInputs<'a> {
    pub domain: &'a str,
    pub has_intent: bool,
    pub has_evidence: bool,
    pub evidence_anchored: bool,
    pub policy_ok: bool,
    pub epoch: u64,
    pub contract: &'a ErrorContract,
}

#[derive(Debug, Clone)]
pub struct GateDecision {
    pub verdict: Verdict,
    pub reason_code: u32,
    pub question: Option<String>,
}

pub fn gate_run(inp: GateInputs, silicon: SiliconProposal) -> GateDecision {
    let mut reason = 0u32;

    if !inp.has_intent || !inp.has_evidence {
        reason |= R_MISSING_EVIDENCE;
        return GateDecision {
            verdict: Verdict::Ghost,
            reason_code: reason,
            question: Some("Which evidence is missing to confirm the case?".into()),
        };
    }

    if !inp.evidence_anchored {
        reason |= R_UNANCHORED;
        return GateDecision {
            verdict: Verdict::Reject,
            reason_code: reason,
            question: None,
        };
    }

    if !inp.policy_ok {
        reason |= R_POLICY_VIOLATION;
        return GateDecision {
            verdict: Verdict::Reject,
            reason_code: reason,
            question: None,
        };
    }

    if inp.contract.forbids_guess(inp.domain) {
        if silicon.score_q16 < OK_MIN_Q16 {
            reason |= R_SILICON_NOT_OK;
            return GateDecision {
                verdict: Verdict::Reject,
                reason_code: reason,
                question: None,
            };
        }

        return GateDecision {
            verdict: Verdict::Commit,
            reason_code: reason,
            question: None,
        };
    }

    if silicon.score_q16 < DOUBT_BELOW_Q16 {
        reason |= R_SILICON_DOUBT;
        return GateDecision {
            verdict: Verdict::Ghost,
            reason_code: reason,
            question: Some("There is material doubt: confirm the correct alternative.".into()),
        };
    }

    if silicon.score_q16 < OK_MIN_Q16 {
        reason |= R_SILICON_NOT_OK;
        return GateDecision {
            verdict: Verdict::Reject,
            reason_code: reason,
            question: None,
        };
    }

    GateDecision {
        verdict: Verdict::Commit,
        reason_code: reason,
        question: None,
    }
}
```

### 5\. Emitting replayable atoms in NDJSON

The example below demonstrates how a constitutional decision can be materialized as facts, sets, and a verifiable derivation.

```
use serde_json::{json, Value};

pub fn gate_run_atoms(seed: u64, idx: u64) -> anyhow::Result<Vec<Value>> {
    let contract = ErrorContract {
        epsilon: 0.05,
        zero_guess_domains: vec!["finance"],
        max_questions: 1,
    };

    let intent_fact = attach_cid(json!({
        "t": "atom.fact",
        "v": 1,
        "payload": {"kind": "intent", "idx": idx}
    }))?;

    let evidence_fact = attach_cid(json!({
        "t": "atom.fact",
        "v": 1,
        "payload": {"kind": "evidence", "idx": idx, "anchored": true}
    }))?;

    let policy_fact = attach_cid(json!({
        "t": "atom.fact",
        "v": 1,
        "payload": {"policy": {"epsilon": 0.05, "max_questions": 1}}
    }))?;

    let epoch_fact = attach_cid(json!({
        "t": "atom.fact",
        "v": 1,
        "payload": {"kind": "epoch", "seed": seed}
    }))?;

    let intent_set = attach_cid(json!({
        "t": "atom.set",
        "v": 1,
        "name": "gate:intent_set",
        "members": [intent_fact["cid"].as_str().unwrap()]
    }))?;

    let evidence_set = attach_cid(json!({
        "t": "atom.set",
        "v": 1,
        "name": "gate:evidence_set",
        "members": [evidence_fact["cid"].as_str().unwrap()]
    }))?;

    let silicon = silicon_propose(seed, idx);
    let silicon_fact = attach_cid(json!({
        "t": "atom.fact",
        "v": 1,
        "payload": {
            "kind": "silicon_output",
            "idx": idx,
            "score_q16": silicon.score_q16,
            "risk_q16": silicon.risk_q16,
            "kernel_hash": silicon.kernel_hash
        }
    }))?;

    let decision = gate_run(
        GateInputs {
            domain: "media",
            has_intent: true,
            has_evidence: true,
            evidence_anchored: true,
            policy_ok: true,
            epoch: seed,
            contract: &contract,
        },
        silicon,
    );

    let (outputs, output_atoms) = match decision.verdict {
        Verdict::Commit => {
            let verified_fact = attach_cid(json!({
                "t": "atom.fact",
                "v": 1,
                "payload": {"kind": "verified", "idx": idx}
            }))?;
            let commit_set = attach_cid(json!({
                "t": "atom.set",
                "v": 1,
                "name": "gate:commit_set",
                "members": [verified_fact["cid"].as_str().unwrap()]
            }))?;
            (
                json!([{"set": commit_set["cid"].as_str().unwrap()}]),
                vec![verified_fact, commit_set],
            )
        }
        Verdict::Ghost => {
            let ghost_fact = attach_cid(json!({
                "t": "atom.fact",
                "v": 1,
                "payload": {"kind": "ghost", "idx": idx, "q": decision.question}
            }))?;
            let ghost_set = attach_cid(json!({
                "t": "atom.set",
                "v": 1,
                "name": "gate:ghost_set",
                "members": [ghost_fact["cid"].as_str().unwrap()]
            }))?;
            (
                json!([{"set": ghost_set["cid"].as_str().unwrap()}]),
                vec![ghost_fact, ghost_set],
            )
        }
        Verdict::Reject => {
            let reject_fact = attach_cid(json!({
                "t": "atom.fact",
                "v": 1,
                "payload": {"kind": "reject", "idx": idx, "reason": decision.reason_code}
            }))?;
            (
                json!([{"fact": reject_fact["cid"].as_str().unwrap()}]),
                vec![reject_fact],
            )
        }
    };

    let deriv = attach_cid(json!({
        "t": "atom.derivation",
        "v": 1,
        "z": "gate:v1",
        "op": "gate_run",
        "inputs": [
            {"set": intent_set["cid"].as_str().unwrap()},
            {"set": evidence_set["cid"].as_str().unwrap()},
            {"fact": policy_fact["cid"].as_str().unwrap()},
            {"fact": epoch_fact["cid"].as_str().unwrap()},
            {"fact": silicon_fact["cid"].as_str().unwrap()}
        ],
        "params": {"seed": seed, "idx": idx, "epsilon": contract.epsilon},
        "outputs": outputs
    }))?;

    let mut atoms = vec![
        intent_fact,
        evidence_fact,
        policy_fact,
        epoch_fact,
        intent_set,
        evidence_set,
        silicon_fact,
    ];
    atoms.extend(output_atoms);
    atoms.push(deriv);
    Ok(atoms)
}
```

### 6\. Verification by replay

The verifier does not interpret hidden intentions. It reexecutes the derivation and compares what history claims with what law produces.

```
use std::collections::HashMap;

pub fn verify_gate_run(
    deriv: &Value,
    by_cid: &HashMap<String, Value>,
) -> anyhow::Result<()> {
    let seed = deriv["params"]["seed"].as_u64().unwrap();
    let idx = deriv["params"]["idx"].as_u64().unwrap();

    let contract = ErrorContract {
        epsilon: 0.05,
        zero_guess_domains: vec![],
        max_questions: 1,
    };

    let silicon = silicon_propose(seed, idx);
    let decision = gate_run(
        GateInputs {
            domain: "media",
            has_intent: true,
            has_evidence: true,
            evidence_anchored: true,
            policy_ok: true,
            epoch: seed,
            contract: &contract,
        },
        silicon,
    );

    let outputs = deriv["outputs"].as_array().unwrap();
    match decision.verdict {
        Verdict::Commit => {
            let out_set = outputs[0]["set"].as_str().unwrap();
            let set = &by_cid[out_set];
            if set["name"] != "gate:commit_set" {
                anyhow::bail!("wrong output set");
            }
        }
        Verdict::Ghost => {
            let out_set = outputs[0]["set"].as_str().unwrap();
            let set = &by_cid[out_set];
            if set["name"] != "gate:ghost_set" {
                anyhow::bail!("wrong output set");
            }
        }
        Verdict::Reject => {
            let out_fact = outputs[0]["fact"].as_str().unwrap();
            let fact = &by_cid[out_fact];
            if fact["payload"]["kind"] != "reject" {
                anyhow::bail!("wrong reject fact");
            }
        }
    }

    Ok(())
}
```

* * *

Note on Scale
-------------

The Constitution does not forbid mass; it forbids irresponsibility.

To scale to hundreds of millions of cases on modest hardware:

*   `silicon_propose` may migrate to `wgpu compute`;
*   the gate may remain light and verifiable on CPU;
*   outputs may be compacted by rollup, sampling, and `batch_hash`;
*   proof continues to govern even as throughput grows.

Legitimate scale is compaction of truth, not suppression of trail.

* * *

Minimum conformance
-------------------

An implementation may claim to honor this Constitution only if, at minimum:

*   every computation ends in `Commit`, `Ghost`, or `Reject`;
*   no result is promoted without an admissible contract, receipt, or proof;
*   ambiguity, timeout, and low confidence are never treated as implicit commit;
*   sovereign state remains local, verifiable, and never replaced by model narrative;
*   CIDs, receipts, and replay remain the foundations of legitimacy.

This RFC establishes, therefore, not only a technique but a regime.  
It marks the point at which performance ceases to be sovereign and enters the service of verifiable truth.

* * *

RFC-0002 — Decision as Proof Process
====================================

> **Status:** Normative draft.
> 
> This RFC succeeds earlier formulations of the same system and becomes the canonical reference for proof-oriented decision.

Summary
-------

This RFC declares that the system does not perform an inference and then attempt a justification. It executes an incremental proof process in which each transition consumes explicit budget, produces a verifiable receipt, and changes a state whose history can be reconstructed by third parties.

The final decision is not a magical moment. It is only the terminal of an auditable chain.

0\. Thesis
----------

The runtime is not the authority.  
The transcript is the authority.

The contract is not decorative normative text.  
The contract is the governing program.

An output does not count because it was produced.  
It counts only when it comes accompanied by sufficient, replayable, verifiable proof.

From this follow four fundamental consequences:

*   each case is a clean session;
*   each advance is transactional;
*   each cost is debited explicitly;
*   each terminal is a verdict sustained by transcript.

* * *

1\. Objective
-------------

Define a runtime in which:

*   each case begins without residual memory;
*   each admissible step is explicitly typed;
*   the contract is hashed, versioned, and executable;
*   external witnesses enter only through declared paths;
*   the final proof can be verified without trust in the original executor.

* * *

2\. Main semantic shift
-----------------------

In simpler formulations, the system operated with three direct states: `Commit`, `Ghost`, and `Reject`.

This RFC introduces a more rigorous model:

```
pub enum StepDecision {
    Commit,
    Continue(StepAction),
    Reject(RejectReason),
}
```

The reason is structural:

*   `Commit` remains terminal;
*   `Reject` remains terminal;
*   the intermediate state is not a mood of the system, but the next step of the protocol.

The name `Ghost` remains useful, but it should be reserved for classes of action or witness, not for the central axis of decision.

* * *

3\. Invariants
--------------

**I1 — Clean session**

Each case is born with:

*   `case_id`;
*   hashed contract;
*   initial budget;
*   initial inputs;
*   empty transcript.

No invisible cache across cases may participate in legitimacy.

**I2 — Every progression is transactional**

All evolution of the case occurs by means of a single `StepAction`, with:

*   cost;
*   receipt;
*   new state;
*   new `state_root`.

**I3 — Without transcript, there is no valid decision**

No terminal is legitimate without a verifiable event chain.

**I4 — Without hashed contract, there is no law**

Every session points to an explicitly identified contract.

**I5 — Without state root, history weakens**

Each transition must record the canonical summary of the subsequent state.

**I6 — Budget is binding**

If the next step exceeds the remaining budget, the system may not proceed.

* * *

4\. Boundary of the runtime
---------------------------

The runtime must do only four things:

1.  execute an atomic action;
2.  measure cost;
3.  emit a receipt;
4.  deliver the new state to the contract.

The runtime does not govern policy.  
It is a disciplined executor.

* * *

5\. Boundary of the contract
----------------------------

The contract must do only two things:

1.  validate the transcript and the current state;
2.  decide the next step or the terminal.

In short:

*   the runtime executes;
*   the contract governs.

That separation is the backbone of this RFC.

* * *

6\. Session state
-----------------

```
pub struct Session {
    pub case_id: String,
    pub contract_hash: String,
    pub proof_mode: ProofMode,

    pub initial_budget: u64,
    pub budget_remaining: u64,

    pub state_root: String,
    pub atoms: AtomStoreView,

    pub transcript_head: Option<String>,
    pub event_count: u64,

    pub current_proposal: Option<ProposalRef>,
}
```

### Notes

*   `Session` need not carry the full materialization in memory.
*   `atoms` may be a partial view, provided it is sufficient for the current decision.
*   `state_root` is the canonical summary of the case at that instant.
*   `current_proposal` is a reference to a verifiable artifact, never invisible magical state.

* * *

7\. Action types
----------------

Admissible actions must distinguish computation, materialization, and witness.

```
pub enum StepAction {
    Compute(ComputeAction),
    Materialize(MaterializeAction),
    Witness(WitnessAction),
}
```

### 7.1 `ComputeAction`

Purely computational and replayable action.

```
pub enum ComputeAction {
    Propose {
        proposer_id: String,
        input_set_cid: String,
    },
    RunExpert {
        expert_id: String,
        input_set_cid: String,
    },
    RecomputePath {
        derivation_cid: String,
    },
}
```

### 7.2 `MaterializeAction`

Rehydration, pagination, or explicit loading action.

```
pub enum MaterializeAction {
    RehydrateAtom {
        cid: String,
    },
    RetrieveEvidence {
        query_cid: String,
        top_k: u8,
    },
    LoadModule {
        module_id: String,
    },
}
```

### 7.3 `WitnessAction`

Acquisition of external, human, or environmental fact.

```
pub enum WitnessAction {
    AskUserBit {
        question_id: String,
        left: String,
        right: String,
    },
    AskUserField {
        field_id: String,
    },
    GetTime {
        oracle_id: String,
    },
    FetchExternalAtom {
        locator: String,
        expected_cid: Option<String>,
    },
}
```

Not every step is inference.  
Some steps are witnesses necessary to the legitimacy of the case.

* * *

8\. Cost and budget
-------------------

Every `StepAction` must carry explicit cost.

```
pub struct ActionCost {
    pub gas: u64,
}
```

Cost policy may be declared by the contract or calculated according to a table authorized by it.

```
pub trait Contract {
    fn eval_step(&self, session: &SessionView) -> StepDecision;
    fn cost_of(&self, action: &StepAction, session: &SessionView) -> ActionCost;
    fn determinism_profile(&self) -> DeterminismProfile;
}
```

`gate_run`, defined in RFC-0001, should be read as a concrete constitutional case of this abstract contract.

### Rule

Cost is debited before execution.

If there is insufficient balance, the result is:

*   `Reject(OutOfBudget)`

* * *

9\. Determinism profile
-----------------------

Every session must declare the exact regime under which it may be replayed.

```
pub struct DeterminismProfile {
    pub fixed_point_only: bool,
    pub allow_user_input: bool,
    pub allow_time_oracle: bool,
    pub allow_external_fetch: bool,
    pub wasm_abi_version: u32,
}
```

### Laws

*   no implicit clock;
*   no implicit entropy;
*   no implicit network;
*   every external source enters as `WitnessAction`;
*   every relevant computation must be replayable under the same profile.

What cannot be redone deterministically must appear as recorded witness.

* * *

10\. Chained transcript
-----------------------

The transcript is not a list; it is a hashed chain of state.

```
pub struct StepEvent {
    pub prev_event_cid: Option<String>,
    pub action_cid: String,
    pub receipt_cid: String,

    pub budget_before: u64,
    pub budget_after: u64,

    pub state_root_before: String,
    pub state_root_after: String,
}
```

### Rule

Each event must render the following verifiable:

*   the action requested;
*   the receipt emitted;
*   the budget consumed;
*   the transition of `state_root`.

History thus ceases to be narrative and becomes an evidentiary chain.

* * *

11\. Receipts
-------------

Every executed action generates a typed receipt.

```
pub enum StepReceipt {
    ProposalCreated {
        proposal_cid: String,
        proposer_hash: String,
    },
    ExpertOutput {
        output_set_cid: String,
        expert_hash: String,
    },
    AtomRehydrated {
        atom_cid: String,
        bytes: u64,
    },
    EvidenceRetrieved {
        result_set_cid: String,
    },
    UserBitWitnessed {
        question_id: String,
        answer: bool,
    },
    UserFieldWitnessed {
        field_id: String,
        value_cid: String,
    },
    TimeWitnessed {
        oracle_id: String,
        timestamp_ms: u64,
    },
    ExternalAtomFetched {
        atom_cid: String,
    },
}
```

The receipt is the smallest unit of operational proof.

* * *

12\. Proposal as artifact, not shadow
-------------------------------------

A proposal must exist as a hashable, materialized object.

```
pub struct FrugalProposal {
    pub hypothesis_cid: String,
    pub score_q16: u32,
    pub risk_q16: u32,
    pub required_atoms: Vec<String>,
    pub required_modules: Vec<String>,
    pub producer_hash: String,
}

pub struct ProposalRef {
    pub proposal_cid: String,
}
```

The session stores a reference, not private magic.

* * *

13\. `ProofMode`
----------------

The system must make explicit the portability form of the proof.

```
pub enum ProofMode {
    FullSelfContained,
    AnchoredImmutableRefs,
}
```

### 13.1 `FullSelfContained`

Carries everything necessary for complete offline replay:

*   contract or bytecode;
*   full transcript;
*   witnesses;
*   required atoms;
*   relevant modules.

### 13.2 `AnchoredImmutableRefs`

Carries only what is necessary for audit against external immutable storage:

*   transcript;
*   CIDs and hashes;
*   immutable references;
*   minimum witnesses.

* * *

14\. `ProofPack`
----------------

```
pub struct ProofPack {
    pub case_id: String,
    pub proof_mode: ProofMode,

    pub contract_hash: String,
    pub initial_budget: u64,

    pub transcript_head: Option<String>,
    pub event_count: u64,

    pub final_state_root: String,
    pub final_outcome: FinalOutcome,
}

pub enum FinalOutcome {
    Commit {
        output_cid: String,
    },
    Reject {
        reason: RejectReason,
    },
}
```

### Requirement

A third party must be able to:

*   reconstruct the initial session;
*   traverse the transcript;
*   reexecute the transitions;
*   confirm the final outcome.

* * *

15\. Typed rejection
--------------------

```
pub enum RejectReason {
    OutOfBudget,
    MissingMinimumEvidence,
    UnanchoredEvidence,
    ZeroGuessViolation,
    DeterminismViolation,
    ContractViolation,
    InvalidWitness,
    InvalidTranscript,
    InternalExecutionFailure,
}
```

Rejection must not be free text.  
It must be a machine-legible juridical state.

* * *

16\. Normative loop
-------------------

```
pub fn run(
    mut session: Session,
    contract: &dyn Contract,
    rt: &mut dyn RuntimeOps,
) -> Result<ProofPack, RejectReason> {
    loop {
        let view = SessionView::from(&session);
        match contract.eval_step(&view) {
            StepDecision::Commit => {
                return Ok(build_proof_pack(
                    session,
                    FinalOutcome::Commit {
                        output_cid: resolve_final_output_cid(&view)?,
                    },
                ));
            }
            StepDecision::Reject(reason) => {
                return Ok(build_proof_pack(
                    session,
                    FinalOutcome::Reject { reason },
                ));
            }
            StepDecision::Continue(action) => {
                let cost = contract.cost_of(&action, &view);

                if session.budget_remaining < cost.gas {
                    return Ok(build_proof_pack(
                        session,
                        FinalOutcome::Reject {
                            reason: RejectReason::OutOfBudget,
                        },
                    ));
                }

                let budget_before = session.budget_remaining;
                session.budget_remaining -= cost.gas;

                let state_root_before = session.state_root.clone();
                let receipt = rt.execute(&session, &action)?;
                session = apply_receipt(session, &action, &receipt)?;
                let state_root_after = session.state_root.clone();

                let event = StepEvent {
                    prev_event_cid: session.transcript_head.clone(),
                    action_cid: cid(&action)?,
                    receipt_cid: cid(&receipt)?,
                    budget_before,
                    budget_after: session.budget_remaining,
                    state_root_before,
                    state_root_after,
                };

                let event_cid = cid(&event)?;
                session.transcript_head = Some(event_cid);
                session.event_count += 1;
            }
        }
    }
}
```

The loop does not think.  
The loop preserves the legality of the process.

* * *

17\. `RuntimeOps`
-----------------

The runtime must be deliberately minimal.

```
pub trait RuntimeOps {
    fn execute(&mut self, session: &Session, action: &StepAction) -> anyhow::Result<StepReceipt>;
}
```

Nothing of policy.  
Nothing of silent authority.  
Nothing of "maybe."

* * *

18\. Universal verifier
-----------------------

```
pub trait UniversalVerifier {
    fn verify(&self, pack: &ProofPack) -> anyhow::Result<()>;
}
```

It must:

1.  resolve the contract by `contract_hash`;
2.  reconstruct the initial session;
3.  traverse the transcript in order;
4.  reexecute each transition under the declared profile;
5.  compare budget, state, and receipts;
6.  validate the `final_outcome`.

The verifier trusts only law, transcript, witnesses, and replay.

* * *

19\. Session without residual memory
------------------------------------

The runtime must not depend on:

*   invisible global cache;
*   warm state between cases;
*   embeddings persisted outside proof;
*   experts inherited from the previous session as a foundation of validity.

Physical reuse may exist as optimization, never as epistemic condition.

* * *

20\. Contract as governing program
----------------------------------

### Requirements of the executable contract

*   hashable;
*   versioned;
*   sandboxable;
*   deterministically replayable under `DeterminismProfile`;
*   incapable of implicit I/O;
*   incapable of mutating state outside the session.

### Recommendation

WASM is a natural target, provided the contract remains restricted law, not arbitrary application.

### Decisive formula

Contract is a governing program, not general sovereign software.

* * *

21\. Main risk and containment
------------------------------

The greatest risk of this RFC is degeneration into a generic VM.

The correct containment is threefold:

*   minimal runtime;
*   restricted contract;
*   hashed external modules called explicitly.

The architecture remains radical without dissolving its identity.

* * *

22\. Philosophical consequence
------------------------------

The relevant computation is not merely the forward pass.

The relevant computation is the chain of transitions that constructs a verifiable certificate.

That is the true unit of decision in this system.

* * *

23\. Crate shape
----------------

```
proof_runtime/
  src/
    lib.rs
    session.rs
    contract.rs
    decision.rs
    action.rs
    receipt.rs
    event.rs
    proof.rs
    reject.rs
    verifier.rs
    runtime.rs
    cid.rs
    state_root.rs
    determinism.rs
```

`lib.rs`:

```
pub mod action;
pub mod cid;
pub mod contract;
pub mod decision;
pub mod determinism;
pub mod event;
pub mod proof;
pub mod receipt;
pub mod reject;
pub mod runtime;
pub mod session;
pub mod state_root;
pub mod verifier;
```

* * *

Minimum conformance
-------------------

An implementation is minimally conformant only if:

*   every session produces a `ProofPack` when it terminates;
*   each step generates a verifiable `StepEvent`;
*   `StepDecision` is always `Commit`, `Continue`, or `Reject`;
*   the transcript is append-only and auditable;
*   `WitnessAction` is the only path through which external evidence may enter;
*   the error contract remains binding throughout the entire session.

* * *

Normative mantra
----------------

To decide is to prove.  
To advance is to transact.  
To execute is to emit a receipt.  
Validity is transcript plus contract plus replay.

Short form:

*   no hidden state
*   no silent authority
*   only steps
*   only receipts
*   only proof

* * *

Verdict
-------

This RFC turns the act of deciding into a verifiable historical process.

It reduces the runtime to its proper office, elevates the transcript to the status of authority, and converts the contract into executable law. From this point onward, legitimate decision ceases to be a psychological event of the system and becomes a proved fact.

* * *

RFC-0003 — Sovereign Atom Space
===============================

> **Status:** Normative draft.
> 
> Subtitle: Storage under Epistemic Law.
> 
> In this RFC, imperative terms carry normative force equivalent to MUST / MUST NOT.

Summary
-------

If RFC-0001 defined the legitimacy of decision and RFC-0002 defined the proof process, this RFC defines the ground on which that history can survive without semantic corruption.

Its purpose is to replace the imagination of a mutable database with a regime of knowledge that is content-addressed, immutable by construction, local-first by nature, and federable through the exchange of CIDs.

0\. Central thesis
------------------

In proof-oriented systems, the mutable database is an epistemological anti-pattern.

If a record can undergo `UPDATE`, cryptographic history weakens.  
If history weakens, replay becomes fragile.  
If replay becomes fragile, proof degenerates into narrative.

Therefore this system affirms:

*   local disk is not dead archive; it is thermodynamic cache;
*   truth does not reside in tables; it resides in immutable content-addressed graphs;
*   legitimate mutation is the emission of a new atom followed by pointer advancement;
*   controlled forgetting is not failure, but a mechanism of survival.

* * *

1\. Objective
-------------

Define a storage subsystem in which:

*   CID is the only canonical form of access to knowledge;
*   everything, from the smallest witness to the largest model, obeys the same law of the universal atom;
*   the local device can operate offline without losing auditability;
*   the dependencies of a `ProofPack` can be resolved without trusting the origin of the bytes.

* * *

2\. Constitutional invariants
-----------------------------

**I1 — Without CID, there is no canonical existence**

No subsystem may fetch knowledge by semantic ID as primary authority. Semantic resolutions are auxiliary; truth always enters by CID.

**I2 — Mutation is forbidden inside the atom**

Once materialized in `AtomSpace`, the content of an atom never changes. Every legitimate change is the emission of a new atom.

**I3 — Absence is admissible**

It is constitutional to know the hash of an atom without possessing its payload locally. The system can prove chains even when it still needs to rehydrate dependencies.

**I4 — Eviction is part of physical law**

When limits of RAM, VRAM, or disk are reached, the system must cool less-prioritized knowledge. The machine's thermal survival is not an operational detail; it is part of the architecture.

* * *

3\. Anatomy of the universal atom
---------------------------------

There are no sovereign tables. There is one common format capable of carrying any materially relevant fact, subjecting the giant and the trivial alike to the same gravitational law: the universal atom.

```
pub struct UniversalAtom {
    pub header: AtomHeader,
    pub links: Vec<String>,
    pub payload: Vec<u8>,
}

pub struct AtomHeader {
    pub kind: AtomKind,
    pub size_bytes: u64,
    pub producer_hash: String,
    pub signature: Option<String>,
}

pub enum AtomKind {
    Weights,
    WasmContract,
    PromptText,
    ProofPack,
    StateRoot,
    WitnessData,
}
```

The system does not distinguish the large from the small by juridical nature.  
It distinguishes them only by weight, heat, and function.

* * *

4\. Epistemic thermodynamics
----------------------------

The machine must know not only what exists, but in what degree of presence that knowledge currently stands.

```
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum EpistemicHeat {
    Absent,
    Cold,
    Warm,
    Hot,
}
```

### Semantics

*   `Absent`: the CID is known, but there are no local bytes.
*   `Cold`: header and links are available, but the payload is outside fast memory.
*   `Warm`: an operational summary is present in useful memory.
*   `Hot`: the full payload is loaded and ready for use.

### Transition rule

The runtime performs no direct I/O. It emits `MaterializeAction::RehydrateAtom`; `AtomSpace` promotes the knowledge to the required thermal level, cooling other atoms if necessary.

* * *

5\. Storage contract
--------------------

```
pub trait AtomSpace {
    fn current_heat(&self, cid: &str) -> EpistemicHeat;
    fn heat_up(&mut self, cid: &str, target: EpistemicHeat) -> Result<(), PageFault>;
    fn cool_down(&mut self, cid: &str) -> Result<(), ()>;
    fn materialize(&mut self, atom: UniversalAtom) -> Result<String, StorageError>;
    fn get_thermal_metrics(&self) -> ThermalMetrics;
}

pub enum PageFault {
    NetworkRequired { cid: String },
    BudgetExhausted { required: u64, available: u64 },
    CorruptedCid { expected: String, actual: String },
}
```

Recommended minimum structure for `ThermalMetrics`:

```
pub struct ThermalMetrics {
    pub hot_bytes: u64,
    pub warm_bytes: u64,
    pub cold_bytes: u64,
    pub absent_count: u64,
    pub total_atoms: u64,
}
```

Storage is not mere persistence.  
It is physical management of presence under epistemic law.

* * *

6\. Epistemic pointers
----------------------

If atoms are immutable, the live state of the system must move by means of minimal, auditable pointers.

```
pub struct StatePointer {
    pub alias: String,
    pub head_cid: String,
    pub sequence_number: u64,
    pub authority_signature: String,
}
```

### Law of pointers

*   the pointer does not contain truth; it contains direction;
*   the pointer does not replace proof; it points to it;
*   destroying the pointer registry does not destroy the universe of the system, provided the `ProofPacks` survive.

For federated context, RFC-0004 extends this structure with `prev_head_cid` and `authority_id`.

* * *

7\. Local-first synchronization
-------------------------------

Correct synchronization between devices is not database reconciliation, but exchange of heads and missing dependencies.

Canonical flow:

1.  the local device emits a `ProofPack` offline;
2.  it advances its local `StatePointer`;
3.  once connectivity returns, it announces only the pointer advance;
4.  the remote peer verifies whether it possesses the announced CID;
5.  if material is missing, it requests only the necessary blocks;
6.  it receives bytes, verifies CIDs, and reexecutes the proof;
7.  it accepts or rejects the advance locally.

There is no merge of truth.  
There is only verifiable replication of graphs.

* * *

8\. Integration with the previous RFCs
--------------------------------------

The complete machine operates as follows:

1.  RFC-0003 resolves the contract and its atoms by pointer and CID;
2.  RFC-0002 starts the clean session;
3.  RFC-0001 governs the decision through the gate and the error contract;
4.  RFC-0003 materializes the necessary data when they are missing;
5.  RFC-0002 emits the final `ProofPack`;
6.  RFC-0003 preserves that `ProofPack` as part of the local sovereign universe.

Storage thus ceases to be passive infrastructure and becomes the physical stage of proof.

* * *

9\. Suggested crate layout
--------------------------

```
epistemic_storage/
  src/
    lib.rs
    atom.rs
    heat.rs
    pager.rs
    cas.rs
    pointers.rs
    network.rs
```

* * *

10\. Normative mantra
---------------------

State is a pointer.  
Knowledge is a graph.  
Disk is a cache.  
Forgetfulness is survival.

* * *

Minimum conformance
-------------------

An implementation is minimally conformant only if it:

*   accesses canonical knowledge by CID;
*   treats atoms as immutable after materialization;
*   permits local absence of payload without destroying chain verifiability;
*   implements explicit thermal transitions for the presence of data;
*   represents state mutation by pointer advancement over immutable graphs.

* * *

Verdict
-------

This RFC gives the system its geography.

With it, state ceases to be mutable anxiety and becomes direction over verifiable history. Disk becomes cache, cache becomes thermodynamics, and memory ceases to be sovereign so that it may serve proof.

* * *

RFC-0004 — Federation under Proof-Carrying State
================================================

> **Status:** Normative draft.
> 
> This RFC defines the federative layer of a local-first, zero-trust, proof-oriented system in which shared state is represented by signed pointers over immutable content-addressed graphs.

Summary
-------

The federation defined here does not synchronize mutable memory. It arbitrates signed advances over verifiable proof.

Its purpose is to allow coexistence among local sovereignties without regression to distributed mutable database, silent overwrite, or blind trust in remote infrastructure.

0\. Status
----------

Normative draft.

* * *

1\. Scope
---------

This RFC specifies:

*   identity of nodes and authorities;
*   advancement of `StatePointer`;
*   announcement of advances;
*   local acceptance of remote advances;
*   detection and preservation of fork;
*   resolution by policy;
*   anti-rewind protection;
*   optional quorum;
*   integration with `ProofPack`, `AtomSpace`, and contract.

This RFC does not specify:

*   any particular physical transport;
*   any concrete signature algorithm;
*   peer-to-peer discovery;
*   universal global consensus;
*   domain-specific business policy.

* * *

2\. Normative thesis
--------------------

The federation MUST NOT synchronize mutable state.

It MUST exchange only:

*   CIDs;
*   `ProofPacks`;
*   signed `StatePointers`;
*   announcements;
*   acceptance receipts;
*   conflict artifacts.

Federative consensus, in this context, is not universal truth. It is local, verifiable, policy-dependent agreement about which proof has the right to advance which pointer in which namespace.

* * *

3\. Normative terms
-------------------

*   **Accept**: to recognize an advance locally as valid under local policy.
*   **Announce**: to publish a candidate advance.
*   **Authority**: an entity authorized to advance or witness within a namespace.
*   **Fork**: the existence of two or more incompatible heads for the same alias.
*   **Pointer**: the minimal mutable record that points to an immutable head.
*   **Proof-Carrying State**: state whose advance is legitimate only when accompanied by replayable proof.

* * *

4\. Invariants
--------------

**I1 — Truth remains outside the federation**

No remote node is primary authority over factual truth. Truth continues to reside in atoms, transcript, hashed contract, receipts, and replayable proof.

**I2 — Pointer advance requires proof**

A new `StatePointer` may not be accepted without valid signature, recognized authority, satisfied policy, and verifiable or resolvable proof.

**I3 — Reception does not imply acceptance**

Receiving bytes, CIDs, or announcements is never equivalent to accepting them.

**I4 — Fork is a first-class object**

Competing heads must be preserved as explicit conflict until resolution or formal coexistence.

**I5 — Anti-rewind is mandatory**

Silent regression of sequence or head is forbidden.

**I6 — Policy is local**

Even data from a trusted source remain subject to local acceptance policy.

* * *

5\. Identity and authority
--------------------------

### 5.1 `NodeIdentity`

```
pub struct NodeIdentity {
    pub node_id: String,
    pub public_key: String,
    pub roles: Vec<NodeRole>,
}

pub enum NodeRole {
    EdgeExecutor,
    PointerAuthority,
    WitnessAuthority,
    ContractPublisher,
    Mirror,
}
```

### Rules

*   each `node_id` must map to a single active public key per trust epoch;
*   a node may accumulate roles;
*   role does not imply universal authority.

### 5.2 Authority namespace

Authority is always namespaced.

```
pub struct AuthorityGrant {
    pub authority_id: String,
    pub namespace_prefix: String,
    pub allowed_roles: Vec<NodeRole>,
    pub valid_from_epoch: u64,
    pub valid_until_epoch: Option<u64>,
}
```

An authority valid for `contracts:*` is not automatically valid for `cases:*`.

* * *

6\. `StatePointer`
------------------

```
pub struct StatePointer {
    pub alias: String,
    pub prev_head_cid: Option<String>,
    pub head_cid: String,
    pub sequence_number: u64,
    pub authority_id: String,
    pub authority_signature: String,
}
```

### 6.1 Normative rules

A candidate pointer must satisfy:

1.  `alias` must not be empty;
2.  `head_cid` must be syntactically valid;
3.  `sequence_number > 0`;
4.  valid signature over canonical content;
5.  authority recognized for the namespace;
6.  `prev_head_cid` consistent with local policy or explicitly treated as fork.

### 6.2 Anti-rewind

Given a `last_seen_pointer`, the new pointer must be rejected if:

*   `sequence_number < last_seen.sequence_number`;
*   `sequence_number == last_seen.sequence_number` and `head_cid != last_seen.head_cid`;
*   `prev_head_cid != Some(last_seen.head_cid)` in a namespace that does not admit fork;
*   the signature is invalid;
*   the authority is not authorized.

### Exception

If the policy of the alias admits fork, the candidate may be registered as explicit conflict instead of rejected.

* * *

7\. Pointer classes
-------------------

```
pub enum PointerClass {
    Personal,
    SharedCase,
    ContractHead,
    WitnessLog,
    MirrorIndex,
}

pub struct PointerPolicy {
    pub alias_prefix: String,
    pub class: PointerClass,
    pub accepted_authorities: Vec<String>,
    pub requires_quorum: bool,
    pub quorum_size: u32,
    pub allow_forks: bool,
    pub require_proof_pack: bool,
}
```

### Rules

*   every alias must match exactly one effective policy;
*   in case of multiple matches, the most specific policy prevails;
*   absence of policy implies lack of authorization.

* * *

8\. Announcement protocol
-------------------------

```
pub struct PointerAnnouncement {
    pub pointer: StatePointer,
    pub proof_pack_cid: String,
    pub contract_hash: String,
    pub announcer_node_id: String,
    pub announcement_signature: String,
}
```

### Rules

*   every announcement must be signed by the announcer;
*   it must reference `proof_pack_cid` whenever policy requires proof;
*   it may not carry inline mutable state as primary authority;
*   dependency hints may exist, but they never replace CID-based verification.

* * *

9\. Dependency resolution
-------------------------

```
pub enum DependencyStatus {
    Complete,
    Missing(Vec<String>),
}

pub trait FederationTransport {
    fn announce(&mut self, msg: PointerAnnouncement) -> anyhow::Result<()>;
    fn request_atoms(&mut self, cids: &[String]) -> anyhow::Result<Vec<UniversalAtom>>;
    fn request_proof_pack(&mut self, cid: &str) -> anyhow::Result<ProofPack>;
}
```

### Rules

*   dependencies are always resolved by CID;
*   a node may not accept a head whose necessary proof is not verifiable;
*   announcements may remain `Deferred` while dependencies are missing;
*   transport is a source of candidate bytes, never a source of truth.

* * *

10\. Acceptance
---------------

```
pub enum AcceptanceVerdict {
    Accepted,
    Rejected(AcceptRejectReason),
    ForkDetected,
    Deferred,
}

pub enum AcceptRejectReason {
    MissingDependencies,
    InvalidSignature,
    InvalidProof,
    InvalidContract,
    AuthorityViolation,
    RewindAttempt,
    SequenceGap,
    PolicyViolation,
}
```

### Rule

Every announcement must produce exactly one local verdict. Silence or timeout never equals acceptance.

* * *

11\. `AcceptanceReceipt`
------------------------

```
pub struct AcceptanceReceipt {
    pub pointer_alias: String,
    pub head_cid: String,
    pub verifier_node_id: String,
    pub verdict: AcceptanceVerdict,
    pub reason: Option<AcceptRejectReason>,
    pub verifier_signature: String,
}
```

### Rules

*   every acceptance receipt must be verifiable and signable;
*   `reason` must exist in case of rejection;
*   receipts may federate, but they do not advance a pointer by themselves.

* * *

12\. Pointer validation
-----------------------

```
pub trait PointerValidator {
    fn validate_pointer(
        &self,
        new_pointer: &StatePointer,
        previous: Option<&StatePointer>,
        fed: &FederationView,
    ) -> AcceptanceVerdict;
}
```

### Minimum validator rules

The validator must check:

*   pointer signature;
*   monotonicity of sequence;
*   consistency of `prev_head_cid`;
*   authority for the namespace;
*   existence of applicable policy.

It must not assume for itself complete proof verification, which belongs to the acceptance pipeline.

* * *

13\. Proof verification before acceptance
-----------------------------------------

When policy requires proof, the receiver must:

1.  resolve the `ProofPack`;
2.  resolve the necessary dependencies;
3.  verify the pack with `UniversalVerifier`;
4.  confirm that `contract_hash` is recognized;
5.  confirm that the announced head corresponds to the verified result.

If any step fails, the announcement must be rejected or deferred, never accepted by benevolence.

* * *

14\. `FederationView`
---------------------

```
pub struct FederationView {
    pub recognized_nodes: Vec<NodeIdentity>,
    pub accepted_contract_hashes: Vec<String>,
    pub pointer_policies: Vec<PointerPolicy>,
    pub acceptance_receipts: Vec<AcceptanceReceipt>,
}
```

### Rules

*   `recognized_nodes` must suffice to verify recognized authorities;
*   `accepted_contract_hashes` list only laws accepted locally;
*   `pointer_policies` must resolve aliases deterministically.

* * *

15\. Forks
----------

```
pub struct PointerFork {
    pub alias: String,
    pub base_head_cid: Option<String>,
    pub competing_heads: Vec<String>,
    pub detected_by: String,
}
```

### Rules

*   valid competition among heads must be recorded as `PointerFork` or treated explicitly by policy;
*   silent overwrite is forbidden;
*   all relevant known heads must be preserved in the fork artifact.

* * *

16\. `ResolutionPolicy`
-----------------------

```
pub trait ResolutionPolicy {
    fn resolve(&self, fork: &PointerFork, ctx: &FederationView) -> ResolutionOutcome;
}

pub enum ResolutionOutcome {
    ChooseHead { head_cid: String },
    PreserveFork,
    RequireHumanWitness,
    RequireQuorum,
    RejectAll,
}
```

### Rules

*   resolution must be explicit;
*   choosing a head requires an auditable trail of reasons;
*   `PreserveFork` may be a legitimate final result in multiversioned namespaces;
*   `RequireHumanWitness` and `RequireQuorum` must point to measurable policy.

* * *

17\. Quorum
-----------

```
pub struct QuorumProof {
    pub alias: String,
    pub head_cid: String,
    pub acceptance_receipt_cids: Vec<String>,
}

pub enum PointerStatus {
    LocalOnly,
    Announced,
    FederallyAccepted,
    Rejected,
    Forked,
}
```

### Rules

*   when `requires_quorum = true`, a head may not be marked `FederallyAccepted` without sufficient receipts;
*   `quorum_size` must be greater than zero;
*   quorum receipts must come from distinct, recognized nodes;
*   nodes outside the namespace of trust do not count toward quorum.

* * *

18\. Sequence gaps
------------------

If a node receives a pointer with `sequence_number > last_seen + 1`, it may:

*   reject with `SequenceGap`;
*   defer as `Deferred`;
*   request intermediate pointers.

It may not presume that intermediate history is irrelevant, absent explicit policy to the contrary.

* * *

19\. Federation of contracts
----------------------------

```
pub struct ContractAnnouncement {
    pub contract_hash: String,
    pub contract_cid: String,
    pub publisher_id: String,
    pub publisher_signature: String,
}
```

### Rules

*   an announced contract must come from an authorized publisher;
*   a `ProofPack` under an unrecognized contract may not be accepted;
*   contract update should prefer its own pointer, such as `contracts:<namespace>:head`.

* * *

20\. Federation of witnesses
----------------------------

```
pub struct WitnessReceipt {
    pub witness_kind: String,
    pub payload_cid: String,
    pub witness_authority_id: String,
    pub witness_signature: String,
}
```

### Rules

*   every federated witness must be signed by a recognized authority for that witness type;
*   a witness does not count outside its namespace without explicit policy;
*   witnesses may participate in fork resolution and proof verification.

* * *

21\. Processing pipeline
------------------------

```
pub trait AnnouncementProcessor {
    fn process_announcement(
        &mut self,
        ann: &PointerAnnouncement,
    ) -> anyhow::Result<AcceptanceReceipt>;
}
```

### Normative order

When processing an announcement, the implementation must:

1.  verify the signature of the announcement;
2.  validate the syntax of the pointer;
3.  locate the policy for the alias;
4.  compare against the previously known pointer;
5.  resolve minimum dependencies;
6.  verify the proof, if required;
7.  evaluate conflict or fork;
8.  emit `AcceptanceReceipt`.

No shared pointer may advance without an equivalent trail of acceptance.

* * *

22\. `ForkRegistry`
-------------------

```
pub trait ForkRegistry {
    fn register_fork(&mut self, fork: PointerFork) -> anyhow::Result<()>;
    fn list_forks(&self, alias: &str) -> Vec<PointerFork>;
}
```

A detected fork must be persisted as an auditable object. Later resolution does not erase its historical existence.

* * *

23\. `ResolutionEngine`
-----------------------

```
pub trait ResolutionEngine {
    fn resolve_fork(
        &self,
        fork: &PointerFork,
        fed: &FederationView,
    ) -> anyhow::Result<ResolutionOutcome>;
}
```

### Rules

*   the resolver depends only on policy and verifiable artifacts;
*   it does not choose a head by informal source preference;
*   it must be deterministic for the same set of inputs.

* * *

24\. Local sovereignty
----------------------

The federation must preserve local sovereignty:

*   a locally valid proof is not destroyed by remote rejection;
*   cloud is not implicit authority;
*   a node may maintain `LocalOnly` state;
*   remote acceptance promotes federative status, but does not redefine the intrinsic cryptographic validity of the `ProofPack`.

* * *

25\. Failure modes
------------------

A conformant implementation must distinguish at least:

*   transport failure;
*   signature failure;
*   policy failure;
*   dependency failure;
*   replay or proof failure;
*   rewind attempt;
*   fork detected;
*   unknown contract.

These failures may not collapse into generic error when federative acceptance is affected.

* * *

26\. Security
-------------

### Attacks to resist

*   silent overwrite of head;
*   replay of old pointer;
*   announcement with invalid signature;
*   malicious unrecognized contract;
*   invalid but well-formed `ProofPack`;
*   injection of incorrect dependency;
*   quorum forged by unrecognized nodes.

### Minimum requirement

A conformant implementation must detect and not accept such cases without explicit policy.

* * *

27\. Suggested crate layout
---------------------------

```
proof_federation/
  src/
    lib.rs
    node.rs
    pointer.rs
    announcement.rs
    acceptance.rs
    fork.rs
    policy.rs
    resolution.rs
    transport.rs
    validator.rs
    quorum.rs
```

`lib.rs`:

```
pub mod acceptance;
pub mod announcement;
pub mod fork;
pub mod node;
pub mod pointer;
pub mod policy;
pub mod quorum;
pub mod resolution;
pub mod transport;
pub mod validator;
```

* * *

28\. Canonical flow
-------------------

### Simple accepted advance

1.  Node A generates `ProofPack`.
2.  Node A creates `StatePointer`.
3.  Node A emits `PointerAnnouncement`.
4.  Node B validates signature and policy.
5.  Node B resolves proof and dependencies.
6.  Node B executes `UniversalVerifier`.
7.  Node B accepts locally.
8.  Node B emits `AcceptanceReceipt`.

### Fork case

1.  Node A announces `head_1`.
2.  Node C announces `head_2` for the same alias and base.
3.  Node B detects incompatibility.
4.  Node B registers `PointerFork`.
5.  Node B applies `ResolutionPolicy`.
6.  The result chooses, preserves, requests witness, or requires quorum.

* * *

29\. Minimum conformance
------------------------

An implementation is minimally conformant only if it:

*   validates pointer signature;
*   applies anti-rewind;
*   resolves dependencies by CID;
*   verifies `ProofPack` when required;
*   treats fork as explicit object;
*   emits `AcceptanceReceipt`;
*   separates reception from acceptance.

* * *

30\. Normative mantra
---------------------

State does not merge.  
Heads compete.  
Proof decides.  
Policy accepts.

Hard form:

*   no blind trust
*   no silent overwrite
*   only signed heads
*   only verifiable advances

* * *

31\. Architectural verdict
--------------------------

This RFC closes the political layer of the machine.

RFC-0001 defines who may decide.  
RFC-0002 defines how proof is built.  
RFC-0003 defines where immutable knowledge lives.  
RFC-0004 defines how local sovereigns coexist without surrendering to the myth of shared mutable state.

The sustaining formula is definitive:

Federation is not synchronization of memory.  
Federation is arbitration of signed advances over verifiable proof.

* * *

RFC-0005 — Non-Chat Manager Plane
=================================

> **Status:** Normative draft.
> 
> This RFC defines the non-conversational management plane for proof-oriented systems, in which the manager is an event-driven semantic control plane rather than a chatbot disguised as an orchestrator.

Summary
-------

The correct manager does not converse in order to exist. It observes, decides admissible continuation, delegates work, requests evidence, governs budget, and consolidates sufficient proof for state advance.

Chat may survive as a surface for inspection, witness, and exception. It may not occupy the throne of the protocol.

If the manager is born as chat, it is born already compromised: state turns implicit, action drifts into free text, reasoning couples itself to interface, replayability weakens, and supervision becomes chaotic.

0\. Status
----------

Normative draft.

* * *

1\. Thesis
----------

The manager MUST NOT be modeled primarily as a chat interface.

The manager MUST be modeled as a machine of transitions that:

*   observes events and receipts;
*   maintains minimum operational context;
*   decides the next admissible step;
*   delegates work to specialized workers;
*   requests evidence when necessary;
*   escalates exceptions;
*   advances pointers when proof is sufficient.

Chat, when it exists, must be treated as a peripheral interface of:

*   supervision;
*   human witness;
*   inspection;
*   explicit override.

Central formulation:

Management is not conversation.  
Management is coordination under policy, budget, and proof.

* * *

2\. Objective
-------------

Define a manager plane in which:

*   inputs and outputs are typed;
*   the main loop is event-driven;
*   the LLM operates as an interpretive component, not opaque authority;
*   humans participate as governed exception;
*   every relevant transition remains replayable;
*   chat ceases to be the primary source of state and decision.

* * *

3\. Scope
---------

This RFC specifies:

*   the role of the manager;
*   the role of the LLM within the manager;
*   the role of workers;
*   the role of the human;
*   the model of events and commands;
*   the operational loop of the manager;
*   the primary non-chat operational UI;
*   integration with RFC-0001 through RFC-0004.

This RFC does not specify:

*   detailed conversational UX;
*   the specific internal algorithm of the LLM;
*   concrete distributed scheduling;
*   business policy for each domain;
*   final visual layout of the dashboard.

* * *

4\. Invariants
--------------

**I1 — Chat is not the primary plane**

The normal flow of the system may not depend on free-form conversation.

**I2 — Every relevant action is typed**

The manager must not emit critical operational commands in free text as the canonical form.

**I3 — The manager is not the worker**

The manager does not execute detailed work when that work can be delegated.

**I4 — The manager decides continuation**

Its central role is to decide whether the case should:

*   continue;
*   delegate;
*   request evidence;
*   escalate;
*   reject;
*   consolidate.

**I5 — The human is a governed exception**

The human enters as witness, arbiter, or explicit approver, never as invisible patch for structural failure of the system.

**I6 — Every relevant continuation leaves a trail**

Any managerial decision that changes case state must produce a replayable artifact.

* * *

5\. Mental model
----------------

The manager must not be understood as:

*   assistant;
*   chatbot;
*   generic conversational agent.

The manager must be understood as:

*   dispatcher;
*   scheduler;
*   workflow supervisor;
*   interpreter of operational policy;
*   arbiter of budget and evidence;
*   semantic controller of transitions.

* * *

6\. Boundaries of the manager
-----------------------------

The manager must do only these classes of work:

1.  interpret case state;
2.  choose the next admissible step;
3.  select the appropriate worker or expert;
4.  request missing evidence;
5.  control budget and risk;
6.  decide escalation;
7.  consolidate sufficient proof for pointer advance or terminal.

The manager must not:

*   hide critical reasoning in ephemeral context;
*   execute arbitrarily the tasks that belong to workers;
*   converse by default as if conversation were the protocol;
*   promote output to decision without passing through the previous RFCs.

* * *

7\. Manager inputs
------------------

The manager operates on typed events.

```
pub enum ManagerInput {
    Event(EventCid),
    Receipt(ReceiptCid),
    PointerAdvanced(StatePointer),
    BudgetTick(BudgetState),
    Deadline(DeadlineSignal),
    Witness(WitnessReceipt),
    ForkDetected(PointerFork),
    PolicyUpdate(PolicyCid),
}
```

### Semantics

*   `Event`: new operational fact.
*   `Receipt`: result of prior action.
*   `PointerAdvanced`: relevant change of head.
*   `BudgetTick`: budget update.
*   `Deadline`: time pressure.
*   `Witness`: typed external proof.
*   `ForkDetected`: federative conflict.
*   `PolicyUpdate`: change in the applicable law.

Free text must not be the primary input when a typed equivalent exists.

* * *

8\. Manager outputs
-------------------

```
pub enum ManagerOutput {
    Delegate {
        worker_id: String,
        task_cid: String,
    },
    RequestEvidence {
        cid: String,
    },
    LoadExpert {
        expert_id: String,
        input_set_cid: String,
    },
    Escalate {
        queue: String,
        reason_code: u32,
    },
    AskHumanWitness {
        witness_kind: String,
        prompt_cid: String,
    },
    AdvancePointer {
        alias: String,
        head_cid: String,
    },
    Reject {
        reason_code: u32,
    },
    NoOp,
}
```

### Rule

Every materially relevant managerial output must be serializable as atom, receipt, or persistable event.

* * *

9\. Role of the LLM
-------------------

The LLM is not the manager. It is a component of the manager plane.

It may be used to:

*   interpret imperfect context;
*   summarize dispersed state;
*   decompose goals into subtasks;
*   suggest viable strategies;
*   prioritize evidence;
*   recommend workers;
*   explain decisions after the fact.

It may not be treated as final authority over:

*   `commit`;
*   federative acceptance;
*   proof validity;
*   pointer integrity;
*   effective budget;
*   zero-guess domains.

Correct formula:

The LLM proposes continuation.  
The manager governs whether that continuation may lawfully proceed.

* * *

10\. Role of workers
--------------------

Workers are specialized executors.

```
pub trait Worker {
    fn id(&self) -> &str;
    fn capabilities(&self) -> Vec<String>;
    fn execute(&self, task_cid: &str) -> anyhow::Result<ReceiptCid>;
}
```

### Rules

*   a worker must be an executor of delimited task;
*   a worker does not advance global pointer without command or explicit policy;
*   a worker returns typed receipt;
*   a worker may be deterministic, heuristic, or hybrid, provided it enters the active proof regime.

* * *

11\. Role of the human
----------------------

The human is not the main loop.

The human is exception authority and governed witness.

The human may enter as:

*   binary witness;
*   textual or structured witness;
*   approver;
*   fork resolver;
*   authorizer of extra budget;
*   policy supervisor.

Every relevant human intervention must generate witness receipt.

* * *

12\. Chat as peripheral interface
---------------------------------

Chat remains permitted, but with restricted standing.

It may serve for:

*   case inspection;
*   explanation of current state;
*   response to witness requests;
*   explicit override;
*   debugging and postmortem.

It may not be:

*   the normal mechanism of dispatch;
*   a hidden repository of state;
*   the primary protocol between manager and worker;
*   the canonical channel of operational decision.

Chat is exception and observability, not the main bus.

* * *

13\. Operational model of the case
----------------------------------

The manager thinks in cases, not in conversation threads.

```
pub struct ManagedCase {
    pub case_id: String,
    pub state_root: String,
    pub current_head_cid: Option<String>,
    pub active_budget: BudgetState,
    pub pending_events: Vec<String>,
    pub pending_actions: Vec<String>,
    pub blocked_on: Option<BlockReason>,
}

pub enum BlockReason {
    WaitingForWorker,
    WaitingForEvidence,
    WaitingForHumanWitness,
    WaitingForBudget,
    WaitingForPolicy,
    WaitingForForkResolution,
}
```

The primary unit of operation is the case.  
Chat is only one of its possible surfaces.

* * *

14\. Manager event loop
-----------------------

```
pub trait ManagerPlane {
    fn ingest(&mut self, input: ManagerInput) -> anyhow::Result<()>;
    fn evaluate_next(&mut self, case_id: &str) -> anyhow::Result<ManagerOutput>;
}
```

### Normative semantics

Upon receiving new input, the manager must:

1.  append it to the observable state of the case;
2.  update the case status;
3.  verify budget and policy;
4.  decide the next admissible step;
5.  emit typed output or `NoOp`.

Critical reasoning must not remain only in ephemeral memory outside the transcript or the observable state of the case.

* * *

15\. Planning and decomposition
-------------------------------

When there is a broad goal, the manager may decompose it into subtasks.

```
pub struct PlanStep {
    pub step_id: String,
    pub task_cid: String,
    pub intended_worker: Option<String>,
    pub dependency_cids: Vec<String>,
}
```

### Rules

*   the plan must be representable as verifiable artifact;
*   a subtask does not execute without admissible budget and policy;
*   replanning is allowed, but must leave trail;
*   planning does not replace proof; it only organizes its production.

* * *

16\. Worker selection
---------------------

Choosing a worker is a materially relevant managerial decision.

```
pub struct WorkerSelection {
    pub worker_id: String,
    pub reason_cid: String,
    pub confidence_q16: u32,
}
```

### Rules

*   selection must consider capability, cost, risk, and policy;
*   it must not be irretrievably opaque when it changes relevant outcomes;
*   the manager may consult the LLM to suggest a selection;
*   final decision remains subordinate to gate, contract, and proof.

* * *

17\. Budget and managerial attention
------------------------------------

To manage is also to administer attention.

```
pub struct BudgetState {
    pub gas_remaining: u64,
    pub max_parallel_workers: u32,
    pub max_open_cases: u32,
    pub max_human_interrupts: u32,
}
```

### Rules

*   the manager must respect the operational budget of the case;
*   it may not open unlimited delegations;
*   it should prefer the lowest-cost resolution compatible with policy;
*   it may reject or escalate cases that exceed admissible budget.

* * *

18\. Manager receipts
---------------------

Managerial action itself must leave operational proof.

```
pub enum ManagerReceipt {
    Delegated {
        case_id: String,
        worker_id: String,
        task_cid: String,
    },
    EvidenceRequested {
        case_id: String,
        cid: String,
    },
    Escalated {
        case_id: String,
        queue: String,
        reason_code: u32,
    },
    HumanWitnessRequested {
        case_id: String,
        witness_kind: String,
        prompt_cid: String,
    },
    PointerAdvanced {
        case_id: String,
        alias: String,
        head_cid: String,
    },
    ManagerRejected {
        case_id: String,
        reason_code: u32,
    },
}
```

Every managerial action with effect on the case must produce a persistable receipt.

* * *

19\. UI model
-------------

The primary UI of the manager is not a text box.

It should privilege:

*   case queue;
*   timeline of events and receipts;
*   case state;
*   pending items;
*   consumed budget;
*   blocks;
*   active workers;
*   escalations;
*   forks;
*   advanced pointers.

Recommended screen models:

*   case queue;
*   case detail;
*   blocked cases;
*   pending human witnesses;
*   fork resolution board;
*   audit trail / replay inspector.

* * *

20\. Human interaction model
----------------------------

Human interactions must be typed.

Admissible examples:

*   confirm A/B;
*   fill a field;
*   approve or reject;
*   sign an exception;
*   select head in fork;
*   authorize budget increase.

Open conversation so that the system may "discover what to do" must not be the primary path in critical flows.

* * *

21\. Integration with RFC-0001
------------------------------

RFC-0001 continues to define the legitimacy of decision:

*   `Commit`, `Ghost`, `Reject`;
*   `epsilon`;
*   no-guess;
*   forbidden domains;
*   the law of budget.

The manager operates within that Constitution. Never above it.

* * *

22\. Integration with RFC-0002
------------------------------

RFC-0002 continues to define transcript and proof.

Every relevant managerial action must be able to enter the transcript as step, action, receipt, witness, or proof artifact.

* * *

23\. Integration with RFC-0003
------------------------------

RFC-0003 continues to define the ground of atoms.

Tasks, plans, prompts, receipts, outputs, witnesses, and proofs must be treated as content-addressed artifacts whenever they are materially relevant.

* * *

24\. Integration with RFC-0004
------------------------------

RFC-0004 continues to define federation.

Distinct managers may federate:

*   state pointers;
*   proof packs;
*   witness receipts;
*   fork decisions;
*   acceptance receipts.

The manager does not replace federation; it produces the artifacts that federation arbitrates.

* * *

25\. Failure modes
------------------

Conformant implementations must distinguish at least:

*   `worker timeout`;
*   `worker invalid receipt`;
*   `insufficient evidence`;
*   `policy violation`;
*   `out of budget`;
*   `blocked on human witness`;
*   `blocked on fork`;
*   `blocked on storage/materialization`;
*   `manager planning failure`.

These failures may not be summarized as "the model did not know how to answer."

* * *

26\. Semantic security
----------------------

The manager plane must resist these anti-patterns:

*   operational command in loose language without receipt;
*   critical state hidden in chat context;
*   delegation without trail;
*   escalation without typed reason;
*   approval without sufficient evidence;
*   silent merging of cases;
*   unrecorded human override.

* * *

27\. Minimum conformance
------------------------

An implementation is minimally conformant only if it:

*   uses typed events as the primary plane;
*   emits typed outputs;
*   treats chat as peripheral;
*   separates manager from worker;
*   records relevant managerial receipts;
*   operates by case, not by conversation thread;
*   respects budget and policy;
*   integrates with the transcript-and-proof regime of the prior RFCs.

* * *

28\. Suggested crate layout
---------------------------

```
manager_plane/
  src/
    lib.rs
    case.rs
    input.rs
    output.rs
    receipt.rs
    worker.rs
    human.rs
    budget.rs
    planner.rs
    loop.rs
    ui_model.rs
```

`lib.rs`:

```
pub mod budget;
pub mod case;
pub mod human;
pub mod input;
pub mod loop;
pub mod output;
pub mod planner;
pub mod receipt;
pub mod ui_model;
pub mod worker;
```

* * *

29\. Canonical flow
-------------------

### Normal case

1.  an `Event` enters;
2.  the manager evaluates the case;
3.  it emits `Delegate`;
4.  the worker returns `Receipt`;
5.  the manager reevaluates;
6.  it requests evidence or delegates a new step;
7.  when proof is sufficient, it advances pointer or terminates.

### Exceptional case

1.  an ambiguous or insufficient `Receipt` enters;
2.  the manager emits `AskHumanWitness`;
3.  the human responds;
4.  the witness becomes receipt;
5.  the case continues or is rejected.

### Federated case

1.  a remote pointer advances;
2.  `PointerAdvanced` enters;
3.  local policy evaluates the impact;
4.  if there is fork, the case blocks in `WaitingForForkResolution`;
5.  resolution generates new input and the flow proceeds.

* * *

30\. Normative mantra
---------------------

Management is not chat.  
Management is typed continuation.  
Chat is exception.  
Proof is memory.  
Policy is law.

Short form:

*   no chat-first control
*   no silent delegation
*   only events
*   only receipts
*   only governed steps

* * *

31\. Architectural verdict
--------------------------

This RFC closes the correct form of the manager.

From this point onward, `LLM as Manager` ceases to mean the fantasy of a chatbot with tools and comes to mean a semantic control plane, event-driven and governed by policy, budget, and proof. That is the difference between a talking interface and an operational institution that can be entrusted with consequence.

* * *

RFC-0006 — Sovereign Worker ABI & Sandboxed Execution
=====================================================

> **Status:** Normative draft.
> 
> This RFC defines the execution interface, isolation regime, and determinism contract of the workers delegated by the Manager Plane.

Summary
-------

If the previous RFCs defined law, process, space, and government, this RFC defines the labour of the machine: the workers.

The correct worker is not a sovereign microservice. It is an isolated, contained, verifiable function subordinate to the same regime of proof that governs the rest of the system.

If the system is truly zero-trust, the code that does the heavy work cannot stand outside the Constitution.

0\. Status
----------

Normative draft.

* * *

1\. Normative thesis
--------------------

The worker is not a service with a will of its own.

The worker is an isolated function that maps a graph of input CIDs to an output receipt.

To preserve replay and verifiability, the worker:

*   does not access disk directly;
*   does not access network directly;
*   does not query host clock;
*   does not possess hidden entropy;
*   does not persist residual state across executions.

Everything it knows comes by atoms.  
Everything it produces must be able to become an atom.

If hot data are missing from memory, the worker does not improvise I/O. It yields, returns control, and requests rehydration.

* * *

2\. Invariants
--------------

**I1 — Absolute statelessness**

The same `TaskCid`, executed on the same `WorkerCid`, under the same contract and determinism profile, must produce the same `ReceiptCid`, except for divergences explicitly admitted by `epsilon`.

**I2 — No-syscall rule**

The worker must not perform arbitrary system calls. Its visible universe is the interface provided by the host.

**I3 — Mandatory epistemic yield**

If a required CID is `Absent` or `Cold`, the worker must suspend execution and return the missing CIDs to the host.

**I4 — Physiological separation**

There are two legitimate classes of worker:

1.  `ChipAsCode`: exact, bit-for-bit deterministic.
2.  `SiliconAsCompute`: statistical, hardware-accelerated, yet contained by explicit error bounds.

* * *

3\. Worker as sovereign artifact
--------------------------------

A worker is not a loose binary in the operating system. It must itself be treated as a content-addressed artifact in `AtomSpace`.

```
pub struct WorkerManifest {
    pub name: String,
    pub version: String,
    pub class: WorkerClass,
    pub bytecode_cid: String,
    pub required_capabilities: Vec<Capability>,
    pub determinism_profile: DeterminismProfile,
}

pub enum WorkerClass {
    ChipAsCode,
    SiliconAsCompute {
        epsilon_bounds: f32,
        quantization: QuantizationLevel,
    },
}
```

`epsilon_bounds` must be compatible with `ErrorContract.epsilon` from RFC-0001. In the absence of conflict, the more restrictive value prevails.

* * *

4\. The ABI between host and worker
-----------------------------------

The execution boundary must be linear, small, and rigorous.

```
pub trait WorkerHostEnv {
    fn request_atom(&self, cid: &str) -> Result<&[u8], PageFault>;
    fn consume_gas(&mut self, amount: u64) -> Result<(), OutOfGas>;
}

pub enum WorkerResult {
    Complete(ReceiptCid),
    Yield(Vec<String>),
    Fail(WorkerError),
}

pub trait WorkerAbi {
    fn execute(
        &mut self,
        task_cid: &str,
        env: &mut dyn WorkerHostEnv,
    ) -> WorkerResult;
}
```

`WorkerAbi` is the form of execution inside the sandbox. The `Worker` interface of RFC-0005 is the managerial layer of identity, capability, and dispatch.

* * *

5\. The problem of divergent hardware
-------------------------------------

Statistical execution on GPU, NPU, or heterogeneous accelerators produces small variations. This RFC rejects both the fiction of false exactness and the irresponsibility of permissiveness.

The correct rule is: `SiliconAsCompute` is not validated by bit-for-bit identity, but by proof of bounded divergence.

```
pub struct SiliconReceipt {
    pub task_cid: String,
    pub result_vector: Vec<i32>,
    pub hardware_signature: String,
}

pub fn verify_silicon_execution(
    expected_receipt: &SiliconReceipt,
    recomputed_receipt: &SiliconReceipt,
    epsilon: f32,
) -> bool {
    let distance = calculate_vector_distance(
        &expected_receipt.result_vector,
        &recomputed_receipt.result_vector,
    );

    distance <= epsilon
}
```

Thus the system admits the physiology of silicon without surrendering its constitution.

* * *

6\. Isolating the oracle
------------------------

If the worker possesses neither clock nor network, how does it access time or external data?

It does not.

The manager and the runtime must inject witnesses into `TaskCid` before execution.

```
{
  "t": "atom.task",
  "worker": "cid_worker_pricing_v1",
  "witnesses": [
    { "type": "time", "ms": 1741753200, "oracle_sig": "0x..." },
    { "type": "fetch", "url": "api.price", "response_cid": "cid_..." }
  ]
}
```

The worker operates over a frozen photograph of the observable universe. This guarantees historical reexecution without dependence on a mutable present.

* * *

7\. Task lifecycle
------------------

The correct execution flow is a yield loop, not an uncontrolled escape into I/O.

1.  the manager emits `Delegate`;
2.  the runtime initializes the sandbox and calls `execute(task_cid)`;
3.  the worker discovers a dependency not yet hot;
4.  it calls `request_atom(cid)`;
5.  the host returns `PageFault` if the data are not materialized;
6.  the worker returns `Yield(missing_cids)`;
7.  the runtime rehydrates the required CIDs via `AtomSpace`;
8.  the sandbox is resumed;
9.  the worker completes and returns `Complete(ReceiptCid)`.

### 7.1 Authoring Friction and Machine Assistance

Suspension for lack of data is not error.  
It is operational discipline.

A natural objection is that explicit yields, governed I/O, resumable workers, and typed continuations impose too much authorial friction for ordinary software work.

That objection was stronger in an unaided programming era.

As software construction becomes routinely machine-assisted — including environments where the interface remains conversational — the cost of writing explicit orchestration, resumable execution, and proof-compatible control flow falls significantly. What once looked prohibitively formal becomes increasingly authorable in practice.

This does not eliminate the overhead. It changes its historical weight.

In such an environment, the relevant question is no longer whether governed execution is more demanding than casual scripting. It is whether high-consequence systems can still justify architectures whose convenience depends on hidden state, arbitrary I/O, and illegible continuation.

Under machine-assisted authorship, disciplines that once seemed excessive may become the minimum price of legitimacy.

* * *

8\. Suggested crate layout
--------------------------

```
worker_abi/
  src/
    lib.rs
    manifest.rs
    env.rs
    yield.rs
    sandbox/
      wasm.rs
      wgpu.rs
    bounding.rs
```

* * *

9\. Normative mantra
--------------------

Logic is exact.  
Silicon is bounded.  
Workers cannot speak; they only yield.  
Time is an input, not a state.

Short form:

*   no syscalls
*   no arbitrary I/O
*   pure functions only
*   yield on cold memory

* * *

Minimum conformance
-------------------

An implementation is minimally conformant only if it:

*   executes workers in isolated sandbox;
*   provides explicit gas budget on every invocation;
*   prevents direct access to network, filesystem, and host clock;
*   subjects outputs to gate and proof regime before promotion;
*   declares `epsilon_bounds` for `SiliconAsCompute`;
*   correctly implements the `yield/resume` cycle.

* * *

Failure modes
-------------

The implementation must distinguish at least:

*   invalid, incomplete, or inconsistent input;
*   excess of budget or quota;
*   divergence incompatible with `epsilon`;
*   refusal or contract violation at the host interface;
*   violation of isolation, capability, or operational policy.

None of these failures may result in implicit commit.

* * *

Security
--------

The minimum guarantees are:

*   explicit isolation and absence of implicit access to host resources;
*   all external interaction passes only through interfaces admitted by the host;
*   no internal execution failure emits canonical receipt by itself;
*   outputs are promoted only when compatible with the contract and the declared environment;
*   any violation of isolation or policy is treated as explicit failure.

* * *

Architectural verdict
---------------------

With this RFC, the cryptographic circle closes.

The system need not trust blindly the model, the plugin, the expert, or the accelerator. It needs only the small auditable boundary between host and worker, the proofs emitted, the hashes preserved, and the margins explicitly contracted.

The worker ceases to be opaque process and becomes a sovereign instrument of work under law.

* * *

RFC-0007 — Economic Fields & Fuel Layers
========================================

> **Status:** Normative draft.
> 
> Subtitle: Gas as Trajectory.
> 
> This RFC consolidates the minimum economic layer of the kernel without prematurely introducing currency, wallet, or settlement as sovereign primitives.

Summary
-------

The transcript already preserves causality, work, authority, and expenditure. This RFC makes explicit that, once identity, contract, and cost enter the hashed chain, those same facts already constitute a primary economic ledger.

The economy, however, must be born in layers. The kernel measures. Economic readings derive. Control modulates. Currency, if it ever deserves to exist, must come later.

0\. Status
----------

Normative draft.

* * *

1\. Thesis
----------

Gas is not the currency.  
Gas is conserved work.

It is primary operational cost, physical fact of the runtime, and the minimum unit of verifiable economic trajectory.

By adding to the transcript the fields:

*   executor;
*   beneficiary;
*   gas\_cost;
*   contract\_hash;

...the system ceases to have merely an operational log and acquires Layer A of a sovereign economic ledger.

But the kernel must not collapse too early into monetary fantasy.

Credit, debt, reputation, valuation, compensation, and settlement belong to derived readings over verified trajectories of work, not to the core of the runtime.

* * *

2\. Layered model
-----------------

This RFC defines three explicit layers.

### Layer A — Operational Gas Ledger

Append-only, hash-chained, and verifiable.

It records:

*   who executed;
*   for whom it was executed;
*   under which contract;
*   how much gas was debited;
*   which semantic receipt was emitted.

This is the measurement layer: physical and observable facts, without embedded monetary interpretation.

### Layer B — Economic Interpretation

Derived, versionable, and queryable.

It produces:

*   relational balance;
*   open debt;
*   reciprocity;
*   reputation;
*   monetary, energy, or carbon valuation;
*   trust indices.

This is the layer of economic reading, not the layer of primary truth.

### Layer C — Control Pressure

Operational modulation layer.

It produces:

*   throttling;
*   routing;
*   circuit breaker;
*   escalation;
*   budget hardening;
*   modulated autonomy.

It interprets economic symptoms for the government of the system, without confusing control with currency.

* * *

3\. What this RFC actually does
-------------------------------

This RFC does only what is necessary to institute Layer A in the kernel:

1.  make the transcript economically identifiable;
2.  record per-step expenditure with executor and beneficiary;
3.  carry that expenditure inside the proof;
4.  permit later reconciliation and query.

It does not create token, wallet, or payment system.

* * *

4\. Invariants
--------------

**I1 — Gas is append-only**

No step expenditure may be altered retroactively once it enters the transcript.

**I2 — Economic identity is load-bearing**

`executor`, `beneficiary`, `gas_cost`, and `contract_hash` must form part of the canonical hashed shape of the transcript.

**I3 — Summary does not replace truth**

Any economic summary in `ProofPack` is a derived claim. The source of truth is the envelopes in the transcript.

**I4 — No wallet in the kernel**

The kernel stores no balance, account, wallet, transfer, or settlement as internal primitive.

**I5 — Gas conserves work**

For any valid `ProofPack`:

```
SUM(envelope.gas_cost) == initial_budget - budget_remaining
```

**I6 — Missing input downgrades certainty**

Derived layers must degrade precision or confidence when sufficient data are absent, rather than invent certainty.

* * *

5\. New primitive: `ReceiptEnvelope`
------------------------------------

```
pub struct ReceiptEnvelope {
    pub executor: NodeId,
    pub beneficiary: NodeId,
    pub gas_cost: u64,
    pub contract_hash: Hash,
    pub receipt: StepReceipt,
}
```

### Semantics of the fields

*   `executor`: who physically executed the step;
*   `beneficiary`: on whose behalf gas was consumed;
*   `gas_cost`: local cost of that transition;
*   `contract_hash`: normative authority under which the expenditure was permitted;
*   `receipt`: semantic payload of the step.

### Rule

`ReceiptEnvelope::canonical()` is the payload that enters the hash chain.

Economic fields are not analytics metadata.  
They are part of the proof.

* * *

6\. Economic session
--------------------

Every session now also exists as an economic relation:

`executor X` performing work for `beneficiary Y` under `contract Z`.

### Mandatory fields

*   `executor_id`;
*   `beneficiary_id`.

`SessionView` now also exposes:

*   `executor_id`;
*   `beneficiary_id`;
*   `initial_budget`;
*   `total_gas_spent`.

### Purpose

To permit future contracts that consider accumulated cost, economic autonomy, and the relation between executor and beneficiary without corrupting the kernel with premature monetary primitives.

* * *

7\. Economic transcript
-----------------------

```
pub struct TranscriptEntry {
    pub envelope: ReceiptEnvelope,
    pub prev_hash: Option<Hash>,
    pub entry_hash: Hash,
    pub budget_before: u64,
    pub budget_after: u64,
    pub state_root_before: Hash,
    pub state_root_after: Hash,
}
```

`TranscriptEntry` is the economic specialization of the `StepEvent` from RFC-0002.

### Critical rule

The chain is hashed over the envelope, not over the raw receipt.

Thus executor, beneficiary, contract, and cost enter the regime of truth of the transcript.

* * *

8\. Minimum additive API
------------------------

To preserve compatibility, this RFC recommends the following evolution.

### New mandatory method

```
append_envelope(envelope: ReceiptEnvelope)
```

### New preferred method

```
append_receipt_with_gas(receipt: StepReceipt, gas_cost: u64)
```

### Legacy method

```
append_receipt(receipt: StepReceipt)
```

The legacy method may survive as shim, but the official runtime must record cost explicitly.

* * *

9\. Reconciliation invariant
----------------------------

The runtime already debits budget in the loop. It must now guarantee that the `gas_cost` of the envelope is exactly the same cost debited in that transition.

### Verification rule

A conformant verifier must be able to prove:

```
sum(transcript_envelopes.gas_cost) == initial_budget - gas_remaining
```

This is the law of conservation of work in the system.

* * *

10\. Economic `ProofPack`
-------------------------

`ProofPack` must carry two levels.

### A. Source of truth

```
pub transcript_envelopes: Vec<ReceiptEnvelope>
```

### B. Summary claim

```
pub struct EconomicSummary {
    pub executor_id: NodeId,
    pub beneficiary_id: NodeId,
    pub total_gas_spent: u64,
    pub gas_remaining: u64,
    pub step_count: u64,
}
```

### Rule

`EconomicSummary` serves indexing, UI, and fast query. Real reconciliation remains the responsibility of the transcript of envelopes.

* * *

11\. What can be derived without changing the kernel
----------------------------------------------------

From the trajectory of envelopes, one may derive:

### 11.1 Relational balance

How much work one agent received minus how much it executed for others.

### 11.2 Debt

Trajectories in which A spent for B without observable later reciprocity.

### 11.3 Payment

Partial closure of debt by reciprocity of execution.

### 11.4 Reputation

Function over success of verification, failures, bounded divergence, and contractual compliance.

### 11.5 Valuation

Mapping of gas trajectory to readings such as estimated USD, energy, or carbon.

### 11.6 Control pressure

Application of policy over patterns of spend, retries, rejects, witness burden, and executor stress.

None of this requires altering the minimal ontology of the kernel.

* * *

12\. Relation to the layer of proposals
---------------------------------------

This RFC does not transform the runtime into a market of economic proposals.

It prepares the ground for that possibility:

*   the economic transcript supplies the facts;
*   Layers B and C produce snapshots, diffs, and packs;
*   manager and LLM may propose;
*   gate and contract continue deciding.

The economy remains subordinate to the same Constitution of the system.

* * *

13\. What this RFC explicitly does not do
-----------------------------------------

This RFC must not:

*   create token;
*   create wallet;
*   create `transfer op`;
*   create payment primitive;
*   create settlement protocol;
*   create table of balances in the kernel;
*   couple federation to monetary logic;
*   introduce economic consensus.

The transcript is already the primary ledger.  
Everything else is later reading.

* * *

14\. Errors of economic verification
------------------------------------

Recommended minimum vocabulary:

*   `GasReconciliationFailed`;
*   `EnvelopeExecutorMismatch`;
*   `EnvelopeContractMismatch`.

Optional future vocabulary:

*   `BeneficiaryPolicyViolation`;
*   `ValuationPrecisionDowngraded`;
*   `TrajectoryCycleMismatch`.

* * *

15\. Relation to the previous RFCs
----------------------------------

### RFC-0001

It continues to define legitimacy: `commit`, `ghost`, `reject`, contracted error, and the law of budget.

### RFC-0002

It continues to define transcript and proof. The transcript is now also economically identifiable.

### RFC-0003

It continues to define the sovereign space of atoms. Envelopes and summaries are artifacts like any others.

### RFC-0004

It continues to define federation. Economic interpretation of proofs occurs after federative acceptance.

### RFC-0005

It continues to define the non-chat manager. The manager may consume derived economic layers for routing, witness, and escalation.

### RFC-0006

It continues to define worker and sandbox. The cost of worker labor now enters the formal economic chain.

* * *

16\. Canonical queries
----------------------

### Query A — Conservation

```
SUM(gas_cost) == total_spent
```

### Query B — Reciprocal debt

```
sum(gas where executor=A and beneficiary=B)
-
sum(gas where executor=B and beneficiary=A)
```

### Query C — Trust by verification

```
verified_steps(node=X) / total_steps(node=X)
```

### Query D — Pressure by trajectory

```
base_gas * penalty(retries, rejects, latencies, witness_burden)
```

* * *

17\. Guiding sentence
---------------------

Gas is conserved work.  
Value is a query over verified trajectories of that work.

Necessary complement:

The transcript does not need a currency primitive to become economic. It only needs identity, authority, and conserved cost.

* * *

18\. Names of the three layers
------------------------------

Recommended nomenclature:

*   Layer A — Transcript Gas
*   Layer B — Trajectory Economics
*   Layer C — Control Pressure

* * *

19\. Implementation mandate
---------------------------

The kernel implements only:

*   `ReceiptEnvelope`;
*   economic identity of the session;
*   economic hashing of the transcript;
*   `EconomicSummary`;
*   reconciliation vocabulary.

Everything else remains outside the kernel.

* * *

Minimum conformance
-------------------

An implementation is minimally conformant only if it:

*   treats gas as append-only;
*   produces `ReceiptEnvelope` with per-step accounted gas;
*   separates Layer A from any derived reading of value;
*   makes economic reconciliation verifiable;
*   declares budget before execution and never permits silent overrun.

* * *

Suggested crate layout
----------------------

```
economic_fields/
  src/
    lib.rs
    envelope.rs
    session_econ.rs
    transcript_econ.rs
    summary.rs
    reconciliation.rs
```

* * *

Closing
-------

The correct next step is not to invent a currency.

The correct next step is to recognize that work is already being conserved, expenditure is already being debited, and proof is already being chained. What was missing was legibility.

If a currency is ever born, let it be born as a historical reading of verified trajectories of work, not as the premature superstition of the runtime.

* * *

RFC-0008 — Jurisdiction from Duty and Sorrow
============================================

**Status:** Normative draft.  
In this RFC, the terms **must**, **must not**, **forbidden**, and their equivalents carry normative force equivalent to **MUST / MUST NOT**.

Summary
-------

If RFC-0001 established law, RFC-0002 established proof, RFC-0003 established epistemic space, RFC-0004 established federation, RFC-0005 established government, RFC-0006 established bounded labour, and RFC-0007 established economic legibility, this RFC establishes the final jurisdiction of consequence.

The human is not placed at the top of the system because the human is more reliable than the model, the worker, the manager, or the machine.

The human is not more reliable.

The human remains the final jurisdiction only where non-transferable consequence still survives computation: legal consequence, civil consequence, regulatory consequence, institutional consequence, bodily consequence, and moral burden that cannot be discharged by the machine.

Where duty cannot be delegated and consequence can still be suffered, final authority must remain.

That is the human place in the architecture.

* * *

0\. Status
----------

Normative draft.

* * *

1\. Normative thesis
--------------------

The final commit of a jurisdiction-bearing case must belong to the party that bears non-transferable consequence.

The system may:

*   establish law by text and contract;
*   execute rule by bounded runtime;
*   produce proposals by silicon;
*   advise by model;
*   coordinate by manager;
*   verify by proof;
*   preserve by receipt and transcript;
*   and expose cost by economic envelope.

But none of those may claim final jurisdiction merely by performing well.

Final jurisdiction belongs where duty is real and consequence is borne.

The human does not rule because the human is infallible.  
The human rules only where the human remains answerable after the machine is done speaking.

* * *

2\. Invariants
--------------

**I1 — Accountability outranks fluency**

No model, worker, manager, or protocol surface may exercise final consequential commitment unless a responsible human authority remains identifiable.

**I2 — Final signature follows consequence**

Where only one party can still be sanctioned, removed, sued, blamed, punished, injured, or otherwise held to answer for the outcome, that party is the rightful locus of final signature.

**I3 — Advice is not jurisdiction**

LLM analysis, expert scoring, bounded silicon execution, managerial recommendation, and policy suggestion may inform final action, but none of them constitutes final authority.

**I4 — Duty is not transferable by convenience**

Operational delegation does not transfer jurisdiction. Convenience, automation, throughput, and scale do not dissolve responsibility.

**I5 — Suffering is part of the jurisdictional test**

The system must distinguish between what can compute, what can advise, and what can still suffer the consequence of a wrong commit. Only the last category may close certain classes of decision.

**I6 — Jurisdiction must remain legible**

A final human act must remain transcript-visible as an attributable act of ratification, authorization, refusal, suspension, or escalation, together with duty class, consequence class, signer identity, and signature.

**I7 — Human jurisdiction remains under law**

The human signer is not above contract, proof, transcript, or policy. Human jurisdiction is constrained jurisdiction.

**I8 — No implicit finality**

Absence of signer, timeout, silence, UI confirmation without accountable signature, or passive exposure to a recommendation must never count as final human commitment.

* * *

3\. The three powers
--------------------

The architecture recognizes three distinct powers, each with a different office.

### 3.1 Text establishes the law

Text and contract define:

*   admissibility;
*   constraints;
*   procedures;
*   thresholds;
*   prohibited moves;
*   burden classes;
*   and the shape of proof.

Text governs because law must not improvise.

### 3.2 Model analyzes and advises

The model:

*   compresses;
*   explores;
*   compares;
*   proposes;
*   prioritizes;
*   and advises.

The model is useful precisely because it is plastic.  
It must not rule for the same reason.

### 3.3 Human signs where consequence remains

The human:

*   ratifies;
*   authorizes;
*   refuses;
*   suspends;
*   escalates;
*   or records structured dissent.

The human does not decide because humans are pure, wise, or trustworthy in themselves.

Humans are not trustworthy in themselves.

The human decides only where the human remains exposed to the world after the computation ends.

* * *

4\. Jurisdictional threshold
----------------------------

Not every commit deserves the same human burden.

This RFC therefore distinguishes between two broad classes of finality.

### 4.1 Fully governable commits

A commit may become final without human signoff only when all of the following are true:

*   proof is complete;
*   law is satisfied;
*   the consequence is low or meaningfully reversible;
*   no named party remains non-transferably answerable beyond the machine boundary;
*   the governing policy explicitly permits automatic promotion;
*   and the action does not affect protected rights, bodily safety, legal standing, or institution-binding obligation.

### 4.2 Jurisdiction-bearing commits

A commit must require explicit human signature when any of the following is true:

*   consequence is high;
*   reversibility is low or absent;
*   protected rights are affected;
*   legal, civil, regulatory, or disciplinary exposure remains;
*   institutional standing or binding obligation is created or altered;
*   bodily integrity, health, or life is implicated;
*   irreversible action is taken;
*   or a named human or institution remains answerable beyond the system boundary.

The system must classify this threshold explicitly.  
It must not pretend that all commits are equal merely because all commits are computable.

* * *

5\. The sorrow test
-------------------

This RFC introduces a practical jurisdictional test:

**Who here can still suffer for this commit?**

This test may also be expressed in operational form as the non-transferable consequence test.

The answer may include:

*   legal exposure;
*   regulatory exposure;
*   civil liability;
*   disciplinary or institutional penalty;
*   reputational destruction;
*   bodily harm;
*   economic ruin;
*   or moral burden that cannot be discharged by the machine.

Where such exposure remains human, final authority must remain human.

This is not sentimentality.  
It is an architectural recognition that consequence has not yet been virtualized.

The system may represent consequence.  
Only the signer may still have to live it.

* * *

6\. Duty, burden, and final signature
-------------------------------------

The final signature is not a decorative approval step.  
It is the visible location where burden becomes attributable.

```
pub struct JurisdictionEnvelope {
    pub case_cid: String,
    pub proofpack_cid: String,
    pub recommendation_cid: String,
    pub signer_id: String,
    pub signer_role: String,
    pub authority_cid: String,
    pub duty_class: DutyClass,
    pub consequence_class: ConsequenceClass,
    pub verdict: HumanVerdict,
    pub justification_cid: Option<String>,
    pub signature: String,
}

pub enum DutyClass {
    RoutineOperational,
    Financial,
    Legal,
    Medical,
    Governance,
    IrreversibleAction,
}

pub enum ConsequenceClass {
    ReversibleLow,
    MaterialHigh,
    RightsAffecting,
    InstitutionBinding,
    BodyOrLifeAffecting,
}

pub enum HumanVerdict {
    Ratify,
    Authorize,
    Refuse,
    Suspend,
    Escalate,
}
```

**Rules**

*   `Refuse`, `Suspend`, and `Escalate` must carry `justification_cid`.
*   `Authorize` must carry `justification_cid`.
*   `Ratify` may omit `justification_cid` only when the governing proof, recommendation, threshold classification, and consequence class already make the act sufficiently legible under policy.
*   Any signature over a jurisdiction-bearing commit must bind signer identity, authority scope, case identity, proof identity, and verdict.

The purpose of this envelope is not to glorify the human.  
It is to make visible where consequence finally lands.

* * *

7\. The human is not trusted
----------------------------

This RFC rejects the romantic fiction that the human is the safe part.

The human is:

*   biased;
*   tired;
*   vain;
*   fearful;
*   corruptible;
*   forgetful;
*   and often wrong.

So is the model, in its own way.

Therefore the architecture does not place the human above law.

It places the human under law, under proof, under receipt, under transcript, and under visible signature.

The human remains the final jurisdiction not because the human is good, but because the human remains punishable, removable, sanctionable, and accountable in a way the model does not.

* * *

8\. Human ratification under proof
----------------------------------

A human signature is valid only when it stands over a legible case.

This means the human authority must receive, at minimum:

*   the governing contract or rule-set;
*   the proof-bearing transcript or proof pack;
*   the recommendation, proposal, or computed basis;
*   the threshold classification that explains why the case is jurisdiction-bearing or auto-finalizable;
*   the relevant grounds for ratification, authorization, refusal, suspension, or escalation;
*   and the consequence class of the action.

The system must not ask the human to sign blind.  
Nor may it allow the human to dissolve proof by whim.

The right human place is neither ornamental approval nor arbitrary override.  
It is constrained jurisdiction under proof.

* * *

9\. Signer authority
--------------------

Not every human may sign every burden.

A jurisdictional signature is valid only when exercised by a recognized signer authority.

```
pub struct SignerAuthority {
    pub signer_id: String,
    pub roles: Vec<String>,
    pub allowed_duty_classes: Vec<DutyClass>,
    pub allowed_consequence_classes: Vec<ConsequenceClass>,
    pub may_ratify: bool,
    pub may_authorize: bool,
    pub may_refuse: bool,
    pub may_suspend: bool,
    pub may_escalate: bool,
    pub valid_from_epoch: u64,
    pub valid_until_epoch: Option<u64>,
}
```

**Rules**

*   the signer must be identifiable;
*   the signer must be valid for the relevant epoch;
*   the signer role must match the active authority grant;
*   the signer may not sign beyond the allowed duty and consequence classes;
*   absence of valid authority must block final signature;
*   the authority artifact must itself be transcript-resolvable and auditable.

Operational delegation does not create signer authority by implication.

* * *

10\. Jurisdiction decision
--------------------------

The system must explicitly determine whether a case may finalize automatically or requires human signoff.

```
pub enum JurisdictionDecision {
    AutoFinalizable,
    RequiresHumanSignature {
        duty_class: DutyClass,
        consequence_class: ConsequenceClass,
        minimum_signer_role: String,
    },
}
```

Recommended supporting structure:

```
pub struct JurisdictionThreshold {
    pub reversibility_low: bool,
    pub rights_affected: bool,
    pub bodily_risk: bool,
    pub legal_exposure: bool,
    pub institutional_binding: bool,
    pub named_accountable_party: bool,
}
```

**Rule**

If any active policy marks the case as jurisdiction-bearing, the commit must not become institutionally final without valid human signature.

A model, manager, or worker recommendation may not silently collapse `RequiresHumanSignature` into `AutoFinalizable`.

* * *

11\. Refusal, suspension, escalation, and dissent
-------------------------------------------------

Human jurisdiction includes the right to refuse.

A responsible signer may:

*   refuse a recommendation;
*   suspend a commit;
*   request further evidence;
*   escalate the case to a higher or different authority;
*   or record structured dissent.

This is not a defect in the system.  
It is part of the constitutional architecture.

A regime that permits only automatic assent has confused execution with authority.

A jurisdictional act that blocks, reopens, redirects, or defers a case must remain legible as an attributable act, not merely visible as an event.

For this reason, refusal, suspension, escalation, and dissent must remain justification-bearing, transcript-visible, and attributable.

```
pub struct StructuredDissent {
    pub case_cid: String,
    pub signer_id: String,
    pub verdict: HumanVerdict,
    pub reason_codes: Vec<String>,
    pub justification_cid: String,
    pub signature: String,
}
```

**Rules**

*   `StructuredDissent` must be preserved in transcript;
*   reason codes may be policy-defined, domain-specific, or institution-specific;
*   free text may supplement but must not replace structured grounds when structured grounds are available;
*   dissent must not be silently discarded after later approval.

* * *

12\. What the signer may not do
-------------------------------

Human jurisdiction is real, but it is not arbitrary sovereignty.

A signer must not:

*   ratify a jurisdiction-bearing commit without minimum proof visibility;
*   sign beyond granted authority scope;
*   silently reclassify a jurisdiction-bearing case as auto-finalizable;
*   suppress dissent, refusal, suspension, or escalation artifacts;
*   impersonate another authority;
*   sign on behalf of an absent signer without explicit delegated legal structure recognized by policy;
*   replace transcript-visible proof with private rationale as sole basis of finality;
*   or convert recommendation into final action without attributable act of signature.

Human authority remains bounded by law, proof, transcript, and grant.

* * *

13\. Ratification and authorization
-----------------------------------

This RFC distinguishes two related but non-identical acts.

### 13.1 Ratification

`Ratify` confirms a commit whose legal, procedural, and operational path is already mature under the active law and proof, but which still requires accountable human closure due to consequence class.

### 13.2 Authorization

`Authorize` permits a commit whose final institutional effect requires an explicit act of empowered human permission, even where the proof and recommendation are sufficient.

**Rule**

The active policy must specify whether a given consequence class requires `Ratify` or `Authorize`.  
No implementation may treat these as equivalent by default.

* * *

14\. Multi-signature and quorum human authority
-----------------------------------------------

Some consequence classes may require more than one signer.

```
pub enum HumanFinalityMode {
    SingleSigner,
    DualControl,
    Quorum { required_signatures: u8 },
}
```

**Rules**

*   `BodyOrLifeAffecting`, `InstitutionBinding`, and selected `Legal` or `Governance` actions may require dual control or quorum under policy;
*   required signers must be distinct recognized authorities;
*   quorum must be explicit and auditable;
*   insufficient signatures must block finality;
*   partial signature must remain visible as incomplete, never final.

The architecture must preserve the possibility that the gravity of consequence exceeds the legitimacy of single-handed closure.

* * *

15\. The cost of finality
-------------------------

The system must not hide the cost of asking a human to sign.

Human finality is expensive:

*   slower;
*   heavier;
*   more institutionally charged;
*   and often more emotionally costly than automated continuation.

That cost is not a defect.

It is the visible price of committing where consequence still exceeds what the machine may rightfully absorb.

In low-consequence domains, this cost should be minimized.  
In high-consequence domains, this cost should be preserved.

* * *

16\. Interactions with earlier RFCs
-----------------------------------

### 16.1 With RFC-0001

RFC-0001 establishes the law of `Commit`, `Ghost`, and `Reject`.  
RFC-0008 determines when a valid commit still requires human ratification or authorization before becoming institutionally final.

### 16.2 With RFC-0002

RFC-0002 produces proof-bearing process.  
RFC-0008 determines who may sign over that proof when consequence cannot be delegated.

### 16.3 With RFC-0005

RFC-0005 gives the Manager Plane authority to govern continuations.  
RFC-0008 limits that authority at the boundary where management ends and accountable signature begins.

### 16.4 With RFC-0006

RFC-0006 contains labour under sandbox and yield.  
RFC-0008 contains finality under burden.

### 16.5 With RFC-0007

RFC-0007 makes work economically legible.  
RFC-0008 makes consequence jurisdictionally legible.

* * *

17\. Suggested crate layout
---------------------------

```
jurisdiction/
  src/
    lib.rs
    envelope.rs       # JurisdictionEnvelope, HumanVerdict
    burden.rs         # DutyClass, ConsequenceClass
    threshold.rs      # JurisdictionDecision, JurisdictionThreshold
    authority.rs      # SignerAuthority
    dissent.rs        # StructuredDissent
    signature.rs      # signer identity and accountable attestation
    quorum.rs         # HumanFinalityMode
```

`lib.rs`:

```
pub mod authority;
pub mod burden;
pub mod dissent;
pub mod envelope;
pub mod quorum;
pub mod signature;
pub mod threshold;
```

* * *

18\. Normative mantra
---------------------

Law governs.  
Models advise.  
Humans sign where consequence remains.

Hard form:

*   text establishes the law;
*   contract and proof constrain the case;
*   the model analyzes and advises;
*   the manager coordinates but does not close jurisdiction-bearing consequence;
*   the human signs where duty cannot be transferred;
*   final authority belongs where consequence can still be suffered.

* * *

Minimum conformance
-------------------

An implementation is minimally conformant only if it:

*   identifies which classes of commit are jurisdiction-bearing;
*   binds final ratification or authorization to a named human authority;
*   records duty class and consequence class for the act;
*   preserves proof, recommendation, authority, and signature together;
*   requires justification for refusal, suspension, escalation, and authorization;
*   allows refusal, suspension, escalation, and dissent as legitimate outcomes;
*   prevents model or manager outputs from silently impersonating final signature;
*   validates signer authority against scope and epoch;
*   and preserves incomplete or failed signoff as non-final.

* * *

Failure modes
-------------

The implementation must distinguish at least:

*   absence of accountable signer for a jurisdiction-bearing commit;
*   invalid or expired signer authority;
*   ratification or authorization without sufficient proof visibility;
*   refusal, suspension, or escalation without justification trail;
*   silent promotion of advisory output into final action;
*   forged, ambiguous, or non-attributable signature;
*   signoff beyond allowed duty or consequence class;
*   quorum required but not satisfied;
*   refusal or escalation path not preserved in the transcript.

None of these may result in implicit finality.

* * *

Security
--------

The minimum guarantees are:

*   final signature remains attributable to a specific human authority;
*   advisory systems cannot impersonate jurisdiction;
*   proof remains visible at the point of ratification or authorization;
*   responsibility is not erased by automation layers;
*   refusal, suspension, escalation, and dissent remain transcript-visible;
*   justification-bearing acts remain attributable where they interrupt or redirect finality;
*   authority scope and validity remain auditable;
*   and no UI surface may convert passive acknowledgement into accountable signature.

* * *

Architectural verdict
---------------------

With this RFC, the system acknowledges what computation cannot abolish.

Text may govern.  
Proof may justify.  
Workers may execute.  
Managers may coordinate.  
Models may advise.

But where duty remains non-transferable and consequence remains sufferable, jurisdiction must still have a human face.

This is not a concession to nostalgia.

It is the final refusal to confuse intelligence with authority, automation with legitimacy, performance with the right to decide, or recommendation with accountable signature.

* * *

On Efficiency and Power
=======================

Ethics as Proper Allocation in Machine-Mediated Systems
-------------------------------------------------------

**Author:** Dan Voulez  
**Status:** Foundational position paper  
**Keywords:** efficiency, power, ethics, AI systems, jurisdiction, proof, bounded computation, machine assistance, governance, distributed systems

* * *

Abstract
--------

This paper argues that efficiency in advanced computational systems does not arise primarily from raw acceleration, reduced friction, or the collapse of intermediate layers. It arises from the proper allocation of power, burden, and consequence across heterogeneous components.

A system becomes inefficient when it repeatedly asks one layer to perform the office proper to another: when probabilistic models are expected to govern, when humans are expected to provide machine-scale throughput, when rules are expected to improvise, when statistical engines are expected to carry legitimacy, or when automation is mistaken for the abolition of responsibility.

The central claim is simple: **power misallocated becomes waste; power properly governed becomes efficiency.**

From this perspective, ethics is not an ornamental layer added after optimization. It is a structural property of architectures that refuse category error. To treat each component according to its real strengths, real limits, and real exposure to consequence is not only more just. It is more efficient.

The paper therefore proposes a doctrine of proper allocation: that future systems should be evaluated not only by throughput, latency, and cost curves, but by whether each layer is permitted to become fully itself without usurping the office of another.

* * *

1\. Introduction
----------------

Contemporary software culture still tends to associate efficiency with simplification by collapse. A system is often called efficient when it removes intermediaries, compresses decision paths, hides form, and allows the strongest or fastest component to dominate execution.

In ordinary software, such simplifications may appear tolerable. In machine-mediated systems — especially those involving probabilistic models, distributed execution, consequential decisions, and institutional accountability — they become deeply misleading.

What looks like efficiency at first often conceals a more expensive disorder underneath:

*   hidden state,
*   illegible continuation,
*   unverifiable outputs,
*   arbitrary I/O,
*   dissolved responsibility,
*   and governance reduced to convenience.

Such systems may be fast in the local sense while remaining profoundly wasteful in the architectural sense. They save milliseconds only to spend legitimacy. They reduce typing only to increase ambiguity. They increase automation only to destroy attribution.

This paper advances a different proposition:

> **Efficiency does not begin where friction disappears.  
> It begins where category error ends.**

A system becomes more efficient when each layer is assigned the kind of work it can actually perform without lying about its nature. This is not merely a technical claim. It is also a moral one.

That is why efficiency and ethics must be treated together.

* * *

2\. The central error: misallocated power
-----------------------------------------

The recurring failure of modern architectures is not simply insufficient optimization. It is **misallocation**.

Systems become unstable when they ask:

*   the model to govern rather than advise;
*   the human to supply machine-scale throughput;
*   the runtime to perform moral judgment;
*   the worker to improvise outside law;
*   the database to rewrite history;
*   the interface to impersonate authority;
*   or the machine to absorb consequences that remain human.

Each of these confusions produces waste.

Sometimes the waste is computational:

*   duplicated checking,
*   pathological orchestration,
*   context bloat,
*   retries,
*   compensatory wrappers,
*   and fragile control flow.

Sometimes it is institutional:

*   signatures without visibility,
*   blame without attribution,
*   automation without legitimacy,
*   and policy without transcript.

Sometimes it is moral:

*   assigning an agent work it cannot truthfully bear,
*   or pretending that burden has vanished because it has become difficult to see.

In every case, the pattern is the same: a layer is assigned a power alien to its office.

That assignment does not increase efficiency.  
It only delays the bill.

* * *

3\. Power is differentiated
---------------------------

The language of “power” is often used too vaguely. A serious system contains multiple distinct powers, each of which must be recognized if efficiency is to become real rather than theatrical.

### 3.1 Power as law

Text, rule, and contract possess the power to define admissibility, constrain action, set thresholds, and forbid illegible moves.

This is not the power of speed.  
It is the power of form.

Law is efficient precisely because it does not improvise. It removes classes of downstream error by refusing them upstream.

### 3.2 Power as exploration

Models and statistical engines possess the power to explore, compress, compare, rank, infer, and propose.

This is not the power of legitimacy.  
It is the power of search.

Exploratory systems become inefficient when they are forced to impersonate certainty. They are most useful when allowed to remain plastic under regime.

### 3.3 Power as execution

Workers, runtimes, accelerators, and silicon possess the power to transform input into bounded output under executable discipline.

This is not the power of sovereignty.  
It is the power of labour.

Execution becomes efficient when it is contained. Unbounded execution appears flexible in the present and expensive in the future.

### 3.4 Power as consequence-bearing closure

Humans and institutions possess the power to answer for what the system does where consequences remain non-transferable.

This is not the power of superior cognition.  
It is the power of burden.

Human finality is not justified because humans are wiser than machines. It is justified where humans remain the only parties who can still be punished, removed, sued, blamed, or made to live with the outcome.

### 3.5 Power as measurement

Economic systems possess the power to make labour, scarcity, throughput, and cost legible.

This is not the power of value itself.  
It is the power of account.

Confusing measurement with governance or currency with ontology produces second-order waste more expensive than the original computation.

* * *

4\. The false efficiencies of collapse
--------------------------------------

The common idea that efficiency arises from collapse is mistaken.

To collapse several offices into one layer may feel elegant:

*   let the chatbot manage;
*   let the model decide;
*   let the worker fetch;
*   let the interface sign;
*   let the database mutate;
*   let the runtime guess.

But collapsed architectures only appear efficient because they suppress distinctions that later return as more expensive failures.

### 4.1 Hidden state

A system that stores decisive state implicitly often feels lightweight until replay, audit, debugging, or institutional dispute become necessary.

Then the missing structure returns as:

*   forensic cost,
*   operational fragility,
*   and irrecoverable ambiguity.

### 4.2 Permissive I/O

A system that lets any worker speak freely to disk, network, clock, and secret environment seems convenient to author.

But the convenience is borrowed from the future:

*   replay becomes harder,
*   provenance becomes partial,
*   policy becomes porous,
*   and verification becomes ceremonial rather than real.

### 4.3 Sovereign models

A system that allows models to propose is useful. A system that allows models to silently close action is not efficient. It is only compressing governance into a statistical shortcut that cannot bear legitimacy.

The apparent savings last until the first consequential error.  
After that, the cost becomes institutional.

### 4.4 Invisible burden

A decision does not become free because a machine proposed it quickly. A finality cost does not vanish because a user interface made it easy to click.

If consequence remains human, efficiency must still reckon with that fact.  
Any architecture that hides burden is already wasting truth.

* * *

5\. Ethics is efficient
-----------------------

This paper therefore proposes the following doctrine:

> **Ethics is efficient when ethics means assigning each component only the burdens it can truthfully bear.**

This is not ethics as sentimentality.  
It is ethics as ontological honesty.

To treat each layer according to its real nature is efficient because it reduces:

*   role confusion,
*   illegible failure,
*   false autonomy,
*   false certainty,
*   compensatory bureaucracy,
*   and wasteful attempts to force one office to simulate another.

### 5.1 What ethics means here

Ethics does not mean kindness in the thin sense.

It means:

*   not asking the model to answer for consequences it cannot suffer;
*   not asking the human to provide machine-scale throughput;
*   not asking text to discover;
*   not asking silicon to legislate;
*   not asking proof to create value;
*   not asking interfaces to impersonate institutions.

A system becomes more ethical when each layer is freed from false office.

A system becomes more efficient for the same reason.

### 5.2 The end of category violence

Many systems are inefficient because they commit a kind of category violence: they force one layer into the office of another and then spend vast energy compensating for the mismatch.

A model forced into sovereignty becomes dangerous.  
A human forced into throughput becomes exhausted.  
A worker forced into arbitrary world-contact becomes unverifiable.  
A contract forced into creativity becomes sterile.

Efficiency begins when those violences stop.

* * *

6\. Potency is not sovereignty
------------------------------

One of the most important distinctions in future architecture is the distinction between **potency** and **sovereignty**.

The strongest layer is not therefore the rightful ruler.

Silicon is extraordinarily potent:

*   parallel,
*   statistical,
*   fast,
*   exploratory,
*   and increasingly generative.

None of that entitles it to final authority.

Models are potent:

*   they compress knowledge,
*   propose hypotheses,
*   draft,
*   compare,
*   and advise.

None of that entitles them to legitimacy.

Text is weak in throughput but strong in law.  
Humans are weak in scale but strong in consequence-bearing closure.

This is not a hierarchy of intelligence.  
It is a differentiation of office.

Efficiency increases when the architecture stops trying to make every potent layer sovereign and instead places each power under the regime that lets it become maximally itself without usurpation.

Thus:

> **Potency well governed becomes efficiency.  
> Potency made sovereign becomes waste.**

* * *

7\. Machine assistance changes the threshold of form
----------------------------------------------------

A common objection to governed architectures is that they impose too much explicit structure:

*   typed continuations,
*   proof-bearing transcripts,
*   explicit yields,
*   structured dissent,
*   constrained finality,
*   authority classes,
*   and bounded execution.

Historically, this objection had force. In a purely manual programming era, some forms of explicitness were prohibitively expensive to author.

That condition is changing.

As software construction becomes increasingly machine-assisted — even where the interface remains conversational — the practical cost of producing explicit orchestration, resumable control flow, structured law, and visible proof decreases materially.

This does not eliminate the overhead.  
It changes its historical weight.

Disciplines once dismissed as excessive may become ordinary once programming itself is routinely mediated by machine assistance.

This matters because the same condition that increases the need for governed architectures also reduces the authorial cost of building them.

The result is not merely convenience.  
It is a historical shift in what becomes architecturally tolerable.

* * *

8\. Distributed efficiency and federated legitimacy
---------------------------------------------------

The error of misallocated power becomes especially visible in distributed systems.

Classical distributed design often oscillates between two fantasies:

*   total global consensus,
*   or total local improvisation.

Both are expensive.

Global totalization sacrifices locality, speed, and practical autonomy.  
Local improvisation sacrifices proof, coordination, and institutional intelligibility.

A more efficient path is federated:

*   local action under law,
*   proof-bearing exchange,
*   explicit pointers,
*   bounded trust,
*   visible divergence where divergence is real,
*   and no forced fiction of universal sameness.

Such systems do not seek identical consciousness.  
They seek legitimate interoperability.

That is more efficient not because it is simpler in code, but because it better matches the world.

Counterparties rarely need identical state.  
They need accountable relation.

* * *

9\. Economic legibility without reduction
-----------------------------------------

A parallel confusion appears in economic design.

Many architectures either:

*   collapse everything into currency too early,
*   or deny economic structure because no token is present.

Both are errors.

Work may already be economically real before it becomes monetary.  
Scarcity, effort, cost, throughput, and trajectory may already exist as measurable fields before any pricing layer appears.

A system becomes more efficient when it measures what is actually conserved, rather than projecting the wrong abstraction onto it.

To say that gas is conserved work rather than currency is not to deny economics.  
It is to place economics at the right layer.

This is also an ethical move, because it refuses to coerce one regime of value into all others.

And again, it is efficient for the same reason.

* * *

10\. The signer remains
-----------------------

No account of efficiency is complete without consequence.

A system may:

*   compute well,
*   advise well,
*   prove well,
*   coordinate well,
*   and measure well,

yet still arrive at a point where some consequence remains stubbornly human.

At that point, efficiency cannot mean eliminating the human burden.  
It can only mean making that burden:

*   visible,
*   attributable,
*   constrained,
*   and worthy of the act being asked.

This is why a consequential architecture cannot let finality dissolve into automation merely because the automation is sophisticated.

Where duty remains non-transferable, the signer remains.

This is not nostalgia.  
It is structural honesty.

* * *

11\. A doctrine of proper allocation
------------------------------------

The doctrine proposed here may now be stated plainly.

A well-ordered system does not ask:  
**Which layer can do the most?**

It asks instead:

*   which layer can lawfully govern?
*   which layer can usefully advise?
*   which layer can efficiently execute?
*   which layer can truthfully bear consequence?
*   which layer can measure without usurping?
*   and which burdens must not be reassigned merely because reassignment is convenient?

The future belongs neither to the strongest layer nor to the fastest one.

It belongs to the architecture that lets each layer realize its full potency without stealing the office of another.

* * *

12\. Conclusion
---------------

This paper has argued that efficiency and ethics are not opposing principles in serious computational design.

They converge when the system ceases to commit category error.

* * *

Paper 10 — The Horizon of the Real
==================================

Actuation, Entropy, and the Irrevocable Event
---------------------------------------------

**Author:** Dan Voulez  
**Status:** Terminal position paper  
**Keywords:** actuation, sensors, physical boundary, thermodynamics, robotics, irrevocable event, limits of formalism

* * *

Abstract
--------

Up to this point, the architecture has secured the epistemic seal of computation. Law, proof, space, federation, labour, economics, and jurisdiction have been strictly allocated. But computation is ultimately sterile if it remains trapped in the dark of the processor. Eventually, the machine must touch the world.

This paper addresses the boundary at which the cryptographic seal terminates in contact with reality: the actuator and the sensor.

Its central claim is simple: physical reality does not hash. Moving a byte is a reversible state transition. Turning a motor, dispensing a chemical, cutting a wire, firing a mechanism, or accelerating a vehicle is an irrevocable thermodynamic event.

The architecture must therefore treat physical actuation not as another subroutine, endpoint, or worker call, but as the terminal exit from the regime of proof into the regime of entropy.

* * *

1\. The delusion of the API
---------------------------

Contemporary software culture often treats the physical world as merely another endpoint. It assumes that calling a payment gateway and commanding a robotic surgical arm are structurally identical acts, differing only in payload.

This is an epistemological fatal error.

When a microservice fails, a transaction may abort and state may be rolled back. When physical actuation fails — or succeeds wrongly — the consequence is not rolled back. The world does not revert to an earlier CID.

A severed limb, a crushed chassis, a discharged weapon, a ruptured pipe, or a spilled toxin cannot be restored by replay. The transcript may prove that a lawful decision was taken. It cannot unspill the toxin.

To treat physical actuation as a standard API is therefore to commit the ultimate category violence: pretending that physics obeys the laws of software.

* * *

2\. The actuator is not a worker
--------------------------------

RFC-0006 defined the Worker.

Workers are bounded, sandboxed, transcript-bearing, and yield when they lack data.

An actuator is not a worker.  
A worker produces a receipt.  
An actuator produces a consequence.

Because an actuator touches the irrevocable world, its architectural office must be stripped of all computational sovereignty:

*   the actuator must not deliberate;
*   the actuator must not evaluate policy;
*   the actuator must not guess;
*   the actuator must not classify jurisdiction;
*   the actuator must not contain a model;
*   the actuator must not reinterpret a human signature.

Its sole office is translation: to consume a valid jurisdiction-bearing command and translate it into voltage, motion, release, pressure, force, or interruption.

It is not an intelligence.  
It is a cryptographic interlock on a physical door.

If the signatures do not match, the motor does not turn.

* * *

3\. The asymmetry of reversibility
----------------------------------

Efficiency in software relies on the cheapness of rollback.

Ethics in the physical world relies on the impossibility of rollback.

The architecture must therefore classify physical acts into two broad regimes.

### 3.1 Reversible physical state

Examples include:

*   unlocking a magnetic door;
*   adjusting a thermostat;
*   switching a light;
*   moving a valve within bounded safe range;
*   or changing a reversible environmental parameter.

Because such states can be reversed with low thermodynamic and institutional cost, they may follow the standard path of auto-finalizable execution under the active Manager Plane and policy, provided the consequence class truly remains low and reversible.

### 3.2 The irrevocable event

Examples include:

*   administering a drug;
*   firing a weapon;
*   severing a structural support;
*   triggering an explosive sequence;
*   transferring kinetic energy at high speed;
*   or initiating a bodily intervention.

Where the physical consequence is not meaningfully reversible, the architecture must force a different path.

These events permanently trigger the sorrow test of RFC-0008.

The relevant proof must be complete.  
The signer must be valid.  
The authority scope must match.  
And crucially, the signature must be verified on the physical hardware path itself, not merely upstream in a cloud transcript.

An irrevocable event must not inherit legitimacy by assumption.  
It must verify legitimacy at the edge where entropy begins.

* * *

4\. The sensor as entropic witness
----------------------------------

If the actuator is how the machine touches the world, the sensor is how the world touches the machine.

Software often imagines input as clean. Physics does not.

Sensors drift.  
They saturate.  
They freeze.  
They blind under glare.  
They misread under heat.  
They degrade with wear.  
They hallucinate under matter rather than language.

A sensor does not enter the system as pure truth.  
It enters only as witness.

This means sensor output must always be treated as:

*   situated,
*   degradable,
*   entropy-bearing,
*   and subject to quorum where consequence is high.

For any physical input that may lead to a jurisdiction-bearing commit, the architecture should require multi-modal corroboration where feasible.

A camera and a LIDAR.  
A pressure sensor and a position encoder.  
A thermal sensor and a current trace.  
A human confirmation and a machine witness.

The machine must never trust a single eye where a wrong seeing can become irreversible consequence.

* * *

5\. The boundary of proof
-------------------------

Proof lives in mathematics.  
Consequence lives in physics.

The architecture must accept this limit without embarrassment.

The machine may prove that:

*   policy was followed;
*   budget was respected;
*   the runtime was lawful;
*   the signer was valid;
*   the transcript was preserved;
*   and the actuator was authorized to receive the command.

But it cannot cryptographically prove that the world complied.

It can prove that a command was lawfully issued.  
It can prove that a sensor claimed the event occurred.  
It cannot prove the event itself in the same sense that it proves a hash, a signature, or a transcript.

This gap cannot be closed by more software.  
It cannot be eliminated by a better blockchain, a larger model, or a faster runtime.

Proof can govern the permission to act.  
It cannot replace the fact of contact.

This uncloseable distance between cryptographic record and physical reality is the Horizon of the Real.

The map is not the territory.  
The transcript is not the world.

* * *

6\. Sensor quorum and actuator interlock
----------------------------------------

Because the architecture reaches its limit at physical contact, the edge must be designed as a double discipline:

### 6.1 Sensor quorum

No single fallible witness should dominate a high-consequence physical decision where corroboration is possible.

This means the architecture should support:

*   multi-modal witness aggregation;
*   temporal coherence checks;
*   bounded disagreement policies;
*   degradation modes;
*   and explicit refusal when witness quality collapses below threshold.

### 6.2 Actuator interlock

No actuator should rely on ambient trust in upstream computation.

The physical execution path should verify, at minimum:

*   command identity;
*   signer identity;
*   authority scope;
*   consequence class;
*   freshness or epoch validity where relevant;
*   and the integrity of the command envelope.

The actuator need not understand the whole law.  
But it must refuse to move in the absence of a lawfully closed command.

A dumb interlock is safer than a clever motor.

* * *

7\. The irreducible place of thermodynamics
-------------------------------------------

Software often behaves as if reality were just another storage backend. This illusion persists because so much computational work occurs in symbol-space, where reversal, duplication, simulation, and rollback are cheap.

Physical actuation interrupts that dream.

Every act in the world has:

*   energetic cost,
*   temporal irreversibility,
*   wear,
*   delay,
*   uncertainty,
*   and exposure to material failure.

This is not an implementation detail.  
It is the final architecture.

A computational system may be perfectly lawful and still fail at the edge because:

*   a relay welds shut,
*   a sensor drifts,
*   a mechanism jams,
*   a battery sags,
*   a motor stalls,
*   or a physical medium refuses abstraction.

A serious architecture must therefore acknowledge that the world does not merely execute commands. It resists them.

Entropy is not a bug in the implementation.  
It is the condition under which all actuation occurs.

* * *

8\. The final allocation
------------------------

If Paper 9 argued that ethics is the proper allocation of power, then this paper argues that the final ethical allocation is the acknowledgment of the machine’s absolute limit.

We have built a system to democratize power without sacrificing trust.  
We have placed law above fluency, proof above opinion, bounded labour above opaque execution, measurement above confusion, and accountable signature above silent automation.

But at the physical edge, formalism ends and reality begins.

The architecture therefore concludes in three final allocations:

*   the machine owns the proof;
*   the human owns the sorrow;
*   the world owns the event.

The machine may lawfully decide to actuate.  
The human may lawfully bear the burden of that decision.  
The world alone determines what finally happens when force meets matter.

That is not defeat.  
It is truth.

* * *

9\. Conclusion
--------------

This paper has argued that the final limit of computation is not complexity, scale, or model capability. It is contact with the irreversible world.

A serious system must therefore distinguish:

*   computation from actuation,
*   witness from truth,
*   transcript from event,
*   and lawful authorization from physical compliance.

The architecture is strongest not when it pretends to absorb the world, but when it knows where its legitimacy ends.

That is the final office of this paper: to deny the fantasy that the cryptographic seal can swallow reality whole.

It cannot.

It can govern the threshold.  
It can constrain the decision.  
It can verify the authority.  
It can preserve the proof.

But once the motor turns, entropy speaks in its own name.

* * *

Final thesis
------------

> **The machine owns the proof.  
> The human owns the sorrow.  
> The world owns the event.**