Government & public sector
Where a decision must be attributable years later
Public-sector decisions are reviewed long after the system that made them has been replaced. The record has to be checkable by someone who has no access to the original system and no reason to trust its operator.
The actions that are not recoverable here
Governance is worth its cost where the effect cannot be undone by correcting a record.
Benefit and entitlement determinations
A determination that affects a person needs a recorded policy version and, where the policy requires it, a named human decision-maker.
Case and record changes
Amending an official record is an action with legal weight. It needs the same authority checks as any other effect, and a record that outlives the case system.
Procurement and disbursement
Money leaving a public body carries both the payment risk and the accountability requirement, and the two are answered by the same evidence.
Inter-agency data actions
Actions crossing an organisational boundary need the acting identity and the principal recorded separately, because 'on whose behalf' is the question that gets asked.
What a reviewer will ask
Each of these is answered by an artifact rather than by a description of a process.
Can the decision be attributed to a specific policy version and identity
Answered from the signed decision record: acting identity, principal, policy version, decision, approver where one exists, and the execution result.
Can the record be verified without the vendor and without the original system
Answered from the signed decision record: acting identity, principal, policy version, decision, approver where one exists, and the execution result.
Where a human was required, is the approval bound to that exact decision
Answered from the signed decision record: acting identity, principal, policy version, decision, approver where one exists, and the execution result.
Are refusals recorded, so the absence of an action is also provable
Answered from the signed decision record: acting identity, principal, policy version, decision, approver where one exists, and the execution result.
The controls that answer them
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.
Human approval, bound and single-use
ProvenAn action held for approval produces no effect until a separately authenticated human with the required role approves that exact request. The approval is bound to the payload and the envelope, is consumed once, and cannot release a different action or the same action twice.
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.
Revocation of agent authority
ProvenAn authorized operator can revoke an agent. Its next request cannot execute, and an action it had already had approved but not yet dispatched cannot execute either — revocation reaches work already in flight, not only new requests.
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.
Relevant frameworks
EU AI Act, NIST AI RMF, ISO/IEC 42001. Coverage is stated control by control, with gaps named. ApexClaw holds no certification and displays no certification badge.