# Annex F

#### F.1 Handling class definitions (Public/Controlled/Restricted) and behavioral rules

F.1.1 **Purpose.** Handling Classes define the minimum disclosure posture and behavioral controls for NXOSI artefacts, telemetry pointers, evidence pack indices, and any derived summaries. Handling Classes are enforced end-to-end across authoring, execution, proof issuance, routing, storage, verification, dispute, and publication.

F.1.2 **Handling Classes.** NXOSI defines three baseline handling classes:

F.1.2.1 **Public (H1).** Content may be distributed publicly without prior approval, provided it does not contain prohibited metadata (F.1.6). Public does not mean “risk-free”; it means permitted for broad distribution under defined minimization rules.

F.1.2.2 **Controlled (H2).** Content is restricted to authorized recipients under purpose limitation, access logging, and forwarding/derivation constraints. Controlled artefacts are designed for operational, audit, and supervisory use without general publication.

F.1.2.3 **Restricted (H3).** Content is highly sensitive and may only be accessed within defined sovereign/organizational boundaries and under explicit approvals, two-person controls for defined actions, and strict do-no-harm constraints. Restricted content is never made broadly available and is not used as a default input to external systems.

F.1.3 **Default classification rules.**\
F.1.3.1 All artefacts MUST carry a handling marker.\
F.1.3.2 In the absence of an explicit classification, implementations MUST default to Controlled (H2).\
F.1.3.3 Evidence Pack contents are always sovereignly retained; only indices and selective summaries may be Portable (see F.2) and only under explicit handling rules.

F.1.4 **Behavioral rules by class (minimum).**\
F.1.4.1 **Public (H1)**: may be forwarded; may be stored in public repositories; may be quoted. Automated processing is permitted. Derivatives MUST remain compliant with metadata minimization and must not re-identify Controlled/Restricted sources.\
F.1.4.2 **Controlled (H2)**: no unrestricted forwarding; recipients MUST be authorized; distribution MUST be logged; derivatives MUST be labeled; automated processing MUST be constrained (purpose-limited, access-controlled, no uncontrolled external paste/export).\
F.1.4.3 **Restricted (H3)**: access only in designated environments (sovereign zones, controlled rooms, or equivalent); mandatory access logging; two-person rule for defined actions (export, disclosure, declassification, dispute release); no external sharing; no uncontrolled copying/printing; no use in general-purpose AI tools unless explicitly authorized by the handling policy and lawful basis.

F.1.5 **Classification authority and change control.**\
F.1.5.1 Each deployment MUST define a Handling Authority (role) empowered to classify, approve exceptions, and authorize declassification or reclassification.\
F.1.5.2 Reclassification MUST be recorded as a governed action (CPAR) and MUST preserve prior classifications in the audit trail.\
F.1.5.3 “Downgrading” (e.g., H3→H2 or H2→H1) MUST require explicit justification, recipient and purpose declaration, and time bounds.

F.1.6 **Prohibited metadata for Public artefacts.** Public artefacts MUST NOT include: direct personal identifiers; protected participant identity; sensitive asset inventories; detailed vulnerability data; law-enforcement-sensitive details; or any data that can reasonably enable targeted harm, coercion, retaliation, or sabotage. If such fields are required for verification, they MUST remain in Controlled/Restricted evidence and be referenced by pointers under sovereignty rules.

F.1.7 **Handling propagation rules.**\
F.1.7.1 Handling markers MUST propagate transitively: if an artefact depends on Restricted evidence for a claim, any derived explanation that reveals Restricted attributes MUST remain Restricted.\
F.1.7.2 Derivative artefacts MUST include a `derived_from` linkage plus a handling derivation statement describing what was removed/aggregated.

***

#### F.2 Disclosure tiers and minimum/maximum disclosure per reliance tier

F.2.1 **Purpose.** Disclosure Tiers define what information is sufficient for reliance, and what is prohibited, given (i) the reliance tier, (ii) handling class, and (iii) lawful basis. Disclosure Tier selection is part of obligation attachment (OAR) and proof issuance (PR).

F.2.2 **Reliance tiers (R0–R4).**\
F.2.2.1 **R0 Informational** (awareness; no operational reliance).\
F.2.2.2 **R1 Operational** (routine operational decisions; bounded risk).\
F.2.2.3 **R2 Audit** (audit reliance; reproducibility expected).\
F.2.2.4 **R3 Supervisory** (examiner-operable reliance under regulated oversight; strict constraints).\
F.2.2.5 **R4 High-Consequence** (sovereign/critical systems; attestation-first mandatory; strongest disclosure controls).

F.2.3 **Disclosure tiers (D1–D4).**\
F.2.3.1 **D1 Receipt-Only**: PR + status + inclusion proof; no evidence pack access; minimal scope fields only.\
F.2.3.2 **D2 Receipt + Structured Summary**: PR plus a bounded, schema-defined summary of checks and outcomes, without raw logs or sensitive configuration.\
F.2.3.3 **D3 Controlled Evidence Access**: PR plus time-bound access to selected parts of an Evidence Pack under approvals, logging, and redaction.\
F.2.3.4 **D4 Full Replay / Reproduction Access**: PR plus sufficient evidence to replay or reproduce checks (where applicable), within sovereign/controlled environments.

F.2.4 **Minimum disclosure by reliance tier (baseline).**\
F.2.4.1 R0: D1 permitted; D2 optional.\
F.2.4.2 R1: D1 minimum; D2 recommended for auditability of operations; D3 only if needed for dispute.\
F.2.4.3 R2: D2 minimum; D3 typically required for selected controls; D4 only for defined classes (e.g., forensic replay).\
F.2.4.4 R3: D2 minimum plus controlled D3 workflows; D4 permitted only under explicit supervisory lawful basis and strict handling.\
F.2.4.5 R4: D2 minimum plus mandatory D3 for defined evidence sets; D4 only under sovereign authority and do-no-harm safeguards.

F.2.5 **Maximum disclosure constraints.**\
F.2.5.1 Public artefacts MUST NOT exceed D2 and MUST remain free of prohibited metadata (F.1.6).\
F.2.5.2 Controlled disclosure MUST be purpose-limited and time-bound; “open-ended evidence access” is prohibited for R3/R4 without renewal and re-approval.\
F.2.5.3 Restricted disclosure MUST be strictly minimized to the smallest evidence subset required to satisfy the verification purpose.

F.2.6 **Selective disclosure support.** Implementations SHOULD support selective disclosure mechanisms so that verifiers can validate required claims without extracting raw sensitive data (e.g., redacted extracts, cryptographic commitments to evidence, structured summaries with integrity binding).

***

#### F.3 Redaction and safe summarization patterns

F.3.1 **Purpose.** Redaction and summarization convert sovereign evidence into portable verification artefacts while preventing harm, leakage, re-identification, and operational exploitation.

F.3.2 **Redaction principles.**\
F.3.2.1 Redactions MUST preserve verification-critical semantics (e.g., pass/fail, control IDs, time binding, issuer authorization, scope).\
F.3.2.2 Redactions MUST remove exploit-enabling detail (e.g., exact vulnerable versions, unpatched endpoints, network diagrams) unless explicitly authorized for a narrow audience and purpose.\
F.3.2.3 Redactions MUST be recorded: each redacted artifact MUST include `redaction_manifest` summarizing removed classes of information and the basis for removal.

F.3.3 **Safe summarization patterns (normative templates).**\
F.3.3.1 **Outcome-only control summaries**: Control ID, result, time, enforcement point, attestation tier used, and status pointers—without operational detail.\
F.3.3.2 **Parameterized threshold summaries**: Show ranges or bounded assertions rather than exact values when exact values could reveal vulnerabilities or sensitive infrastructure capacity.\
F.3.3.3 **Dependency hashing**: Replace detailed component lists with hashed references and SBOM pointers under controlled access.\
F.3.3.4 **Role-marker abstraction**: Use role markers instead of personal identity; identity mapping is restricted.\
F.3.3.5 **Geo fuzzing for sensitive sites**: Use jurisdictional region rather than exact coordinates for Restricted-class entities unless lawful basis explicitly permits.

F.3.4 **Summarization controls.**\
F.3.4.1 Summaries MUST be reproducible from underlying evidence (at least within the zone) and MUST include integrity bindings (hashes/commitments).\
F.3.4.2 Summaries MUST include uncertainty/confidence indicators when derived from probabilistic sources or participatory inputs.\
F.3.4.3 Summaries MUST not introduce new claims not supported by the underlying evidence pack.

F.3.5 **Re-identification and correlation resistance.**\
F.3.5.1 Public and Controlled summaries MUST be assessed for correlation risk (combining multiple “safe” fields into a sensitive inference).\
F.3.5.2 Implementations MUST provide mitigation controls: field suppression, aggregation, time bucketing, and audience scoping.

***

#### F.4 Lawful basis matrices (purpose limitation, time bounds, authorized recipients)

F.4.1 **Purpose.** Lawful Basis Matrices define who may receive what information, for which purpose, under which legal basis, for how long, and with what constraints. They are mandatory for Controlled and Restricted classes and recommended for Public disclosures.

F.4.2 **Matrix structure (minimum).** A Lawful Basis Matrix MUST specify:\
F.4.2.1 **Purpose** (e.g., operational remediation, audit, supervisory review, dispute resolution, research).\
F.4.2.2 **Legal basis** (deployment-defined categories consistent with local law; e.g., legal obligation, vital interest, public task, contractual necessity, consent where applicable).\
F.4.2.3 **Recipient classes** (operator team, auditor, supervisor, critical counterparty, public).\
F.4.2.4 **Permitted artefacts** (PR only; PR+summary; evidence subset; full replay).\
F.4.2.5 **Handling class ceiling** (maximum handling class permissible under that purpose/basis).\
F.4.2.6 **Time bounds** (access expiry; retention windows; re-approval cadence).\
F.4.2.7 **Cross-border constraints** (evidence stays; receipt travels; escrow conditions).\
F.4.2.8 **Approval requirements** (single approver vs two-person rule; supervisory warrant/mandate conditions).\
F.4.2.9 **Audit requirements** (logging fields; periodic review; breach escalation).

F.4.3 **Purpose limitation enforcement.**\
F.4.3.1 Access decisions MUST be enforced by policy gates (not only by procedure).\
F.4.3.2 Evidence access MUST be revocable and time-bound; access tokens MUST be short-lived and logged.\
F.4.3.3 Reuse of evidence for a new purpose MUST require a new matrix entry or explicit re-authorization.

F.4.4 **Jurisdiction overlays.** National and regional overlays MUST be able to override or further restrict lawful basis matrix entries without forking core artefacts. Overlay changes MUST be recorded with status objects and supersession discipline.

***

#### F.5 Access logging and audit trail requirements

F.5.1 **Scope.** Access logging applies to: evidence stores, evidence pack indices, disclosure workflows, status queries (for higher tiers), and any export or declassification actions.

F.5.2 **Minimum access log fields.** Every Controlled/Restricted access event MUST record:\
F.5.2.1 `event_id`, `timestamp`, `actor_role`, `actor_auth_context`.\
F.5.2.2 `resource_id` (artefact/evidence subset identifier), `handling_class`.\
F.5.2.3 `purpose_code` and lawful basis reference (matrix row ID).\
F.5.2.4 `action` (view, export, transform, disclose, redact, delete).\
F.5.2.5 `approval_chain` (approver role markers, two-person rule evidence if required).\
F.5.2.6 `session_context` (zone, device/service identity, network boundary).\
F.5.2.7 `result` (granted/denied) and any denial reason.

F.5.3 **Tamper resistance.**\
F.5.3.1 Access logs MUST be integrity-protected (append-only or equivalently tamper-evident).\
F.5.3.2 Access logs MUST be linkable to the associated docket (DKT) and disclosure request records.\
F.5.3.3 Access logs MUST support audit replay for defined periods (retention defined in F.7).

F.5.4 **Audit exports.**\
F.5.4.1 The system MUST support generating handling-aware audit exports that include access logs, approval trails, and disclosure deltas without exposing Restricted content unnecessarily.\
F.5.4.2 Exports MUST be signed and versioned, and MUST include the applicable lawful basis matrix references.

***

#### F.6 Protected participation and do-no-harm safeguards

F.6.1 **Purpose.** Protected participation enables public and community inputs to improve ground truth while preventing harm, retaliation, coercion, doxxing, and capture.

F.6.2 **Core safeguards (minimum).**\
F.6.2.1 **Protected identity**: reporter identity MUST be protected by default; identity exposure requires explicit lawful basis and high-threshold approvals.\
F.6.2.2 **Anti-coercion**: processes MUST avoid creating incentives or mechanisms that allow coercive actors to compel disclosure of reporters or sensitive evidence.\
F.6.2.3 **Anti-sybil and bounded influence**: participatory inputs MUST be trust-weighted and bounded so no single actor or coordinated cluster can dominate.\
F.6.2.4 **Triangulation**: participatory reports MUST be treated as evidence candidates, not truth, until corroborated and adjudicated.\
F.6.2.5 **Do-no-harm handling**: sensitive reports MUST be Restricted by default, with careful summarization for any external use.

F.6.3 **Escalation pathways.**\
F.6.3.1 Submissions MUST have a safe escalation path to expert adjudication with clear clocks.\
F.6.3.2 Where community harms are alleged, the system MUST support protected grievance and remedy workflows without exposing participants.

F.6.4 **Disclosure constraints for participatory data.**\
F.6.4.1 Public outputs derived from participatory sources MUST not be re-identifiable.\
F.6.4.2 Controlled disclosures MUST be purpose-limited and logged, and MUST include safeguards against retaliation.

***

#### F.7 Retention and destruction policy templates

F.7.1 **Purpose.** Retention and destruction rules ensure auditability and long-lived verification without creating indefinite risk through unnecessary storage of sensitive evidence.

F.7.2 **Retention policy structure (template fields).** A retention policy SHOULD specify:\
F.7.2.1 Artefact type (PR, STO, OAR, XPL, CRR, AEP contents, access logs, conformance reports).\
F.7.2.2 Handling class (H1/H2/H3).\
F.7.2.3 Minimum retention (for verification, audit replay, dispute windows).\
F.7.2.4 Maximum retention (privacy, security, lawful basis time limits).\
F.7.2.5 Destruction method (secure delete, cryptographic erasure, archive vaulting).\
F.7.2.6 Legal hold exceptions (litigation, regulatory inquiry, dispute hold).\
F.7.2.7 Sovereign zone constraints (where data may reside; compute-to-data requirements).\
F.7.2.8 Review cadence (periodic review and re-authorization for continued retention).

F.7.3 **Baseline retention guidance (normative posture).**\
F.7.3.1 PR/STO MUST be retained long enough to support declared reliance tiers and archival verification requirements; these are generally long-lived and should be integrity-protected.\
F.7.3.2 AEP contents SHOULD be retained minimally consistent with lawful basis and dispute/audit requirements; Restricted evidence should not be retained indefinitely without explicit renewal.\
F.7.3.3 Access logs MUST be retained at least as long as the evidence they govern and long enough to support audit replay and breach investigations.

F.7.4 **Destruction controls.**\
F.7.4.1 Destruction actions MUST be logged and authorized according to handling class (two-person rule recommended for Restricted).\
F.7.4.2 Where destruction could affect reliance, the system MUST ensure that verification can still proceed via retained receipts, status objects, and lawful summarizations.\
F.7.4.3 Destruction MUST not break the “no silent change” invariant; if destruction changes what can be re-verified, that limitation MUST be expressible as an artefact/status constraint under the deployment’s policy.

F.7.5 **Archival verification bundles.** For long-lived proofs, the deployment SHOULD maintain archival bundles (receipts, status checkpoints, transparency checkpoints, verifier versions) sufficient to validate claims years later without retrieving Restricted evidence.


---

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