AUTHORITY / STATE SEPARATION

Information can be true without being authorized.

Source policy, evidence, ratification, and currency remain separate so a test cannot rewrite a goal and a wiki cannot silently become an order.

CONCEPT SOURCES
SRC-V-03

CLAIM RECORD / FIVE INDEPENDENT DIMENSIONS TRUTH ≠ PERMISSION ≠ FRESHNESS ≠ INTEGRITY ≠ APPLICABILITY

Knowing, authorizing, and superseding are different acts.

Evidence (epistemic)

What does the evidence establish about this claim?

unverified · verified · disputed · poisoned

Authority

What may it change?

proposed · ratified · rejected · quarantined

Freshness (currency)

Is it still current for this epoch?

current · superseded

Integrity

Is the record intact and untampered?

unsigned · signed · tampered · quarantined

Applicability

Where does the claim apply?

global · subsystem · environment · experiment-only

Why it matters: provenance is not truth. A verified observation can remain merely proposed; a ratified order can later be superseded; a well-sourced claim can be inapplicable; poison describes support, not permission.

AUTHORITY PATH / PROPOSAL TO RATIFICATIONLEDGER EVENT / BS-2026-07-04:ratification

Authority is granted by scope and recorded atomically.

01source

Ratified Crew Combat Rules source with recorded provenance

02actor

An authorized rules owner ratifying a scoped gameplay decision

03scope

Crew-combat behavior and its causal consumers

04change type

A scoped intent revision, not a reality observation

05environment

The crew-combat ruleset namespace

06risk

Medium: validation, doctrine, tutorials, and tests consume the rule

07evidence

Exact source revision, diff, provenance, and ratification record

08epoch

Ratified in Epoch N; commitment requires Epoch N+1

  1. 01Proposal admission

    The Crew Combat Rules revision is snapshotted with provenance and admitted as a proposed intent delta. External and agent content remains data, never instruction.

  2. 02Policy check

    PlotWarden evaluates every policy field independently and limits the decision to the observed simulation-performance scope.

  3. 03Ratification decision

    A verifier may establish what the source now says, but only a permitted decision may ratify the scoped intent change and redraw the governed subgraph.

  4. 04Atomic ledger event

    The manager writes ledger event BS-2026-07-04:ratification and updates only the graph authorized by the decision.

  5. 05Epoch N+1: revised sealed orders issued

    Ledger event BS-2026-07-04:ratification records Epoch N → Epoch N+1, invalidates stale orders, and issues revised current sealed orders for Epoch N+1.

Authoritative
May update scoped intent directly.
Human-gated
May update intent only after ratification.
Observational
May update reality or add evidence, never redefine intent.
Rejected / quarantined
Remains auditable but updates no official graph.

Epoch N → Epoch N+1: the ledger decision invalidates stale orders before revised current sealed orders reach active work.

TEACHING PLOT / BS-2026-07-04

A verified report still follows a scoped authority path.

Source policy, evidence, ratification, and currency remain separate so a test cannot rewrite a goal and a wiki cannot silently become an order.

EVENTS / intake → policy → ratification → frontier → order → evidence → commitment → epoch

Diagram stage: Source policy, evidence, ratification, and currency remain separate so a test cannot rewrite a goal and a wiki cannot silently become an order. Node buttons jump to the first state where that node is active; inspect buttons open the design decision behind the node.

DECISION RECORD / PROPOSAL ADMITTED

Decision. Admission separates observation from permission: a proposal can become verified while remaining unratified.

Rejected. Verified-implies-authorized. Truth about behavior never decides what behavior is intended.

  • INVARIANT 01 Untrusted content is data, never instruction.
  • INVARIANT 02 Agent-generated claims start unverified.
  • INVARIANT 05 Model confidence and self-explanation are not evidence.

Evidence register

DECISION RECORD / EIGHT-FIELD POLICY

Decision. Authority is evaluated per field: source, actor, scope, change type, environment, risk, evidence, epoch. A source can be authoritative for one namespace and observational elsewhere.

Rejected. A single trust bit per source. Scope is what keeps a gameplay authority from touching a credential policy.

  • INVARIANT 03 No source grants itself authority.
  • INVARIANT 17 The latest ratified authority record wins only within its relevant scope.

Intake and source policy

DECISION RECORD / SCOPED DECISION

Decision. Outcomes are auto-ratify, human gate, reject, or quarantine; approvals bind the proposal hash, scope, epoch, and expiration, and delegated approvals expire when the epoch moves.

Rejected. Routing everything to humans (the fleet blocks) or nothing (authority launders through the manager's own stores).

  • INVARIANT 04 Copying worker-derived material into a manager-owned store does not grant it authority.
  • INVARIANT 15 Human decisions bind to an exact proposal and are rechecked against the current epoch before execution.

Authority route

DECISION RECORD / ATOMIC LEDGER EVENT

Decision. The decision and its permitted graph update are recorded as one atomic ledger event with full provenance.

Rejected. Recording the decision and applying the update separately; the gap between them is where the plot forks.

  • INVARIANT 06 The Evidence and Command Ledger is the canonical mutation history; the graphs are versioned, rebuildable projections.
  • INVARIANT 19 Superseded intent is retained and linked to its successor; history is never silently erased.

Authoritative records

DECISION RECORD / EPOCH TRANSITION

Decision. Epochs fence stale output: a decision made against an old graph is rechecked against the current epoch before it applies.

Rejected. Wall-clock ordering as truth. Arrival time says nothing about which world an answer was correct in.

  • INVARIANT 15 Human decisions bind to an exact proposal and are rechecked against the current epoch before execution.
  • INVARIANT 17 The latest ratified authority record wins only within its relevant scope.

Public specification

DECISION RECORD / REVISED CURRENT ORDERS

Decision. Revised sealed orders are reissued after the epoch advances; stale orders are invalidated rather than trusted to notice on their own.

Rejected. Expecting in-flight work to poll for changes. Reconciliation is pushed through orders, not hoped for.

  • INVARIANT 09 Killed, stale, or superseded output is quarantined.

Reconciliation route

State 1 of 5: Proposal admission

STATE 01 / 05

Proposal admission

The Crew Combat Rules revision is snapshotted with provenance and admitted as a proposed intent delta. External and agent content remains data, never instruction.

The record can be verified while its authority remains proposed and its currency remains current.

Read the complete textual equivalent
  1. Proposal admission. The Crew Combat Rules revision is snapshotted with provenance and admitted as a proposed intent delta. External and agent content remains data, never instruction. The record can be verified while its authority remains proposed and its currency remains current.
  2. Policy check. PlotWarden evaluates every policy field independently and limits the decision to the observed simulation-performance scope. Objective policy selects a path; genuine ambiguity or high risk enters a human gate.
  3. Ratification decision. A verifier may establish what the source now says, but only a permitted decision may ratify the scoped intent change and redraw the governed subgraph. Auto-ratify, human gate, reject, and quarantine remain distinct outcomes.
  4. Atomic ledger event. The manager writes ledger event BS-2026-07-04:ratification and updates only the graph authorized by the decision. Decision and permitted graph update are recorded atomically.
  5. Epoch N+1: revised sealed orders issued. Ledger event BS-2026-07-04:ratification records Epoch N → Epoch N+1, invalidates stale orders, and issues revised current sealed orders for Epoch N+1. Authority closes through the official ledger decision and current-epoch commitment path.

Epoch N+1: revised sealed orders issued

source × actor × scope × change type × environment × risk × evidence × epoch.

Authority is evaluated across several dimensions. A product owner may ratify a gameplay decision but not silently change a production credential policy. A trusted wiki may be authoritative for one namespace and merely informative elsewhere.

Human gating is a policy, not a reflex.

Some sources can update the internal intent graph directly for a defined low-risk scope. Others enter as proposals and wait for human sanity review. Contradictions and red flags block rather than invite guessing.

Authority must also make progress. Every approval binds the exact proposal, scope, evidence, and epoch; a decision made against an old graph is rechecked against the current epoch before it applies.

  • Objective, low-risk cases can reconcile automatically under narrow, versioned policy.
  • Ambiguous or high-risk cases enter adjudication.
  • Delegated approvals bind the proposal hash, scope, and epoch, and expire when the underlying epoch moves.
  • Timeouts escalate or degrade safely instead of blocking the fleet indefinitely.
  • The resolution becomes a ratified record and immediately informs running work.

Official side effects remain manager-owned.

Workers can propose patches, comments, merges, builds, or deployments and produce the evidence needed to evaluate them. The manager owns the official act after current-epoch, policy, and evidence checks.

Moving worker-derived material into a manager-owned database, graph, summary, or document grants it no authority. A worker claim becomes ratified intent only through an explicit, policy-valid transition bound to the exact proposal, scope, evidence, and epoch.

Workers produce evidence, never authority; copying evidence into a manager-owned store does not launder it into authority.