# Annex D

#### D.1 Transparency service model (append-only log; inclusion proofs; audit hooks)

D.1.1 **Purpose.** The Transparency Service provides a tamper-evident, append-only publication layer for NXOSI Proof Receipts (PR) and selected status events (STO) so that relying parties can (i) verify inclusion, (ii) detect equivocation or log manipulation posture violations, and (iii) validate time-bound publication requirements without re-audit.

D.1.2 **Scope.** This annex specifies: the log model, inclusion/consistency proof semantics, checkpointing/snapshots, operational SLO expectations, privacy constraints, and the interoperability profile required for “NXOSI-compliant” transparency publication.

D.1.3 **Non-execution boundary.** The Transparency Service MUST NOT perform regulated execution functions. It does not adjudicate disputes, certify outcomes, or replace supervisory processes. It provides verifiable publication and audit hooks only.

D.1.4 **Objects eligible for logging.**\
D.1.4.1 The log MUST support PR inclusion entries.\
D.1.4.2 The log SHOULD support STO inclusion entries for revocation/supersession/scope narrowing, or alternatively provide a verifiable pointer to a status service whose outputs are separately integrity-protected and checkpointed.\
D.1.4.3 The log MAY support additional objects (e.g., conformance report digests) if they comply with handling and privacy constraints.

D.1.5 **Append-only property.**\
D.1.5.1 The service MUST provide an append-only structure such that any removal or modification of entries is detectably inconsistent with the published checkpoints.\
D.1.5.2 The service MUST provide cryptographic proofs of inclusion for entries and proofs of consistency between checkpoints.

D.1.6 **Receipt-to-log binding.**\
D.1.6.1 A PR MUST carry an `inclusion_proof_pointer` referencing the log identifier and entry coordinates.\
D.1.6.2 The log entry payload MUST bind to the PR `content_hash` (or a canonical digest thereof) such that inclusion proof verification fails if the PR is altered.

D.1.7 **Audit hooks.**\
D.1.7.1 The service MUST expose auditable checkpoints and MUST support independent monitoring of checkpoint progression.\
D.1.7.2 The service SHOULD support external witness/monitor ingestion of checkpoints to strengthen equivocation detection posture.

D.1.8 **Handling-awareness.**\
D.1.8.1 The service MUST enforce handling-class constraints such that Restricted-class artefacts are not leaked through log metadata.\
D.1.8.2 Where necessary, the log MUST accept hashed or redacted representations rather than raw metadata.

***

#### D.2 Log operations and APIs (append, prove-inclusion, prove-consistency, checkpoint)

D.2.1 **Interoperability objective.** A relying party MUST be able to verify inclusion and consistency using only standardized API semantics, the PR envelope data, and a checkpoint/snapshot.

D.2.2 **API surface (normative minimum).** The service MUST provide:\
D.2.2.1 `append(entry)` — append an entry to the log.\
D.2.2.2 `prove_inclusion(entry_digest, tree_size|checkpoint)` — return an inclusion proof for a specified digest relative to a checkpoint.\
D.2.2.3 `prove_consistency(old_checkpoint, new_checkpoint)` — return a proof that the new checkpoint is a strict append-only extension of the old checkpoint.\
D.2.2.4 `get_checkpoint()` — return the latest signed checkpoint.

D.2.3 **Append operation semantics.**\
D.2.3.1 The append request MUST include: `entry_digest`, `entry_type` (PR/STO/other), `handling_class`, and `issuer_hint` (minimized).\
D.2.3.2 The append response MUST include: `log_id`, `entry_index` (or equivalent coordinate), `integrated_time`, and a pointer to inclusion proof retrieval.

D.2.4 **Inclusion proof semantics.**\
D.2.4.1 `prove_inclusion` MUST return a proof object sufficient for a verifier to validate membership of the digest in the log at the referenced checkpoint.\
D.2.4.2 The proof object MUST include the checkpoint identifier and the path elements required to verify membership.

D.2.5 **Consistency proof semantics.**\
D.2.5.1 `prove_consistency` MUST enable a verifier to confirm that the log has not been rewritten between two checkpoints.\
D.2.5.2 Consistency proofs MUST be verifiable without contacting the log operator beyond retrieving the proof object.

D.2.6 **Checkpoint semantics.**\
D.2.6.1 A checkpoint MUST include at minimum: `log_id`, `tree_size`, `root_hash`, `checkpoint_time`, and a `checkpoint_signature`.\
D.2.6.2 Checkpoints MUST be monotonically increasing in `tree_size`.

D.2.7 **Authorization model (publication vs verification).**\
D.2.7.1 Appends MAY be access-controlled (to prevent spam and abuse).\
D.2.7.2 Verification endpoints (`prove_inclusion`, `prove_consistency`, `get_checkpoint`) SHOULD be publicly accessible for Public/Controlled reliance tiers, subject to rate limits and abuse controls.\
D.2.7.3 Restricted handling MAY require gated verification access; however, it MUST still support portability without revealing sensitive metadata.

D.2.8 **Error semantics.** The API MUST define stable error codes for: invalid digest, unknown checkpoint, inconsistent checkpoint, rate limited, unauthorized append, and service unavailable.

***

#### D.3 Checkpointing and snapshot distribution

D.3.1 **Checkpoint cadence.**\
D.3.1.1 The service MUST publish checkpoints on a defined cadence appropriate to operational use; the cadence MUST be declared as a service parameter.\
D.3.1.2 For higher reliance tiers, maximum checkpoint staleness windows SHOULD be enforced (by profile or deployment policy).

D.3.2 **Snapshot definition.** A snapshot is a verifiable bundle enabling offline verification for a defined window. A snapshot MUST include:\
D.3.2.1 One or more signed checkpoints.\
D.3.2.2 Sufficient auxiliary data (e.g., compacted proof material or a range structure) to support inclusion proof verification for receipts expected to be verified offline within the window.\
D.3.2.3 Snapshot metadata: creation time, coverage period, expiry, update policy.

D.3.3 **Snapshot distribution.**\
D.3.3.1 Snapshots MUST be distributable via offline channels (e.g., removable media, secure transfer) for air-gapped deployments.\
D.3.3.2 Snapshot bundles MUST be signed and integrity-checked.\
D.3.3.3 Snapshot identifiers MUST be stable and resolvable, and MUST support archival verification.

D.3.4 **Snapshot update rules.**\
D.3.4.1 Updates MUST be incremental where possible (delta snapshots) to reduce bandwidth.\
D.3.4.2 Verifiers MUST reject snapshots beyond expiry or outside declared coverage for the target receipt’s publication time.

D.3.5 **Cross-checkpoint proofs.** The service SHOULD support verifiers to validate consistency across snapshot checkpoint sequences (prove\_consistency chain) without online access.

***

#### D.4 Equivocation threat model and posture requirements

D.4.1 **Equivocation definition.** Equivocation is any behavior where different relying parties observe different log histories that cannot be reconciled by consistency proofs, including split-view attacks, delayed inclusion manipulation, or selective withholding of checkpoints.

D.4.2 **Threat posture classes (declarative).** The service MUST declare an equivocation posture class as part of service metadata:\
D.4.2.1 **Posture P1 — Single-operator, monitored:** checkpoints are externally monitored, but no independent witnesses are required.\
D.4.2.2 **Posture P2 — Audited checkpoints:** periodic independent audits verify checkpoint continuity and publication discipline.\
D.4.2.3 **Posture P3 — Witnessed/federated:** checkpoints are co-signed or independently witnessed/recorded to materially reduce split-view feasibility.

D.4.3 **Minimum requirements by reliance tier.**\
D.4.3.1 R1/R2 MAY accept P1 with monitoring.\
D.4.3.2 R3 SHOULD require P2 or stronger.\
D.4.3.3 R4 SHOULD require P3 or equivalent controls, or an explicitly stated risk acceptance policy with compensating controls.

D.4.4 **Delayed inclusion constraints.**\
D.4.4.1 The maximum delay between PR issuance (`issued_at`) and log integration (`integrated_time`) MUST be bounded by policy and declared as a parameter.\
D.4.4.2 Exceeding delay bounds MUST be detectable and MUST downgrade permitted reliance.

D.4.5 **Split-view detection hooks.** The service SHOULD provide:\
D.4.5.1 Public checkpoint feed(s) suitable for independent monitors.\
D.4.5.2 Monitor APIs or export formats enabling third parties to detect inconsistent checkpoints.

D.4.6 **Equivocation response.** The system MUST define response behaviors when equivocation is detected or suspected, including: receipt reliance downgrade, emergency freeze hooks, and incident disclosure clocks (linked to Part 9 controls).

***

#### D.5 Availability SLOs, monitoring, and incident response

D.5.1 **SLO declaration.** The service MUST declare SLOs for:\
D.5.1.1 `get_checkpoint` availability and latency.\
D.5.1.2 inclusion/consistency proof endpoint availability and latency.\
D.5.1.3 checkpoint cadence and maximum staleness.\
D.5.1.4 append acceptance throughput (where append is offered).

D.5.2 **Operational resilience.**\
D.5.2.1 The service SHOULD be highly available, with redundancy and disaster recovery appropriate to its reliance tier usage.\
D.5.2.2 The service MUST support degraded operation, including serving last-known checkpoints and snapshots even when append is impaired.

D.5.3 **Monitoring requirements.**\
D.5.3.1 The service MUST emit monitoring signals for: checkpoint progression, proof endpoint errors, consistency failures, and abnormal integration delays.\
D.5.3.2 Monitors SHOULD be able to detect: stalled log growth, inconsistent checkpoints, or missing scheduled checkpoint publications.

D.5.4 **Incident response.**\
D.5.4.1 The service MUST maintain incident playbooks aligned with the wider NXOSI incident clocks (Part 9).\
D.5.4.2 Incident classes MUST include: integrity incident (suspected equivocation), availability incident, privacy/metadata leak incident, key compromise incident.\
D.5.4.3 The service MUST support emergency measures, including: freeze of new appends, accelerated checkpoint publication, key rotation, and publication of corrective checkpoint statements.

D.5.5 **Client fallback behavior.** Verifier behavior under service outage MUST be defined by reliance tier; for higher tiers, absence of fresh checkpoints MUST block or downgrade reliance.

***

#### D.6 Privacy and metadata minimization in logs

D.6.1 **Principle.** The transparency log MUST be safe to publish without becoming a surveillance dataset.

D.6.2 **Minimum log entry content.**\
D.6.2.1 Log entries MUST contain only digests and minimized metadata needed for verification and operational monitoring.\
D.6.2.2 The log MUST NOT contain PII.\
D.6.2.3 The log MUST NOT reveal sensitive operational topology (asset inventories, internal identifiers) through entry fields or predictable encoding.

D.6.3 **Handling-class enforcement.**\
D.6.3.1 Public/Controlled entries MAY be publicly verifiable.\
D.6.3.2 Restricted entries MUST be logged using privacy-preserving representations (hashes and opaque pointers), and verification access MAY be gated, but MUST remain portable.

D.6.4 **Correlation resistance.** The service SHOULD mitigate correlation risks by avoiding stable, linkable metadata across entries that can reveal patterns about an operator unless explicitly permitted.

D.6.5 **Redaction and correction policy.** The log itself is append-only; privacy corrections MUST be handled via additional append-only corrective statements and status semantics, not deletion.

***

#### D.7 Offline verification snapshot formats and update rules

D.7.1 **Snapshot format requirements.**\
D.7.1.1 Snapshots MUST be self-describing: include `log_id`, coverage window, root hash, and signature.\
D.7.1.2 Snapshots MUST support verification of receipts whose inclusion proofs reference checkpoints within the snapshot coverage.

D.7.2 **Update distribution.**\
D.7.2.1 Snapshot updates MUST support delta distribution and MUST include consistency proofs from prior snapshots where feasible.\
D.7.2.2 Snapshots MUST declare expiry; verifiers MUST enforce expiry for higher reliance tiers.

D.7.3 **Air-gapped operations.**\
D.7.3.1 Snapshot import/export processes MUST be auditable (Control Plane action records MAY be required).\
D.7.3.2 The system MUST define how long an air-gapped environment may operate with stale snapshots for each reliance tier before reliance is downgraded or blocked.

D.7.4 **Archival snapshots.** The service SHOULD support archival snapshot bundles suitable for long-lived verification, including crypto suite identifiers and verification instructions.

***

#### D.8 Interoperability profile for transparency services (required vs optional features)

D.8.1 **Objective.** Establish a minimum interoperability profile such that a PR issued in one NXOSI deployment can be verified in another without bespoke integration.

D.8.2 **Required features (normative).**\
D.8.2.1 Append-only log with signed checkpoints.\
D.8.2.2 Inclusion proof generation and verification.\
D.8.2.3 Consistency proof generation and verification between checkpoints.\
D.8.2.4 A stable `get_checkpoint` endpoint.\
D.8.2.5 A stable `prove_inclusion` endpoint.\
D.8.2.6 A stable `prove_consistency` endpoint.\
D.8.2.7 Declared checkpoint cadence and integration delay bounds.\
D.8.2.8 Handling-class aware entry processing and metadata minimization constraints.\
D.8.2.9 Snapshot export format sufficient for offline verification under defined tiers.

D.8.3 **Optional features (recommended where feasible).**\
D.8.3.1 Witnessing/federation mechanisms to strengthen equivocation posture.\
D.8.3.2 Public monitor feed(s) and monitor-friendly export formats.\
D.8.3.3 Rate-limit and abuse control signals exposed to relying parties.\
D.8.3.4 Multi-log support (e.g., separate logs per handling class or sector) with defined cross-log referencing rules.

D.8.4 **Conformance surfaces.** A transparency service claiming NXOSI interoperability MUST pass the conformance suite covering: inclusion proofs, consistency proofs, checkpoint progression, integration delay bounds, privacy/metadata minimization, outage fallback behavior, and snapshot verification workflows.

D.8.5 **Compatibility promise.** Implementations MAY differ internally (storage engines, witness architecture, scaling approach), but MUST preserve the observable semantics and proof verifiability required by this annex.


---

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