# Annex R #### R.1 Control plane architecture, RBAC/SoD, and audit trail requirements R.1.1 **Purpose.** This Annex specifies the normative product requirements for the NXOSI Control Plane (NXCP): the singular, end-to-end operational interface for authoring, simulating, deploying, monitoring, correcting, and exporting NXOSI artefacts—without collapsing the non-execution boundary and without weakening handling discipline. R.1.2 **Architectural posture (mandatory).** NXCP MUST be designed as a **policy-governed orchestration and evidence interface**, not as an execution engine. R.1.2.1 **Assurance-only invariant.** NXCP MUST NOT initiate or perform regulated execution actions (custody, underwriting, placement, market operation, claims execution, settlement). Where integrations exist, NXCP MUST only route determinations/dockets and record outcomes as evidence. R.1.2.2 **Replaceable parts.** NXCP MUST interact with NXOSI components through stable, versioned APIs (artefact store, compiler, SAC runtime, proof service, status service, docket service, ontology service). UI implementation details MAY vary; API semantics MUST NOT. R.1.2.3 **Trust-zone separation.** NXCP MUST support sovereign deployment patterns: * portable/public-safe functions (receipt verification, public conformance views) MAY run outside sovereign zones; * controlled evidence operations (AEP access, restricted dockets) MUST remain in-zone and MUST enforce handling and lawful basis. R.1.2.4 **Offline/degraded modes.** NXCP MUST provide operator capability to: * verify receipts with cached snapshots; * queue actions for later sync (store-and-forward); * display degraded-mode constraints on reliance and permitted operations. R.1.3 **Identity, roles, and authorization (mandatory).** R.1.3.1 **Role-key awareness.** NXCP MUST integrate with role keys / authorization proofs used to sign artefacts and CPAR actions. Operator identity MAY be abstracted in role-marker form for stealth-by-design deployments, while maintaining audit-grade traceability within authorized identity cells. R.1.3.2 **RBAC + ABAC.** NXCP MUST enforce: * Role-Based Access Control (RBAC) for coarse permissions (author, reviewer, approver, verifier, operator, adjudicator, auditor); * Attribute-Based Access Control (ABAC) for handling class, lawful basis, jurisdiction, and zone attributes. R.1.3.3 **Separation of duties (SoD) (mandatory).** NXCP MUST enforce SoD constraints such that: * authors cannot be sole approvers for their own changes; * overrides/break-glass require independent approval (two-person rule or quorum, as configured); * adjudicators cannot be the same principals as the disputing parties; * auditors/examiners have read-only access and cannot change artefacts or status. R.1.3.4 **Step-up security.** High-impact actions (deploy, override, revoke, publish status, export controlled packs) MUST require step-up authentication and MUST be logged as CPAR with explicit authority references. R.1.4 **Audit trail and evidence discipline (mandatory).** R.1.4.1 **Action-as-evidence.** Every state-changing action in NXCP MUST generate a **Control-Plane Action Record (CPAR)** with immutable identifiers, timestamps, actor role, authority basis, affected artefact IDs, handling class, and linkage to dockets/status objects where applicable. R.1.4.2 **End-to-end linkability.** NXCP MUST preserve trace context across operations such that any PR/DKT/STO can be traced back to: * the OAR and trigger evaluation record; * the XPL and CRRs; * the CPAR trail for approvals/deployments/overrides. R.1.4.3 **No silent edits.** NXCP MUST prevent unlogged changes to: * standards/profile artefacts (PSA/SPP), * ontology semantics, * status objects, * docket histories, * simulation results.\ All changes MUST be versioned and governed via explicit supersession/status objects. R.1.4.4 **Tamper resistance.** Audit logs and CPAR records MUST be integrity-protected (append-only semantics or equivalent), and exportable as signed, time-bound bundles for third-party verification. *** #### R.2 Expert cockpit UX modules (obligations, dockets, receipts, drift, ontology views) R.2.1 **Purpose.** The expert cockpit is the operational interface for expert users (operators, verifiers, adjudicators) to observe, decide, and act—while ensuring every action is evidence-producing and handling-compliant. R.2.2 **Obligations & clocks module (OAR cockpit).** NXCP MUST provide: R.2.2.1 A unified view of active OARs by jurisdiction, profile stack, entity scope, hazard class, and reliance tier. R.2.2.2 Clock dashboards showing verification deadlines, remediation timers, retest schedules, dispute windows, and emergency-mode expiry. R.2.2.3 Escalation ladders (who is notified when; what triggers escalation; what is “stop-the-line”). R.2.2.4 Drill-down: OAR → XPL → CRR → PR linkage chain, including status resolution. R.2.3 **Docket module (DKT case management).** NXCP MUST provide: R.2.3.1 Case lifecycle views (open/update/pending remediation/retest/closure) with clock alignment. R.2.3.2 Workflow integration views (links to SOC/NOC/ITSM/GRC tickets) without importing sensitive content by default. R.2.3.3 Controlled vs public-safe docket summaries, with handling gating and redaction workflows. R.2.3.4 Dispute flagging and holds: when reliance must pause, what interim measures apply. R.2.4 **Receipts & verification module (PR/STO cockpit).** NXCP MUST provide: R.2.4.1 Receipt verification workflows (offline and online) including signature checks, inclusion proof verification, status resolution, scope/time binding checks, and reliance-tier inference constraints. R.2.4.2 Batch verification for procurement/audit workflows (accept/deny) with exportable signed verification results. R.2.4.3 Status timeline views for an artefact (issuance → supersession → scope narrowing → revocation) to support reliance stability. R.2.5 **Drift, exceptions, and continuous verification module.** NXCP MUST provide: R.2.5.1 Drift signal dashboard (telemetry anomalies, attestation freshness failures, semantic drift, overlay changes). R.2.5.2 Exception/waiver registry with expiry, authority, compensating controls, and mandatory retest scheduling. R.2.5.3 “Impact lens” showing which OARs, checks, entities, and receipts are affected by drift or exceptions. R.2.6 **Ontology view module (NOF cockpit).** NXCP MUST provide: R.2.6.1 Canonical entity graph exploration with handling-aware redaction. R.2.6.2 Relation overlays (dependencies, custody, exposure, influence) and hazard/event overlays. R.2.6.3 Provenance/uncertainty display for assertions, including quarantine flags and trust scoring indicators. R.2.6.4 Graph-to-controls view: event → trigger → OAR → checks → receipts → graph updates. R.2.7 **Role-based views.** NXCP MUST provide views tailored to roles (operator, verifier, adjudicator, auditor/examiner) with least-privilege field-level restrictions by handling class and lawful basis. *** #### R.3 Governed low-code/no-code builders (constraints, templates, linting, approvals) R.3.1 **Purpose.** NXCP MUST enable low-code/no-code authoring of policies, triggers, profiles, overlays, playbooks, and disclosure policies while enforcing constraints that preserve determinism, safety, and conformance. R.3.2 **Builder scope (mandatory).** NXCP MUST include builders for: R.3.2.1 Policy/Standard Artefacts (PSA) and mappings to controls/tests. R.3.2.2 Trigger definitions (TRG) with explicit uncertainty policies and clock bindings. R.3.2.3 Profile and overlay packages (SPP) with composition declarations and precedence rules. R.3.2.4 Playbooks/runbooks with automation-safe forms and evidence outputs. R.3.2.5 Disclosure and handling policies for AEP indexing and controlled summaries. R.3.3 **Constraint system (mandatory).** R.3.3.1 Builders MUST enforce schema correctness and required fields. R.3.3.2 Builders MUST enforce “no silent edits”: every change must produce a new version and an explicit status/supersession plan. R.3.3.3 Builders MUST prevent authoring constructs that introduce non-determinism unless explicitly permitted via declared uncertainty policy and bounded behavior. R.3.3.4 Builders MUST enforce non-execution constraints (cannot define actions that move money, execute claims, or perform market operations). R.3.4 **Linting and static analysis (mandatory).** R.3.4.1 TRG linting: ensure ontology bindings exist, thresholds are declared, and defer/uncertainty handling is explicit. R.3.4.2 Profile linting: detect conflicts, missing enforcement points, missing dependency declarations, and overlay precedence errors. R.3.4.3 Disclosure linting: detect forbidden metadata leakage, unlawful basis mismatches, and handling downgrades. R.3.4.4 Security linting: ensure signing requirements, provenance metadata, and status pointers are present. R.3.5 **Approval workflows (mandatory).** R.3.5.1 NXCP MUST support multi-stage review gates (draft → review → approved → staged → deployed). R.3.5.2 Approvals MUST be captured as CPAR with authority basis and SoD compliance. R.3.5.3 Emergency changes MUST be supported but require stricter logging, explicit time bounds, and mandatory post-review workflows. *** #### R.4 Simulation and what-if requirements (evidence outputs) R.4.1 **Purpose.** Simulation is required to prevent policy/overlay changes from creating uncontrolled blast radius, interoperability breaks, or silent meaning changes. R.4.2 **Simulation capabilities (mandatory).** R.4.2.1 Trigger simulation: evaluate TRG predicates against historical or synthetic NOF event sets, producing a predicted OAR issuance set. R.4.2.2 Profile composition simulation: show composed control sets and detect conflicts under overlays. R.4.2.3 XPL simulation: generate execution plans and validate enforcement-point coverage, dependencies, and attestation requirements. R.4.2.4 Drift/impact simulation: estimate which existing receipts/dockets would be impacted by a proposed change, including reliance-tier implications. R.4.2.5 Degraded-mode simulation: test offline verification and stale cache behavior for relying parties. R.4.3 **Simulation evidence outputs (mandatory).** Simulation runs MUST produce: R.4.3.1 A signed simulation record (SIM-R) containing inputs (artefact IDs, versions, snapshots), outputs (predicted OARs/XPL hashes), and handling markers. R.4.3.2 A compatibility impact summary declaring whether changes are compatible, breaking, or require a governed migration. R.4.3.3 A “stop-the-line” signal when breaking changes are detected without required governance artefacts (e.g., STO migration notes). R.4.4 **Promotion gates.** Deployment promotion MUST require successful simulation evidence for defined artefact classes (at minimum: TRG, overlays, SAC runtime policy changes, ontology semantic changes). *** #### R.5 Override/kill switch governance (constraints, CPAR logging, post-review) R.5.1 **Purpose.** Overrides and kill switch exist for safety, incident response, and urgent containment. They are also a primary abuse vector. NXCP must implement strict governance. R.5.2 **Override types (mandatory enumeration).** NXCP MUST support explicitly typed overrides such as: * policy freeze, * rollback to prior version, * emergency profile activation, * waiver issuance, * receipt invalidation request workflow (status action proposal), * quarantine of ontology sources/assertions. R.5.3 **Eligibility rules (mandatory).** Each override type MUST specify: * qualifying conditions, * who may initiate, * required approvers/quorum, * maximum duration, * scope constraints, * mandatory post-review steps. R.5.4 **Mandatory logging (CPAR).** Every override MUST generate CPAR including: * reason code and incident linkage, * scope/duration, * authority basis, * approving parties (as role markers if required), * associated artefact IDs (OAR/XPL/PR/DKT/STO), * post-review due date clock. R.5.5 **Post-incident review (mandatory).** NXCP MUST implement: * a structured post-review workflow (root cause, corrective actions, lessons learned), * publication outputs (public-safe summary vs controlled details), * conversion of emergency actions into governed changes (status objects, supersession, corrected profiles). R.5.6 **Misuse controls.** NXCP MUST support sanctions hooks: access suspension, role revocation, badge withdrawal workflow, and required correction notice templates where misrepresentation occurs. *** #### R.6 Export and reporting (examiner packs; audit exports; handling compliance) R.6.1 **Purpose.** NXCP must generate examiner-operable and auditor-operable outputs that are independently verifiable, handling-compliant, and portable—without exporting sovereign evidence by default. R.6.2 **Export classes (mandatory).** R.6.2.1 **Receipt-only verification pack.** Includes: PRs, verifier results, cached transparency snapshots/checkpoints, status resolution outputs, conformance report pointers—sufficient for reliance tiers that do not require evidence access. R.6.2.2 **Docket summary pack.** Public-safe or controlled summary of DKT lifecycle, clocks, remediation actions, and status timeline—without restricted evidence content. R.6.2.3 **Controlled evidence request pack.** A workflow artefact set (requests, approvals, lawful basis matrix, access logs, redaction outputs) enabling controlled AEP access without uncontrolled exfiltration. R.6.2.4 **Audit replay pack (where permitted).** Includes reproducibility pointers (CRR inputs/outputs references, attestation appraisal references) enabling replay of checks in-zone under controlled access. R.6.3 **Export constraints (mandatory).** R.6.3.1 Exports MUST be signed, time-bound, and include version/compatibility metadata. R.6.3.2 Exports MUST include handling markers and MUST enforce redaction rules and metadata minimization. R.6.3.3 Exports MUST include an explicit “permitted reliance” statement aligned to the reliance tier and MUST prohibit implied endorsement or overclaiming. R.6.3.4 Exports MUST include traceability pointers so a recipient can validate chain-of-custody and status without trusting the exporting operator. R.6.4 **Reporting dashboards (informative but recommended).** NXCP SHOULD provide: * compliance posture by profile and overlay, * clock compliance performance (verify/remediate/retest/dispute), * drift and exception trends, * supply-chain and third-party oversight posture, * sovereignty/handling compliance indicators (access logs, disclosure counts). R.6.5 **Machine-readable reporting.** NXCP MUST support machine-readable exports for: * conformance reports, * verification results, * CPAR logs (filtered by handling class), * status timelines,\ to enable continuous assurance and automated procurement acceptance workflows. --- # 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-r.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.