Governed Execution Core
The component that decides, executes and signs
Authenticates the caller, decides against the active policy inside the write transaction, consumes approvals, reserves limits, executes exactly once through a capability the agent never holds, and signs every step into a hash-linked chain.
The properties the core is built to hold
The decision and the effect share a transaction
Policy is read inside the same write transaction that commits the action. A policy change cannot slip between the decision and the effect, and an action approved under an old policy is re-decided at dispatch.
The agent never holds the capability
The credential that performs the real-world effect is held by the execution identity, not the requesting agent. An agent that is fully compromised still cannot execute directly.
Exactly once, or not at all
Execution is idempotent against a reserved intent. A retry, a replay or a crash between commit and acknowledgement cannot produce a second effect.
A refusal is a record
Denials and holds are written into the evidence chain with the same signing discipline as successful executions. Absence of an effect is itself provable.
Core capabilities and their verdicts
Each carries a status and, where one exists, a stated limitation.
Pre-execution authorization
ProvenEvery governed action is authorized before it executes, not observed after. The decision to allow, hold or deny is taken against the active policy inside the same write transaction that reserves the budget and consumes the approval, so a policy change lands entirely before or entirely after an action — never halfway through one.
Agent identity from authenticated context
ProvenAn agent's identity and its accountable owner come from the authenticated credential and the agent directory. They are never read from the request body. A request whose body disagrees with its credential is refused, and the refusal itself is recorded as signed evidence.
Deterministic policy enforcement
ProvenDecisions are produced by explicit rules over an explicit policy document with a version, not by a model's judgement. The same request under the same policy version yields the same decision, and the policy version that governed each decision is recorded in the signed evidence.
Budget and action limits
ProvenSpend and action limits are reserved atomically inside the authorization transaction. A limit lowered below what is already spent stops further spend without rewriting history, and the change is recorded as a signed configuration record naming the principal who made it.
Signed, hash-linked evidence
ProvenEach decision, authorization, outcome, refusal and configuration change is written as a signed record in a hash-linked chain. The record carries the request identity, the policy version, the decision, the approver where one exists, timestamps and the execution result.
Offline independent verification
ProvenEvidence is verified by a portable verifier with no database, no signing key, no network and no product installation on the path. Deliberately altered evidence — an edited amount inside a signed body, a stripped signature, a broken chain link, a checkpoint re-signed by the writer's own key — is refused, and a verifier that cannot run reports an instrument failure rather than a refusal.
Limitation · The verifier was written by the same party as the system it checks. Verifying with it confirms signatures, linkage and key separation; it is not a substitute for an independent implementation of the documented record format.
What the core does not do
It does not evaluate whether an action is a good idea, judge intent, or replace a model's own safety behaviour. It answers one question — is this action authorized under the active policy — and enforces that answer.