# XIII. Testable Minima #### 13.1 Purpose and Scope 13.1.1 **Purpose.** This Part defines the non-negotiable, testable baseline required to claim “NXOSI-compliant.” It establishes the minimum artefacts, semantics, interfaces, verification procedures, handling discipline, and operational behaviors that must hold across vendors, sovereign deployments, and mixed-connectivity environments. 13.1.2 **Scope.** The baseline covers: (a) mandatory artefact set and linkage rules; (b) receipt, transparency, and status semantics; (c) profile packaging, overlay composition, and trigger/obligation attachment; (d) standards-as-code runtime determinism and safe change; (e) check runtime enforcement-point coverage and evidence outputs; (f) ontology fabric semantics and governance; (g) control plane auditability and separation-of-duties; (h) sovereign zone handling rules; (i) observability linkage minima; (j) AI/agentic minimum controls; (k) crypto agility and long-lived verification; and (l) minimum conformance harness requirements and reporting. 13.1.3 **Audience.** This Part is written for: implementers building conformant components; operators deploying NXOSI in production; auditors and independent assessors verifying artefacts and procedures; supervisors/examiners relying on receipt-only and controlled-disclosure workflows; and procuring entities requiring objective, enforceable requirements in contracts. 13.1.4 **Non-execution boundary.** NXOSI compliance concerns assurance and operability—proof production, verification, correctionability, and governed routing. It does not include regulated financial execution, custody, underwriting, market operation, settlement, claims execution, or the assumption of supervisory authority. Compliance claims must not imply that NXOSI performs or replaces regulated activities or legal determinations. 13.1.5 **Normative precedence.** This Part defines the baseline normative requirements. The annex set provides: schemas, canonical field definitions, conformance tests, gold vectors, negative/adversarial suites, reference verification procedures, and machine-readable reporting formats. Where an annex conflicts with this Part, this Part prevails. *** #### 13.2 Compliance Claims and Conformance Assertions 13.2.1 **Permitted compliance statements.** Compliance claims MUST be precise and scoped to the object of conformance: * **Implementation conformance** (a software component or library passes the conformance suite for defined interfaces and artefacts). * **Deployment conformance** (a specific deployed environment enforces handling, sovereign zone constraints, logging, and degraded-mode behaviors). * **Profile conformance** (a specific profile package, overlay set, and version passes composition and verification tests).\ Claims MUST include version identifiers, conformance level (if used), and the specific test suites executed. 13.2.2 **Prohibited claims.** The following claims are prohibited: “certified secure,” “regulator approved,” “supervisory compliant,” “guaranteed safe,” “endorsed,” or any statement implying legal approval or substitution for statutory duties. Claims MUST NOT imply that NXOSI is a regulator, court, accreditor, or supervisory authority, nor that NXOSI compliance ensures risk absence. 13.2.3 **Evidence required to substantiate a claim.** Any compliance claim MUST be supported by: (a) a signed conformance report, (b) test outputs or test receipts for the suites invoked, (c) a manifest listing artefact versions and dependency hashes, and (d) status pointers for the reported artefacts (to enable later revocation or supersession). Evidence MUST be verifiable by an independent relying party using published verification procedures. 13.2.4 **Badge usage rules and misuse sanctions.** Badges (if used) are permitted only when backed by signed conformance reports and status semantics. Misuse controls MUST include: takedown requests, badge revocation, registry updates, access suspension for repeated abuse, and public correction notices where misrepresentation created reliance risk. Badge semantics MUST state explicitly what is covered and what is excluded. 13.2.5 **Reliance tiers mapping.** Each compliance claim MUST declare the permitted reliance tier(s) it supports (informational, operational, audit, supervisory) and MUST enforce permitted inference limits in verification tooling. Higher reliance tiers require stronger evidence quality and stronger operational controls, including controlled disclosure workflows and auditable access logging. *** #### 13.3 NXOSI-Compliant Core Artefacts (Mandatory Set) 13.3.1 **Mandatory artefacts and minimum fields.** NXOSI-compliant implementations and deployments MUST support the following artefacts with minimum required fields, signatures, identifiers, handling markers, and status linkage: 13.3.1.1 **PSA — Policy/Standard Artefact.** MUST be signed, versioned, and immutable once published; MUST declare normative requirements, scope, testability declarations, trigger bindings, control mappings, and supersession pointers; MUST prohibit silent edits via explicit status actions. 13.3.1.2 **SPP — Signed Profile Package.** MUST include profile ID, version, dependencies, overlays, parameters, composition rules, required tests, enforcement points, event/message declarations, compatibility notes, and deprecation metadata; MUST be signed and distributable as a standalone bundle. 13.3.1.3 **TRG — Trigger Definitions.** MUST include trigger ID, predicate logic bound to ontology events, uncertainty handling rules, scope bindings, clocks, reliance tier defaults, handling defaults, and dispute/challenge window references where relevant. 13.3.1.4 **OAR — Obligation Attachment Records.** MUST include OAR ID, profile binding, entity scope set, geography/jurisdiction, time window, hazard/risk class, clock bindings, emergency mode eligibility and constraints, reliance tier declaration, handling defaults, evidence access policy pointers, and status pointers. 13.3.1.5 **XPL — Execution Plans.** MUST include deterministic plan graph, selected profiles/overlays, parameter bindings, enforcement point mapping, dependency set, data/attestation requirements, failure handling and degraded-mode rules, and determinism/equivalence declarations. 13.3.1.6 **CRR — Check Run Records.** MUST include control ID, check ID, input set identifiers, output set identifiers, pass/fail semantics, attestation binding (where required), telemetry pointers with trace context, waiver/exception objects (if any), replay/misuse protections, and linkage to the OAR/XPL. 13.3.1.7 **PR — Proof Receipts.** MUST include issuer identity and authorization reference, subject and scope binding, profile hash binding, time binding and freshness fields, inclusion proof pointer, status pointer, reliance tier declaration, permitted inference limits, and selective disclosure/minimization fields. 13.3.1.8 **AEP — Evidence Pack Index + retention declaration.** MUST include evidence pack identifier, sovereign zone location pointer, handling class, access policy pointer, retention/destruction declaration, provenance chain pointers, and a statement of portability rules (“receipt travels, evidence stays”). 13.3.1.9 **DKT — Docket Object.** MUST include docket ID, case lifecycle state, linkage to OAR/XPL/CRR/PR/AEP, remediation and retest tasks with clocks, dispute holds, closure conditions, and retention/summary outputs by handling class. 13.3.1.10 **STO — Status Objects.** MUST support revocation, supersession, scope narrowing, validity windows, migration notes, and resolution rules for relying parties; MUST be queryable online and satisfiable offline where required by reliance tier. 13.3.1.11 **CPAR — Control-Plane Action Records.** MUST capture approvals, deployments, overrides, waivers, freezes, rollbacks, and closures; MUST include authority proofs, separation-of-duties markers, timestamps, affected artefacts, linkage to dockets/receipts/status objects, and post-incident review references for break-glass actions. 13.3.2 **Artefact linkage minima.** Artefacts MUST be end-to-end linkable through immutable identifiers. At minimum: TRG→OAR, OAR→XPL, XPL→CRR, CRR→PR, PR→STO, PR→AEP index pointer, all objects→DKT where a case is opened, and all significant changes→STO/COR objects. Linkage MUST support independent reconstruction of the obligation→check→proof→case→correction chain without privileged internal context. 13.3.3 **Handling class markers.** All artefacts MUST carry a handling class marker (Public/Controlled/Restricted) and MUST enforce handling behaviors in storage, transport, display, logging, and export. Handling class MUST be part of conformance testing, including “no leakage through metadata” expectations. *** #### 13.4 Mandatory Verification Procedures (Relying Party Testability) 13.4.1 **Offline verification.** Offline verification MUST be possible for defined reliance tiers, at minimum for informational and operational reliance, and SHOULD be possible for audit reliance where lawful basis permits. Offline verification MUST include receipt signature validation, profile hash validation, inclusion proof verification against a cached transparency snapshot, and bounded status resolution based on cached status snapshots and declared freshness windows. 13.4.2 **Online verification.** Online verification MUST be possible for status and supersession resolution. Implementations MUST provide stable endpoints for: status queries, supersession chains, scope narrowing, and validity windows. Relying parties MUST be able to determine whether a receipt remains valid, and if not, the precise reason and scope of invalidation. 13.4.3 **Minimum receipt verification steps.** A verifier MUST, at minimum:\ 13.4.3.1 Verify signature and issuer authorization (including that the issuer is permitted to issue the receipt class).\ 13.4.3.2 Verify scope binding (subject identity, jurisdiction/overlay context, time window, and hazard/risk class where declared).\ 13.4.3.3 Verify inclusion proof and transparency publication pointer against a valid snapshot or live log.\ 13.4.3.4 Verify status (not revoked; supersession handled per rules; scope narrowing applied).\ 13.4.3.5 Verify profile hash and version compatibility (including overlay compatibility rules).\ 13.4.3.6 Enforce permitted inference limits for the declared reliance tier (verification tooling MUST prevent over-interpretation). 13.4.4 **Verification under degraded conditions.** When transparency services are unavailable or caches are stale, verification MUST: (a) declare constrained reliance; (b) apply conservative status assumptions as defined by policy; and (c) produce a verifiable “degraded verification record” that can be re-evaluated later. Degraded verification MUST NOT silently pass as full verification. 13.4.5 **Controlled evidence access workflow.** Where a relying party requests controlled evidence, the workflow MUST include: lawful basis validation, handling clearance, approval logging, redaction/selection rules, access audit trails, expiry of access grants, and a record of what was disclosed. Controlled evidence access MUST be linkable back to the receipt and docket, and MUST generate CPAR entries. *** #### 13.5 Proof Receipt Minimum Requirements (PR Baseline) 13.5.1 **Required fields.** Receipts MUST include issuer, subject, scope, profile hash, relevant overlay identifiers, time binding, reliance tier, permitted inference limits, inclusion proof pointer, and status pointer. Missing required fields MUST fail conformance. 13.5.2 **Required cryptographic properties.** Receipts MUST be signed using approved suites; MUST include freshness/anti-replay semantics; MUST include identifiers preventing out-of-context reuse; and MUST support key rotation and revocation via status resolution rules. 13.5.3 **Required transparency properties.** Receipts MUST reference inclusion proof material or a verifiable pointer to it. Publication MUST be time-bounded according to reliance tier; verification tooling MUST detect delayed inclusion beyond permitted thresholds. 13.5.4 **Required status properties.** Every receipt MUST be resolvable to a status object that can revoke, supersede, or narrow scope. Status chains MUST be verifiable and MUST not require privileged internal access. 13.5.5 **Selective disclosure and metadata minimization.** Receipts MUST minimize identity/metadata disclosure and MUST support selective disclosure where required. Public receipts MUST NOT leak restricted information through identifiers, timing, or correlatable metadata beyond what is necessary for verification. 13.5.6 **Offline verification bundles.** Where offline verification is required, receipts MUST be verifiable with defined snapshot bundles and MUST declare freshness windows and staleness handling rules. 13.5.7 **Negative requirements.** Receipts MUST NOT include PII unless strictly required by the reliance tier and lawful basis; MUST NOT imply endorsement; MUST NOT overclaim beyond the tested control scope; MUST NOT be usable as a substitute for regulated approvals. *** #### 13.6 Signed Profile Package Minimum Requirements (SPP Baseline) 13.6.1 **Required fields.** SPPs MUST declare dependencies, overlays, parameters, required tests, enforcement points, event/message contracts, reliance tier defaults, handling defaults, and compatibility/deprecation metadata. 13.6.2 **Composition declarations.** SPPs MUST declare stacking order, precedence, conflict resolution policy, and overlay algebra outcomes. Composition MUST be deterministic, and the compiler MUST emit a conflict report when compositions cannot be safely resolved. 13.6.3 **Inter-profile communication declarations.** SPPs MUST declare produced/consumed events/messages, topic governance requirements, ordering/idempotency expectations, replay handling, and handling-aware message constraints. 13.6.4 **Compatibility and deprecation rules.** SPPs MUST follow semantic versioning; MUST include migration notes for breaking changes; MUST include deprecation and end-of-support fields to preserve reliance stability. 13.6.5 **Secure distribution.** SPPs MUST be signed; distribution channels MUST preserve integrity; profile tooling SHOULD ship with SBOM/provenance to the extent it can affect obligations and verification outcomes. *** #### 13.7 Trigger and Obligation Attachment Minimum Requirements (TRG/OAR Baseline) 13.7.1 **Trigger predicate requirements.** Triggers MUST be bound to ontology events; MUST declare uncertainty handling; MUST define the minimum evidence candidate set required to fire; and MUST specify failure behavior when data is missing or ambiguous. 13.7.2 **OAR scope binding requirements.** OARs MUST bind obligations to a defined entity set, geography, jurisdiction, time window, and hazard/risk class. Scope MUST be machine-interpretable and verifiable by independent parties at the permitted reliance tier. 13.7.3 **Clock binding requirements.** OARs MUST include:\ 13.7.3.1 **Verification clock** (deadline to verify and issue receipts).\ 13.7.3.2 **Remediation clock** (deadline to remediate or declare compensating controls).\ 13.7.3.3 **Retest clock** (deadline or cadence for re-verification).\ 13.7.3.4 **Dispute window** (challenge rights and hold behavior).\ 13.7.3.5 **Emergency mode duration** (maximum break-glass duration and required review). 13.7.4 **Emergency mode governance.** Emergency mode MUST require explicit approval rules, mandatory CPAR generation, constrained privileges, time limits, and mandatory post-incident review that results in either restoration to normal posture or published correction objects. 13.7.5 **Invalidation and supersession.** OARs MUST be invalidatable via status objects and MUST support supersession when scope changes, evidence changes, or policy changes occur. Supersession MUST preserve an audit trail and reliance semantics. *** #### 13.8 Standards-as-Code Runtime Minimum Requirements (SACR Baseline) 13.8.1 **Determinism.** For deterministic inputs, SACR MUST produce deterministic outputs under declared semantics. Where probabilistic allowances exist, the runtime MUST explicitly declare the uncertainty model and MUST not mask probabilistic behavior as deterministic compliance. 13.8.2 **Equivalence and regression.** SACR MUST support equivalence testing and regression suites that prove semantic stability. Changes MUST produce explicit status objects and compatibility notes. 13.8.3 **Safe rollout lifecycle.** SACR MUST support staged rollout, canary, rollback, freeze controls, and emergency shutdown controls. Each stage transition MUST generate CPAR evidence. 13.8.4 **Inter-profile communication.** Runtime messaging MUST enforce ordering/idempotency/replay protection policies and MUST be handling-aware. Cross-zone leakage MUST be prevented by design and tested. 13.8.5 **Constrained authoring.** Authoring MUST be governed through linting, guardrails, sandboxing, and approval workflows. Unsafe constructs MUST be rejected or quarantined before deployment. 13.8.6 **No silent edits.** Every deployed change MUST produce a status object and an auditable CPAR trail, with scope, reason, and reliance implications. *** #### 13.9 Check Runtime Minimum Requirements (CRR Baseline) 13.9.1 **Minimum enforcement-point coverage.** Baseline compliance MUST cover at minimum: (a) one build or supply-chain gate, (b) one deploy-time or runtime policy gate, and (c) one incident/retest gate tied to clocks. Sector profiles MAY require additional enforcement points for higher reliance tiers. 13.9.2 **CRR content requirements.** CRRs MUST include control ID, inputs/outputs, pass/fail, telemetry pointers, trace context, and linkage to OAR/XPL. Missing linkage MUST fail conformance. 13.9.3 **Attestation binding by risk class.** Where attestation is required by profile or reliance tier, CRRs MUST include attestation context and appraisal outcomes. Attestation absence MUST be explicitly declared and MUST constrain reliance. 13.9.4 **Waiver/exception objects.** Exceptions MUST be first-class objects with authority, justification, compensating controls, expiry, and linkage to dockets and retest clocks. Exceptions MUST NOT be “notes in a ticket.” 13.9.5 **Drift detection signals.** Baseline compliance MUST emit a minimum drift signal set sufficient to attach obligations and trigger retests (configuration drift, dependency drift, control bypass indicators). Sector overlays MAY expand the required signal set. *** #### 13.10 Ontology Fabric Minimum Requirements (NOF Baseline) 13.10.1 **Mandatory schema components.** NOF MUST implement the baseline entity/relation/event model required to scope obligations, bind triggers, and produce audit-grade provenance. The model MUST include identifiers usable across organizations without requiring central identity. 13.10.2 **Identity resolution.** NOF MUST support canonical IDs, aliasing rules, collision handling, and deterministic resolution outcomes. Identity resolution changes MUST be governed and correctionable. 13.10.3 **Provenance and uncertainty.** Every assertion MUST carry provenance and uncertainty fields, including source class, transformation manifests for derived data, and signatures where applicable. Missing provenance MUST constrain reliance. 13.10.4 **Trust scoring.** Trust scoring MUST bound the influence of any source class, include poisoning resistance measures, and provide quarantine paths for anomalous assertions. Trust scoring MUST be auditable and testable. 13.10.5 **Semantic versioning and change control.** NOF MUST enforce semantic versioning, supersession, and semantic regression tests. Silent meaning changes are prohibited and must be detected through conformance tests. 13.10.6 **Graph-to-controls mapping.** The mapping from events to triggers and from entity scope to OARs MUST be deterministic, auditable, and reproducible for defined contexts. *** #### 13.11 Control Plane Minimum Requirements (NXCP Baseline) 13.11.1 **Auditability.** The control plane MUST generate a complete CPAR trail for key actions: authoring, approvals, deployments, overrides, waivers, freezes, rollbacks, and closures. Audit exports MUST be verifiable and tamper-evident. 13.11.2 **Separation of duties.** Role constraints and approval gates MUST be enforced by design for sensitive actions, including break-glass usage. Two-person or quorum rules MUST exist where reliance is high. 13.11.3 **Governed low-code/no-code authoring.** Low-code/no-code authoring MUST be constrained by templates, linting, and review workflows that produce testable outputs and prevent silent edits. Authoring must produce artefacts, not free-text procedures. 13.11.4 **Simulation.** Pre-deploy simulation MUST be supported and MUST generate evidence of expected obligations, enforcement-point coverage, and blast radius. Simulation outputs MUST be linkable to subsequent deployments. 13.11.5 **Override/kill switch.** Overrides MUST be constrained, time-limited, logged (CPAR), and followed by mandatory post-incident review and correction actions. Override misuse MUST be detectable and sanctionable. 13.11.6 **Handling compliance.** The control plane MUST prevent cross-class leakage in UI, logs, exports, and integrations; controlled exports MUST require approvals and must be logged. *** #### 13.12 Evidence Pack Handling and Sovereign Zone Minimum Requirements (AEP Baseline) 13.12.1 **Sovereign zone enforcement.** Evidence packs MUST be retained in sovereign zones under compute-to-data patterns. Systems MUST enforce access logging, policy gates, and retention controls. Evidence access MUST be auditable. 13.12.2 **Handling class enforcement.** Public/Controlled/Restricted behaviors MUST be enforced technically and operationally, including distribution constraints, watermarking where appropriate, and safe summarization rules. 13.12.3 **Lawful basis matrices and purpose limitation.** Deployments MUST support lawful basis declarations and purpose limitation controls governing collection, processing, and disclosure, with time bounds and audit trails. 13.12.4 **Retention and destruction.** Minimum retention for verification and maximum retention for privacy MUST be enforceable and recorded. Destruction events SHOULD be logged and verifiable where policy requires. 13.12.5 **Selective disclosure and redaction.** Evidence access workflows MUST support selective disclosure and redaction with documented rules, ensuring verifiers can confirm integrity without full exfiltration. 13.12.6 **Evidence access audit trails.** All controlled disclosures MUST generate audit trails including requestor, authorizer, artefact scope, disclosed subset, timestamps, and lawful basis. *** #### 13.13 Observability Minimum Requirements (Telemetry Baseline) 13.13.1 **Required linkage fields.** Telemetry MUST include trace context fields that connect checks, receipts, dockets, and corrections. Missing linkage MUST be detectable and treated as a conformance failure at required enforcement points. 13.13.2 **Event emission minima.** Checks and control plane actions MUST emit normalized events sufficient to drive triggers, open dockets, enforce clocks, and support drift detection. 13.13.3 **Normalized incident/security semantics.** Deployments MUST map incident/security events into normalized semantics to enable cross-tool portability and consistent obligation attachment. 13.13.4 **Retention and handling-aware logging.** Logging must minimize metadata leakage, honor handling classes, and enforce retention rules. Observability MUST NOT become a backdoor data export channel. *** #### 13.14 AI / Agentic Systems Minimum Requirements (AI Baseline) 13.14.1 **AI trigger conditions.** Deployments MUST implement AI obligation attachment triggers for model deployment and version change, tool enablement, domain shift signals, and defined abnormal behavior classes. 13.14.2 **Prompt/output logging classes.** Where required by profile, prompt and output logging MUST be classified by handling rules and retention policies, with minimization by default and explicit justification for higher retention. 13.14.3 **Tool allowlists and policy-bound invocation.** Agentic tool use MUST be constrained by allowlists, least privilege, and policy-bound invocation rules that can be checked and evidenced. 13.14.4 **Human override and kill switch evidence.** High-impact AI cases MUST require human override pathways and kill switch controls, with CPAR evidence and post-incident review workflows. 13.14.5 **Drift detection and retest clocks.** AI behavior/data/policy drift MUST generate triggers that attach obligations and initiate retest clocks; drift must not remain “monitoring-only.” 13.14.6 **Provenance and endpoint attestation.** Model/toolchain provenance and inference endpoint integrity MUST be evidenced; endpoint attestation MUST be mandatory for defined high-impact use cases. *** #### 13.15 Crypto Agility and Post-Quantum Minimum Requirements (Crypto Baseline) 13.15.1 **Suite identifiers.** Cryptographic suites MUST be versioned and identifiable in receipts, status objects, and verification libraries. 13.15.2 **Dual-signing and migration clocks.** A defined migration policy MUST exist, including dual-signing windows and explicit clocks for algorithm transitions that preserve historical verifiability. 13.15.3 **Archival verification bundles.** Long-lived reliance MUST be supported through archival bundles containing sufficient material to verify receipts and status years later, subject to handling constraints. 13.15.4 **Key lifecycle.** Key rotation, revocation, compromise response, and emergency key policies MUST be defined and testable, including procedures for receipt invalidation and re-issuance. *** #### 13.16 Minimum Conformance Test Suite Requirements (Harness Baseline) 13.16.1 **Gold vectors and invariants.** The harness MUST include mandatory gold vectors for receipt verification, profile composition, overlay algebra, status resolution, deterministic plan generation, and graph-to-controls mapping. 13.16.2 **Negative tests.** The harness MUST include malformed receipts, invalid signatures, missing required fields, revoked/superseded status, stale freshness windows, and replay/context misuse attempts. 13.16.3 **Adversarial tests.** The harness MUST include equivocation posture tests, poisoning attempts in ontology ingestion, privilege escalation and override misuse tests, and tampering tests across artefacts and logs. 13.16.4 **Drift tests.** The harness MUST include semantic drift tests (ontology and profiles) and, where AI controls are present, AI drift regression tests that demonstrate obligation attachment and retest clock behavior. 13.16.5 **Performance and resilience tests.** The harness MUST include offline/degraded verification tests, transparency outage behavior tests, failover drills, and clock compliance tests. 13.16.6 **Signed conformance reports.** Test outputs MUST be summarized in signed machine-readable reports and accompanied by human-readable summaries that respect handling rules, including explicit scope and permitted inference statements. *** #### 13.17 Baseline Procurement Language (Optional Insert-Ready Clauses) 13.17.1 **Required compliance claim language.** Procurement language MUST require scoped compliance statements (implementation/deployment/profile), version identifiers, and evidence deliverables; and MUST prohibit implied endorsement and overbroad security claims. 13.17.2 **Required evidence deliverables.** Contracts SHOULD require: signed conformance reports, receipt verification libraries, status endpoints and snapshot formats, and portability/export capability for receipts and artefact manifests. 13.17.3 **Portability and exit clauses.** Contracts SHOULD require anti-lock-in: export of receipts, status chains, docket summaries (as permitted), and profile packages; and the ability to validate artefacts with independent verifiers. 13.17.4 **Security and disclosure clauses.** Contracts SHOULD require handling discipline enforcement, incident clocks, vulnerability disclosure SLAs, key compromise drills, and controlled disclosure workflows with audit trails. *** #### 13.18 Part 13 Summary and Annex Pointers 13.18.1 **Summary checklist for “NXOSI-compliant.”** An NXOSI-compliant claim requires: mandatory artefacts present and linked; receipts verifiable offline/online with status semantics; deterministic plan generation under declared uncertainty; minimum enforcement-point coverage with CRR outputs; governed triggers and clocks via OARs; ontology fabric with provenance/uncertainty/trust scoring and semantic change control; control plane auditability with CPAR and SoD; sovereign evidence handling with compute-to-data; observability linkage minima; AI and crypto minima where applicable; and a conformance harness with gold/negative/adversarial/drift/resilience tests. 13.18.2 **Where schemas, APIs, and test vectors live.** The annex index contains normative schemas for PSA/SPP/TRG/OAR/XPL/CRR/PR/AEP/DKT/STO/CPAR, verification procedures, conformance harness specifications, gold vectors, negative/adversarial suites, and machine-readable report formats. 13.18.3 **Next step.** Following this baseline, the paper closes with adoption activation guidance—how institutions adopt NXOSI without collapsing the assurance perimeter, how governance gates and conformance governance are operationalized, and how deployments scale from pilot to federation under continuous verification and correctionability discipline. --- # 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/xiii.-testable-minima.md?ask= ``` 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.