# XI. Sector Profiles

#### 11.1 Purpose and Scope

11.1.1 **Purpose.** This Part demonstrates that Nexus Standards and NXOSI deliver the same end-to-end operability—portable proofs, machine-attachable obligations, and testable trust—across multiple sectors and hazard classes without changing the core artefact model or conformance surfaces. The intent is to make the system *inspectable in practice*: readers can trace how triggers become obligations, how obligations become executable plans, how checks yield receipts, how receipts bind to dockets, and how corrections preserve reliance stability.

11.1.2 **Scope.** This Part specifies: (a) a reference sector profile library and naming conventions; (b) uniform use-case formats with explicit evidence checklists; (c) end-to-end operational flows spanning triggers → OAR → XPL → checks → receipts → dockets → corrections; and (d) examiner-operable walkthroughs showing how an independent relying party can verify outcomes with receipt-only access or with controlled evidence access. The scope includes degraded operation and dispute/correction paths as first-class aspects of operational reality.

11.1.3 **Non-execution boundary.** Each use case reaffirms that NXOSI routes determinations and produces auditable artefacts but does not execute regulated actions. Where sector scenarios include regulated outcomes (e.g., financial stability actions, claims decisions, market decisions, safety shutdowns), NXOSI’s role is limited to obligation attachment, evidence production, docket routing, and correction governance; external systems and authorized parties execute regulated operations under their own governance and licensing.

11.1.4 **How to read this Part.** Each use case is presented as an operational dossier with the same structure: (a) scenario statement and why it matters; (b) ontology baseline (entities/relations/events); (c) trigger predicates and OAR scope/clocks; (d) execution plan and enforcement points; (e) evidence outputs and reliance tiers; (f) relying-party verification steps; (g) failure modes and degraded operation; (h) dispute/correction path; and (i) conformance tests exercised. Where sector-specific nuance exists, it is expressed as **profiles and overlays**, not as bespoke logic.

***

#### 11.2 Reference Sector Profile Library (Pack Index)

11.2.1 **Profile naming, versioning, and overlay conventions.** Profile packages MUST follow stable identifier conventions and semantic versioning. Every package MUST declare dependencies, overlays, parameter bindings, and handling defaults. Sector and hazard overlays MUST be additive and conflict-resolving under the overlay algebra; overlays MUST NOT silently redefine semantics that would break receipt portability or relying-party verification. Each profile SHALL publish a “profile intent summary” that is non-normative but helps implementers understand design scope and expected evidence outputs.

11.2.2 **Baseline profiles.** Baseline profiles form the cross-sector minimums required to claim NXOSI operability. Baselines are composed first in profile stacking order and provide the invariant spine for receipts, status, handling, and correctionability.

11.2.2.1 **Core Baseline (cross-sector minimums).** Establishes minimum artefacts, linkage rules, determinism requirements, status semantics, and clock discipline. It defines the universal minimum for issuing portable receipts and producing docket traceability that survives cross-vendor and cross-jurisdiction review.

11.2.2.2 **Supply Chain Integrity Baseline (SBOM/provenance/secure release).** Establishes minimum requirements for verifiable provenance, dependency pinning, signed release bundles, vulnerability intake, patch clocks, and build integrity evidence. It includes required conformance vectors for tampered artefacts, dependency drift, and compromised signing scenarios.

11.2.2.3 **Operational Resilience Baseline (degraded modes, clocks, third-party oversight).** Defines degraded-mode behavior, offline verification bundles, continuity-related triggers, and minimum third-party oversight artefacts (vendor evidence intake, remediation clocks, retest requirements). It standardizes SLO declarations and minimum audit exports.

11.2.2.4 **Evidence & Disclosure Baseline (handling classes; minimal disclosure; sovereign zones).** Defines handling markers, lawful basis matrices, selective disclosure rules, sovereign zone constraints, retention/destruction rules, and controlled evidence access workflows. It enforces the “receipts travel, evidence stays” posture as operationally testable behavior.

11.2.2.5 **Ontology Fabric Baseline (entity/event/provenance minimums; semantic change control).** Defines canonical entity/relation/event primitives, provenance and uncertainty fields, identity resolution rules, semantic versioning, and semantic regression tests. It standardizes the graph-to-controls mapping interface used by triggers and OAR scope binding.

11.2.2.6 **Control Plane Baseline (auditability; separation of duties; override governance).** Defines required approval gates, CPAR semantics, override and kill-switch constraints, simulation evidence requirements, and audit exports. It ensures that operational decision points are evidence-producing and subject to due process.

11.2.3 **Sector profiles.** Sector profiles bind baseline controls to sector-specific contexts through parameters, overlays, and additional enforcement-point expectations. Sector profiles MUST remain interoperable: their receipts remain verifiable using the same verification procedures, and they MUST not introduce opaque requirements that cannot be tested.

11.2.3.1 **Financial sector operational resilience profile.** Specializes third-party concentration mapping, continuity testing, incident clocks, and examiner packet generation. Emphasizes auditable oversight of critical service providers and reliable evidence under stress without disclosure overreach.

11.2.3.2 **Critical infrastructure profile (energy/transport/telecom/water).** Specializes OT/IT convergence constraints, safety sign-off semantics, edge/offline operation, and dependency mapping. Emphasizes compartmentalization, lawful handling, and restoration evidence that can be validated without forcing unsafe interventions.

11.2.3.3 **Public sector / sovereign deployment profile.** Specializes data residency, lawful basis constraints, minimal disclosure defaults, and national overlay hooks. Emphasizes compute-to-data workflows and the ability to demonstrate compliance and readiness while protecting sensitive national systems.

11.2.3.4 **Software factory and supply-chain profile.** Specializes build-time and release-time enforcement points, provenance requirements, dependency governance, and emergency freeze behavior. Emphasizes proof-carrying releases and deterministic verification across toolchains.

11.2.3.5 **AI/agentic systems profile.** Specializes dynamic obligation attachment for model/tool enablement, prompt risk classes, drift triggers, endpoint attestation, and kill-switch governance. Emphasizes audit-grade logging of high-impact AI behaviors without turning the standards system into a surveillance system.

11.2.3.6 **Health and safety critical systems profile (optional).** Specializes high-assurance attestation tiers, strict change control, safety constraints, and evidence quality requirements suitable for contexts where errors produce direct physical harm.

11.2.4 **Hazard overlays.** Hazard overlays attach to baseline and sector profiles to introduce hazard-specific triggers, clocks, evidence requirements, and retest schedules. Hazard overlays MUST be explicitly composable; they MUST declare the event semantics they consume and emit.

11.2.4.1 **Cyber incident overlay.** Defines incident detection events, containment obligations, attestation requirements for compromised zones, receipt invalidation semantics where needed, and retest clocks for restoration.

11.2.4.2 **Outage/continuity overlay.** Defines service degradation thresholds, continuity test obligations, restoration evidence minima, and clock discipline for recovery actions, including controlled publication of public-safe continuity summaries.

11.2.4.3 **Disaster/climate shock overlay.** Defines multi-source signal fusion triggers, readiness obligations, safe disclosure defaults, and inter-agency docket coordination patterns while maintaining minimal disclosure and sovereignty constraints.

11.2.4.4 **AI incident overlay.** Defines prompt injection/tool misuse/model drift triggers, emergency kill-switch procedures, evidence retention rules, and post-incident correction workflows.

11.2.4.5 **Systemic supply disruption overlay.** Defines dependency shock triggers, critical supplier designation hooks, procurement gate escalation rules, and remediation clocks for substitute sourcing and integrity validation.

11.2.5 **Jurisdiction overlays.** Jurisdiction overlays encode local lawful basis, disclosure constraints, critical entity definitions, incident reporting clocks, and retention rules without forking base semantics. Overlays MUST preserve proof portability by restricting changes to permitted overlay dimensions.

11.2.5.1 **National overlays.** Encode national lawful basis constraints, disclosure and retention requirements, critical entity definitions, and local governance approvals. National overlays MUST not weaken baseline integrity or correctionability semantics and MUST publish explicit conflict resolution decisions when they narrow or elevate duties.

11.2.5.2 **Regional overlays.** Encode cross-border portability requirements and common supervisory expectations, including evidence packaging minima and status resolution expectations for cross-jurisdiction relying parties.

11.2.5.3 **Cross-sector overlays.** Encode rules such as critical supplier designation and common reporting thresholds that apply across sectors and hazards, ensuring consistent duty attachment and avoiding fragmented interpretations across organizational silos.

***

#### 11.3 Use Case Format and Evidence Checklist (Applied Uniformly)

11.3.1 **Scenario statement and why this matters.** Each use case begins with an operational scenario tied to a concrete failure mode: cascading dependencies, third-party shocks, drift-driven incidents, or cross-border compliance collisions. The scenario defines the “operability stake”: what must be provable, to whom, under what constraints.

11.3.2 **Entities and ontology baseline.** Each use case declares the minimum ontology entities, relations, and events required for interoperability. This includes identity resolution requirements (canonical IDs), dependency relations, exposure relations, and event semantics. Missing ontology minima are treated as conformance failures or declared uncertainty requiring reliance downgrades.

11.3.3 **Trigger and obligation model.** Each use case specifies the trigger predicate, evidence candidates, uncertainty rules, OAR scope binding, clocks, reliance tier defaults, and handling defaults. Triggers MUST map to ontology events and MUST support replay-safe evaluation.

11.3.4 **Execution plan and enforcement points.** Each use case defines how XPL selects enforcement points and check runtimes. Enforcement points include build, deploy, runtime, procurement, incident, and retest contexts. Where an enforcement point is unavailable (e.g., OT safety constraints), the use case specifies fallback checks and declared uncertainty.

11.3.5 **Evidence outputs.** Each use case enumerates the required evidence artefacts: CRR, PR, AEP index pointers, docket entries, CPAR for decisions and overrides, and STO/COR where corrections occur. Evidence outputs MUST be linkable end-to-end and MUST include handling markers.

11.3.6 **Relying-party verification steps.** Each use case includes both offline and online verification steps: signature verification, inclusion proof verification, status resolution, scope/time validation, reliance tier enforcement, and clock compliance checks. Where controlled evidence is required, the workflow must be explicit, logged, and handling-aware.

11.3.7 **Failure modes and degraded operation.** Each use case defines deterministic behavior under degraded operation: stale caches, transparency outage, network partition, attestation failure, partial data availability, and compromised sources. Degraded outcomes MUST be reflected in receipts and docket statuses rather than hidden.

11.3.8 **Dispute/correction path.** Each use case includes a dispute window and correction workflow: who can challenge, what evidence is admissible, how interim reliance is handled, and how final outcomes are recorded via status objects and correction objects.

11.3.9 **Conformance tests used.** Each use case declares which gold vectors and negative/adversarial tests are exercised. Use cases are not narratives; they are applied conformance demonstrations with defined expected artefact outputs.

***

### Use Case Cluster A — Critical Infrastructure and Cascading Failures

#### 11.4 Critical Infrastructure Outage + Cyber Compound Scenario (Cascading Systems)

11.4.1 **Scenario.** A cyber intrusion compromises a service that is a dependency of multiple critical services, triggering an outage cascade (e.g., telecom degradation affects emergency dispatch and water treatment telemetry). The operator must prove containment and restoration actions under strict safety constraints and without disclosing sensitive network architecture to external parties.

11.4.2 **Ontology mapping.** Required ontology elements include: asset entities, service entities, dependency relations, supplier relations, service criticality attributes, and event semantics for intrusion indicators, service degradation, restoration milestones, and safety sign-offs. Provenance and uncertainty must be recorded for all derived dependency assertions.

11.4.3 **Trigger.** Triggers combine anomaly events and outage threshold crossings and issue OARs scoped to affected services, regions, and time windows. OAR clocks include verification, containment, restoration, retest, and dispute windows. Handling defaults classify sensitive technical details as controlled or restricted.

11.4.4 **Checks.** Enforcement points include segmentation posture checks, patch posture checks for exposed components, backup integrity verification, restoration evidence capture, and safety constraint validation for OT systems. Attestation is mandatory for high-impact claims (e.g., “restoration completed”) and optional for lower-impact claims with declared uncertainty.

11.4.5 **Proofs.** Receipts are issued for containment steps, restoration steps, and compensating controls (e.g., temporary routing restrictions). Receipts declare scope, time binding, reliance tier, and permitted inferences. Evidence packs remain in-zone; only receipt-level proof travels across organizations.

11.4.6 **Docket.** A docket coordinates remediation across teams (security operations, network operations, OT safety teams). The docket binds clocks to each remediation task, links CPAR approvals and overrides, and records retest requirements and closure criteria.

11.4.7 **Correction path.** If root cause changes due to new evidence (e.g., intrusion vector updated), corrections supersede prior determinations and may narrow scope of earlier receipts. Status objects ensure reliance stability: relying parties can see exactly which receipts remain valid and which are superseded.

11.4.8 **Examiner walkthrough.** An examiner verifies: receipt signatures, inclusion proofs, status timelines, scope/time bounds, and separation-of-duties evidence (CPAR). Controlled evidence access—if needed—is requested through logged workflows and reviewed via compute-to-data summaries that preserve safety and confidentiality.

***

#### 11.5 OT/IT Convergence Scenario (Edge + Safety Constraints)

11.5.1 **Scenario.** An OT gateway is suspected compromised; connectivity is limited and safety constraints prohibit invasive scanning. The organization must prove that mitigations and safe restoration were applied without introducing unsafe interventions.

11.5.2 **Enforcement points.** Checks occur at edge policy gates, remote attestation of gateways where available, offline verification of configuration baselines, and controlled inspection procedures approved by safety authorities. Where attestation is infeasible, the plan requires compensating controls and declared uncertainty.

11.5.3 **Evidence handling.** Full evidence packs are stored in restricted operational zones; external relying parties receive receipts and controlled summaries that do not reveal sensitive network topology or safety-critical process details.

11.5.4 **Degraded mode.** Store-and-forward receipts are generated locally; transparency publication is delayed until safe connectivity is restored. Receipts declare degraded-mode constraints and include required pointers for later inclusion proof verification.

11.5.5 **Restoration.** Retest clocks are mandatory, and safety sign-offs are captured as CPAR with role-based authorization. Closure requires evidence of safe return-to-service and verification of compensating control removal or formalization.

***

### Use Case Cluster B — Financial Sector Operational Resilience and Third-Party Oversight

#### 11.6 Financial Sector Third-Party Concentration + Resilience Scenario

11.6.1 **Scenario.** A critical vendor suffers disruption. A regulated entity must demonstrate third-party oversight, continuity actions, and response timelines, including concentration awareness and remediation actions, without disclosing proprietary vendor contracts or sensitive system details beyond what is necessary.

11.6.2 **Ontology mapping.** Required ontology elements include vendor entities, vendor relationship relations, critical function mappings, concentration relations, and dependency chains from critical functions to vendor services. Provenance must record sources of relationship assertions and any uncertainty.

11.6.3 **Triggers.** Vendor incident events plus concentration threshold conditions trigger OAR issuance. OAR scope binds impacted critical functions, service dependencies, and time windows. Clocks include verification deadlines, continuity action deadlines, and supervisory packet timelines.

11.6.4 **Checks.** Checks validate continuity test results, recovery procedures, restoration evidence, vendor oversight artefacts, and remediation completion. Procurement/vendor gates validate vendor evidence receipts and enforce remediation clocks and waiver expiry.

11.6.5 **Proofs.** Receipts provide portable evidence that required oversight controls were executed and that continuity actions occurred within declared clocks. Receipts remain independent of vendor narrative reports: proofs are tied to checks, attestations where required, and status semantics.

11.6.6 **Docket.** The docket manages remediation tasks, tracks waiver objects with expiry, attaches retest schedules, and generates controlled supervisory packets that show compliance with clocks and duties without bulk evidence export.

11.6.7 **Examiner walkthrough.** Examiner verifies receipt validity, status resolution, scope bounds, and duty separation. Where controlled access is required, evidence is reviewed through logged and purpose-limited workflows; replayable checks are conducted where supervisory reliance demands reproducibility.

***

#### 11.7 Audit-Grade Continuous Controls Monitoring Scenario

11.7.1 **Scenario.** Continuous verification replaces periodic audit snapshots. The organization must demonstrate that control execution is consistent over time, drift is detected, exceptions are governed, and corrective actions are tracked to closure.

11.7.2 **Controls.** Runtime checks produce CRRs; drift triggers generate OARs and dockets; exceptions are issued as governed objects with expiry and compensating controls. Attestation requirements apply to high-impact checks; others are evidence-scoped.

11.7.3 **Proofs.** Periodic receipts and status updates support audit reliance by demonstrating continuous execution and correctionability. Receipts bind to time windows and include pointers to status changes and docket closure evidence.

11.7.4 **Correction.** Supersession preserves reliance stability: when controls change, prior receipts remain interpretable through status resolution and migration notes, preventing ambiguous claims of continuous compliance across incompatible control regimes.

***

### Use Case Cluster C — Public Sector and Sovereign Deployments

#### 11.8 Sovereign Deployment with Data Residency and Minimal Disclosure

11.8.1 **Scenario.** A sovereign deploys NXOSI under strict lawful-basis constraints and data residency requirements. External stakeholders must verify compliance and readiness without access to sensitive national systems or raw evidence.

11.8.2 **Sovereign zone topology.** Evidence packs and sensitive ontology assertions remain in sovereign zones. Compute-to-data workflows allow controlled review. Portable components provide verification libraries, profile packages, and public-safe registries.

11.8.3 **Cross-border proof portability.** Receipts travel across borders; evidence stays in-zone. Receipts include selective disclosure-friendly fields and status pointers. Relying parties verify with receipt-only workflows unless lawful basis explicitly permits controlled access.

11.8.4 **National overlay example.** National overlays define disclosure constraints, retention windows, critical entity definitions, and escalation paths. Overlays narrow duties where required by law and elevate duties where national policy requires higher assurance; all changes are explicit and status-bound.

11.8.5 **Examiner walkthrough.** External examiners verify receipts, inclusion proofs, and status without evidence export. Domestic examiners may execute controlled evidence workflows, with access logs and redaction rules enforced, and with replayable verification where high reliance is required.

***

#### 11.9 Cross-Jurisdiction Standards Overlays (National/Regional/Global)

11.9.1 **Scenario.** A cross-border operator must satisfy multiple overlays without forking standards. Obligations must attach correctly per jurisdiction, and receipts must remain verifiable across relying parties.

11.9.2 **Overlay algebra in action.** Precedence resolves global baseline, regional overlay, national overlay, and operator policy. Conflict detection prevents silent contradictions. Carve-outs and parameter narrowing are expressed explicitly in overlays and recorded as governed decisions.

11.9.3 **Proof portability.** Receipts bind to the specific overlay stack hash and declare reliance and scope. Multiple relying parties validate the same receipt under compatible overlay semantics; where overlays differ, status objects and compatibility notes provide deterministic interpretation.

11.9.4 **Dispute and correction.** Disputes resolve overlay conflicts via correction objects and status actions. Interim reliance may be held or narrowed pending resolution; final reliance is stabilized through supersession and explicit migration guidance.

***

### Use Case Cluster D — Software Factory and Supply-Chain Integrity

#### 11.10 Proof-Carrying Software Release Scenario (SBOM + Provenance + Policy Gates)

11.10.1 **Scenario.** A release requires verifiable provenance, dependency integrity, and policy compliance. The goal is to make releases auditable and verifiable without repeating full audits for every consumer.

11.10.2 **Enforcement points.** CI/CD gates enforce SBOM requirements, provenance attestations, dependency policies, and signing rules. Deploy gates validate deployment configuration integrity. Runtime gates enforce policy constraints for critical services.

11.10.3 **Proofs.** Receipts prove provenance compliance, policy gate passing, and release integrity. Receipts reference the release artefact hash, profile hash, and status endpoints. Evidence packs include the full provenance chain, logs, and tool attestations retained in-zone.

11.10.4 **Docket.** Vulnerability response is docketed with patch clocks and retest requirements. Exceptions require waiver objects with expiry and compensating controls, tracked in docket status and audit exports.

11.10.5 **Supply-chain incident.** If a dependency is compromised, emergency freeze behavior is activated: receipt issuance may be paused, affected receipts may be narrowed or revoked by status, and remediation actions are tracked to closure with retest clocks.

11.10.6 **Examiner walkthrough.** Examiner verifies release receipts, inclusion proofs, and status timelines, confirms duty separation in approvals (CPAR), and validates that emergency response occurred within defined clocks without requiring exposure of proprietary build logs unless supervisory reliance requires controlled access.

***

#### 11.11 Third-Party Component Intake Scenario (Vendor Evidence Acceptance)

11.11.1 **Scenario.** An enterprise must accept or deny third-party components based on portable proofs and overlay compatibility. The enterprise must avoid bespoke re-audits for every vendor while preserving safety.

11.11.2 **Checks.** Intake checks validate receipt signatures, inclusion proofs, status resolution, overlay compatibility, declared scope, and evidence quality tier where applicable. Where verification fails, a docket is opened with remediation requests and clocks.

11.11.3 **Docket and waiver discipline.** Waivers are permitted only as governed exception objects with expiry and compensating controls, producing CPAR records. Waivers are visible in auditor workflows and cannot be used to mask persistent nonconformance.

***

### Use Case Cluster E — AI and Agentic Systems (Dynamic Obligations)

#### 11.12 Agentic AI Tool-Use Scenario (Tool Allowlists + Human Override + Kill Switch)

11.12.1 **Scenario.** An agentic system uses tools and data sources, creating risk of tool misuse, data exfiltration, and prompt injection. Obligations must attach dynamically based on tool enablement, prompt risk class, and domain shift.

11.12.2 **Trigger.** Triggers attach obligations when tool enablement changes, when domain shift is detected, when prompt-risk class escalates, or when drift exceeds thresholds. OAR scope includes model version, tool set, endpoint identity, and time window; clocks cover verification, remediation, and retest.

11.12.3 **Checks.** Checks enforce tool allowlists, prompt/output logging classes, policy-bound tool invocation constraints, and endpoint attestation. Checks also validate that human override paths exist and that kill-switch actions are constrained and logged.

11.12.4 **Proofs.** Receipts bind the runtime policy posture, tool invocation controls, logging compliance, and attested endpoint claims. Receipts declare reliance tier and permitted inference limits to prevent over-claiming safety.

11.12.5 **Drift.** Behavior drift, data drift, and toolchain drift feed triggers that tighten obligations, shorten clocks, and require retest and additional evidence. Drift outcomes are docketed and require explicit resolution before reliance is restored.

11.12.6 **Control plane accountability.** Overrides and kill-switch actions are recorded as CPAR. Post-incident review workflows generate correction objects and, where needed, supersede prior receipts or narrow their scope.

11.12.7 **Examiner walkthrough.** Examiner verifies that obligations attached correctly at tool enablement and domain shift, verifies receipts and status timelines, inspects CPAR for override governance, and validates drift response clocks. Controlled evidence access is performed only when reliance tier demands it and under logged disclosure workflows.

***

#### 11.13 Model Supply-Chain and Inference Endpoint Integrity Scenario

11.13.1 **Scenario.** Model versions change, and inference endpoints drift over time. Continuous verification is required to prevent silent safety regressions and unlogged capability changes.

11.13.2 **Enforcement points.** Model registry gates enforce versioning and provenance. Deploy gates enforce endpoint configuration integrity. Runtime gates enforce policy constraints for tool use and data access. Attestation is mandatory for high-impact inference contexts.

11.13.3 **Proofs.** Receipts prove model lineage, endpoint integrity, approvals, and runtime policy compliance. Status objects handle revocation or supersession when a model is found to be unsafe or when evidence is corrected.

11.13.4 **Correction.** When model artefacts are updated, receipts are superseded with explicit migration notes; relying parties can determine whether prior receipts remain valid, are narrowed, or are revoked.

***

### Use Case Cluster F — All-Hazards / All-of-Society Intelligence + Participation

#### 11.14 All-Hazards, All-of-Society Intelligence Scenario (Ontology-Driven Operations)

11.14.1 **Scenario.** Multi-source hazard signals (cyber + outage + supply + climate shock) drive obligations across agencies and operators. The challenge is coordination with minimal disclosure and reliable cross-domain semantics.

11.14.2 **Ontology fabric.** The ontology provides entity overlays and event overlays that unify hazards and dependencies. Provenance and uncertainty are tracked for all inputs; trust scoring bounds influence and quarantines suspect sources.

11.14.3 **Triggers.** Threshold crossings issue OARs across domains with coordinated clocks. Triggers operate on ontology events and must remain replay-safe. OAR scope binds affected systems and regions without requiring disclosure of sensitive underlying evidence outside zones.

11.14.4 **Checks.** Checks validate readiness actions, continuity posture, cyber posture, and supply posture using enforcement points appropriate to each domain. Where direct measurement is infeasible, declared uncertainty and compensating controls are required.

11.14.5 **Proofs.** Receipts enable cross-agency coordination: parties verify that obligations were attached and checks executed without exchanging full evidence. Controlled summaries support decision-making while preserving handling constraints.

11.14.6 **Dockets.** Coordinated dockets support shared clocks, remediation tasks, and dispute paths across agencies. Public-safe docket summaries may be published without exposing restricted details, supporting transparency without harm.

***

#### 11.15 Participatory Ground Truthing at Scale Scenario (Governed Public Inputs)

11.15.1 **Scenario.** Community reports contribute to detection and verification. Inputs may be high-value but are vulnerable to manipulation, coercion, and harm to reporters.

11.15.2 **Safeguards.** The participatory pipeline enforces anti-sybil protections, bounded influence, do-no-harm handling, protected participation, and escalation to expert adjudication. Submissions are treated as evidence candidates until corroborated.

11.15.3 **Evidence candidates to verified assertions.** Submissions are triangulated against independent sources where possible, annotated with uncertainty, and either promoted to ontology assertions or quarantined. Promotions and rejections are recorded and subject to dispute rules.

11.15.4 **Proofs.** Receipts can be issued for adjudicated determinations without exposing reporter identities. Receipts bind to protected evidence pack references and provide public-safe summaries where appropriate.

11.15.5 **Disputes and remedies.** Dispute channels support correction workflows, and protective procedures prevent retaliation or coercion. Corrections are explicit: scope narrowing, supersession, and revocation are recorded via status objects.

***

### Examiner / Supervisor Walkthroughs (Applied Verification)

#### 11.16 Examiner Walkthrough A — Receipt-Only Verification (No Evidence Exfiltration)

11.16.1 **What the examiner requests.** The examiner requests: proof receipts for relevant controls and time windows, status endpoints (or status snapshots), inclusion proofs (or transparency snapshots), profile packages and overlay stack identifiers, and signed conformance reports.

11.16.2 **Steps.** The examiner verifies: issuer authorization, signature validity, scope/time bounds, profile hash binding, inclusion proof validity, and status resolution (revocation/supersession/scope narrowing). The examiner confirms clock compliance and separation-of-duties evidence via CPAR summaries where permitted.

11.16.3 **Permitted conclusions.** Conclusions are strictly limited by the reliance tier declared in receipts and conformance level evidence. Receipt-only verification supports deterministic conclusions about *what was checked, under what profile and scope, at what time, and with what status*, but does not grant access to controlled evidence or allow inference beyond declared bounds.

11.16.4 **Handling compliance.** The examiner workflow enforces minimal disclosure: no requests for restricted evidence without explicit lawful basis and authorization. Verification logs are retained as audit artefacts with handling markers.

***

#### 11.17 Examiner Walkthrough B — Controlled Evidence Access (Audit/Supervisory Reliance)

11.17.1 **Controlled disclosure request.** The examiner submits a controlled disclosure request specifying purpose, lawful basis, scope, and required reliance tier. Approval workflows enforce separation of duties and must be logged.

11.17.2 **Evidence access logs and redaction.** Evidence pack access is performed with access logging, redaction rules, and selective disclosure mechanisms. Evidence is reviewed via compute-to-data where possible; extraction is the exception and must be explicitly authorized.

11.17.3 **Replay and reproduction of checks.** Where required, checks are replayed deterministically using cached profile packages, execution plans, and logged inputs. Replay outcomes generate additional receipts and docket entries, preserving full traceability.

11.17.4 **Closing the loop.** The examiner verifies remediation completion, retest outcomes, and docket closure criteria. If deficiencies persist, the docket remains open with updated clocks and may trigger correction objects or status changes.

***

#### 11.18 Part 11 Summary and Transition Forward

11.18.1 **Use-case-to-artefact mapping index.** This Part demonstrates that sector and hazard differences are expressed as profile composition and overlays while the artefact model remains invariant. Each use case maps to the same artefact chain: TRG → OAR → XPL → CRR → PR/AEP → DKT → STO/COR/CPAR.

11.18.2 **Transition to roadmap and build packages.** The next Part specifies adoption sequencing, build packages, and delivery milestones required to implement the reference sector library and operationalize the use cases in phased deployments.

11.18.3 **Transition to annexes.** Schemas, APIs, conformance vectors, profile packages, and verification procedures referenced in this Part are defined in the annex set, enabling implementers and examiners to reproduce the walkthroughs and validate interoperability claims.


---

# 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/xi.-sector-profiles.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.