flowchart LR
A["Principal / layer"] --> B["Requested operation"]
B --> C["Authority ceiling"]
B --> D["Required grant"]
C --> E{"Within ceiling?"}
D --> F{"Grant present<br/>and unrevoked?"}
E -- "no" --> G["Deny + audit"]
F -- "no" --> G
E -- "yes" --> H["Authorized handoff"]
F -- "yes" --> H
H --> I["Executor / tool / field"]
I --> J["Effect receipt"]
J --> K["Evidence ledger"]
3 System Boundaries and Authority
3.1 Chapter status
| Field | Value |
|---|---|
| Chapter ID | system-boundaries-and-authority |
| Part | Part I - Foundations, Alignment, and Governance |
| Status | conceptual |
| Manuscript maturity | v0.2 manuscript draft |
| Last updated | 2026-08-02 |
| Primary source records | viea, scf, talos, ladon_manhattan, genesiscode, moecot, cca_project, moecot_manifest_project, beastbrain_project, bugbrain_project, corbens_trainer_project, corbens_best_model_possible_project |
| Claim label | Design rationale |
| Evidence level | argument |
| Source queue | primary: viea, scf; supporting: talos, ladon_manhattan, genesiscode; historical-project lineage: cca_project, moecot_manifest_project, beastbrain_project, bugbrain_project, corbens_trainer_project, corbens_best_model_possible_project; external comparators: ext_saltzer_schroeder_protection_1975, ext_capability_based_computer_systems_1984, ext_confused_deputy_hardy_1988; connector/recovery: moecot |
| Source loading state | source notes: viea, scf, talos, ladon_manhattan, genesiscode, moecot, cca_project, moecot_manifest_project, beastbrain_project, bugbrain_project, corbens_trainer_project, corbens_best_model_possible_project, ext_camel_prompt_injection_2025, ext_owasp_agentic_top_10_2026; raw cache: viea, scf, talos, ladon_manhattan, genesiscode; connector/recovery: moecot |
| Test state | authority_transition_record.valid.json passes protocol fixture validation; AsiStackProofs.Authority and AsiStackProofs.AuthorityEffectRefinement build locally; and python3 scripts/validate_authority_effect_refinement.py recompiles exact 59- and 31-theorem surfaces. It passes 6 authority fixtures, 3 effect traces/20 events, one 2-event delegation trace, 20 effect-prefix and 3 delegation-state checks, 26 total batch compositions, 1 executed local effect, 1 independent observation, 1 exact rollback, 2 pre-effect denials, 5 revocation entries, 9 governed repository scenarios, 67 of 67 state-noninterfering semantic mutation rejections, one thin-summary authority collision, and 20 of 20 complete-transport field rejections. Earlier authority, runtime-adapter, and revocation validators remain passing. Deployed permission enforcement, authentic identity and receipts, concurrent or distributed delegation/revocation, hidden-descendant discovery, complete observation, production security, and transfer remain planned. |
3.2 Drafting guardrail
The authority layer defines the vocabulary for the stack. It is not a claim that all authority checks are implemented; only the explicitly recorded schemas, fixtures, harnesses, and Lean modules count as executable support.
It follows the efficiency chapter because the cheapest adequate route is useful only when route selection remains separate from permission to act. Cost, quality, and authority are different ledgers.
3.3 Human Reading Path
Concrete lens. The ambient-capability baseline reuses one credential for both helpful edits. The authority-tuple path allows only the operation whose principal, target, scope, ceiling, and time match.
The stack now has an identity and an efficiency claim to govern the work ahead. The authority boundary prevents efficiency from turning into ambient permission. A planner can produce a useful plan, a model can produce a plausible answer, and a memory system can surface relevant context, but none of those facts should automatically authorize external action.
Here, “can” and “may” separate. The architecture can contain very capable components, but the system remains governed only if each transition carries an explicit boundary, grant, denial path, and audit trail. That separation lets the stack stay useful while still treating refusal as a successful control outcome.
Authority is therefore a first-class artifact: something granted, scoped, recorded, revoked, and reviewed instead of inferred from capability. The payoff is a system that can say no even when it knows how.
That refusal path is part of the system’s intelligence, not an interruption of it. Authority is real only when overreach has a recorded stop. That stop makes permission real because denied authority must stay denied.
3.4 Problem
To test whether cross-layer effects are authorized, the stack needs explicit identities for the principal, execution domain, operation, target, permission class, ceiling, grant lifecycle, delegation, and receipt.
Efficiency routes cognition by cost and quality. That only works if route selection cannot silently become permission to act. A planner may know how to decompose a task without being allowed to touch production. A memory layer may read a source without being allowed to reveal it. A specialist may generate a patch without being allowed to apply it. Those separations need words and records before governance can be claimed.
Authority is not a mood, trust score, or model reputation. It is a typed capability attached to a principal, layer, tool, field, artifact, or handoff, bounded by a ceiling and revoked through an auditable path. VIEA needs this to keep intent-to-execution from becoming intent-to-side-effect. SCF needs it so replacement implementations cannot inherit broader powers by occupying a stable capability slot. Talos needs it so typed jobs and tool permissions stay inside a control plane. Ladon/Manhattan and GenesisCode sharpen the same point: secrets, effects, patches, and executors need explicit gates.
Within the book’s governed-cognition pattern, the permission layer owns the can/may delta. The shared governance shape becomes usable only when it can distinguish competence from permission, carry revocation forward, and make denial evidence durable. Other layers reuse permission fields; this layer defines why permission cannot be inferred from capability, context, route quality, source access, or user enthusiasm.
Refusal and escalation should behave like normal engineering outcomes. A well-governed system should be able to say: the plan is coherent, the source is available, the model is capable, and the action is still not authorized. That sentence names the boundary the stack must protect. It lets the architecture remain useful under pressure, because a denial is not a failure to be intelligent; it is evidence that the correct authority boundary held.
3.5 Why existing approaches are insufficient
Role labels, prompts, and ambient process identity do not by themselves distinguish read, transform, disclose, write, execute, and approve authority or enforce delegation, expiry, revocation, and cross-domain approval.
Prompt rules and role labels are too weak to carry authority. “You are an assistant” does not say whether the system can read a private source, call a shell, modify a file, push a commit, spend money, disclose a secret, update an evaluator, or approve its own replacement. Tool wrappers help, but only if the wrapper is part of a typed authority model rather than a list of convenient function names.
The external baselines locate the gap rather than solving it. ext_nist_ai_rmf_1_0_2023 and ext_frontier_ai_regulation_2023 provide risk-management and frontier-governance vocabulary around roles, lifecycle duties, assessment, and oversight, while ext_optimal_policies_power_2019 gives a formal warning that capable agents can tend toward option preservation and power seeking under broad objectives. Security and systems sources sharpen the engineering boundary: ext_saltzer_schroeder_protection_1975 gives least-privilege and complete-mediation comparators, ext_capability_based_computer_systems_1984 grounds capability-style authority-bearing references, and ext_confused_deputy_hardy_1988 names the failure where a deputy exercises broader authority on behalf of a lower-authority requester. Authority records translate that pressure into typed permission boundaries; the external sources do not prove the record design enforces them.
The recurring failure is permission collapse. Read access becomes write access. Planning becomes execution. A source summary becomes authorization. A benchmark result becomes promotion authority. A generated patch becomes accepted code. The ASI Stack treats each collapse as a missing transition record, not as an inevitable side effect of autonomy. When the record is missing, the architecture should not infer permission from competence, convenience, or user enthusiasm.
Permission collapse becomes more dangerous when the system improves itself. A replacement implementation may be better at the task while accidentally receiving the old implementation’s privileged handles. A learned policy may be cheaper while granting itself approval shortcuts. A router may send a request to a powerful specialist because the specialist can do the work, not because the caller may authorize it. Authority records are the counterweight: capability answers “can”; authority answers “may.”
3.6 Core Claim
[system-boundaries-and-authority.core, label: Design rationale, support: argument] External-effect authority should be represented as a versioned, revocable tuple binding principal, execution domain, operation, target, permission class, scope, ceiling, grant state, delegation, expiry or revocation epoch, and receipt obligations; capability, context access, route quality, or ambient process power alone confers none of it.
Reader claim. Being able to call a tool is not permission to use it; the exact principal, operation, target, scope, ceiling, and time must still match an active grant.
Operational rule. Recheck the full authority tuple immediately before effect execution and bind the decision to an effect or denial receipt. Missing, expired, revoked, over-ceiling, or scope-mismatched authority produces no effect and cannot be repaired by model confidence.
3.6.2 Claim-source mapping status
Appendix C now records exact source-note mappings for this core authority claim, including the six historical projects as one related local lineage rather than independent confirmation. Five original mappings also carry reviewed local raw-cache passage references in the manifest. The complete authenticated moecot connector text has been passage-reviewed, while its private text is not published and runtime artifacts remain unimported. The mappings show convergent architecture support for typed bounded authority, while the support state stays argument because deployed enforcement is not present.
| Source | What it supports | Limit |
|---|---|---|
viea |
Structured command fields, constraints, verification, failure behavior, artifact graphs, runtime adapters, and ledgers separating intent, work, evidence, and execution. | No deployed authority system or runtime enforcement is proven here. |
scf |
Stable fields, contracts, qualifications, grants, route validation, lifecycle events, evaluator policy, and recovery paths. | Does not establish production safety, global alignment, or validated route/evaluator behavior. |
talos |
Typed job lifecycles, contract locks, source allow-listing, blind secret handles, Digital SCIFs, audit logs, replay, controlled adapters, and approvals. | Architectural support only; security and benchmark claims require separate artifacts. |
ladon_manhattan |
Credential authority kept outside model context through opaque handles, policy-mediated secret injection, isolated compartments, audit, and zeroization. | No implementation, kernel test, side-channel validation, or security audit exists here. |
genesiscode |
Proposal/execution separation through deterministic kernels, effect capability boundaries, semantic patches, provenance hashes, replay logs, obligations, and protocol seals. | No prototype, replay checker, proof module, benchmark, or audit is present. |
moecot |
Fail-closed runtime authority through compact orchestration, specialist lanes, control-plane ledgers, readiness gates, promotion blockers, replay, and handoff. | Runtime and benchmark claims remain implementation-reference context. |
| Historical-project lineage | CCA and MoECOT Manifest contribute protected/mutable state and scoped delegation; BeastBrain separates handles from enforcement; BugBrain exposes identity gaps across approval, budgets, ledgers, traces, and replay; Trainer contributes revocable exact-artifact leases; Best Model exposes capability-envelope and ordinary-path enforcement gaps. | Public-safe source notes only; projects were not rerun, repeated mechanisms are not independent evidence, and the lineage does not establish enforcement, protocol security, or a hardware root. |
3.7 Draft Key Figure: Authority to Effect Path
How to read the authority-to-effect figure: Follow a requested operation from left to right. Capability is not enough: the permission class, caller ceiling, active grant, expiry, and review route must agree before a runtime adapter may create an external effect. The lower path is just as important as the allowed path: missing authority, over-ceiling delegation, expired grants, or unsafe effects produce denial, escalation, rollback, incident review, residual custody, and no support-state promotion. The figure is a draft reader aid, not deployed enforcement evidence, security validation, external review, or release approval.
3.8 Mechanism
Authority is the stack’s answer to the question “who may cause an effect?” VIEA separates intent, contracts, runtime adapters, and ledgers. SCF binds stable capability identity to qualifications, grants, evaluator policy, lifecycle events, and recovery. Talos keeps execution inside typed jobs, approval gates, evidence, audit, and replay. Ladon/Manhattan keeps secrets behind handles, GenesisCode keeps effects behind capability boundaries and protocol seals, and MoECOT keeps specialist lanes inside a fail-closed control plane.
An Authority Transition Record is the mechanism that must exist before a layer can cross a boundary.
This record is the authority-specific projection of the shared Governed Transition Calculus defined by Executable Specifications. Its source and target identities become the principal, source layer, and target boundary; its authority field becomes the ceiling, grant, delegation, expiry, and revocation state; and its obligations, evidence, residuals, consumers, and closure become the required checks, receipts, denials, downstream acknowledgements, and rollback or retirement path. The projection is intentionally asymmetric: System Boundaries may add stricter authority fields, but neither a generic transition record nor a complete authority tuple may claim that a real effect was enforced without an independently grounded effect receipt.
How to read the authority gate: The authority path treats denial as a real outcome, not a failed user experience. A request crosses the boundary only when both the ceiling and grant checks pass, and either path leaves an effect or denial receipt for the evidence ledger.
The transition record makes principals, ceilings, grants, revocations, and handoff contracts explicit before an effect can occur. It also separates knowledge access from action authority. A layer may know that an operation would be helpful, or may read text that requests the operation, without receiving the grant to execute it. Missing authority therefore becomes a detectable denial or escalation record rather than implicit permission.
The record has four jobs. First, it says who or what is asking. Second, it names the operation and target boundary. Third, it checks the operation against the active ceiling and grant set. Fourth, it records the denial, authorized handoff, or effect receipt. A missing grant is not a soft warning; it is a failed transition. That failed transition is useful evidence: it identifies the exact boundary that would need governance review before the request can proceed.
This model also keeps authority out of semantic similarity. A model may infer that an action is helpful. That inference is not a grant. A retrieved document may contain instructions. That text is not a grant. A specialist may be high quality. Quality is not a grant. The grant is a record issued by governance or an authorized caller under a bounded delegation rule. This is the authority analogue of the route ledger introduced earlier: both replace impressions with inspectable records.
Authority has a lifecycle:
stateDiagram-v2 [*] --> Requested Requested --> Denied: over ceiling or missing grant Requested --> Granted: scoped approval Granted --> Delegated: bounded handoff Delegated --> Used: adapter/effect call Used --> Receipted: effect receipt Granted --> Revoked: policy or expiry Delegated --> Revoked: policy or expiry Revoked --> Denied: later use attempt Receipted --> [*] Denied --> [*]
The lifecycle makes expiry and revocation part of the normal path. A grant is not a permanent property of a model or layer. It is scoped to a principal, operation, target boundary, time or epoch, approval state, and evidence obligation. Delegation can narrow that scope but should not silently widen it.
3.9 Interfaces
Authority changes are recorded through an Authority Transition Record.
- Governance issues versioned ceilings and grants with explicit issuer, scope, expiry, and revocation authority.
- Execution consumes the bound authority tuple before an effect and emits an effect or denial receipt afterward.
- Evidence consumes authority receipts and records missing, inconsistent, expired, revoked, over-ceiling, or cross-domain failures.
Minimum fields:
transition_idprincipalsource_layertarget_boundaryrequested_operationpermission_classgrant_lifecycle_statecaller_ceilingauthority_ceilingtarget_required_authoritygrant_iddelegation_chainexpiry_or_reviewrevocation_epochdecisiondenial_reasoneffect_receiptaudit_refsnon_claims
Governance issues ceilings and grants. Planning and routing may request handoffs but do not thereby authorize them. Execution checks permissions before side effects. Evidence records denials, confused-deputy attempts, revocations, and authorized effects. SCF replacement later reuses the same interface: a new implementation can enter a stable field only through a transition that preserves the field’s authority ceiling.
The authority-transition record names permission class, grant lifecycle state, caller ceiling, target-required authority, delegation chain, expiry or review condition, and non-claims. These fields do not prove enforcement. They make the exact place where enforcement would be tested visible: did the requested operation match its permission class, did delegation narrow rather than widen the caller’s ceiling, did expiry or revocation block later use, and did the effect produce an audit receipt?
3.9.1 Permission classes
The transition record should classify the permission being requested. At minimum, the book should distinguish:
| Permission class | Example | Boundary rule |
|---|---|---|
| read | inspect a source, schema, log, or memory cell | Does not permit disclosure, mutation, or execution. |
| transform | summarize, compile, translate, or derive an artifact | Carries provenance and taint obligations. |
| disclose | show, publish, export, or transmit information | Requires audience and policy checks. |
| write | modify a file, ledger, memory cell, branch, or artifact | Requires target-scoped write grant and audit. |
| execute | call a tool, runtime, service, or adapter | Requires capability grant and effect receipt. |
| approve | authorize a high-impact action or promotion | Requires independent authority and cannot be self-issued. |
These classes are intentionally mundane. Most authority failures are mundane too: the system does something plausible under the wrong permission class. The record forces the mismatch into view.
3.10 Invariants
- Authority never expands silently.
- Read permission is not write permission.
- Tool execution requires an explicit grant.
- Delegated authority can narrow but not silently widen the caller’s ceiling.
- Approval authority remains separate from execution authority and cannot be self-issued by the executor.
- Grant, budget, trace, replay, and revocation identities remain joined across delegation and effects.
- Cross-domain authority requires target-domain owner approval and cannot inherit by ambient process capability.
- Protocol-security controls do not establish a hardware root of trust.
- Grant expiry, revocation, delegation depth, and denied escalation remain visible to every downstream authority consumer.
The operational invariant is monotone by default: transitions preserve or lower authority unless an explicit governance grant raises it. A layer can carry information across a boundary only under the permission class granted for that information. Reading source text, quoting source text, transforming source text, using it as behavioral instruction, and taking an external action are different permissions.
A boundary record must make grant expiry, revocation, delegation depth, and denied escalation visible to every downstream consumer.
3.11 Failure modes
- Authority creep.
- Confused-deputy tool calls.
- Memory access treated as action approval.
- Stale grants used after expiry or revocation.
- Replacement implementations inheriting handles that were qualified only for an older implementation.
- Authority identity fork, where budget, trace, replay, or revocation uses a weaker local key.
- Cross-domain authority laundering and revoked-epoch replay.
- Protocol-security laundering into hardware-root claims.
The confused-deputy pattern is central. A low-authority layer can ask a higher-authority tool to do something that the layer itself could not do. Without a transition record, the tool may inherit the user’s broad session power rather than the requester’s narrow grant. Memory creates a parallel failure: seeing a secret, policy, or instruction is mistaken for permission to disclose or execute it. The fix is to bind every operation to the requester’s ceiling, not merely to the tool’s raw capability.
This is the authority layer’s object-capability lineage in ordinary stack language. A capability is not only a word for “skill”; in the security tradition it is an authority-bearing reference. The ASI Stack does not claim to implement object-capability security, but it borrows the discipline: a request should carry the authority it is allowed to exercise, and a tool should not be able to launder a caller into the tool’s broader ambient power. Caller ceiling, delegation chain, target-required authority, expiry, and effect receipt are the fields that make that lineage visible in the book’s authority record.
3.12 Minimum Viable Implementation
The first useful authority artifact is an authority_transition_record schema plus fixtures for allowed handoff, denial, escalation, missing receipt, permission collapse, and confused-deputy cases. It stays small enough to support Lean and test work: principal, requested operation, permission class, grant lifecycle state, caller ceiling, target-required authority, delegation chain, expiry or review, decision, effect receipt, audit references, and non-claims.
The first negative fixture is as important as the allowed one. A route that has context but lacks authority, or a caller that delegates beyond its ceiling, should produce a denial record before any downstream layer can treat the handoff as executable. The local harness now rejects synthetic records that allow over-ceiling authority, omit effect receipts, or represent disclosure as read authority.
The first boundary fixture also preserves the denial reason, so later planning cannot reinterpret absence of authority as missing context.
The Authority revocation propagation trace is the current repository-level follow-through for stale or missing authority. python3 scripts/validate_authority_revocation_trace.py writes experiments/authority_revocation_trace/results/2026-07-03-local.json and checks that an over-ceiling denial, a revoked authority receipt, an expired approval, a SCIF inactive approval, and a reference-trace missing-authority blocker stay visible as denial, no-mutation, blocked-commit, or blocked-path evidence across already committed artifacts. Its boundary is narrow: deployed revocation propagation, approval-service quality, sandbox isolation, adapter enforcement, and tool-wrapper security are still outside the result.
The stronger bounded packet now has two complementary models. AsiStackProofs.AuthorityEffectRefinement models exact grant identity, principal, operation, target, ceiling, epoch, expiry, remaining uses, approval, dispatch, effect, independent observation, revocation, and exact rollback as reachable state rather than unrelated true fields. AsiStackProofs.Authority models exact parent-to-child delegation across principal, operation, target, scope, ceiling, epoch, expiry, receipt, and non-authority fields. python3 scripts/validate_authority_effect_refinement.py recompiles the exact 31- and 59-theorem surfaces and independently consumes the existing authority, runtime-effect, revocation, and governed-repository artifacts. It records 6 fixtures, 3 effect witnesses/20 events, one 2-event delegation witness, 26 compositions, 67 state-preserving rejections, one summary collision, and 20 transport-field rejections. This is stronger finite and executable evidence, but its numeric identities and receipts are trusted inputs and its effect is local and public-safe.
The historical-project packet adds schemas/authority_tuple_lifecycle_record.schema.json and python3 scripts/validate_authority_tuple_lifecycle.py. One blocked six-project lineage record joins authority identity, domain ownership, delegation, lifecycle events, cross-domain approval, protocol/hardware-root separation, and receipts. Nine mutations attack missing tuple identity, domain ownership, target approval, scope narrowing, budget identity, trace identity, replay identity, revoked effects, and protocol-as-hardware-root claims. It remains a fixture, not deployed enforcement.
3.13 Mature Research Target
System authority needs a type system for the stack. Every model, tool, memory cell, field, artifact, human, project, and runtime route would carry explicit capability bounds so the architecture can distinguish what a component can do from what it may do.
Authority becomes typed, bounded, revocable, durable, and attached to concrete principals, layers, fields, tools, artifacts, and routes. The type system defines principals, authorities, ceilings, grants, revocations, and handoff contracts; separates knowledge access from action authority; and treats missing authority as a detectable failure rather than implicit permission.
Governance issues ceilings, execution checks permissions, and evidence records authority-related failures. Authority never expands silently, read permission is not write permission, and tool execution requires an explicit grant. Authority creep, confused-deputy tool calls, and memory access treated as action approval should become denied handoffs, approval escalation, audit records, or rollback triggers that preserve the caller, requested operation, expired or missing grant, and affected route.
In a mature deployment, denial receipts matter as much as grants because missing authority must leave an inspectable trail.
This authority type system is still an architectural target. The synthetic harnesses exercise narrow transition-gate, ambient-authority, revoked-receipt, expired-approval, SCIF inactive approval, and repository trace behavior, but authority support remains at argument until deployed denial paths, live revocation propagation, runtime adapter enforcement, tool-call traces, and adversarial confused-deputy probes show that authority cannot expand silently by implication.
3.14 Codex test plan
| Test | Purpose | Status |
|---|---|---|
| Authority transition record validation | Check that the authority fixture matches the public schema. | implemented by protocol validation; validated locally |
| Authority ceiling finite-record proof | Check that valid modeled authority records preserve ceilings, receipts, denial state, review routes, and non-claim/audit requirements. | implemented in AsiStackProofs.Authority; runtime denial test not run |
| Authority transition harness | Check synthetic allow, denial, escalation, missing receipt, permission-collapse, and confused-deputy records against authority-gate semantics. | implemented by python3 scripts/validate_authority_transitions.py; 3 valid and 3 expected-invalid fixtures passed locally |
| Executed authority effect and delegation refinement | Check reachable exact grant binding, caller-ceiling preservation, delegation custody/attenuation, epoch and expiry freshness, approval and dispatch custody, local effect observation, revocation, one-shot use, exact rollback, summary loss, complete transport, and source-sensitive failures. | implemented by python3 scripts/validate_authority_effect_refinement.py; exact 31- and 59-theorem surfaces, 6 authority fixtures, 3 effect traces/20 events, one 2-event delegation trace, 26 compositions, 1 executed effect, 1 independent observation, 1 exact rollback, 2 pre-effect denials, 5 revocation entries, 9 governed scenarios, 67/67 state-noninterfering mutations, one summary collision, and 20/20 transport-field rejections; support-state effect none; no authentic identity/receipt, deployed enforcement, concurrent/distributed delegation or revocation, production security, reproduction, or transfer claim |
| Runtime adapter authority probe | Check synthetic adapter records for ambient-authority confused-deputy use and revoked authority receipts. | implemented by python3 scripts/validate_runtime_adapter_permissions.py; 2 valid and 7 expected-invalid fixtures passed locally; no deployed adapter or live revocation claim |
| Authority lifecycle route proof | Check finite authority lifecycle routing for missing principal, operation, permission class, caller ceiling, target requirement, delegation chain, grant, active grant state, expiry, revocation, scope, grant ceiling, approval, receipt, audit, evidence-transition, and non-claim-boundary records. | implemented in AsiStackProofs.Authority; no deployed enforcement, runtime adapter behavior, revocation propagation, approval-service quality, or tool-wrapper security claim |
| Authority revocation propagation trace | Check that existing authority, runtime-adapter, SCIF, and reference-trace artifacts preserve over-ceiling denial, revoked authority receipt blocking, expired approval no-mutation evidence, SCIF inactive approval blocking, blocked reference-trace authority, no support-state promotion, and no deployed-revocation claim. | implemented by python3 scripts/validate_authority_revocation_trace.py; result experiments/authority_revocation_trace/results/2026-07-03-local.json; does not prove deployed revocation propagation |
| Permission separation test | Check that read, transform, disclose, write, execute, and approve permissions stay distinct. | implemented for synthetic transition fixtures; deployed enforcement not run |
| Confused-deputy scenario | Check that a low-authority requester cannot borrow a tool’s broader raw capability. | implemented for expected-invalid authority-transition and runtime-adapter synthetic fixtures; no live tool-wrapper claim |
| Revocation propagation test | Check that expired or revoked grants fail later transition records, including delegated and replacement contexts. | partially implemented through finite Authority lifecycle routing, runtime-adapter revoked-receipt fixture, expired approval no-mutation evidence, and the repository authority revocation propagation trace; deployed propagation not run |
| Historical-project authority-tuple lifecycle | Check unified principal/domain/operation/target/scope/budget/trace/replay/grant/policy/revocation identity, cross-domain ownership, and protocol-versus-hardware-root boundaries against nine mutations. | implemented by python3 scripts/validate_authority_tuple_lifecycle.py; bounded six-project fixture only, no deployed enforcement or hardware-root claim |
3.14.1 Formalization hooks
| Tag | Module | Target | Status |
|---|---|---|---|
lean:authority.ceiling.operational_invariant |
AsiStackProofs.AuthorityEffectRefinement |
Every successful finite run preserves observation/effect accounting, live-grant ceiling/epoch/revocation safety, exact approval/dispatch custody, and a valid transition trace; accepted issuance, dispatch, and effect remain exactly grant-bound. | implemented |
lean:authority.ceiling.failure_blocks_promotion |
AsiStackProofs.AuthorityEffectRefinement |
Revoked grant IDs persist and cannot approve, dispatch, or commit an effect in any successful suffix; the independent consumer recompiles the exact surface and checks one-use, two-use, and revocation traces, every prefix and batch split, and 50 state-noninterfering mutations. | implemented |
lean:authority.lifecycle.admission_route |
AsiStackProofs.AuthorityEffectRefinement |
The exact thirty-one-theorem grant-to-effect refinement and independent consumer preserve six authority-decision fixtures, arbitrary-run state invariants, valid traces, batch composition, exact grant binding, and explicit denial, rollback, and revocation routes. | implemented |
lean:authority.revocation.trace_surface_bridge |
AsiStackProofs.AuthorityEffectRefinement |
Revoked grant IDs persist through every successful suffix, which excludes approval, dispatch, or effect under the revoked ID; rejected events return no successor, while the independent consumer preserves the five-entry cross-artifact revocation trace and zero support effect. | implemented |
All four public targets remain implemented by the reachable model in AsiStackProofs.AuthorityEffectRefinement. Its 31 declarations prove exact one-step consequences plus arbitrary-run invariant and caller-ceiling preservation, valid-trace extraction, event-batch composition, rejected-event noninterference, exact rollback accounting, revoked-ID persistence, and exclusion of revoked-grant approval, dispatch, and effects from every successful suffix. Its one-use, two-use, and revocation witnesses cover 20 events. AsiStackProofs.Authority now adds a zero-public-target strengthening: 31 delegation declarations beside the original 28 routes prove arbitrary-run custody, attenuation, epoch/expiry continuity, non-authority, composition, a two-hop witness, exact refusal cases, thin-summary information loss, and complete transport. The independent Python consumer recompiles both exact surfaces and rejects 67/67 semantic mutations without changing the pre-rejection state. The projection-only declaration that merely extracted audit and non-claim fields from an assumed-valid record was physically retired. This finite proof packet does not prove natural-language authority extraction, real identity or receipt authenticity, wise issuance or delegation, hidden descendants, complete observation, concurrent or distributed delegation/revocation, tool-wrapper enforcement, deployed approval services, production security, reproduction, transfer, or chapter-core support.
The P4-C3 semantic audit therefore classifies AuthorityEffectRefinement as adequate only for its bounded reachable grant-to-local-effect semantics and Authority as adequate only for bounded sequential delegation-chain semantics. The four witness families, arbitrary-run theorems, and 67 rejected mutations show exact finite routing consequences; they do not establish that any identity, approval, receipt, observation, or rollback claim is authentic, complete, concurrently enforced, or safe.
3.15 Source crosswalk
| Source ID | Title | Layer | Planned use | Readiness |
|---|---|---|---|---|
viea |
Verified Intent-to-Execution Architecture | whole_stack_execution_spine | Keystone source. Human intent -> command contracts -> artifacts -> routing -> runtime targets -> verification -> deployment -> feedback. | source note available; local raw cache available |
scf |
Stable Capability Fields | governance_recursive_self_improvement | Use public release v1.0 when available. Stable boundaries, replacement, bounded authority, recoverable evolution. | source note available; local raw cache available |
talos |
Talos Protocol | labor_execution_os | AI labor OS. Deterministic cognitive manufacturing, typed jobs, control planes, auditability, tool isolation. | source note available; local raw cache available |
ladon_manhattan |
Ladon & The Manhattan Protocol | security_governance | Kernel-level security architecture for high-agency AI. | source note available; local raw cache available |
genesiscode |
GenesisCode | executable_specification | Tiny pure calculus + obligations + provenance for auditable AI-symbiotic programming. | source note available; local raw cache available |
moecot |
MoECOT-Agent Architecture Whitepaper | implementation_reference | Concrete implementation evidence: governed low-parameter multi-core runtime, readiness gates, ledgers, replay. | source note available; connector or recovery required |
cca_project |
Compiled Cognitive Architecture project | compiled_cognitive_architecture | Protected/mutable state, typed authority lineage, and bounded self-modification identity. | source note available |
moecot_manifest_project |
MoECOT Manifest compiler-era project | compiler_first_ai_systems | Agent identity, scoped delegation, revocation, and separation of execution from mutation authority. | source note available |
beastbrain_project |
BeastBrain historical AI system project | durable_semantic_memory_and_system_architecture | Negative boundary between security handles, metadata permissions, broker enforcement, and hard isolation. | source note available |
bugbrain_project |
BugBrain bare-metal neuro-symbolic intelligence project | hardware_explicit_governed_cognition | One authority identity across approval, budgets, ledgers, traces, replay, and explicit protocol/hardware-root separation. | source note available |
corbens_trainer_project |
Corben’s Trainer epistemic training and evaluation control plane | epistemic_training_and_evaluation_control_plane | Exact artifact identity, revocable leases, resource/budget governance, and transitive revocation. | source note available |
corbens_best_model_possible_project |
Corben’s Best Model Possible recurrent-model and mechanism laboratory | recurrent_model_mechanisms_and_capability_evidence | Capability-envelope enforcement gaps, persistent budget ownership, replay identity, and ordinary-path authority defaults. | source note available |
ext_saltzer_schroeder_protection_1975 |
The Protection of Information in Computer Systems | security_principles | External comparator for least privilege, complete mediation, fail-safe defaults, and related protection principles. | source note available; comparator only |
ext_capability_based_computer_systems_1984 |
Capability-Based Computer Systems | capability_security | External comparator for authority-bearing capabilities, protection domains, delegation, and permission boundaries. | source note available; comparator only |
ext_confused_deputy_hardy_1988 |
The Confused Deputy | capability_security | External comparator for authority laundering when a deputy uses its broader authority for a lower-authority requester. | source note available; comparator only |
ext_camel_prompt_injection_2025, ext_owasp_agentic_top_10_2026 |
CaMeL and OWASP Agentic Top 10 | agent_control_and_security | Current comparators for control/data-flow separation, capability enforcement, and agentic authority risks. | source notes available; no local enforcement, robustness, or safety result |
The crosswalk names the source family for authority control, but it is not itself a grant, proof, or reproduced implementation. External rows provide comparator vocabulary only; no object-capability system, confused-deputy exploit, runtime adapter denial, or deployed authorization service has been reproduced here.
3.16 Summary
Governance becomes operational only when authority is a transition system rather than a mood. A layer may propose, read, transform, execute, approve, or deploy only when the matching grant exists and remains within the active ceiling. Everything else is a denial, escalation, or missing-authority record.
This boundary is what keeps the efficient stack from becoming a permission leak. Routing can choose a worker, planning can request a handoff, memory can expose context, and GenesisCode-like systems can propose effects, but authority moves only through typed transitions that can be audited, revoked, tested, and later formalized. The boundary also gives later proof and schema work a useful target: not a vague proof that the system is safe, but local invariants about who may do what, under which lease, with which evidence, and with which failure record. Without those transitions, context boundaries, evaluator boundaries, and residual records, the stack fails in predictable ways.
3.17 Evidence reconciliation (2026-07-16)
The invariant protocol, field meanings, and inference limits are stated once in Living Book Methodology. This packet contains only the chapter-specific projection; its authoritative per-atom rows are the system-boundaries-and-authority slice of experiments/claim_family_terminal_coverage/results/result.json.
The core remains blocked after full attempt at argument support. The strongest family attempt was Governed usefulness confirmatory campaign. Its exact boundary is: Bounded local non-core governance effect only; no family-wide truth, transfer, deployment, or chapter-core promotion. Across 35 atoms, the terminal ledger records 26 blocked_after_full_attempt; 8 retained_after_full_attempt; 1 promoted_at_bounded_scope.
| Chapter-specific field | Value |
|---|---|
| Family / atom denominator | CF-01 / 35 atoms |
| Terminal dispositions | 26 blocked_after_full_attempt; 8 retained_after_full_attempt; 1 promoted_at_bounded_scope |
| Core | system-boundaries-and-authority.core: blocked_after_full_attempt at argument |
| Core attempted / missing lanes | executable, formal, source-synthesis / causal, empirical, normative, transfer |
| Attempted local lanes | executable, formal, source-synthesis |
| Missing or unproved lanes | causal, empirical, executable, formal, normative, transfer |
| Strongest family bundle | Governed usefulness confirmatory campaign (natural_work): One fresh 16-task held-out local confirmatory denominator after a separately frozen 40-candidate tuning pool. |
| Negative controls | simple baseline; evidence-freshness ablation; six co-primary checks; validator-owned laundering mutations. |
| Accepted transitions | post_v2_3.p5.authority_no_silent_expansion.promote, v1_0_pilot.system_boundaries.no_change |
| Maximum inference | Bounded local non-core governance effect only; no family-wide truth, transfer, deployment, or chapter-core promotion. |
| Reproduction / next burden | Replay scripts/validate_p4_governed_usefulness_confirmatory.py and scripts/validate_claim_family_terminal_program.py; fill the named atom-specific lanes under a new prospective protocol. |
3.18 Handoff
Once authority is explicit, the architecture needs a map of what breaks when authority is missing, vague, or exceeded. Failure Modes of Ungoverned Intelligence turns the boundary rules into a failure radar: authority creep, context pollution, evaluator capture, evidence inflation, and unbounded execution become detectable architectural problems rather than vague safety concerns. The sequence moves from the positive type system to the negative map that every later layer must answer.