# Annex E

#### E.1 Status object semantics (revocation, supersession, scope narrowing, validity windows)

E.1.1 **Purpose.** Status Objects (STO) are the exclusive mechanism by which NXOSI changes reliance conditions after issuance of an artefact, receipt, plan, or determination. STOs preserve reliance stability by ensuring that changes are explicit, time-bound, queryable, and linkable—never implicit.

E.1.2 **Scope.** This annex specifies the normative semantics for: revocation, supersession, scope narrowing, validity windows, interim holds during dispute, and compromise response behaviors. These semantics apply uniformly to all status-bearing objects, including but not limited to PSA, SPP, OAR, XPL, CRR, PR, AEP index, DO/GDO, DKT, CPAR, and conformance reports where status is referenced.

E.1.3 **No silent change invariant.**\
E.1.3.1 Any change that affects permitted reliance, interpretation, verification results, or portability MUST be represented by an STO.\
E.1.3.2 Implementations MUST NOT alter previously published artefacts “in place.”\
E.1.3.3 Implementations MUST treat an STO as authoritative for the objects it covers, subject to dispute rules in E.5.

E.1.4 **Status-bearing set.**\
E.1.4.1 Every PR MUST include a `status_pointer` that resolves to the current STO resolution for the PR and any referenced artefacts required for verification.\
E.1.4.2 Objects that are referenced by other objects (PSA/SPP/OAR/XPL) MUST expose status resolution paths to prevent reliance on stale or revoked dependencies.

E.1.5 **Core status actions.** The STO model supports four primary action types:\
E.1.5.1 `REVOKE` — invalidates reliance for specified scopes and windows; relying parties MUST treat the covered objects as not valid for the revoked scope/time from the effective point forward (and possibly retroactively if explicitly stated and permitted).\
E.1.5.2 `SUPERSEDE` — declares a successor object/version and defines migration semantics, equivalence constraints, and reliance continuity rules.\
E.1.5.3 `NARROW_SCOPE` — constrains the valid scope without full revocation (e.g., limits geography, hazard class, dependency set, or reliance tier).\
E.1.5.4 `VALIDITY_WINDOW` — establishes explicit start/end validity and freshness boundaries; may be attached to any of the above actions.

E.1.6 **Required STO fields (normative minimum).** An STO MUST include:\
E.1.6.1 `sto_id` (globally unique), `sto_version`, `issued_at`, `effective_at`.\
E.1.6.2 `issuer` and `issuer_authorization_proof` (role key / authority basis).\
E.1.6.3 `target_set` identifying the objects covered (by immutable IDs and hashes).\
E.1.6.4 `status_action` with one of the action types above, plus action-specific fields.\
E.1.6.5 `reason_code` and `reason_summary` (handling-aware; minimal disclosure).\
E.1.6.6 `scope` (jurisdiction, geography, entity set, hazard class, time window) that the status applies to.\
E.1.6.7 `reliance_impact` specifying which reliance tiers are affected and how.\
E.1.6.8 `challenge_window` parameters when applicable (see E.5).\
E.1.6.9 `signature` and `crypto_suite_id`, with optional countersignatures for higher tiers.

E.1.7 **Effective time semantics.**\
E.1.7.1 `issued_at` denotes when the STO is created and signed; `effective_at` denotes when relying parties MUST apply it.\
E.1.7.2 If `effective_at` is in the future, relying parties MAY continue reliance until that time, subject to dispute holds.\
E.1.7.3 Retroactive effects MUST be explicitly flagged and MUST include justification and limitations; retroactivity SHOULD be constrained to integrity incidents and only where reliance stability rules permit.

E.1.8 **Revocation semantics.**\
E.1.8.1 Revocation MUST specify whether it is total (entire object invalid) or scoped (only certain claims/scopes invalid).\
E.1.8.2 Revocation MUST specify whether it affects: (i) verification validity, (ii) permitted inference limits, (iii) only a specific dependency chain, or (iv) a specific time window.\
E.1.8.3 Relying parties MUST treat revoked objects as invalid for the revoked scope; verification MUST fail or downgrade reliance in accordance with the declared rules.

E.1.9 **Supersession semantics.**\
E.1.9.1 Supersession MUST identify the successor object and successor version/hash.\
E.1.9.2 Supersession MUST include migration and equivalence notes per E.4.\
E.1.9.3 Supersession MAY preserve reliance if equivalence constraints are satisfied; otherwise reliance MUST be downgraded or re-verified under the new version.

E.1.10 **Scope narrowing semantics.**\
E.1.10.1 Scope narrowing MUST specify the new permitted scope and the delta from the prior scope.\
E.1.10.2 Scope narrowing MUST NOT introduce broader claims than the target object originally permitted.\
E.1.10.3 Relying parties MUST enforce the narrower scope for any verification and permitted inference.

E.1.11 **Validity windows and freshness.**\
E.1.11.1 Validity windows MUST specify start/end times and may specify freshness bounds for dependent evidence (e.g., attestations).\
E.1.11.2 Relying parties MUST enforce freshness windows when verifying receipts for higher reliance tiers; stale dependencies trigger downgrade or failure.

***

#### E.2 Status query APIs and caching rules

E.2.1 **Status resolution API (minimum).** Implementations MUST provide a status query interface that resolves current status for a target object (by ID and hash) and returns a machine-readable status response sufficient for verification and audit.

E.2.2 **Required queries.**\
E.2.2.1 `get_status(target_id, target_hash)` — returns the effective status chain for the target.\
E.2.2.2 `get_status_batch([...])` — batch resolution for dependency graphs (profiles, plans, receipts).\
E.2.2.3 `get_status_at_time(target_id, time)` — optional but recommended for audit replay and “verify as-of” semantics.

E.2.3 **Status response fields.** A status response MUST include:\
E.2.3.1 `resolved_state` (VALID / INVALID / LIMITED / ON\_HOLD / EXPIRED / UNKNOWN).\
E.2.3.2 `effective_sto_set` (the STO(s) that produced the resolved state).\
E.2.3.3 `resolution_time` and `resolution_freshness` (cache lifetime guidance).\
E.2.3.4 `constraints` (if LIMITED: the narrowed scope or downgraded reliance tiers).

E.2.4 **Caching rules.**\
E.2.4.1 The service MUST publish cache-control parameters: maximum staleness and refresh frequency bounds.\
E.2.4.2 Relying parties MUST respect cache freshness windows according to reliance tier; higher tiers require shorter cache windows and more frequent refresh.\
E.2.4.3 Offline verification MUST be supported via cached status snapshots or checkpointed status publications, subject to declared expiry.

E.2.5 **Dependency-aware resolution.**\
E.2.5.1 Status resolution MUST support dependency graphs: if a PR depends on SPP/PSA/OAR/XPL, the relying party MUST be able to resolve status for the entire verification chain.\
E.2.5.2 Resolution MUST detect contradictions (e.g., PR valid but underlying SPP revoked) and produce a deterministic outcome (fail or downgrade) defined by policy.

E.2.6 **Error handling.** The status API MUST have stable error semantics: not found, stale/expired snapshot, unauthorized, service unavailable, inconsistent chain.

***

#### E.3 Relying party resolution rules (offline/online; degraded modes)

E.3.1 **General rule.** A relying party MUST resolve status for: (i) the PR itself, and (ii) the minimum dependency set required by the declared reliance tier.

E.3.2 **Online resolution.**\
E.3.2.1 When online, relying parties MUST query current status unless the receipt declares a reliance tier permitting cached status.\
E.3.2.2 If the status service is reachable but returns UNKNOWN or inconsistent results, reliance MUST be downgraded or rejected according to tier policy.

E.3.3 **Offline resolution.**\
E.3.3.1 Offline verification is permitted only if the relying party possesses a valid, unexpired status snapshot and transparency snapshot consistent with the receipt’s publication time constraints.\
E.3.3.2 If the snapshot is expired, the relying party MUST either (i) refresh online, or (ii) downgrade reliance to a tier that permits stale status, if permitted by policy.

E.3.4 **Degraded-mode rules.**\
E.3.4.1 If the status service is unavailable, relying parties MUST apply the receipt’s declared degraded-mode policy: fail closed for supervisory tiers; fail-open with explicit downgrade for lower tiers if allowed.\
E.3.4.2 Degraded-mode verification MUST record that degraded mode was used, including snapshot identifiers and staleness.

E.3.5 **Resolution priority.** If multiple STOs apply:\
E.3.5.1 A REVOKE overrides SUPERSEDE and NARROW\_SCOPE for overlapping scope unless explicitly constrained.\
E.3.5.2 NARROW\_SCOPE overrides VALIDITY\_WINDOW where it further restricts the scope.\
E.3.5.3 SUPERSEDE preserves continuity only when equivalence constraints are satisfied; otherwise it results in LIMITED or INVALID depending on policy.

E.3.6 **Cross-jurisdiction overlays.** If overlays alter reliance tier permissions or disclosure constraints, relying parties MUST apply the most restrictive applicable rule for the relevant scope and jurisdiction.

***

#### E.4 Migration and equivalence notes requirements under supersession

E.4.1 **Purpose.** Supersession must not destabilize reliance by ambiguity. Migration and equivalence notes are mandatory for any supersession that affects interpretation, verification results, or operational duties.

E.4.2 **Mandatory content.** A SUPERSEDE STO MUST include:\
E.4.2.1 `successor_id` and `successor_hash`.\
E.4.2.2 `supersession_type` (patch / minor / major) aligned with semantic versioning.\
E.4.2.3 `equivalence_claim` stating whether the successor is functionally equivalent for defined scopes.\
E.4.2.4 `equivalence_constraints` describing the conditions required for equivalence (e.g., unchanged control semantics; parameter-only change; stricter-only change).\
E.4.2.5 `migration_steps` describing required operator actions or verification steps.\
E.4.2.6 `compatibility_impact` describing what verifiers must update (schema/API changes, new crypto suites, altered overlays).\
E.4.2.7 `rollout_timeline` including any sunset of the prior version and deadlines.

E.4.3 **Equivalence proofs.**\
E.4.3.1 For higher reliance tiers, supersession SHOULD include evidence pointers to equivalence testing results (e.g., regression vectors, determinism checks).\
E.4.3.2 If equivalence cannot be established, the STO MUST explicitly say so and define reliance downgrade or re-verification requirements.

E.4.4 **Backward compatibility guarantees.** Supersession SHOULD preserve receipt verification where feasible; when not feasible, the STO MUST provide a verification migration pathway and explain the break.

***

#### E.5 Dispute holds and interim status behaviors

E.5.1 **Purpose.** Dispute holds prevent premature reliance on contested artefacts while ensuring operations remain deterministic and time-bound.

E.5.2 **Interim hold status.** The STO model MUST support `ON_HOLD` as an interim resolved state when a dispute is accepted for review.

E.5.3 **Triggers for hold.** A hold MAY be applied when:\
E.5.3.1 A formal challenge is submitted within the challenge window.\
E.5.3.2 A credible integrity concern is raised (e.g., suspected compromised signing key).\
E.5.3.3 A conflict between overlays or dependency statuses cannot be resolved automatically.

E.5.4 **Hold semantics.**\
E.5.4.1 While ON\_HOLD, relying parties MUST pause reliance for affected tiers and scopes, or downgrade according to policy.\
E.5.4.2 Holds MUST have explicit `hold_start`, `hold_expiry`, and `review_deadline` clocks.\
E.5.4.3 Holds MUST specify whether operational continuity actions may proceed under constrained reliance.

E.5.5 **Interim measures.** The status system MUST support interim scope narrowing as a less disruptive alternative to full revocation during dispute.

E.5.6 **Resolution.** Dispute resolution MUST end in one of: confirm valid (lift hold), narrow scope, supersede with migration, or revoke. The final resolution MUST be recorded via STO(s) with explicit effective times.

***

#### E.6 Compromise response: bulk invalidation and emergency freeze hooks

E.6.1 **Purpose.** NXOSI must respond to compromise events (key compromise, systemic bug, supply-chain incident, equivocation suspicion) with rapid, verifiable invalidation while preserving audit replay.

E.6.2 **Bulk invalidation.**\
E.6.2.1 The system MUST support bulk revocation of a defined target set (e.g., all receipts signed by a compromised key within a time window).\
E.6.2.2 Bulk invalidation MUST be expressible as an STO with a target selector (issuer key ID + time range + object type + optional scope constraints).\
E.6.2.3 Bulk invalidation MUST be discoverable via status queries and, where permitted, via transparency publication.

E.6.3 **Emergency freeze hooks.**\
E.6.3.1 The system MUST support an emergency freeze mechanism that halts issuance of new receipts or acceptance of new profile releases under defined conditions.\
E.6.3.2 Freeze actions MUST be recorded as CPAR objects and SHOULD be reflected in status publication metadata so relying parties can understand verification impacts.

E.6.4 **Recovery workflow.**\
E.6.4.1 Compromise response MUST include key rotation, re-baselining of attestations, and re-issuance where appropriate.\
E.6.4.2 The system MUST maintain an audit trail linking compromised artefacts to corrective actions and replacement artefacts.

E.6.5 **Reliance downgrade rules.** During compromise response windows, reliance tiers MUST downgrade as declared by policy; higher tiers default to fail closed until status is stable.

***

#### E.7 Status transparency and publication constraints (public-safe vs controlled)

E.7.1 **Publication objective.** Status must be discoverable enough to prevent reliance on invalid artefacts, without exposing sensitive operational metadata.

E.7.2 **Public-safe vs controlled status.**\
E.7.2.1 Public-safe status publication MAY disclose: object IDs/hashes, status state (valid/revoked/superseded/limited), effective time, and minimal reason codes.\
E.7.2.2 Controlled status publication MAY include richer rationale, migration details, and scoped impact analysis, subject to handling rules and lawful basis.

E.7.3 **Minimum public-safe requirement.** For artefacts intended for cross-organization reliance, at least a public-safe status endpoint MUST exist so that relying parties can detect revocation and supersession.

E.7.4 **Metadata minimization.** Status publications MUST NOT expose: identity of protected participants, sensitive asset inventories, detailed incident telemetry, or Restricted-class evidence references.

E.7.5 **Checkpointing and snapshots.** Status publications SHOULD be checkpointed and snapshot-capable for offline verification. Snapshots MUST carry expiry and update rules consistent with reliance tiers.

E.7.6 **Consistency with proof publication.** Where PR inclusion is published in transparency logs, STO publication SHOULD be co-published or cryptographically chained to avoid “receipt valid but status hidden” failure modes.

E.7.7 **Misrepresentation controls.** If a party continues to assert validity contrary to published STOs, the governance sanctions ladder MUST permit badge withdrawal, role key revocation, and publication of a correction notice consistent with handling rules.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-osi/annexes/annex-e.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.