Open architecture specification for provenance-aware AI systems and institutional memory.
A Coverage Assertion is a referenceable evidence artifact asserting that a defined boundary was authoritative and complete for a class of state or events during a defined interval, supported by evidence of the custody configuration in force throughout that interval.
It is a distinct evidence artifact, not a field of an individual Forensic Receipt.
It has its own identity, scope, temporal validity, verification requirements, and trust dependencies.
Receipts and ledger segments that support a negative claim reference it. They do not embed it.
The governing principle is:
Observation records what a boundary saw. Coverage is the claim that nothing in scope could have bypassed it.
The term Coverage Assertion was proposed and contributed to the Sovereign Systems Specification by Nicolás Moreno (@bimmer2003) in 2026, in issue #1 and pull request #2, and refined in discussion with Ken W. Alger.
A Forensic Receipt binds an event to the evidence observable at a boundary.
A ledger of integrity-valid receipts can therefore support the claim:
This boundary observed X.
It cannot, by itself, support the claim:
Nothing else of class Y happened during interval Z.
The second claim depends on something no individual receipt records: that the boundary was the only path to the state in question for the whole interval.
That guarantee comes from custody, not from the ledger.
Without an explicit artifact carrying it, a verifier must either take exclusivity on faith or reconstruct it from outside the evidence.
Negative Evidence already states that its adequacy “depends on the completeness and authority of the source.” A Coverage Assertion is the artifact that makes that completeness and authority inspectable.
These are different claims:
Observation: this boundary observed X.
Coverage: this boundary was authoritative and complete for class Y during interval Z.
flowchart LR
A["Consequential Event"] --> B["Forensic Receipt<br/>(Observation)"]
C["Custody Configuration<br/>History"] --> D["Coverage Assertion"]
E["Observations of Effective<br/>Enforcement State"] --> D
B --> F["Negative Claim"]
D --> F
G["Event Evidence<br/>Complete for the Claim"] --> F
classDef capture fill:#378ADD,stroke:#378ADD,color:#FFFFFF
classDef governance fill:#1D9E75,stroke:#1D9E75,color:#FFFFFF
classDef memory fill:#BA7517,stroke:#BA7517,color:#FFFFFF
classDef boundary fill:#6B7280,stroke:#6B7280,color:#FFFFFF
classDef failure fill:#C0392B,stroke:#C0392B,color:#FFFFFF
class A capture
class B,D,F governance
class C,E,G boundary
Most receipts only need to support observation.
An ordinary receipt attesting to an observed event carries no completeness obligation, and a Coverage Assertion does not change that.
Coverage is required only where a receipt or ledger segment is used to support a negative claim.
The exact schema is implementation-specific.
A Coverage Assertion should make explicit:
Exclusions and gaps are part of the assertion.
A declared exclusion is stronger than a silent one, for the same reason a Known Blind Spot is stronger than silent absence.
Coverage has the same shape as key authority.
These are different questions:
Is this boundary exclusive now?
and:
Was this boundary exclusive for class Y throughout interval Z?
Custody configuration changes. A grant is added, a connector is registered, a network path is opened for an incident, an enforcement mechanism is reconfigured.
A policy version recorded at time T does not establish continuity across Z.
Each change to custody configuration that can affect what the boundary covers is a consequential event. It should be governed by Write-Side Custody and witnessed like any other consequential event.
Versioning and witnessing configuration changes is necessary. It is not sufficient.
A signed sequence of known changes does not, by itself, prove that no unobserved change occurred.
The change history must therefore be reconciled with evidence it did not produce: independent observations of the effective enforcement state, read from the enforcement mechanism itself rather than from the record of intended changes.
flowchart LR
O1["Observed Effective State<br/>(start of interval)"] --> R["Replay Recorded<br/>Changes"]
H["Recorded Configuration<br/>Changes"] --> R
R --> P["Predicted State"]
O2["Observed Effective State<br/>(next observation)"] --> C{"Reconcile"}
P --> C
C -->|"Consistent"| S["Supports Continuity"]
C -.->|"Inconsistent"| X["Contradicts Continuity"]
classDef capture fill:#378ADD,stroke:#378ADD,color:#FFFFFF
classDef governance fill:#1D9E75,stroke:#1D9E75,color:#FFFFFF
classDef memory fill:#BA7517,stroke:#BA7517,color:#FFFFFF
classDef boundary fill:#6B7280,stroke:#6B7280,color:#FFFFFF
classDef failure fill:#C0392B,stroke:#C0392B,color:#FFFFFF
class O1,O2 capture
class H,R,P boundary
class C,S governance
class X failure
At a minimum, effective enforcement state should be observed at the bounds of the interval.
Replaying the recorded changes from one observation should reproduce the next.
The observations are themselves evidence. They should be witnessed, and where the assurance model requires it, checkpointed or anchored independently of the operator who controls the configuration.
The method of observation is implementation-specific. It may be a read of access-control state, network policy, hardware isolation state, or another mechanism appropriate to the boundary.
The requirement is the same: the observation must come from the mechanism that enforces, not from the record of what was meant to be enforced.
A declared observation resolution is not a guarantee that every transient configuration change within the interval would be detected.
A change introduced and reverted between two observations can remain invisible to reconciliation.
A supported Coverage Assertion is therefore always relative to the declared observation model, the evidence available, and the trust anchors the verifier accepts.
It is not proof of absolute completeness.
Coverage is evidenced at the resolution it declares, and no finer.
This does not make coverage evidence weak. It defines its strength and scope, in the same way a chain relationship supports verification relative to the trusted anchors available to the verifier.
Coverage must not become a Boolean that a producer can set to true.
A Coverage Assertion is verified, not declared verified.
Verifying it should produce one of three outcomes:
Supported: the assertion resolves, its custody policy and enforcement references resolve, the configuration history reconciles with every observation of effective enforcement state within the declared resolution, no evidence shows activity of the covered class outside the boundary, and the observations validate against the selected trust anchors.
Contradicted: evidence is inconsistent with the assertion. For example, an observation of effective enforcement state does not match the state predicted from the recorded changes, or a receipt or other evidence shows activity of the covered class reaching durable state through a path outside the boundary during the interval.
Undetermined: the available evidence does not establish the assertion. For example, an observation at a bound of the interval is missing, a gap between observations exceeds the declared resolution, a referenced artifact is unavailable, or a trust anchor cannot be validated.
A verifier may ask:
Exclusions and gaps do not automatically produce undetermined.
A claim that falls entirely outside a declared exclusion or gap may still be supported. A claim that depends on an excluded path, or on a gap, cannot be supported by the assertion.
A producer may declare coverage. Only verification can support it.
A supported Coverage Assertion does not, by itself, establish a negative claim.
It establishes that the boundary was authoritative and complete for the covered class during the interval, at the declared resolution.
The negative claim also requires that the relevant event evidence produced at that boundary be sufficiently complete for the claim: the ledger segment must cover the interval, be intact relative to its trust anchors, and be within the assertion’s claim class.
Both are necessary:
A negative claim needs both: the boundary saw nothing, and nothing could go around it.
A Forensic Receipt binds a consequential event to the evidence observable at a boundary.
A Coverage Assertion asserts that the boundary was the only path for a class of events during an interval.
A receipt that supports only observation needs no Coverage Assertion.
A receipt or ledger segment that supports a negative claim should reference the Coverage Assertion it depends on, by identity and integrity material, rather than embedding its contents.
Multiple receipts and ledger segments may depend on the same Coverage Assertion.
Negative Evidence directly supports a negative claim, and its adequacy depends on the completeness and authority of the source.
A Coverage Assertion is the evidence-level form of that completeness and authority for a boundary over an interval.
Without one, negative evidence drawn from a boundary’s records rests on an unstated assumption that the boundary was exclusive.
Write-Side Custody governs admission to durable state.
A Coverage Assertion depends on custody in two ways.
Custody is what makes the boundary exclusive, so the assertion references the custody policy and enforcement mechanism that did so.
Changes to custody configuration are consequential events, so the assertion depends on custody having governed and witnessed those changes for the interval.
The assertion does not make custody exclusive. It preserves the evidence by which a later verifier can evaluate whether it was.
Custody enforces. The ledger witnesses. Coverage evidences that custody had no gaps in scope.
The Reasoning Ledger records observable evidence surrounding consequential decisions and operations.
A Coverage Assertion may scope a ledger segment: it states for which class and interval the segment’s absence of an event can be read as evidence of absence.
The ledger records what happened at the boundary. The Coverage Assertion records why the ledger’s silence about something else is meaningful.
Sovereign Systems distinguish what a boundary observed from what a boundary was complete for.
A conforming design should:
supported, contradicted, or undetermined, never to a producer-set BooleanThe objective is not to prove that nothing unobserved could ever have happened.
The objective is to make the completeness a negative claim depends on into evidence that a later verifier can evaluate, with its scope, resolution, and trust dependencies stated.