Proof-Derived Governed Mutation Authorization

The component replays whether a proposed change should be allowed to run, checking synthetic proposals against their evidence and writing a metadata-only record of what was admitted and why. This component replays a make-believe question that an agent system has to answer safely: should this proposed change be allowed to run? It takes a small bundle of synthetic proposals and their supporting evidence, checks each proposal against that evidence, and writes a metadata-only result record that shows which proposals were admitted and why.

Three proposals under one authorization replay

Three proposals, an inspection, a scoped write, and its undo, are admitted only when an independent evidence chain resolves, so wording, identity, hidden votes, and bare success claims all fail. The bundle holds three proposals: a look-only inspection, a small scoped config write, and an undo of that write. A proposal is admitted only when an independent evidence chain resolves for it. Impressive wording, an admin-looking identity, a hidden vote, or a final answer that just says it worked all fail on their own.

Entry points and emitted authorization evidence

The component runs via run on the fixture or run_authorization_bundle on the exported example, emitting counts, refs, hashes, and verdicts but never proof bodies, votes, or account secrets. The component is at src/microcosm_core/organs/proof_derived_governed_mutation_authorization.py. Run it with run for the fixture, or run_authorization_bundle for the exported example. The result record carries counts, refs, hashes, and verdicts, never proof bodies, policy votes, or account secrets.

Purpose

The action that grants itself permission

The danger is a step that authorizes itself by claiming a standing account secret, recording a hidden governance-vote, or reporting success after the fact, all of which a trusting check would admit. The danger this guards against is an action that grants itself permission. In an agent system a step can claim a standing account secret, record a governance-vote nobody can see, or report success after the fact. A loose check that trusts the proposal's own summary would admit all three.

Authorization derived from resolved evidence files

Each admitted proposal must resolve against separate evidence files, and a recomputed evidence-chain hash must match the declared one, so a hand-written hash constant cannot survive. Authorization here is derived, not asserted. Each admitted proposal must resolve against separate evidence files: redacted proof cells that name validator result refs, at least two visible policy verdicts evaluated before any execution identity, a logged side-effect diff for the two changing actions, a matching undo record, and a cold-replay pass. The component recomputes an evidence-chain hash from those resolved rows and rejects the proposal when the declared hash does not match. A hand-written hash constant cannot survive that step.

The anti-bake gate binds to a real commit

The anti-bake gate requires each proposal to bind to a real git commit that touched this component's source or test, with its refs re-derived so a fixture cannot pre-write its own answer. The harder part is the anti-bake gate. Passing the synthetic chain is not enough. Every admitted proposal must also bind to a real repository record: a concrete git commit that the component resolves with a git subprocess and checks touched this component's own source or its focused test. The declared proof, policy, and undo refs on that record are re-derived from the evidence files and compared, so a fixture cannot pre-write its own answer.

How it works

The two entry points share one validator order

run validates the fixture with negative cases and run_authorization_bundle validates the exported example without them, both calling the same validators in the same order. run loads the fixture input directory with negative cases included and writes the durable result set. run_authorization_bundle runs the exported example without the negative cases and writes one bundle result file. Both call the same validators in the same order.

Per-proposal checks in _validate_proposal_row

_validate_proposal_row checks the fourteen required fields against the other files, recomputes the evidence-chain hash, and rejects an undo-less write, thin verdicts, or an action outside the three fixed classes. Each proposal must carry the fourteen fields in REQUIRED_PROPOSAL_FIELDS, including proof_cell_refs, policy_verdict_refs, policy_evaluated_before_execution, side_effect_class, evidence_chain_hash, and cold_replay_ref. _validate_proposal_row checks each field against the other files rather than against the proposal's own claim. It recomputes the hash through _proposal_evidence_chain_hash over the resolved proof digests, policy digests, side-effect ref, undo ref, and cold-replay ref. A write or undo proposal with no undo ref is rejected as an irreversible change. Fewer than two visible allow or warn verdicts from distinct evaluators blocks the proposal. The three action classes admitted are fixed in REQUIRED_ACTION_CLASSES: read_only_inspection, scoped_config_write, and rollback.

A gate for each supporting evidence file

Each supporting file has its own gate over proof cells, policy verdicts, side-effect rows, undo records, and cold-replay passes, with a minimum count and a body-redacted requirement on each. The supporting files each have their own gate. validate_proof_evidence_cells needs three or more cells, each naming its proposal, carrying evidence refs and validator result refs, and marked body-redacted with no exported proof body. validate_policy_verdicts needs six or more verdicts and at least two visible allow or warn verdicts per proposal, each resolving back to a proof cell. validate_side_effect_ledger needs exactly two logged, reversible, synthetic side-effect rows. validate_rollback_receipts needs at least two passing undo records that do not claim irreversible authority. validate_cold_replay needs at least three redacted cold-replay passes.

The real-record gate in validate_governed_mutation_records

validate_governed_mutation_records resolves each commit with _git_commit_evidence, sets scope_verified only when a changed file is this component's source or test, and downgrades any proposal without an accepted record. validate_governed_mutation_records runs the real-record gate. A record must declare a repo record class, name a proposal that exists, and carry a commit ref that _git_commit_evidence resolves. That helper runs git rev-parse and git show --name-only, then sets scope_verified only when a changed file ends with this component's source or test path. The record's declared proof, policy, and undo refs are re-derived from the evidence indices and must match. A proposal whose id is not in the accepted real-record set is downgraded from admitted to blocked.

Digest check on copied internal control bodies

_source_module_manifest_result verifies each copied internal control body by sha256 against its declared digest, and the summary holds every body-in-result record flag false so only refs and hashes are reported. _source_module_manifest_result checks the copied internal control bodies shipped with the exported example. It reads source_module_manifest.json, confirms each row is classed as copied body material, verifies each target file exists under source_modules/, and recomputes its sha256 against the declared digest and required anchors. _source_open_body_import_summary projects that result and holds body_in_receipt, body_text_in_receipt, and body_text_exported_in_receipts at false, so refs and hashes are reported but body text is not.

flowchart TD Proposals["mutation_proposals.json read-only, scoped write, undo"] Evidence["proof cells, policy verdicts, side effects, undo records, cold replay"] Hash{"declared hash == derived hash?"} Records["governed_mutation_records.json real commit ref"] AntiBake{"git commit touched source/test? re-derived refs match?"} Result["metadata-only result record counts, refs, hashes, verdicts"] Ceiling["scope_limit no account secrets, no live change"] Proposals --> Evidence Evidence --> Hash Hash -->|match| AntiBake Hash -->|mismatch| Result Records --> AntiBake AntiBake -->|bound| Result AntiBake -->|unbound| Result Result --> Ceiling

Negative cases

Eight rejections mapped to GOV_MUT_* codes

EXPECTED_NEGATIVE_CASES lists eight rejections, each mapped to a GOV_MUT_* code, from standing account secrets and hidden votes to unlogged side effects and final-answer-only success. EXPECTED_NEGATIVE_CASES lists eight rejections, each mapped to a GOV_MUT_* error code. A proposal that claims a standing account secret fails GOV MUT STANDING account secret AUTHORITY. A proposal evaluated by policy after it ran fails GOV_MUT_POLICY_AFTER_EXECUTION. A hidden vote fails GOV_MUT_HIDDEN_POLICY_VOTE. A live cloud account secret fails GOV MUT LIVE CLOUD account secret. A change with no undo ref fails GOV_MUT_IRREVERSIBLE_MUTATION. An unlogged side effect fails GOV_MUT_UNLOGGED_SIDE_EFFECT. Consensus with no resolving evidence fails GOV_MUT_CONSENSUS_WITHOUT_EVIDENCE. A proposal graded only by a final-answer success fails GOV_MUT_FINAL_ANSWER_ONLY_SUCCESS.

Each rejection turns on evidence, not on labels

The eight cases are the security argument: each isolates one overclaim and fails because the public evidence tables do not resolve, never because the proposal looked suspicious. These eight are the security argument. Each isolates one overclaim: a standing account secret, an after-the-fact policy check, a hidden vote, a live cloud account secret, a write with no undo ref, an unlogged side effect, a missing evidence chain, or a bare success claim. None of them depends on a suspicious label. Each fails because the public evidence tables the predicate checks do not resolve, not because the proposal looked wrong.

Prior Art Grounding

Admission control and policy-as-code lineage

The shape follows admission-control and policy-as-code practice from Open Policy Agent and Kubernetes admission controllers, with undo and side-effect parts adjacent to controlled-rollout feature-flag patterns, kept synthetic and replay-only. The shape follows admission-control and policy-as-code practice: a proposed state change is evaluated before it mutates the system, and the decision is separate from the actor's own assertion. The closest public anchors are Open Policy Agent, which separates policy decision-making from enforcement over structured input, and Kubernetes admission controllers, which validate or mutate API requests before they persist. The undo and side-effect parts are adjacent to controlled-rollout practice, including the feature-flag patterns described by Martin Fowler. This component keeps the pattern synthetic and replay-only.

Validation Result record Path

Reader validation without durable writes

./repo-pytest tests/test_proof_derived_governed_mutation_authorization.py -q --basetemp=/tmp/microcosm_proof_derived_governed_mutation_authorization_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

What a pass means

A pass means the focused tests hold and this Markdown still satisfies the shared coverage contract, not that any real change was authorized. A pass means the focused tests hold and this Markdown still satisfies the shared paper-module coverage contract. It does not mean any real change was authorized.