# Annex O #### O.1 Trust scoring objectives and invariants (bounded influence; transparency; auditability) O.1.1 **Purpose.** This Annex specifies the normative requirements for how the Nexus Ontology Fabric (NOF) and NXOSI compute and use trust scores to (i) decide what can trigger obligations, (ii) determine what can be relied upon at each reliance tier, and (iii) resist capture, manipulation, and poisoning—without centralizing sovereignty or forcing evidence exfiltration. O.1.2 **Non-goals.** Trust scoring MUST NOT be used to (i) rank persons for punitive action, (ii) enable surveillance, (iii) replace due process, or (iv) create execution creep into regulated decisions. Trust scores are an *assurance primitive* that conditions triggers, checks, and reliance semantics. O.1.3 **Core invariants (non-negotiable).** Implementations claiming NXOSI compliance MUST enforce: O.1.3.1 **Bounded influence.** No single source, vendor, institution, or participant cohort MAY dominate trust outcomes beyond explicit caps; caps MUST be enforceable in code and testable. O.1.3.2 **Handling-aware computation.** Trust scoring MUST respect handling classes and sovereign zones; Restricted evidence MUST NOT be required to compute a public-safe trust posture, and public trust outputs MUST NOT leak Restricted metadata. O.1.3.3 **Transparency of method, not of sensitive inputs.** The scoring *method* MUST be inspectable (versioned, testable, reproducible), while sensitive inputs MAY remain in-zone and access-controlled. O.1.3.4 **Auditability and replay.** For each trust-relevant output used in triggers/OARs/determinations, the system MUST be able to produce a replayable explanation bundle (in-zone if required), including provenance pointers and the scoring version. O.1.3.5 **Correctionability.** Trust scoring outputs MUST be correctionable: erroneous weights, poisoned sources, or flawed transformations MUST be addressable via correction objects and status semantics; silent changes are prohibited. O.1.3.6 **Uncertainty-first discipline.** Trust outputs MUST carry explicit uncertainty bounds and freshness/decay semantics; downstream triggers MUST declare deterministic decision rules over these bounds. O.1.4 **Where trust scores are permitted to influence NXOSI.** Trust scores MAY condition: O.1.4.1 Trigger eligibility (whether a candidate signal can satisfy a TRG predicate). O.1.4.2 Escalation behavior (auto-attach vs “human review required”). O.1.4.3 Evidence candidate promotion (from observation to grounded assertion). O.1.4.4 Reliance tier ceilings (what reliance a PR/summary can support without controlled evidence access). O.1.4.5 Quarantine decisions (whether assertions are routed to anomaly workflows). O.1.5 **Where trust scores are prohibited to influence NXOSI.** Trust scores MUST NOT: O.1.5.1 Override explicit conformance failures (failed checks remain failures). O.1.5.2 Grant exceptions without governance (waivers require CPAR and authority). O.1.5.3 Suppress dispute rights or shorten challenge windows. O.1.5.4 Be used as the sole basis for punitive determinations; trust outputs are *inputs*, not verdicts. *** #### O.2 Source weighting and reputation bounds (anti-capture controls) O.2.1 **Source classes and minimum typing.** All inputs contributing to grounded assertions MUST be typed into source classes, including at minimum: EO, OSINT, IoT/sensors, enterprise telemetry, operational logs, third-party attestations, human/community reports, and analyst/expert adjudications. O.2.2 **Reputation is bounded and scoped.** Implementations MAY maintain source reputation signals, but MUST enforce: O.2.2.1 **Scope binding.** Reputation MUST be scoped by domain/hazard/context (a source reputable in flood reporting is not automatically reputable for cyber intrusions). O.2.2.2 **Time binding.** Reputation MUST decay and be time-bounded; “past correctness” cannot indefinitely dominate. O.2.2.3 **Cap and floor.** Reputation MUST have explicit caps and floors to prevent both (i) dominance and (ii) irreversible exclusion. O.2.2.4 **Non-transferability.** Reputation MUST NOT transfer across identities or entities without explicit, recorded justification (no implicit “endorsement by association”). O.2.3 **Anti-capture influence bounds.** The system MUST implement and test: O.2.3.1 **Contribution caps** per source, per organization, and per governance seat cohort for any single trust-relevant decision (trigger satisfaction, grounded assertion promotion). O.2.3.2 **Diversity requirements** (e.g., multi-source corroboration classes) for higher reliance tiers, where feasible. O.2.3.3 **Conflict-of-interest constraints**: sources with declared conflicts MAY be downweighted or require independent corroboration; the decision policy MUST be explicit and versioned. O.2.4 **Weight governance.** Weighting policies MUST be: O.2.4.1 Versioned and signed (policy-as-code artifact). O.2.4.2 Subject to safe rollout (simulation/canary/rollback). O.2.4.3 Linked to a status object on change (no silent weight change). O.2.4.4 Testable via conformance vectors (O.6). O.2.5 **Sovereign and sector overlays.** Jurisdiction or sector overlays MAY constrain admissible sources, but MUST do so by explicit overlay bindings and documented precedence rules; overlays MUST NOT redefine base semantics silently. *** #### O.3 Poisoning detection and anomaly quarantine workflows O.3.1 **Threat scope.** Poisoning includes: false signals, manipulated telemetry, coordinated disinformation, adversarial sensor injection, model-induced hallucinated assertions, and malicious participatory submissions. O.3.2 **Detection objectives.** The system MUST detect and respond to: O.3.2.1 **Inconsistency** across sources beyond declared uncertainty bounds. O.3.2.2 **Improbable patterns** (rate anomalies, geographic impossibilities, dependency violations). O.3.2.3 **Sudden reputation swings** (fast reputation inflation, coordinated corroboration). O.3.2.4 **Split-view effects** (different parties receiving different “truth” views due to compromised feeds). O.3.2.5 **Semantic drift anomalies** (assertions that only become “true” under a changed meaning). O.3.3 **Anomaly quarantine (mandatory workflow).** When poisoning risk is detected, the system MUST: O.3.3.1 Mark suspect assertions/events with a quarantine status and restrict their ability to satisfy triggers for higher reliance tiers. O.3.3.2 Route the case to a quarantine docket (DKT) with explicit clocks (review, decision, correction). O.3.3.3 Preserve provenance and transformation manifests without expansion of disclosure (handling must remain enforced). O.3.3.4 Require human-in-the-loop adjudication for defined classes (especially when obligations would attach). O.3.3.5 Produce correction objects if quarantined assertions previously contributed to determinations or proofs. O.3.4 **Containment actions.** Implementations MUST support: O.3.4.1 Source throttling (rate limits) and temporary exclusion (time-bound, reviewable). O.3.4.2 Confidence degradation (bounded, explicit) rather than deletion. O.3.4.3 Compensating corroboration requirements (e.g., raise corroboration threshold). O.3.4.4 Safe rollback of derived products (transformation manifest supersession). O.3.5 **Recovery actions.** After adjudication, the system MUST: O.3.5.1 Either promote, correct, or reject the assertion with explicit status. O.3.5.2 Update reputation signals within bounded ranges. O.3.5.3 Issue a publishable summary where required (public-safe vs controlled), without revealing protected sources. *** #### O.4 Participatory ground truthing trust-weighting model (anti-sybil; protected participation) O.4.1 **Purpose.** Participatory inputs are permitted as *evidence candidates*, not as authoritative truth. This section defines mandatory safeguards to gain coverage benefits without enabling coercion, retaliation, or capture. O.4.2 **Participation classes.** The system MUST support distinct participation classes with different default handling and weighting, such as: O.4.2.1 Public anonymous reports (highest default uncertainty; strong anti-sybil requirements). O.4.2.2 Community-verified reports (e.g., through local institutions) with controlled handling. O.4.2.3 Expert-curated reports (adjudicated, signed determinations as promotion mechanism). O.4.3 **Anti-sybil controls (mandatory).** Implementations MUST include a layered approach that is compatible with sovereignty and minimal disclosure: O.4.3.1 Rate limiting and anomaly-based throttling by network/region/time bucket. O.4.3.2 Proof-of-uniqueness or equivalent mechanisms that do not require revealing identity in public logs. O.4.3.3 Cross-signal corroboration requirements for any participatory inputs to satisfy triggers. O.4.3.4 Reputation caps for participatory cohorts to enforce bounded influence. O.4.4 **Protected participation (do-no-harm).** The system MUST implement: O.4.4.1 Handling defaults that prevent inadvertent exposure of reporters (Restricted by default for sensitive contexts). O.4.4.2 Redaction and safe summarization patterns that remove identifying details. O.4.4.3 Anti-coercion measures: delayed publication, aggregation thresholds, and controlled visibility. O.4.4.4 Anti-retaliation governance hooks: dispute/remedy paths and incident response for participation abuse. O.4.5 **Promotion pipeline (candidate → grounded assertion).** Participatory inputs MUST pass through an explicit pipeline: O.4.5.1 Intake as candidate signal with provenance pointer and uncertainty fields. O.4.5.2 Triangulation with other sources and/or verification checks. O.4.5.3 Adjudication step producing a signed determination (DO/GDO) to promote the assertion to grounded status. O.4.5.4 Explicit traceability from participatory input to grounded assertion, without disclosing protected identity. O.4.6 **Use in triggers.** Triggers MUST declare whether participatory inputs are admissible: O.4.6.1 For informational reliance tiers: may be admissible with high uncertainty and strict limits. O.4.6.2 For operational/audit/supervisory tiers: admissible only after promotion and corroboration, with defined rules. *** #### O.5 Trust score auditability and correction pathways O.5.1 **Trust score object model (mandatory).** Whenever a trust score is used to satisfy a trigger, create an OAR, or support a determination, the system MUST produce a trust score record (TSR) or equivalent that is linkable and replayable. O.5.2 **Minimum TSR fields.** The TSR MUST include: O.5.2.1 Subject (entity/relation/event assertion identifiers). O.5.2.2 Scoring policy version (signed reference). O.5.2.3 Input provenance pointers (summarized or in-zone detailed list, handling-aware). O.5.2.4 Weighting summary (caps applied, diversity constraints satisfied). O.5.2.5 Uncertainty bounds and freshness/decay parameters. O.5.2.6 Decision usage context (which trigger predicate or reliance tier decision consumed it). O.5.2.7 Linkage fields to docket/correction objects when later challenged. O.5.3 **Replay requirements.** For audit-grade reliance tiers, the system MUST support replay: O.5.3.1 Replay MUST produce the same outcome given the same snapshot and policy version. O.5.3.2 If replay cannot be deterministic, the system MUST (i) declare non-determinism explicitly and (ii) restrict permitted reliance tier. O.5.4 **Challenge and dispute rights.** Parties MUST be able to challenge: O.5.4.1 Source inclusion/exclusion decisions (subject to handling and lawful basis). O.5.4.2 Weight policy changes (as governance actions with status objects). O.5.4.3 Quarantine decisions and their impact on obligations. O.5.5 **Correction workflow for trust scoring.** Corrections MUST be handled as first-class: O.5.5.1 A correction object MUST specify: what was wrong, what changes, which artefacts are impacted. O.5.5.2 Status objects MUST be issued when trust scoring changes affect the meaning of prior determinations or triggers. O.5.5.3 Reliance stability rules MUST be applied: where reliance is destabilized, scope narrowing or revocation MUST be explicit. O.5.6 **Publication discipline.** Public-safe summaries MAY disclose: O.5.6.1 That bounded influence and corroboration criteria were satisfied. O.5.6.2 The scoring policy identifier and version. O.5.6.3 High-level uncertainty band (not raw sensitive inputs). O.5.6.4 Status changes affecting reliance (revocation/scope narrowing), without exposing protected sources. *** #### O.6 Trust scoring conformance tests and adversarial vectors O.6.1 **Purpose.** Trust scoring is only credible if it is testable against adversarial conditions. Conformance suites MUST include deterministic vectors, negative tests, and adversarial simulations. O.6.2 **Minimum conformance test categories (mandatory).** O.6.2.1 **Bounded influence tests.** Demonstrate that single-source dominance is capped and cannot exceed policy limits, including coordinated multi-identity attempts. O.6.2.2 **Corroboration threshold tests.** Validate that higher reliance tiers require multi-source corroboration according to policy. O.6.2.3 **Poisoning injection tests.** Inject conflicting signals and confirm quarantine triggers, docket routing, and reliance constraints. O.6.2.4 **Sybil simulations.** Generate high-volume participatory submissions and confirm anti-sybil throttling, bounded cohort influence, and promotion pipeline enforcement. O.6.2.5 **Capture simulations.** Model a high-reputation source turning malicious and confirm decay, anomaly detection, and containment behaviors. O.6.2.6 **Semantic drift tests.** Change ontology meaning versions and verify that trust outputs are invalidated or scope-narrowed appropriately via status objects. O.6.2.7 **Freshness and replay tests.** Confirm decay policies, time binding, and deterministic replay under snapshots. O.6.2.8 **Handling leakage tests.** Confirm that public-safe trust outputs do not leak restricted metadata or identity. O.6.3 **Adversarial vector requirements.** The suite MUST include vectors for: O.6.3.1 Coordinated corroboration attacks (botnets, brigading). O.6.3.2 Slow poisoning (sub-threshold manipulation over time). O.6.3.3 Data source substitution (spoofed feeds, compromised telemetry endpoints). O.6.3.4 Insider manipulation (policy weight changes attempted without governance gates). O.6.3.5 Quarantine evasion (attacks attempting to keep signals just below quarantine thresholds). O.6.4 **Expected test outputs.** Conformance runs MUST output: O.6.4.1 Signed conformance reports (machine-readable + human summary). O.6.4.2 Evidence of cap enforcement (explicit cap application records). O.6.4.3 Quarantine docket creation and lifecycle evidence (DKT + CPAR where applicable). O.6.4.4 Status/correction objects where tests force reliance-impacting changes. O.6.5 **Regression lock.** Plugfests and ecosystem interoperability events MUST include trust scoring regression suites to prevent silent weakening of anti-poisoning controls across releases. --- # 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-o.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.