Policy & Durable Authority
Relevant source files
The following files were used as context for generating this wiki page:
Policy and Durable Authority in Noesis constitute the protected control plane responsible for governing side effects, principal grants, and the integrity of the self-modification loop. The system is designed to ensure that while LLMs can propose semantic changes, the actual activation of executable behavior and expansion of permissions remain strictly bounded by human-in-the-loop approvals and deterministic code rails.
The core architecture centers on the AuthorityBoundary and EffectGateway, which mediate all interactions between internal logic and external resources. By utilizing SQLite-authoritative state for grants and reservations, Noesis ensures that authority is persistent, auditable, and resilient to system restarts or crashes.
Sources: AGENTS.md:52-67, plans/noesis-high-leverage-correction-plan.html:438-466
Architecture and Core Components
The authority system is structured as a protected layer that resides outside the reach of self-modifiable content. It utilizes a "reserve-before-execute" pattern to prevent unauthorized or ambiguous side effects.
Effect Gateway and Authority Boundary
The EffectGateway serves as the primary enforcement point. All side effects and protected transitions (such as promotion or rollback) must pass through this gateway. It works in conjunction with the AuthorityBoundary, which verifies that a requestor has the necessary grants before an operation is permitted.
Sources: AGENTS.md:55-58, plans/noesis-high-leverage-correction-plan.html:438-444
Principal and Grant Management
Authority is granted to specific "Principals" (e.g., foreground, reflector, evaluator). Each principal operates under scoped grants that define allowed effect classes and resource access.
- Foreground Principal: Acts with approved user grants for standard tasks.
- Reflector Principal: Authorized to read traces and write proposals but cannot promote behavior.
- Evaluator Principal: Permitted to run sandboxed trials and record results.
- Scheduler Principal: Receives job-scoped, expiring grants that cannot be widened by the job itself.
Sources: plans/noesis-first-complete-iteration.html:learning-panel, AGENTS.md:65-67
Durable Operations Flow
The following diagram illustrates the sequence for executing a protected operation:
The diagram shows the mediation of effects through gateways, verification of grants, and the use of transactional reservations in SQLite.
Sources: plans/noesis-high-leverage-correction-plan.html:shadow-replay-logic, AGENTS.md:59-64
Implementation Details
Authority Receipts
Receipts are the primary mechanism for proving authorization. In the production implementation, receipts are unforgeable and verified at a deep adapter level. Verification includes checking the issuing boundary, effect class, resource, and specific operation.
Sources: plans/noesis-high-leverage-correction-plan.html:453-466, packages/domain/test/architecture.test.ts:182-192
Idempotency and Recovery
To prevent duplicate side effects during retries or after crashes, the system uses stable operation identities and idempotency keys. These keys are bound to:
- The Principal
- The Effect Class
- The Target Resource
- The Request Identity
If a reservation exists without an unambiguous outcome (success or failure), the system "fails closed" and does not allow a retry by assuming failure.
Sources: AGENTS.md:61-64, plans/noesis-high-leverage-correction-plan.html:267-275
Key Data Structures (Durable Authority)
| Structure | Description | Authority |
|---|---|---|
AuthorityReceipt | An unforgeable token representing a granted permission for a specific operation. | Protected Boundary |
Grant | A durable record in SQLite linking a Principal to an Effect Class and Resource scope. | SQLite |
OperationReservation | A pre-execution record that locks an idempotency key and estimated cost. | SQLite |
EffectCompletion | A recorded outcome of a side effect, used to fulfill idempotent requests. | SQLite |
Sources: plans/noesis-high-leverage-correction-plan.html:245-265, AGENTS.md:59-64
Security and Integrity Rails
The system enforces strict boundaries to ensure LLM-generated content cannot compromise the control plane.
Protected Mutation Whitelist
Only specific controllers are exposed through the protected adapter for critical actions:
- Activation: Materializing new capability versions.
- Veto/Pin: Blocking or locking specific capability lineages.
- Revert: Restoring a prior activation snapshot.
- Approval: Human-in-the-loop expansion of dangerous permissions.
Sources: plans/noesis-high-leverage-correction-plan.html:442-448, AGENTS.md:55-58
Separation of Concerns
Architecture tests ensure that the TUI and other non-protected packages cannot import or access raw mutation ports. Only the packages/policy deep adapter holds references to these ports, requiring a valid AuthorityReceipt for every call.
This diagram depicts the isolation of the Protected Zone from the Research Zone and UI, ensuring all external access and state changes are mediated.
Sources: packages/domain/test/architecture.test.ts:108-150, plans/noesis-high-leverage-correction-plan.html:438-450
Summary
Policy & Durable Authority serves as the foundational trust layer for Noesis. By anchoring permissions and operation state in a persistent SQLite store (WorkspaceStore) and enforcing access through unforgeable receipts, the system provides a robust framework for autonomous self-improvement that remains safe, auditable, and strictly under human control.
Sources: AGENTS.md:46-51, plans/noesis-autonomous-compounding-implementation-plan.html:one-authority-table