# Annex C

#### C.1 Receipt purpose, reliance tiers, and prohibited inferences

C.1.1 **Purpose.** A Proof Receipt (PR) is the NXOSI portable reliance object. It is a cryptographically signed, time-bound statement that binds a subject and scope to a specific profile/version and a defined set of verification semantics, while allowing full evidence to remain in a sovereign zone. A PR exists to eliminate re-audit by enabling independent verification of *what was checked, under which obligations, at what time, and with what permitted reliance*.

C.1.2 **Receipt as a reliance object, not a narrative report.** A PR MUST be machine-verifiable, schema-validatable, and stable under correctionability rules. A PR MUST be linkable to the relevant obligation (OAR), plan (XPL), check runs (CRR set), and status timeline (STO chain), subject to handling constraints.

C.1.3 **Relying party model.** A relying party is any entity that verifies a PR to make an operational, audit, or supervisory decision. NXOSI does not define who *may* rely as a legal matter; it defines what reliance is *technically permitted* by the receipt’s declared reliance tier and status.

C.1.4 **Reliance tiers (mandatory enumeration).** Each PR MUST declare exactly one reliance tier, which constrains permitted inference and required verification procedures:\
C.1.4.1 **R1 — Informational:** indicative, non-actionable; may support awareness and prioritization only.\
C.1.4.2 **R2 — Operational:** may support internal operational decisions under defined scope; not sufficient for external assurance claims without additional controls.\
C.1.4.3 **R3 — Audit:** may support audit reliance where supported by evidence access workflows and reproducibility requirements (via AEP access where lawful).\
C.1.4.4 **R4 — Supervisory:** may support supervisory/examiner reliance where controlled disclosure procedures, evidence lineage, and independence requirements are satisfied.

C.1.5 **Prohibited inferences (non-exhaustive; normative).** Regardless of tier, a PR MUST NOT be interpreted as:\
C.1.5.1 A statement of overall security, safety, fitness, or absence of vulnerabilities beyond the explicit controls and scope referenced.\
C.1.5.2 A certification, accreditation, regulatory approval, endorsement, or supervisory conclusion.\
C.1.5.3 Evidence of compliance with requirements not explicitly bound via `profile_hash`/`profile_ref` and linked control/test identifiers.\
C.1.5.4 A guarantee of future state (the PR is time-bound; drift can occur immediately after issuance).\
C.1.5.5 A substitute for legal, contractual, or statutory determinations outside the defined assurance perimeter.\
C.1.5.6 A basis to infer identities, locations, or sensitive operational details not explicitly disclosed under handling rules.

C.1.6 **Permitted inference limits (mandatory expression).** Each PR MUST carry a machine-readable `permitted_inference_limits` block that constrains: (i) what conclusions may be drawn, (ii) what conclusions are prohibited, and (iii) what additional artefacts must be present for stronger reliance (e.g., status freshness, required countersignatures, attestation tier).

***

#### C.2 Required fields and semantics (issuer, subject, scope, profile hash, time binding)

C.2.1 **Canonical structure.** A PR MUST include a canonical payload and a common envelope (Annex B.16) enabling deterministic hashing/signing and cross-implementation verification.

C.2.2 **Required PR payload fields (normative minimum).**\
C.2.2.1 `pr_id` — globally unique, canonical identifier.\
C.2.2.2 `object_type` = `PR`.\
C.2.2.3 `schema_id`, `schema_version`.\
C.2.2.4 `issuer` — issuer identifier plus authorization reference (see C.3).\
C.2.2.5 `issued_at` — issuance time.\
C.2.2.6 `subject` — the subject of the receipt (see C.2.3).\
C.2.2.7 `scope` — a machine-readable scope binding (see C.2.4).\
C.2.2.8 `profile_ref` and `profile_hash` — binding to the exact Signed Profile Package version and content.\
C.2.2.9 `oar_ref` — binding to the obligation instance that attached the duties and clocks.\
C.2.2.10 `xpl_ref` — binding to the execution plan used to generate check outcomes.\
C.2.2.11 `crr_set_ref` — a pointer or manifest hash referencing the CRR set underlying the receipt (handling-aware).\
C.2.2.12 `reliance_tier` — R1/R2/R3/R4.\
C.2.2.13 `permitted_inference_limits` — machine-readable constraints.\
C.2.2.14 `inclusion_proof_pointer` — pointer to transparency inclusion proof (see C.4).\
C.2.2.15 `status_pointer` — pointer to STO resolution endpoint (see C.5).\
C.2.2.16 `handling_class` — Public/Controlled/Restricted.\
C.2.2.17 `evidence_pack_pointer` — AEP index reference or access policy pointer (handling-aware).\
C.2.2.18 `integrity` — content hash, signature(s), crypto suite identifier(s) per envelope.

C.2.3 **Subject semantics (who/what is covered).**\
C.2.3.1 The subject MUST be expressible without leaking sensitive identity metadata by default.\
C.2.3.2 The subject SHOULD be represented as a canonical entity identifier from the ontology fabric (NOF), or a stable enterprise identifier, with aliasing rules defined in controlled metadata.\
C.2.3.3 Where the subject is a set (e.g., fleet of devices, vendor portfolio, service cluster), the receipt MUST include a deterministic set definition reference (e.g., a hashed membership manifest) and validity window constraints.

C.2.4 **Scope binding semantics (where/when/what conditions).**\
C.2.4.1 Scope MUST include: jurisdiction, time window, relevant hazard class (if applicable), and applicability constraints.\
C.2.4.2 Scope MUST be tight enough to prevent reuse out of context and MUST support anti-replay checks.\
C.2.4.3 Scope MUST declare whether it covers build-time, deploy-time, runtime, procurement, incident, retest, or mixed enforcement points.

C.2.5 **Result semantics (what is being asserted).**\
C.2.5.1 A PR MUST include a normalized `assertion_summary` referencing the evaluated control outcomes, expressed as structured codes rather than free narrative.\
C.2.5.2 A PR MUST NOT embed raw evidence; it MUST only carry pointers/hashes sufficient for verification under the declared reliance tier.\
C.2.5.3 Where probabilistic checks are allowed, the PR MUST declare uncertainty fields (confidence bounds, thresholds, and model/tool versions used).

***

#### C.3 Signing rules, authorization proofs, and key requirements

C.3.1 **Signature requirement.** Every PR MUST be signed using an approved cryptographic suite declared in `crypto_suite_id`. The signature MUST cover the canonical serialized payload and MUST be verifiable by any relying party with access to the issuer’s public verification material.

C.3.2 **Issuer authorization proof.**\
C.3.2.1 A PR MUST include `issuer_authorization_ref` pointing to a verifiable authorization record indicating the issuer is permitted to issue PRs for the relevant object class, reliance tier, and scope class.\
C.3.2.2 Authorization MUST be status-resolvable (revocable) and MUST support expiry and rotation.\
C.3.2.3 If issuer authorization is revoked or expired at verification time, the PR MUST be treated as invalid for reliance.

C.3.3 **Key lifecycle constraints.**\
C.3.3.1 Signing keys MUST be managed under a defined lifecycle: generation, storage, rotation, revocation, and compromise response.\
C.3.3.2 PRs intended for R3/R4 reliance SHOULD use keys protected by hardware-backed security (HSM/TEE-backed key stores) or equivalent.\
C.3.3.3 Key identifiers MUST be resolvable and MUST support transparent rotation without invalidating historical receipts (long-lived verification requirement).

C.3.4 **Countersignatures and quorum (optional, risk-tiered).**\
C.3.4.1 Profiles MAY require countersignatures for defined high-impact PR classes (e.g., supervisory reliance, sovereign acts, break-glass outcomes).\
C.3.4.2 When required, countersignatures MUST be included in the envelope and MUST be independently verifiable, with explicit role separation constraints.

C.3.5 **Post-quantum readiness.**\
C.3.5.1 The PR envelope MUST support dual-signing during migration windows where required.\
C.3.5.2 PQ fields MUST include suite identifiers, migration clock references, and archival verification instructions where applicable.

***

#### C.4 Inclusion proof pointer requirements and verification procedure

C.4.1 **Objective.** Transparency inclusion enables auditability, portability, and equivocation resistance. A PR MUST be verifiable against an append-only transparency publication model appropriate to its handling class and reliance tier.

C.4.2 **Inclusion proof pointer requirements.**\
C.4.2.1 A PR MUST include `inclusion_proof_pointer` referencing: the transparency log identifier, entry index (or equivalent), and the inclusion proof object location.\
C.4.2.2 The pointer MUST be stable and MUST support offline verification via snapshots for defined tiers.\
C.4.2.3 The inclusion proof MUST bind to the receipt’s `content_hash` and MUST fail verification if the receipt payload differs.

C.4.3 **Verification procedure (minimum steps).** A relying party verifying inclusion MUST:\
C.4.3.1 Validate PR payload schema and signature (C.2/C.3).\
C.4.3.2 Recompute canonical payload hash and confirm it matches `content_hash`.\
C.4.3.3 Fetch or load the inclusion proof and the relevant transparency snapshot/head.\
C.4.3.4 Verify the inclusion proof against the transparency head under the declared suite/format.\
C.4.3.5 Confirm the publish-time constraints: the transparency publish time MUST fall within the PR’s permitted time binding/freshness window, subject to tier rules.\
C.4.3.6 Apply reliance-tier rules when transparency is unavailable (see C.6 and C.7 fallback behavior).

C.4.4 **Equivocation posture declaration.** The PR SHOULD declare the log’s equivocation posture class (e.g., monitored, audited, federated witnesses) as metadata for reliance evaluation. Where R4 is claimed, an equivocation monitoring expectation MUST be satisfied as defined by conformance.

***

#### C.5 Status pointer requirements (revocation/supersession/scope narrowing)

C.5.1 **Status is mandatory.** Every PR MUST include a `status_pointer` enabling relying parties to determine whether the PR is valid, revoked, superseded, scope-narrowed, or expired.

C.5.2 **Status resolution semantics.**\
C.5.2.1 Status MUST be expressed via STO objects (revocation, supersession, scope narrowing, validity windows).\
C.5.2.2 Status resolution MUST support both online queries and offline snapshots for defined tiers.\
C.5.2.3 If status cannot be resolved, reliance MUST degrade according to the tier’s fallback rules; for high tiers, unresolved status MUST block reliance.

C.5.3 **Revocation.**\
C.5.3.1 Revocation MUST be explicit and time-effective; relying parties MUST treat a revoked PR as invalid for any reliance from the revocation effective time forward.\
C.5.3.2 Revocation reason codes MUST be controlled vocabulary and MUST not leak sensitive details under restrictive handling classes.

C.5.4 **Supersession.**\
C.5.4.1 Supersession MUST link the prior PR to the replacement PR and MUST declare migration/equivalence notes where applicable.\
C.5.4.2 Supersession MUST not silently “rewrite history”; it MUST preserve the old receipt as a historical object with updated status semantics.

C.5.5 **Scope narrowing.**\
C.5.5.1 Scope narrowing MUST explicitly state what portion of scope is no longer valid for reliance and why.\
C.5.5.2 Relying parties MUST enforce narrowed scope before drawing conclusions.

C.5.6 **Dispute holds.** If a PR is under dispute, status resolution MUST expose a dispute reference and MAY require reliance hold or reduced reliance until adjudicated, per dispute clock rules.

***

#### C.6 Offline verification bundle requirements (formats, caching, archival)

C.6.1 **Offline-first objective.** NXOSI MUST support verification without continuous network connectivity for defined tiers and deployment modes (sovereign/air-gapped/offline).

C.6.2 **Offline verification bundle contents (minimum).** Where offline verification is supported or required, the bundle MUST include:\
C.6.2.1 PR payload and signature(s).\
C.6.2.2 Issuer public verification material and authorization snapshot sufficient for validation.\
C.6.2.3 The relevant SPP package or a hash-resolved proof of the profile contents and version constraints.\
C.6.2.4 A transparency snapshot/head and inclusion proof material for the receipt.\
C.6.2.5 Status snapshot(s) sufficient to resolve revocation/supersession within the bundle’s freshness window.\
C.6.2.6 Bundle metadata: creation time, expiry, and update policy.

C.6.3 **Caching rules.**\
C.6.3.1 Caches MUST be signed and integrity-checked.\
C.6.3.2 Caches MUST declare freshness windows and MUST be treated as stale beyond expiry.\
C.6.3.3 Stale cache behavior MUST be defined by reliance tier (e.g., informational may proceed with warning; supervisory must halt).

C.6.4 **Archival verification.**\
C.6.4.1 Long-lived verification bundles MUST include cryptographic suite identifiers, verifier instructions, and any required intermediate certificates/endorsements.\
C.6.4.2 Where PQ transition applies, archival bundles MUST preserve both classical and PQ verification material for the relevant window.

***

#### C.7 Anti-replay and context binding semantics

C.7.1 **Problem.** Without anti-replay, a PR could be copied and reused outside its intended context, time, or scope to mislead a relying party.

C.7.2 **Context binding (mandatory).** A PR MUST bind to:\
C.7.2.1 Scope (jurisdiction, time window, hazard class, enforcement point domain).\
C.7.2.2 Profile identity (SPP reference + profile hash).\
C.7.2.3 Obligation instance (OAR reference).\
C.7.2.4 Time binding (issued\_at; not\_before; expires\_at as applicable).\
C.7.2.5 Optional: environment binding identifiers when attestation is required (measured environment ID, endpoint identity, or appraisal result reference).

C.7.3 **Freshness and expiry.**\
C.7.3.1 PRs MUST declare freshness constraints appropriate to tier and context (e.g., operational vs audit vs supervisory).\
C.7.3.2 Verifiers MUST reject PRs outside declared validity windows unless an explicit policy allows historical use for limited purposes (e.g., forensic reconstruction) and only with clear non-reliance marking.

C.7.4 **Replay detection support.**\
C.7.4.1 PRs SHOULD include a nonce/sequence field or equivalent replay-guard mechanism when used in interactive verification contexts.\
C.7.4.2 Where replay detection depends on online services, offline verification MUST downgrade reliance if replay detection cannot be performed and the tier requires it.

***

#### C.8 Selective disclosure and metadata minimization

C.8.1 **Minimal disclosure default.** PRs MUST be designed to reveal the least information required for the declared reliance tier and verification procedure.

C.8.2 **Metadata minimization rules.**\
C.8.2.1 PRs MUST NOT disclose personal identifiers by default.\
C.8.2.2 PRs MUST avoid revealing sensitive topology (e.g., detailed asset lists, precise locations, internal hostnames) unless explicitly permitted by handling class and lawful basis.\
C.8.2.3 PRs MUST not embed raw telemetry; they MAY include hashed pointers and controlled access references.

C.8.3 **Selective disclosure mechanisms.**\
C.8.3.1 PRs SHOULD support selective disclosure of scope components, subject details, or control subsets, using cryptographically verifiable techniques (e.g., disclosure manifests, redaction hashes, or proof-of-inclusion over disclosed subsets).\
C.8.3.2 Any selective disclosure MUST preserve verifiability and MUST not change semantics; a disclosed subset MUST clearly state what is omitted and what reliance limits apply.

C.8.4 **Handling-aware summaries.** Public-safe summaries MAY be derived, but MUST be linked to the PR ID, MUST reference the same status pointer, and MUST not expand permitted inference.

***

#### C.9 Negative requirements (no PII leakage; no implied endorsement)

C.9.1 **No PII leakage (normative).** A PR MUST NOT include personal data unless: (i) strictly necessary for the reliance tier, (ii) permitted by handling class, and (iii) supported by lawful basis and purpose limitation declarations. When included, PII MUST be minimized, access-controlled, and auditable.

C.9.2 **No implied endorsement (normative).** A PR MUST NOT contain language, fields, badges, or metadata that imply regulator approval, certification of overall security, or endorsement by an authority absent an explicit, separately governed instrument.

C.9.3 **No overclaim beyond bound scope (normative).** A PR MUST NOT:\
C.9.3.1 Claim coverage beyond the declared scope window, jurisdiction, or subject set.\
C.9.3.2 Claim conformance beyond the referenced profile/hash and linked controls/tests.\
C.9.3.3 Claim that evidence has been disclosed or reviewed when it has not; the PR MUST clearly distinguish “receipt-only verification” from “controlled evidence review completed.”

C.9.4 **No silent edits (normative).** A PR MUST be immutable once issued. Any change in meaning MUST occur only via STO/correction objects, with explicit links and effective times.

C.9.5 **No covert metadata channels (normative).** Implementations MUST prevent PR fields from being used as covert channels to leak sensitive information (e.g., by restricting free-form text, bounding field sizes, and using controlled vocabularies where feasible).


---

# 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-c.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.