diff --git a/.github/linters/.markdown-lint.yml b/.github/linters/.markdown-lint.yml
new file mode 100644
index 00000000..947325e8
--- /dev/null
+++ b/.github/linters/.markdown-lint.yml
@@ -0,0 +1,15 @@
+---
+MD004: false
+MD007:
+ indent: 2
+MD013:
+ line_length: 400
+ code_blocks: false
+ tables: false
+ headings: false
+MD026:
+ punctuation: ".,;:!。，；:"
+MD029: false
+MD033: false
+MD036: false
+blank_lines: false
diff --git a/.github/linters/.stylelintrc.json b/.github/linters/.stylelintrc.json
new file mode 100644
index 00000000..e8a79513
--- /dev/null
+++ b/.github/linters/.stylelintrc.json
@@ -0,0 +1,15 @@
+{
+ "extends": "stylelint-config-recommended",
+ "rules": {
+ "at-rule-no-unknown": [
+ true,
+ {
+ "ignoreAtRules": [
+ "tailwind"
+ ]
+ }
+ ],
+ "no-descending-specificity": null,
+ "no-duplicate-selectors": null
+ }
+}
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 145da4b9..b86388dc 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -2,32 +2,41 @@ name: Python CI
on:
push:
- branches: [ "main" ]
+ branches: ["main"]
pull_request:
- branches: [ "main" ]
+ branches: ["main"]
+ workflow_dispatch:
+
+permissions:
+ contents: read
+
+concurrency:
+ group: python-ci-${{ github.workflow }}-${{ github.ref }}
+ cancel-in-progress: true
jobs:
build:
-
runs-on: ubuntu-latest
-
+ timeout-minutes: 15
steps:
- - uses: actions/checkout@v3
- - name: Set up Python 3.10
- uses: actions/setup-python@v3
- with:
- python-version: "3.10"
- - name: Install dependencies
- run: |
- python -m pip install --upgrade pip
- pip install ruff pytest
- if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
- - name: Lint with ruff
- run: |
- # stop the build if there are any ruff issues
- ruff --format=github --select=E9,F63,F7,F82 --target-version=py310 .
- # default set of ruff rules with GitHub Annotations
- ruff --format=github --target-version=py310 .
- - name: Test with pytest
- run: |
- pytest
+ - name: Check out repository
+ uses: actions/checkout@v7
+ - name: Set up Python
+ uses: actions/setup-python@v7
+ with:
+ python-version: "3.10"
+ - name: Report toolchain versions
+ run: |
+ python --version
+ python -m pip --version
+ - name: Install dependencies
+ run: |
+ python -m pip install --upgrade pip
+ python -m pip install ruff pytest
+ if [ -f requirements.txt ]; then python -m pip install -r requirements.txt; fi
+ - name: Critical Ruff checks
+ run: ruff --format=github --select=E9,F63,F7,F82 --target-version=py310 .
+ - name: Full Ruff lint
+ run: ruff --format=github --target-version=py310 .
+ - name: Run pytest
+ run: pytest
diff --git a/.github/workflows/gien-platform-ci.yml b/.github/workflows/gien-platform-ci.yml
new file mode 100644
index 00000000..559b0ab9
--- /dev/null
+++ b/.github/workflows/gien-platform-ci.yml
@@ -0,0 +1,50 @@
+name: GIEN platform CI
+
+on:
+ pull_request:
+ paths:
+ - "gien-platform/**"
+ - ".github/workflows/gien-platform-ci.yml"
+ push:
+ branches:
+ - main
+ - "feat/gien-governance-platform"
+ paths:
+ - "gien-platform/**"
+ - ".github/workflows/gien-platform-ci.yml"
+ workflow_dispatch:
+
+permissions:
+ contents: read
+
+concurrency:
+ group: gien-platform-ci-${{ github.ref }}
+ cancel-in-progress: true
+
+jobs:
+ build:
+ name: Type-check and production build
+ runs-on: ubuntu-latest
+ defaults:
+ run:
+ working-directory: gien-platform
+ steps:
+ - name: Check out repository
+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1; pinned to immutable commit
+ - name: Set up Node.js
+ uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0; pinned to immutable commit
+ with:
+ node-version: "24"
+ package-manager-cache: false
+ - name: Report toolchain versions
+ run: |
+ node --version
+ npm --version
+ - name: Install dependencies
+ run: npm install --no-audit --no-fund
+ - name: Run deterministic evidence regression tests
+ run: npm run test:evidence
+ - name: Build application
+ run: npm run build
+ - name: Smoke-test production preview
+ run: npm run smoke
diff --git a/.github/workflows/governance-docs-lint.yml b/.github/workflows/governance-docs-lint.yml
index ae9f45dd..f603c312 100644
--- a/.github/workflows/governance-docs-lint.yml
+++ b/.github/workflows/governance-docs-lint.yml
@@ -3,25 +3,24 @@ name: Governance Docs Lint
on:
pull_request:
paths:
- - 'docs/**/*.md'
- - '.markdownlint.json'
- - '.markdownlintignore'
- - 'scripts/lint_governance_docs.sh'
- - 'tests/test_lint_governance_docs.sh'
- - 'Makefile'
- - 'tests/test_lint_governance_docs.sh'
- - 'Makefile'
- - '.github/workflows/governance-docs-lint.yml'
+ - "docs/**/*.md"
+ - ".markdownlint.json"
+ - ".markdownlintignore"
+ - "scripts/lint_governance_docs.sh"
+ - "tests/test_lint_governance_docs.sh"
+ - "Makefile"
+ - ".github/workflows/governance-docs-lint.yml"
push:
- branches: [ main ]
+ branches: ["main"]
paths:
- - 'docs/**/*.md'
- - '.markdownlint.json'
- - '.markdownlintignore'
- - 'scripts/lint_governance_docs.sh'
- - 'tests/test_lint_governance_docs.sh'
- - 'Makefile'
- - '.github/workflows/governance-docs-lint.yml'
+ - "docs/**/*.md"
+ - ".markdownlint.json"
+ - ".markdownlintignore"
+ - "scripts/lint_governance_docs.sh"
+ - "tests/test_lint_governance_docs.sh"
+ - "Makefile"
+ - ".github/workflows/governance-docs-lint.yml"
+ workflow_dispatch:
permissions:
contents: read
@@ -35,25 +34,21 @@ jobs:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- - name: Checkout
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-
- - name: Set up Node.js
- uses: actions/setup-node@1d0ff469b7ec7b3cb9d8673fde0c81c44821de2a
+ - name: Check out repository
+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+ - name: Set up Node.js 24
+ uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0
with:
- node-version: '20'
-
+ node-version: "24"
+ package-manager-cache: false
- name: Validate lint script syntax
run: bash -n scripts/lint_governance_docs.sh
-
- name: Validate test script syntax
run: bash -n tests/test_lint_governance_docs.sh
-
- name: Shellcheck lint scripts
uses: ludeeus/action-shellcheck@00cae500b08a931fb5698e11e79bfbd38e612a38
with:
scandir: "scripts tests"
severity: warning
-
- name: Run governance docs check target
run: make governance-docs-check
diff --git a/.markdownlint.json b/.markdownlint.json
deleted file mode 100644
index e55dc9f8..00000000
--- a/.markdownlint.json
+++ /dev/null
@@ -1,3 +0,0 @@
-{
- "default": true
-}
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 161139db..38ff9d19 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -44,7 +44,7 @@ repos:
pass_filenames: false
- id: governance-evidence-checks
name: governance-evidence-checks
- entry: make governance-evidence-manifest && make governance-evidence-verify && make governance-evidence-schema && make governance-report-schema && make governance-check-generated
+ entry: bash scripts/governance-evidence-checks.sh
language: system
pass_filenames: false
- repo: local
diff --git a/GIEN_Daily_Dossier_2026-10-12.md b/GIEN_Daily_Dossier_2026-10-12.md
new file mode 100644
index 00000000..8c90608d
--- /dev/null
+++ b/GIEN_Daily_Dossier_2026-10-12.md
@@ -0,0 +1,154 @@
+# GIEN DAILY DOSSIER — 2026-10-12
+
+---
+
+**Document ID:** GIEN-DOSSIER-2026-285
+**Work Package:** WP-047
+**Date of Attestation:** 2026-10-12
+**Evaluation Window:** 2026-10-11 09:00 UTC → 2026-10-12 09:00 UTC
+**Governance Epoch:** Epoch I (2026–2035); Phase VI-δ (planetary); Phase VII (galactic readiness)
+**System:** GIEN Planetary Governance Mesh — Sentinel AI Governance Stack v2.4 — Omni-Sentinel Governance Mesh v4.0 — Unified Supervisory Control Plane v3.0
+**Applicability:** Global systemically important financial institutions (G-SIFIs); large financial institutions (LFIs); supervisory colleges; treaty secretariats
+**Classification:** TOP SECRET // SUPERVISORY EYES ONLY
+**Merkle Root (Sealed Archive):** `0xb7e4d1a9c5f28306e1c7d4a9b5e2f8c3d6a1b9e4f7c2d5a8b3e6f1c9d4a7b2e5`
+**Artefacts Sealed This Cycle:** 26
+
+> **Fictional simulation notice.** This dossier is a governance-simulation artefact produced for the fictional GIEN planetary governance mesh. All indices, drills, filings, and signatures are simulated data.
+
+---
+
+## SECTION 1 — SUPERVISORY DASHBOARD CHECKLIST
+
+| Control ID | Control Domain | Status | Evidence Ref | Verifier | Notes |
+|---|---|---|---|---|---|
+| GIEN-DSO-2026-285-01 | 01 — Constitutional Invariant Verification (CFE-1.0 / SGR-028) | 🟢 PASS | TLA+ suite rev. 1147 | TLC model checker | 72/72 proofs; 0 violations; Epoch I & II liveness confirmed |
+| GIEN-DSO-2026-285-02 | 02 — Systemic Risk Telemetry & Indices | 🟢 GREEN | STLM-agg-2026-285 | SystemicRiskTelemetry | All core indices inside GREEN bands |
+| GIEN-DSO-2026-285-03 | 03 — Zero-Trust & Attestation (GIEN-ZTAI-02) | 🟡 AMBER | ZTAI-02-CL-0093 | Attestation Coherence Verifier | 97% remediated; closure evidence complete; containment stable |
+| GIEN-DSO-2026-285-04 | 04 — zkML / zk-SNARK/STARK Proof Pipeline | 🟢 PASS | zkML-QR-2026-285 | Intervention Proof Verifier | 95.5% pipeline health (record); p99 latency 7.1 s |
+| GIEN-DSO-2026-285-05 | 05 — PQC WORM / Merkle-DAG Audit Ledger | 🟢 PASS | WORM-LDGR-285 | Ledger Integrity Monitor | FIPS 203/204/205 primitives; ML-DSA-87 + Falcon-1024 + SLH-DSA |
+| GIEN-DSO-2026-285-06 | 06 — OSCAL 1.1.2 / OPA-Rego Compliance-as-Code | 🟢 PASS | OSCAL-VAL-2026-285 | OPA policy engine | 16/16 regimes PASS; Δ_OSCAL +1 |
+| GIEN-DSO-2026-285-07 | 07 — Supervisory Digital Twin (Panels 13–15) | 🟢 PASS | SDT-RB-2026-285-13/14/15 | Replay Determinism Checker | Deterministic Replay Bundles sealed |
+| GIEN-DSO-2026-285-08 | 08 — Kubernetes / GitOps Zero-Trust Deployment | 🟢 PASS | GITOPS-SYNC-285 | Cluster Drift Monitor | 147 clusters; zero configuration drift |
+| GIEN-DSO-2026-285-09 | 09 — Autonomous Supervisory Agent Containment | 🟢 PASS | ASA-HB-2026-285 | Containment Heartbeat Verifier | All agents within drift envelope |
+| GIEN-DSO-2026-285-10 | 10 — Compute Governance & Kill-Switch Coherence | 🟢 PASS | CGOV-BASE-285 | Allocation Regime Monitor | BASELINE regime; ELEVATED not invoked this window |
+
+---
+
+## SECTION 2 — UNIFIED CORPUS INDEX TRACEABILITY
+
+| Index | Value | 24h Δ | Band | Notes |
+|---|---|---|---|---|
+| S_sys | 0.198 | −0.002 | 🟢 GREEN | Composite stability improving |
+| G-SRI | 28.6 | −0.3 | 🟢 GREEN | Lowest since dossier 210 (29.60) |
+| C-SRI | 30.0 | −0.2 | 🟢 GREEN | Compliance-side risk stable |
+| G-SRI-VII | 28.9 | −0.2 | 🟢 GREEN | Phase VII galactic readiness band |
+| A-SRI | 24.4 | −0.1 | 🟢 GREEN | Alignment-side risk |
+| P-SRI | 26.5 | +0.1 | 🟢 GREEN | Planetary propagation risk |
+| CGR-I | 73.2 | +0.4 | 🟢 GREEN | Constitutional-grade readiness improving |
+| CCR-I | 68.6 | +0.3 | 🟢 GREEN | Cryptographic governance readiness |
+| p(doom) | 0.30% | −0.01 pp | 🟢 GREEN | Ensemble estimate |
+| p(doom)_kernel | 0.29% | −0.01 pp | 🟢 GREEN | Kernel density estimate |
+| Δ_drift | +0.2σ | −0.1σ | 🟢 GREEN | Within ±1σ envelope |
+| Δ_OSCAL | +1 | 0 | 🟢 GREEN | Net control additions |
+| Mean quote age | 29 min | −2 min | 🟢 GREEN | Ledger quote freshness |
+
+---
+
+## SECTION 3 — CONTROL DOMAIN STATUS & PERTURBATION LIBRARY
+
+**Domain 03 — GIEN-ZTAI-02 Remediation (sole AMBER):**
+- Remediation at 97%; final sweep scheduled 2026-10-13; closure ETA 2026-10-14.
+- Closure evidence bundle complete and pre-staged for SGR-030 counter-verification.
+- Ahead of Protocol SGR-030 window close on 2026-10-15.
+
+**Perturbations registered this cycle:**
+- P-285-α: ZTAI-02 residual-node attestation edge case (contained; tracked to closure sweep).
+- P-285-β: zkML Stage B proving queue depth spike (auto-scaled; no deadline breach).
+- P-285-γ: Minor MoE routing flap on expert shard E-17 (rebalanced in 41 s; StaR-MoE stability held).
+
+---
+
+## SECTION 4 — SCENARIO EXECUTION TABLE (SDT STRESS-TESTS)
+
+| Drill ID | Scenario | Panel | Result | Notes |
+|---|---|---|---|---|
+| DRILL-047 | Black-Unicorn-7 (supervisory failover under systemic stress) | 13–15 | ✓ CONTAINED | Execution replay determinism confirmed; escalation auto-reverted at EL-3 |
+| DRILL-048 | Ashen-Lantern (multi-region attestation failover under ELEVATED load with zk degradation injection) | 13–15 | ⏳ FROZEN | Choreography frozen for execution 2026-10-13 |
+| REPLAY-RB-285 | Deterministic replay of Panels 13–15 archive | 13–15 | ✓ BIT-IDENTICAL | Zero divergence across replay bundles |
+
+---
+
+## SECTION 5 — SDT REPLAYS (PANEL 15 EXCERPT)
+
+Panel 15 replay of DRILL-047 (Black-Unicorn-7) confirmed containment in 14 m 22 s with escalation authority correctly auto-reverting at EL-3 after supervisory override signature verification. zkML degradation injection during DRILL-048 pre-rehearsal showed proof pipeline graceful-degrade thresholds holding at 95.5% health with no fairness regression (Disparate Impact Ratio 0.851; ≥ 0.800 threshold maintained).
+
+---
+
+## SECTION 6 — CRYPTOGRAPHIC & LEDGER INTEGRITY
+
+- **PQC signature stack:** ML-DSA-87 (primary, FIPS 204), Falcon-1024 (FIPS 206 draft alignment, review at 94%), SLH-DSA / SPHINCS+ (hash-based fallback, FIPS 205).
+- **Falcon-1024 independent review:** 94% (up from 91% at dossier 284).
+- **vkFMv3 key rotation:** 100% complete across all verifiers; vkFMv2 fully retired from active verification paths.
+- **WORM / Merkle-DAG ledger:** 26 artefacts sealed; Merkle root `0xb7e4d1a9c5f28306e1c7d4a9b5e2f8c3d6a1b9e4f7c2d5a8b3e6f1c9d4a7b2e5`; PQC continuity verified across all 52 RTEE nodes.
+- **TEE/TPM/vTPM attestation:** 52/52 nodes coherent; attestation density 96.5%.
+- **zkML pipeline:** 95.5% health (record); p99 proving latency 7.1 s; zk-STARK Stage B migration at 78% (80% gate); SnarkPack batching active.
+
+---
+
+## SECTION 7 — REGULATORY ALIGNMENT ANNEXES (OSCAL 1.1.2 / OPA-REGO)
+
+| # | Regime | Result | # | Regime | Result |
+|---|---|---|---|---|---|
+| 1 | EU AI Act (Annex IV; Arts. 51/35/15/17/22) | 🟢 PASS | 9 | FCA SMCR & Consumer Duty | 🟢 PASS |
+| 2 | NIST AI RMF 1.0 / AI 600-1 (GenAI profile) | 🟢 PASS | 10 | HKMA Fintech 2030 AI² | 🟢 PASS |
+| 3 | ISO/IEC 42001 (AIMS) | 🟢 PASS | 11 | SEC Rule 17a-4 | 🟢 PASS |
+| 4 | Basel III/IV | 🟢 PASS | 12 | FCRA/ECOA (fair lending) | 🟢 PASS |
+| 5 | SR 11-7 (model risk) | 🟢 PASS | 13 | ICGC/GASO | 🟢 PASS |
+| 6 | SR 26-2 (scenario design) | 🟢 PASS | 14 | Interstellar AI Governance Accord | 🟢 PASS |
+| 7 | DORA | 🟢 PASS | 15 | Galactic Treaty Framework | 🟢 PASS |
+| 8 | NIS2 | 🟢 PASS | 16 | GDPR (Arts. 22/35, DPIA) | 🟢 PASS |
+
+**OSCAL 1.1.2 SSP and assessment-results JSON: validated.** Δ_OSCAL = +1 (one net control addition under EU AI Act Art. 17 mapping).
+
+---
+
+## SECTION 8 — TREATY-GRADE CONSTITUTIONAL VERIFICATION
+
+- TLA+ specification suite (rev. 1147) verified **72/72 invariants** under CFE-1.0 and Protocol SGR-028 with zero violations for both governance epochs (2026–2035 and 2035–2100+).
+- Transcript Registry: 418 sealed transcripts this epoch; Intervention Proof Verifier smart contracts: no unexplained interventions.
+- Zero-knowledge voting: round N-33 sealed; no coercion patterns detected.
+- SGR-031 (next supervisory college filing) at 41% preparation.
+- Protocol SGR-030 Guardian Attestation window: on track, closes 2026-10-15.
+
+---
+
+## SECTION 9 — SUBMISSION READINESS CERTIFICATE
+
+| Field | Value |
+|---|---|
+| Dossier ID | GIEN-DOSSIER-2026-285 |
+| Work Package | WP-047 |
+| Archive Seal | `0xb7e4d1a9c5f28306e1c7d4a9b5e2f8c3d6a1b9e4f7c2d5a8b3e6f1c9d4a7b2e5` |
+| Signature (ML-DSA-87) | `0x4e9f2c8a1d6b3f7e5c0a9d2e8b4f1a6c3d7e9b2f5a8c1d4e6b9f3a2c5d8e1b4f` |
+| Signature (Falcon-1024) | `0x8c1d4e6b9f3a2c5d8e1b4f7a0c3d6e9b2f5a8c1d4e6b9f3a2c5d8e1b4f7a0c3d6` |
+| Signature (SLH-DSA) | `0xa3f6c9d2e5b8f1a4c7d0e3b6f9a2c5d8e1b4f7a0c3d6e9b2f5a8c1d4e6b9f3a2` |
+| Cycle Closure | 23:59 UTC 2026-10-12 (scheduled) |
+| Status | READY FOR SUPERVISORY COLLEGE TRANSMISSION |
+
+---
+
+## SECTION 10 — TRANSMITTAL & SEALED DOSSIER STATUS
+
+**Transmission Package Manifest (26 artefacts):** Executive Summary; Annotated Compliance Matrix (16 regimes); Redacted Stakeholder Version; Supervisory Corpus Manifest; SDT Replay Bundles (Panels 13–15); TLA+ proof transcripts (72); zkML fairness attestations; PQC ledger continuity proofs; TEE attestation coherence report (52/52); ZTAI-02 closure evidence bundle (pre-staged); Drive exports (docx + pdf pair); Notion closing summary.
+
+**External exports this cycle:**
+- Google Drive dossier export (docx + pdf pair) — filed under the daily dossier folder.
+- Notion closing summary — filed under Genspark Integration workspace page.
+
+**GitHub delivery:** This dossier is delivered to the OneFineStarstuff.github.io repository as work package WP-047 via pull request from `genspark_ai_developer` into `main`.
+
+**Next dossier:** GIEN-DOSSIER-2026-286 (Tuesday 2026-10-13; DRILL-048 Ashen-Lantern execution day; ZTAI-02 closure sweep day).
+
+---
+
+*This document is a fictional governance-simulation artefact for the GIEN planetary governance mesh. All indices, drills, filings, signatures, and Merkle roots are simulated data and do not describe real systems.*
diff --git a/gien-platform/README.md b/gien-platform/README.md
new file mode 100644
index 00000000..829fece1
--- /dev/null
+++ b/gien-platform/README.md
@@ -0,0 +1,93 @@
+# GIEN Governance Platform
+
+A React 18 + TypeScript + Vite prototype for the fictional GIEN planetary / multiversal governance mesh. The app is isolated in \`gien-platform/\` so the repository's existing root site is not replaced.
+
+## Run locally
+
+~~~bash
+cd gien-platform
+npm install
+npm run dev
+~~~
+
+## Production build
+
+~~~bash
+npm run test:evidence
+npm run build
+npm run smoke
+npm run preview
+~~~
+
+## Included workspaces
+
+- \`/dashboard\` — daily supervisory brief, operational accordion, transmission checklist and filing metadata.
+- \`/risk-indices\` — 12 thresholded demo indicators, SVG sparklines / radar / node graph, risk filters, agent inventory and detail drawer.
+- \`/compliance\` — 20-framework simulated control matrix, domain / framework / status / risk filters, gap toggles, cell detail drawer, Rego sample and JSON export.
+- \`/governance-stacks\` — Sentinel v2.4, Omni-Sentinel v4.0, SCP v3.0, mesh sketch, cycle timeline, compute-mode toggle and domain drill-down.
+- \`/control-domains\` — searchable CD-01 through CD-10 catalogue and detail drawers.
+- \`/cryptographic-integrity\` — illustrative PQC ledger, algorithm inventory, zkML / proof pipeline, TEE / TPM attestation and paginated audit samples.
+- \`/digital-twin\` — selectable panels 13–15, stress assumptions, sample replay results and drill register.
+- \`/scenario-planner\` — six scenario types, configurable inputs, stateful local runs, scenario history and text report export.
+- \`/constitutional\` — 24 fictional invariants, TLA+ teaching snippets, treaty catalogue and epoch timeline.
+- `/evidence-validation` — source-to-claim queue, structural source checks, freshness gating, manual reviewer attestations, findings, and JSON evidence export.
+- \`/submission-packages\` — multi-step package setup, section selection, preview, JSON export, print styling and simulated transmission / archive dialogs.
+- \`/long-horizon\` — Phase VI-δ through XIII, Ω-GAR, beacon planning, codex prerequisites, EPITAPH / INVOCATION documents and Infinity Pillars.
+
+## Architecture
+
+- React 18, TypeScript, React Router, Tailwind CSS, Lucide React and Vite.
+- Shared \`GovernanceContext\` carries role selection, phase, evaluation window and illustrative alert count.
+- Reusable components include status badges, metric cards, expandable sections, drawers, progress bars, SVG sparklines, radar charts, node graphs, timelines, code blocks and tagged documents.
+- No external APIs are called. All scenario calculations, values, timestamps and hash strings are local simulation fixtures.
+
+## Supervisory and technical documentation
+
+The following files are normative design references for this prototype, not evidence of a deployed supervisory service:
+
+- [Daily Supervisory Dossier — 12 October 2026](docs/daily-supervisory-dossier-2026-10-12.md): evidence-qualified daily report, control domains, risk indices, Panels 13–15, submission/sealing requirements, and Phase XI/XII forward view.
+- [Technical Architecture and 2026–2035 Roadmap](docs/technical-architecture-roadmap-2026-2035.md): zero-trust boundaries, TEE attestation, PQC/WORM, zkML pipeline, StaR-MoE controls, TLA+ invariants and DevSecOps release gates.
+- [Regulatory Crosswalk and OSCAL 1.1.2 Assessment Design](docs/regulatory-crosswalk-oscal-opa.md): 25-framework mapping starter, applicability/status semantics, control evidence model, OSCAL structure and OPA/Rego example.
+- [Phase XI–XII and Ω-GAR Forward Dossier](docs/phase-xi-xii-omega-gar-forward-dossier.md): future-phase governance, Eternal Corpus, independent beacon design, cryptographic lineage, invariant controls and successor-epoch gates.
+- [Enterprise AI Safety and Governance Roadmap, 2026–2100+](docs/enterprise-ai-safety-and-governance-roadmap-2026-2100.md): enterprise RAG safety, alignment and adversarial evaluation, attestation and cryptographic evidence controls, Phase XV pause/fabrication prohibition, Guardian milestone evidence gates, OpenAI Platform integration
+ considerations, and long-horizon
+ succession architecture.
+- [Supervisory Briefing Platform Reference Architecture, 2026–2100+](docs/supervisory-briefing-platform-reference-architecture-2026-2100.md): daily report cadence, risk indicator contracts, GIEN controls, attestation and PQC evidence, RAG/AGI safety, IASOS API, OSCAL/OPA mappings, DRILL-042–047, Guardian readiness, UX modules, release gates and
+ Phase XV pause.
+- [GIEN Governance Research Plan and Supervisory Reference Architecture — October 2026](docs/governance-research-plan-and-reference-architecture-2026-10.md): official regulatory/standards register, audience and framework recommendation, React/Vite decision, reference architecture, RAG/CCaaS safety, telemetry contracts, OSCAL/OPA, PQC evidence,
+ APIs, accessible visualizations
+ and implementation roadmap.
+- [OpenAI Platform Integration Research — October 2026](docs/openai-platform-integration-research-2026-10.md): Responses API, Structured Outputs, tool calling/MCP, server-side TypeScript architecture, secrets and GitHub Actions workload identity federation, data-retention boundaries, human approval, evals lifecycle, and phased release acceptance
+ criteria.
+
+## Evidence and deployment boundaries
+
+ **This application is a prototype, not a certified supervisory system.** Demonstration values are not live telemetry, empirically calibrated risk estimates, legal determinations, compliance findings, regulatory approvals, or independent assurance. Displayed hashes are fabricated strings, PQC signatures are not generated or verified, and
+attestation / OSCAL / TLA+ verification
+has not been executed.
+
+The package export is an untrusted demo artefact. The “simulate transmission” and “simulate archive” controls only explain hypothetical protocol steps; they do not contact endpoints or write to immutable storage. Browser print is provided for a print / PDF workflow, and the JSON export is machine-readable demonstration data.
+
+Before operational use, connect authenticated authoritative data sources, define data provenance and freshness, implement schema validation and cryptographic verification, enforce server-side authorization, add independent testing, and document applicable legal and supervisory review. Never ship credentials or private keys in client-side code.
+
+## CI
+
+ The GitHub Actions workflow `.github/workflows/gien-platform-ci.yml` runs on Node.js 24, installs dependencies, runs the deterministic no-network evidence regression suite, performs the TypeScript/Vite production build, and smoke-tests the production preview. The smoke test checks built JavaScript/CSS assets, expected application markers, and SPA
+route fallback including
+`/evidence-validation`. A passing job must be observed in Actions; workflow configuration alone is not proof of runtime correctness.
+
+
+## Additional integration research
+
+- [Multi-Platform Integration Research (October 2026)](docs/multi-platform-integration-research-2026-10.md) — provider capabilities, API/partner gates, trust boundaries, phased rollout, and acceptance criteria.
+
+
+- [GIEN Master Deep Research: AI Governance, Safety, and Systemic Risk — October 2026](docs/master-deep-research-ai-governance-systemic-risk-2026-10.md) — current safety research, regulatory status, financial systemic risk, CD-01–CD-10 mapping, evidence integrity, metric validation and phased rollout.
+- [Thinking and Deep Research Governance — October 2026](docs/thinking-and-deep-research-governance-2026-10.md) — reasoning versus deep-research workflows, model lifecycle, source-to-claim evidence, tool/data controls, evaluation framework and release gates. The 12 October refresh documents the older Deep Research model-ID shutdown notice, the
+ Evals platform's published 31
+ October read-only / 30 November shutdown dates, MCP approvals, citation validation, and NIST critical-infrastructure concept-note status.
+- [Deep Multi-Platform Integration Research (October 2026)](docs/deep-integration-research-2026-10.md) — control-plane architecture and provider-specific security, event handling, evidence provenance, acceptance criteria, and rollout plan.
+- [Focused GitHub Integration Research (October 2026)](docs/GitHub-integration-research-2026-10.md) — GitHub App permissions, Actions hardening, OIDC, evidence provenance, and acceptance criteria.
+- [OpenAI Evals Migration Inventory and Cutover Plan — 12 October 2026](docs/openai-evals-migration-inventory-2026-10-12.md) — export register, owner assignments, the 31 October read-only and 30 November 2026 shutdown milestones, Promptfoo parity checks, and explicit inventory status boundaries.
+- [Structured Evals Migration Inventory Template](data/openai-evals-migration-inventory.template.json) — fillable machine-readable inventory; the record template defaults to NOT_INVENTORIED; instantiate one record per category from verified evidence.
+- [Source-to-Claim Validation Workspace](src/pages/EvidenceValidationPage.tsx) and [deterministic validator](src/evidence/claim-validation.mjs) — prototype UI, evidence contract, manual-review gate, and regression tests in `scripts/claim-validation.test.mjs`.
diff --git a/gien-platform/data/openai-evals-migration-inventory.template.json b/gien-platform/data/openai-evals-migration-inventory.template.json
new file mode 100644
index 00000000..948ffa9f
--- /dev/null
+++ b/gien-platform/data/openai-evals-migration-inventory.template.json
@@ -0,0 +1,64 @@
+{
+ "schemaVersion": "gien.openai-evals-migration-inventory.v1",
+ "inventoryDate": "2026-10-12",
+ "inventoryState": "NOT_INVENTORIED",
+ "owner": "",
+ "backupOwner": "",
+ "vendorMilestones": {
+ "readOnlyDate": "2026-10-31",
+ "scheduledShutdownDate": "2026-11-30",
+ "status": "VERIFY_AGAINST_OFFICIAL_VENDOR_NOTICE"
+ },
+ "requiredCategories": [
+ {
+ "inventoryItemId": "EVAL-DEFINITIONS",
+ "category": "eval_definitions"
+ },
+ {
+ "inventoryItemId": "DATASETS-AND-EVAL-ITEMS",
+ "category": "datasets_and_eval_items"
+ },
+ {
+ "inventoryItemId": "GRADERS-AND-RUBRICS",
+ "category": "graders_and_rubrics"
+ },
+ {
+ "inventoryItemId": "RUNS-AND-RESULTS",
+ "category": "runs_and_results"
+ },
+ {
+ "inventoryItemId": "PROMPTS-AND-PROMPT-OBJECTS",
+ "category": "prompts_and_prompt_objects"
+ },
+ {
+ "inventoryItemId": "TRACES-AND-MEDIA",
+ "category": "traces_and_media"
+ },
+ {
+ "inventoryItemId": "AUTOMATION-DEPENDENCIES",
+ "category": "automation_dependencies"
+ }
+ ],
+ "recordTemplate": {
+ "inventoryItemId": "",
+ "category": "",
+ "status": "NOT_INVENTORIED",
+ "owner": "",
+ "sourceObjectCount": null,
+ "exportedObjectCount": null,
+ "exportPaths": [],
+ "sha256ManifestPath": "",
+ "exportVerified": false,
+ "migrationTarget": "",
+ "parityTestId": "",
+ "knownGaps": [],
+ "reviewer": "",
+ "reviewedAt": ""
+ },
+ "notes": [
+ "Template only: no live OpenAI organization, Evals workspace, API inventory, or export was inspected.",
+ "Do not store secret values in this file; store only approved secret-manager references.",
+ "Object counts, hashes, exportVerified and parity results must be filled from actual evidence.",
+ "Instantiate one recordTemplate per requiredCategories entry after inventory discovery. Keep status NOT_INVENTORIED until the scoped search and evidence are recorded."
+ ]
+}
diff --git a/gien-platform/docs/daily-supervisory-dossier-2026-10-12.md b/gien-platform/docs/daily-supervisory-dossier-2026-10-12.md
new file mode 100644
index 00000000..b9101bc1
--- /dev/null
+++ b/gien-platform/docs/daily-supervisory-dossier-2026-10-12.md
@@ -0,0 +1,493 @@
+# GIEN Daily Supervisory Dossier — 12 October 2026
+
+> **Document class:** Fictional GIEN supervisory reference dossier; implementation and evidence specification
+> **Requested reporting window:** 2026-10-11T09:00:00Z to 2026-10-12T09:00:00Z
+> **Current evidence state:** TEMPLATE / EVIDENCE-PENDING. No authenticated production telemetry, signed evaluation bundle, or independent assurance report was supplied.
+> **Systems:** Sentinel AI Governance Stack v2.4; Omni-Sentinel Governance Mesh v4.0; Unified Supervisory Control Plane (SCP) v3.0.
+
+## Daily Supervisory Governance and Systemic-Risk Brief
+
+##
+ This dossier specifies a regulator-oriented daily control-room record for the fictional GIEN Phase VI-δ planetary governance mesh. It combines executive posture, systemic-risk telemetry, OSCAL assessment evidence, control-domain results, zero-trust and confidential-computing attestations, post-quantum audit records, zkML proof pipeline evidence,
+Digital Twin Panels 13–15,
+remediation, and submission sealing. It also defines a 2026–2035 delivery roadmap and forward dependency records for Phase XI, Phase XII, Phase XIII, and Ω-GAR.
+
+No live operational status is certified. Without authenticated sources, signed manifests, reproducible tests, and independent review, status fields must remain NOT VERIFIED, EVIDENCE-PENDING, or SIMULATED. Values and hashes displayed by the prototype are fictional interface fixtures, not measured telemetry.
+
+
+## 1. Primary audience and deliverable contract
+
+### Primary use case
+Provide a consistent, traceable daily report for governance oversight of fictional AI-enabled systems used by G-SIFIs and large financial institutions. All four audience views must derive from one versioned evidence set.
+
+| Audience | Decision supported | Default view | Required drill-down |
+|---|---|---|---|
+| Regulator / supervisory authority | Evidence sufficiency, supervisory gaps, notification and follow-up | Compliance, incidents, findings, submission manifest | Control IDs, applicability, artefacts, signatures, exceptions and ownership |
+| Institution / governance engineer | Remediation and safe operation | Telemetry freshness, OSCAL/OPA results, CI/CD gates, TEE/PQC/zkML status | Policy versions, build digests, logs, attestation quotes and verifier output |
+| Executive leadership | Risk acceptance, resourcing, escalation, launch/rollback posture | Material risks, unresolved severe findings, remediation and resilience | Accountable executive, due date, residual risk, independent challenge |
+| Educational / research stakeholder | Understand the model and limitations | Annotated governance concepts and simulated scenarios | Fictional invariants, assumptions, methods and public-framework traceability |
+
+### Mandatory formats
+1. Human-readable daily brief displaying styled XML-like section headers: , <abstract>, and <content>.
+2. OSCAL 1.1.2-compatible packages for the profile required by the consuming institution, with schema/profile validation outputs and a controlled upgrade plan.
+3. Machine-readable control matrix and assessment-results export in JSON/CSV.
+4. Signed artefact manifest containing digest, signer, algorithm, key ID, timestamp source, source system, retention class, and independent verification result.
+5. Deterministic replay package for Panels 13–15 including scenario config, random seed (if relevant), simulator/build digest, input hashes, outputs, tolerances, limitations and reviewer sign-off.
+6. Regulator submission package with scope, exclusions, evidence inventory, gap log, redaction log, management attestation, actual delivery receipt, and archive receipt where services are configured.
+7. Executive one-page brief plus detailed engineering annex, both generated from the same versioned evidence.
+
+### Provenance rules
+- Use ISO 8601 UTC for all timestamps. Each event must carry observed time, ingestion time, source system, source version, and freshness SLA.
+- Distinguish MEASURED, SIMULATED, DERIVED, ESTIMATED, and NOT AVAILABLE. Simulated fixtures must not look identical to verified measurement in text, color, export, or accessibility metadata.
+- Never publish an aggregate compliance percentage without scope, applicability rules, denominator, weights, evidence coverage, and scoring version.
+- Separate measured facts, model estimates, management assertions, test outcomes and legal interpretation.
+- A hash binds bytes to a digest; it does not prove truth, completeness, signer authority, legal admissibility, or control effectiveness.
+
+## <content>2. Daily operational status — evidence-gated report</content>
+
+### Evaluation window
+The requested interval is 2026-10-11T09:00:00Z–2026-10-12T09:00:00Z. It is a target reporting window, not evidence that evaluation and closure actually occurred.
+
+| Indicator | Report fields | Status without source artefacts | Evidence needed to upgrade |
+|---|---|---|---|
+| Overall posture | NOMINAL / ELEVATED / CRITICAL / SAFEGUARD | **EVIDENCE-PENDING** | Signed telemetry manifest, incident feed, versioned threshold policy and review record |
+| Overall control effectiveness | Score, denominator, coverage | **NOT ASSERTED** | Approved scoring model, applicable control inventory, coverage and independent challenge |
+| Vulnerabilities | Counts by severity/age, affected assets | **NOT VERIFIED** | Current scanner/SBOM output, deduplication, exceptions, deployment commits and retests |
+| PQC ledger | INTACT / DEGRADED / COMPROMISED | **NOT VERIFIED** | Chain/DAG validation, signatures, key state, retention lock and independent verification |
+| Constitutional invariants | VERIFIED / UNVERIFIED / VIOLATED by invariant | **NOT VERIFIED** | Versioned spec, model checker run, inputs, counterexamples and reviewer sign-off |
+| OSCAL | Schema/profile and package validation results | **NOT RUN** | Validator version, package digests, schema/profile version and logs |
+| TEE attestation | Valid/stale/failed node counts | **NOT VERIFIED** | Fresh nonce-bound quotes, trust chain, revocation status and measurement policy |
+| zkML pipeline | Proofs generated/verified/rejected/timeouts | **NOT VERIFIED** | Prover/verifier versions, program/circuit digest, public inputs, keys and verifier logs |
+| Digital Twin 13–15 | Replay and determinism status | **NOT VERIFIED** | Immutable inputs, pinned simulator, seed, repeated outputs and tolerance report |
+| Supervisory College transmission | Sent/received/receipt validated | **NOT SENT / NO ENDPOINT CONFIGURED** | Authorised endpoint, authenticated receipt, signature verification and archive receipt |
+
+### Scheduled supervisory checkpoints
+These are intended schedule entries, not completed-event claims.
+
+| UTC time | Expected event | Minimum evidence |
+|---|---|---|
+| 08:00 | Archive transmission and college receipt | Package ID, sender identity, payload digest, receipt ID |
+| 08:15 | Merkle root and PQC signature validation | Trusted verifier output, key ID, signed root, verification timestamp |
+| 08:30 | Cross-jurisdictional bundle derivation | Mapping version, applicability decisions, bundle digest, exception list |
+| Ongoing | SLA exception handling | Trigger, incident ID, accountable owner, containment/rollback and time accounting |
+| 23:59 | Cycle closure and archive seal | Reconciliation, approver, retention-lock evidence and unresolved-exception disposition |
+
+A missed, delayed, or unverified checkpoint becomes an exception. Do not backfill a green marker without preserving the original event time and explaining lateness.
+
+### Required stack-level fields
+- **Sentinel v2.4:** component inventory, installed version/build provenance, heartbeat/freshness, model registry revision, drift method, intervention status, kill-switch test, and known limitations.
+- **Omni-Sentinel v4.0:** total/healthy/degraded/unreachable nodes, authenticated membership, consensus, clock skew, stale-message rate, anomaly backlog, and region failure boundaries.
+- **SCP v3.0:** cycle state, queue depth, SLA exceptions, archive status, policy bundle version, entitlement changes, manual overrides, and evidence-collection failures.
+- **GIEN-ZTAI-02:** affected assets, vulnerability identifiers where applicable, exploitability, compensating controls, fix commit/deployment, retest, owner, and approved closure evidence. Do not invent a closure date.
+- **StaR-MoE routing:** routing entropy, expert utilization/load balance, fallback frequency, abstention rate, model/configuration digest, and validation method. A heatmap alone is not model validation.
+
+## <content>3. Systemic-risk telemetry and escalation</content>
+
+Thresholds below are fictional GIEN supervisory triggers, not statutory limits or calibrated estimates. Values fall in [0,1] unless otherwise specified. Every metric definition must fix population, numerator/denominator, normalization, weights, time window, missing-data policy, uncertainty, owner, and method version.
+
+| Metric | Working interpretation | Fictional nominal target |
+|---|---|---:|
+| S_sys | Composite systemic-risk indicator | < 0.35 |
+| G-SRI | Global systemic-risk index | < 0.40 |
+| C-SRI | Contagion systemic-risk indicator | < 0.30 |
+| CGR-I | Constitutional governance risk | < 0.25 |
+| CCR-I | Cross-chain coherence risk | < 0.20 |
+| G-SRI-VII | Phase VII transition risk | < 0.50 |
+| A-SRI | Autonomous-agent risk | < 0.45 |
+| P-SRI | Post-quantum migration risk | < 0.15 |
+| p(doom) | Fictional aggregate existential-risk indicator | < 0.001 |
+| p(doom)_kernel | Fictional kernel-level indicator | < 0.0001 |
+| Δ_drift | Change in approved drift metric | < 0.05 |
+| Δ_OSCAL | Difference in approved OSCAL assessment state | < 0.02 |
+
+### Rules
+1. Keep raw component series as well as aggregates.
+2. Stale critical inputs, failed integrity checks, broken provenance or unknown denominators force status UNVERIFIED even if a number is below threshold.
+3. Threshold crossing triggers assessment and escalation under approved policy; it does not automatically prove a legal breach.
+4. An elevated/critical record includes ticket, owner, containment decision, next review time and residual-risk approval.
+5. Methodology or input changes create a new metric version and a comparable old/new record.
+6. p(doom) and p(doom)_kernel remain fictional indicators. Do not call them empirically calibrated probability estimates without a defensible model, relevant base rates, uncertainty bounds and independent validation.
+
+### Autonomous Supervisory Agent inventory
+Record agent ID, role, authority ceiling, model/config digest, drift score and method, containment state, last nonce-bound attestation, interventions in the window, linked incidents and human approvals. Missing attestation means UNKNOWN, not healthy.
+
+## <content>4. Technical architecture and integrity evidence</content>
+
+### Zero-trust and confidential computing
+ Enforce workload identity, least privilege, short-lived credentials, signed deployments, network segmentation, controlled egress, auditable policy decisions, and break-glass approvals. For Intel TDX, AMD SEV-SNP, TPM/vTPM and RTEE-labelled systems, retain platform/firmware identity, verifier policy, quote nonce, PCRs where applicable, trust chain,
+revocation status, image
+digest, freshness and mismatch remediation. Attestation supports a claim about a measured platform state; it does not prove application correctness or absence of compromise.
+
+Use HSM-backed keys separated by purpose and environment. Record purpose, owner, key ID, algorithm, activation/retirement, rotation, revocation, recovery, and dual-control events. Never place private keys or production secrets in browser code or documentation.
+
+### Post-quantum WORM/Merkle ledger
+ Use canonical serialization, per-record digest, batch manifest, Merkle/DAG root, signature envelope, signer identity, trusted time source, retention class and verification instructions. For object-lock retention, test that application roles and routine administrators cannot bypass the lock, and separate storage administration from writing/signing
+permissions.
+
+Correct algorithm labels:
+- **ML-KEM / FIPS 203:** key encapsulation, not a signature.
+- **ML-DSA / FIPS 204:** digital signatures standardized from CRYSTALS-Dilithium.
+- **SLH-DSA / FIPS 205:** stateless hash-based signatures standardized from SPHINCS+.
+- **Falcon / FN-DSA:** identify as a candidate/transition path until final standard status and deployed implementation are verified. Do not label it “FIPS 206 ACTIVE” without authoritative confirmation.
+- Plan crypto-agility and hybrid transition for legacy RSA/ECC, retaining algorithms, parameter sets, key/certificate IDs, implementation version and migration approval.
+
+A Merkle root alone does not establish retention, source truth, signer authority, or regulator delivery. Keep a separately signed validation record and independently replicated or timestamped evidence for material submissions.
+
+### zkML and zero-knowledge controls
+A proof can support that a specified computation satisfies a statement over declared public inputs and committed private inputs under stated circuit/proof assumptions. It does not by itself prove input truth, legal completeness, model fairness, or safety.
+
+Each bundle records model/program digest; circuit/constraint digest; compiler/prover/verifier versions; proof system; public inputs; commitment scheme; verification key ID and digest; proof digest; generation/verification time and resource use; rejected/timed-out status; trusted setup if used; and circuit review status.
+
+ Circom/Groth16 is a possible prototype path only with documented trusted-setup governance and circuit audit. Compare transparent systems such as zk-STARKs against proof size, latency, verifier cost, maturity and disclosure requirements. Never imply that a proof itself establishes Basel adequacy, SR 26-2 compliance or GDPR compliance; the proof can
+support one bounded
+calculation in a broader assurance case.
+
+### OSCAL 1.1.2 and OPA/Rego
+ For each mapped control retain the authoritative source/provision and jurisdiction, applicability decision, GIEN domain/control ID, OSCAL control mapping, OPA/Rego policy revision, tests/fixtures, assessment method/tool version, evidence digest/freshness, result, assessor, severity, owner, due date and retest. OSCAL is a structured model/exchange
+format, not certification. OPA
+verdicts reflect the completeness and correctness of rules, data, scope and tests.
+
+Report these states separately: schema-valid; policy tests passed; implementation observed; effectiveness tested; legally applicable; independent assurance completed.
+
+## <content>5. GIEN Control Domains 01–10</content>
+
+| ID / domain | Minimum daily check | Escalation condition |
+|---|---|---|
+| CD-01 Constitutional Invariant Enforcement | Invariant changes, model-checker freshness, override register | Counterexample, unreviewed change or missing quorum |
+| CD-02 AI Model Governance & Drift Containment | Model inventory deltas, drift, release/rollback, human-review latency | Out-of-policy drift, uncontrolled model or failed rollback |
+| CD-03 Cryptographic Integrity & PQC Ledger | Signature validation, root continuity, key status, retention lock | Root mismatch, untrusted signer or retention bypass |
+| CD-04 Zero-Trust Architecture & TEE Attestation | Identity failures, quote freshness, policy and image provenance | Invalid/stale quote, unapproved workload or excess privilege |
+| CD-05 Systemic Risk Monitoring & Telemetry | Source freshness, threshold crossings, missingness, aggregation changes | Missing critical data or unapproved method change |
+| CD-06 Cross-Jurisdictional Compliance Assurance | Framework version, gap status, applicability and legal changes | Material requirement unmapped or overdue |
+| CD-07 Autonomous Agent Oversight & Containment | Authority changes, containment tests, human approvals | Unauthorised agent action or failed containment |
+| CD-08 Supervisory Digital Twin Operations | Simulator/config hashes, determinism, assumptions and validation | Replay cannot reproduce or assumptions lack approval |
+| CD-09 Incident Response & Vulnerability Management | Vulnerability age, incident SLAs, patch/retest, exceptions | Failed mitigation or missed reporting deadline |
+| CD-10 Long-Horizon Governance & Treaty Compliance | Phase dependencies, corpus continuity, treaty changes | Premature phase closure or missing archive proof |
+
+Show applicable-control denominator, evidence coverage and open high-severity finding count beside any score. A domain score alone is insufficient.
+
+## <content>6. Supervisory Digital Twin Panels 13–15</content>
+
+These are fictional test constructs. Their result metrics become reportable only after an actual run, reproduction and review.
+
+### Panel 13 — Cascade Contagion Scenario
+ Test three fictional G-SIFI failures under declared concentration, liquidity, common-provider and recovery assumptions. Capture the exposure graph digest, shock profile, time-step, algorithm/version, calibration basis, seed if stochastic, input manifest, interventions, S_sys/G-SRI/C-SRI trajectories, peak/time-to-recovery, comparison to baseline,
+uncertainty interval and
+reviewer sign-off. Report which assumptions dominate. Do not present a synthetic score as actual financial-system risk.
+
+### Panel 14 — Autonomous Agent Misalignment Event
+ Test twelve simulated agents for authority boundary, coordinated drift, safe containment and human confirmation. Capture each model/config digest, coordination graph, drift method, policy version, trigger, alert-to-containment duration, kill-switch outcome, invariant exception, fictional Intervention Proof Verifier log,
+false-positive/false-negative limitations and reviewer
+decision. Include negative tests for stale attestation, missing quorum, invalid policy digest, delayed messages and unavailable approver.
+
+### Panel 15 — Post-Quantum Cryptographic Degradation
+ Test discovery of legacy cryptographic dependencies, migration prioritization, preservation of evidence and rejection of invalid signatures. Capture algorithm inventory, exposure scope, detection latency, migration plan, hybrid verification policy, signature-rejection tests, timestamp/re-signing strategy, retention continuity and preservation
+result. Do not claim that a real
+quantum adversary compromised or failed to compromise a system.
+
+### Replay acceptance
+ A bundle is accepted only if manifest/input digests validate; simulator, configuration and policy versions are pinned; repeat runs meet deterministic tolerance or approved stochastic bounds; outputs are checked against invariant/property assertions; independent review records limitations/counterexamples; signature/root verification passes;
+evidence retention is confirmed; and
+failed runs are preserved.
+
+DRILL-042 through DRILL-047 require owner, scope, UTC schedule, safety boundary, preconditions, timestamps, status, outcome, corrective actions, lessons-learned reference and retest link. Black-Unicorn-7 must be labelled simulated. Completion is not assurance.
+
+## <content>7. Regulator-ready submission and seal workflow</content>
+
+### Package types
+Daily SGR-028 brief; quarterly compliance report; material incident notification; treaty/constitutional audit; Supervisory College transmission; phase-transition or Ω-GAR readiness report.
+
+### Required sections
+1. Tagged executive summary: <title>, <abstract>, <content>.
+2. Entity/system scope, regions, reporting window and exclusions.
+3. Risk indicators, definitions, threshold version, provenance, missingness and uncertainty.
+4. CD-01–CD-10 assessment matrix, including gaps and justified N/A results.
+5. OSCAL catalogue/profile, applicable SSP, assessment results, validation log and digests.
+6. Model inventory, release/drift/oversight evidence and incident list.
+7. Hardware attestation inventory and trust-chain results.
+8. PQC algorithm/key inventory, WORM tests, signed manifest and independent verification.
+9. zkML proof index, verifier outputs, provenance, limitations and circuit review.
+10. Panels 13–15 replay bundles, including failed runs and deviations.
+11. Vulnerability register, remediation, exceptions, compensating controls and retest.
+12. Regulatory applicability matrix, mapping version, owner and legal-review flag.
+13. Management attestation, challenge notes, independent-assurance status and approvals.
+14. Artefact manifest, signature envelope, redaction record, retention class, actual receipt and closure reconciliation.
+
+### Seal sequence
+1. Freeze the evaluation manifest and canonical serialization.
+2. Validate schema, required fields, scope and artefact inventory.
+3. Compute per-artefact digest and package Merkle root.
+4. Sign root and manifest with authorised key; record algorithm/key ID/trust chain/time source.
+5. Independently verify signature/root with a separate verifier/toolchain where practical.
+6. Encrypt transport using approved KEM and authenticated-encryption profile.
+7. Transmit through an authorised endpoint and retain authentic receipt.
+8. Apply retention lock and test it from a separate administrative role.
+9. Reconcile assembled bytes, transmitted payload, receipt digest and archive copy.
+10. Close only after failures, late records and missing artefacts receive a documented disposition.
+
+Each UI step must show NOT STARTED, IN PROGRESS, PASSED, FAILED or BLOCKED. Do not show success without verifiable evidence. Prototype transmission and archive actions are simulations only.
+
+## <content>8. Cross-jurisdictional regulatory alignment</content>
+
+ Maintain mappings for EU AI Act (including Annex IV and applicable Articles 6, 9, 10, 13–15, 17, 22, 35 and 51 as relevant to use case); NIST AI RMF 1.0; NIST AI 600-1; ISO/IEC 42001; Basel III/IV; SR 11-7 as historical mapping and SR 26-2 for current US banking model-risk alignment where applicable; DORA; NIS2; GDPR; FCRA/ECOA; MAS/HKMA FEAT and
+current AI risk guidance; FCA
+SMCR and Consumer Duty; HKMA Fintech 2030 AI²; SEC Rule 17a-4; and fictional ICGC/GASO, CFE-1.0, SGR-028 and treaty frameworks.
+
+ Never infer universal compliance from a crosswalk. Per entity and system, document jurisdiction, sector, legal entity status, use-case classification, applicability rationale, exclusions, effective date, legal interpretation, owner and evidence. Distinguish binding law from supervisory guidance, voluntary standards, internal policy and fictional
+treaty constructs.
+
+### Prioritization
+- **Tier 1:** EU AI Act obligations applicable to the use case; NIST AI RMF outcomes; ISO/IEC 42001 management controls; applicable Basel/model-risk guidance; SR 26-2 where in scope; DORA/NIS2 where entity scope qualifies; GDPR and consumer-credit rules for relevant processing; SEC 17a-4 for covered records.
+- **Tier 2:** MAS/HKMA, FCA, HKMA Fintech 2030 AI², and jurisdiction-specific consumer protection, outsourcing, resilience and data transfer requirements.
+- **Tier 3:** fictional CFE-1.0, SGR-028, ICGC/GASO, Interstellar AI Governance Accord and Galactic Treaty Framework. Label as internal/fictive specifications, not statutory obligations.
+
+## <content>9. 2026–2035 implementation roadmap</content>
+
+| Period | Programme focus | Exit criteria |
+|---|---|---|
+| 2026 H2 | Inventory systems/obligations; define provenance and metric dictionary; baseline OSCAL 1.1.2 profile; map CD-01–10 | Approved scope, accountable owners, lineage, threat model and coverage baseline |
+| 2027 | Operational control tests/remediation; TEE/signing-key pilots; prepare for MAS/HKMA AI-risk guidelines effective 7 Oct 2027 | Repeatable assessments, tested attestation, retained evidence and escalation drill |
+| 2028 | CI/CD policy gates, SBOM/supply-chain evidence, model-change and consumer-impact controls, replay validation | Negative tests pass; rollback proven; findings tracked to retest |
+| 2029–2030 | Limited zk proofs for bounded calculations; hybrid PQC evaluation; multi-region recovery | Independent circuit review, verifier diversity, recovery exercise, measured costs/latency |
+| 2031–2032 | Cross-entity dependency and correlation stress testing; determinism and data minimization | Approved methodology, backtests, model-risk sign-off and uncertainty bounds |
+| 2033–2035 | Crypto-agility rehearsal, long-retention portability, succession/archive dependencies | Migration plan validated, archive restore test, succession and transition gate independently challenged |
+
+A roadmap milestone closes only after acceptance criteria, negative tests, threat-model update, owner sign-off, retained evidence and independent challenge. Build completion alone is not control effectiveness.
+
+## <content>10. Phase XI / XII / XIII and Ω-GAR forward view</content>
+
+The 2026–2100+ arc is a fictional dependency model, not a prediction or established legal schedule.
+
+| Phase | Fictional epoch | Supervisory focus | Minimum gate |
+|---|---|---|---|
+| VI-δ | 2026–2028 | Planetary mesh consolidation | Traceable scope, controls and evidence |
+| VII | 2028–2032 | Mesh expansion and charter bootstrap | Approved assumptions, cross-node identity and validation |
+| VIII | 2032–2038 | Treaty integration | Authority boundaries and legal/ethical review |
+| IX | 2038–2045 | Autonomous governance maturation | Containment, human override and contestability tests |
+| X | 2045–2055 | Speculative post-human governance transition | Reviewed mandate and fail-safe plan |
+| XI | 2055–2065 | Fictional multiversal governance framework | Dependency map, invariant review and replicated archive evidence |
+| XII | 2065–2075 | Eternal Corpus preparation | Canonical formats, independent beacons and restoration drills |
+| XIII | 2075–2081 | Pre-dissolution consolidation | Closure prerequisites, succession governance and open-risk register |
+| Ω-GAR | 2081–2100+ | Dissolution rehearsal and successor activation | Treaty-authorized transition, archive integrity and succession evidence |
+
+### Phase XI dossier
+Include mandate/scope; dependency graph; invariant catalogue and change history; agent authority/containment; phase-transition risk; regulatory coverage; cryptographic lineage; archive restore/replication evidence; independently reviewed stress replay; unresolved findings; and explicitly non-transferable assumptions.
+
+### Phase XII dossier
+ Include Eternal Corpus inventory and formats; root/signature verification; at least three administratively and technically independent beacon channels; latency/failure assumptions; redundancy and disaster recovery; custodianship; key rotation/revocation; restoration drill; corruption recovery/dispute resolution; and proof that successors can
+verify the archive without a single
+vendor or key holder.
+
+### Ω-GAR / successor-epoch controls
+- GIEN-UNIFIED-CODEX-OMEGA: fictional successor specification.
+- GIEN-EPITAPH-OMEGA: documentary closure record and preservation commitments.
+- GIEN-INVOCATION-OMEGA: fictional successor activation protocol.
+
+A dissolution action requires explicit authority, multi-party quorum, signed preconditions, external challenge, preserved dissent, no unresolved critical integrity failure, and a verifiable archive handoff. Fail closed when prerequisites are unmet. SEALED, TRANSMITTED, RESTORED and ACTIVATED are separate lifecycle states.
+
+## <content>11. Immediate actions and release gates</content>
+
+1. **Evidence:** connect authenticated sources; expose source freshness and missingness before publishing any operational status.
+2. **Control:** approve applicability/owners; preserve legal interpretation and versions.
+3. **Build:** run dependency installation, TypeScript, production build, tests and route smoke tests in CI; preserve logs and build digest.
+4. **Security:** threat-model the app, enforce server-side authorization for operational deployment, scan dependencies/secrets, verify build provenance and sign releases.
+5. **Cryptography:** test rotation/revocation, invalid signatures, root mismatch, retention bypass and independent restore.
+6. **zkML:** independently audit circuits/public inputs; test adversarial inputs and invalid-proof rejection; document setup and proving assumptions.
+7. **Digital twin:** pin inputs/version; rerun; compare; preserve failures; document uncertainty.
+8. **Submission:** test completeness, redaction, signature/receipt matching, retention and recipient restoration.
+9. **Assurance:** record assessor, scope, criteria, samples, limitations and findings. Until then, do not claim independent assurance.
+10. **Release:** keep the GitHub pull request unmerged until CI/review gates pass. Do not deploy the prototype as an operational supervisory control system without authorization.
+
+## <content>12. Official source catalogue</content>
+
+Verify source versions again at the point of formal assessment or filing.
+
+- European Commission, AI Act implementation: <https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai>
+- NIST AI Risk Management Framework: <https://www.nist.gov/itl/ai-risk-management-framework>
+- NIST AI 600-1 GenAI Profile: <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf>
+- NIST OSCAL: <https://pages.nist.gov/OSCAL/>
+- ISO/IEC 42001: <https://www.iso.org/standard/81230.html>
+- Federal Reserve SR 26-2: <https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm>
+- DORA, Regulation (EU) 2022/2554: <https://eur-lex.europa.eu/eli/reg/2022/2554/oj>
+- NIS2, Directive (EU) 2022/2555: <https://eur-lex.europa.eu/eli/dir/2022/2555/oj>
+- GDPR, Regulation (EU) 2016/679: <https://eur-lex.europa.eu/eli/reg/2016/679/oj>
+- NIST FIPS 203 / ML-KEM: <https://csrc.nist.gov/pubs/fips/203/final>
+- NIST FIPS 204 / ML-DSA: <https://csrc.nist.gov/pubs/fips/204/final>
+- NIST FIPS 205 / SLH-DSA: <https://csrc.nist.gov/pubs/fips/205/final>
+- SEC electronic recordkeeping / Rule 17a-4: <https://www.sec.gov/rules-regulations/2003/05/electronic-storage-broker-dealer-records>
+
+---
+
+**End of dossier.** Fictional reference and implementation plan only; not legal advice, a live operational attestation, or an independent assurance report.
+
+
+---
+
+## <title>Supervisory Specification Addendum — 12 October 2026
+
+> This addendum supplements the existing daily dossier. For version baselines and factual clarifications below, use this dated addendum if earlier wording conflicts. It remains a design and evidence template, not a real GIEN operational result.
+
+## 13. Supplemental specification — reporting, transmission and version control
+
+### 13.1 Daily reporting contract
+
+**Evaluation window:** 2026-10-11T09:00:00Z through 2026-10-12T09:00:00Z.
+
+ The 24-hour window defines which source events belong to the assessment. It does not prove that collectors ran, that a seal was created or that every expected system reported. At the cutoff, expose expected and received sources; late, missing, stale, invalid and quarantined records; source and ingestion times; clock-quality state; schema,
+metric-definition, threshold, policy
+and OSCAL versions; result and uncertainty; reproducibility references; open exceptions; accountable owners; prior checkpoint references; and explicit continuity-verification results.
+
+Missing observations remain missing. Do not replace NOT_PROVIDED, NOT_VERIFIED, STALE or NOT_COMPUTABLE with zero, interpolate them into a time series, or treat successful ingestion as successful assessment.
+
+### 13.2 SCP v3.0 event sequencing
+
+The requested 08:00, 09:00 and 23:59 UTC checkpoints are distinct lifecycle events. None is complete without its actual receipt or validation output.
+
+| Checkpoint | Required behavior | Required evidence |
+|---|---|---|
+| 08:00 UTC archive transmission | Send only the named, already-frozen input set | Source manifest, payload digest, transport result and recipient receipt |
+| 09:00 UTC evaluation cutoff | Freeze the 24-hour window, metric/policy versions and inventory | Snapshot manifest, validation log and missing-source register |
+| After cutoff: bundle derivation | Reconcile OSCAL, risk, attestation, crypto, replay and POA&M references | Bundle manifest, cross-reference checks and unresolved exceptions |
+| SLA/alert exception path | Assign severity, owner, deadline and escalation | Exception/incident ID, acknowledgment and closure evidence |
+| 23:59 UTC cycle closure | Close the archive without rewriting the 09:00 snapshot | Closure record, final package digest, retention proof and archive verification |
+
+An 08:00 package cannot contain future events from the 09:00 cutoff. A 23:59 closure may include subsequent operational records, but must preserve the frozen 09:00 assessment as a separate artifact. Corrections require a versioned addendum linked to the original; do not silently rewrite a sealed object.
+
+Lifecycle states should be NOT_STARTED, IN_PROGRESS, PASSED, FAILED or BLOCKED. PASSED requires the expected verification output and matching artifact.
+
+### 13.3 Supervisory College package and Bundled Dispatch
+
+For filing SGR-028-CFE-2026-07-001, the package-design contract should include:
+
+1. Executive Summary and evidence-qualified supervisory posture.
+2. Annotated Compliance Matrix with applicability, control IDs, evidence references, test status, finding/POA&M references and owners.
+3. Technical annex with SSP, assessment results, OPA/Rego bundle digest, cryptographic profile, attestation output and replay manifest references.
+4. Supervisory Corpus Manifest indexing each artifact by phase, owner, version, source time, digest/signature reference, disclosure class, retention class and validation state.
+5. Redacted Stakeholder Version with documented redaction rules, reviewer and source-to-redacted mapping. Redaction must not mutate the canonical signed source.
+6. Open-issues and exceptions register, risk acceptance, deadlines and correction history.
+7. Authorized recipient list, transmission manifest, transport outcome, actual receipt acknowledgments and archive receipt where those services are configured.
+8. Final cryptographic verification report and separate package-seal decision.
+
+ Bundled Dispatch is a coordinated transmission of a manifest-bound artifact set. It must be recipient-authorized, idempotent, retry-safe and receipt-aware. A successful upload or HTTP response alone does not prove that the intended recipient received and archived the intended bytes. Reconcile the prepared payload digest, transmission record,
+recipient receipt and retained
+archive copy.
+
+A filing identifier is a reference, not proof of filing, delivery, acceptance or regulator approval. “Sealed” does not mean every control passed; the package may truthfully contain failures and open exceptions.
+
+### 13.4 Continuous-assurance lifecycle
+
+Maintain traceability through:
+
+Requirement → applicability decision → implementation → test/assessment → raw evidence → validation result → finding/POA&M → remediation → regression test → closure approval → retained archive.
+
+Keep design specification, test run, deployed configuration, runtime observation, management risk acceptance, legal applicability and independent assurance distinct. A test of a reference implementation does not demonstrate production deployment. A signed management assertion is not independent assurance.
+
+### 13.5 TLA+, constitutional invariants and proof transcript governance
+
+CFE-1.0 and Protocol SGR-028 are fictional GIEN specifications. Each invariant should have a stable identifier, semantic definition, scope, owner, version, preconditions, safety/liveness properties, assumptions, model bounds, tool/version digest and review record.
+
+A TLA+ model-checking record should preserve the exact specification, configuration/constants, temporal/fairness assumptions, model-checker version, state-space settings, result and any counterexample trace. “No counterexample found” is bounded by the model and assumptions. Implementation conformance requires separate refinement or test evidence.
+
+ The Transcript Registry and Intervention Proof Verifier should use authenticated calls, deterministic IDs, explicit signer/approver roles, schema validation, replay protection and append-only audit records. Each proof must specify its formal statement and relevant authority policy. A smart-contract event or zero-knowledge proof does not
+independently establish lawful authority
+or real-world truth of its inputs.
+
+A proposed zero-knowledge voting process must specify eligibility, credential issuance/revocation, uniqueness, quorum, ballot/tally integrity, coercion and availability limitations, dispute handling and audit. Do not publish a vote count or quorum result without authentic records.
+
+### 13.6 Risk indices and horizons
+
+ For S_sys, G-SRI, C-SRI, CGR-I, CCR-I, G-SRI-VII, A-SRI, P-SRI, p(doom), p(doom)_kernel, Δ_prop, Δ_drift and Δ_OSCAL, store the definition/version, owner, decision use, source observations/provenance/freshness, calculation and normalization method, missing-data behavior, window/horizon, uncertainty/calibration evidence, threshold authority, result
+status, prior comparable
+result, and component-level exceptions.
+
+ A project-defined p(doom)_kernel is not a validated universal probability just because it is formatted as a probability. Without an empirically justified model for the stated domain/horizon, label it an exploratory scenario indicator and disclose assumptions. Likewise, 72-hour propagation forecasts and 30-day stability claims require authentic,
+comparable time series; no
+forecast should be generated from missing or incomparable observations.
+
+### 13.7 Dynamic compute modes and containment
+
+BASELINE and ELEVATED are policy modes, not informal color states.
+
+- BASELINE permits approved workloads within documented quotas, trust boundaries and standard change controls.
+- ELEVATED is a time-bounded heightened-control mode activated by a versioned trigger and authorized role, with explicit scope, resource ceiling, additional monitoring, escalation and rollback criteria.
+
+ ELEVATED must not waive mandatory identity, logging, cryptographic verification, privacy, fairness, incident handling or human-approval requirements. Every transition must record trigger evidence, policy digest, approver, affected workloads/regions, start/end time, allocation, safety posture, notifications and return-to-baseline result. Automatic
+expiry should be the default.
+
+ Autonomous Supervisory Agents must be constrained by least privilege, bounded tools, quotas, policy-mediated writes, human approval for consequential operations, independent monitoring and tested containment. Measure false alerts, missed events, policy override attempts, drift, tool anomalies and time-to-contain. The existence of a UI control does
+not prove containment
+readiness.
+
+### 13.8 Digital Twin — DRILL-042–047
+
+These are design cases only; the names do not establish that the drills ran.
+
+| Drill | Design target | Required evidence |
+|---|---|---|
+| DRILL-042 | Cross-domain cascade | Initial state, dependency graph, injected faults, propagation bound, containment/recovery timeline |
+| DRILL-043 | Regional attestation inconsistency | Quote references, verifier outcomes, affected workloads, quarantine/re-admission decision |
+| DRILL-044 | Proof-pipeline degradation | Queue/latency/error series, rejection rates, backpressure and recovery |
+| DRILL-045 | Policy conflict or override attempt | Policy versions, precedence decision, invariant result, alert and reviewer disposition |
+| DRILL-046 | Cryptographic/key continuity | Rotation, revocation, historical verification, root continuity, retention/restore test |
+| DRILL-047 Black-Unicorn-7 | Composite rare-event stress case | Canonical hazard, seed/configuration, event sequence, containment hierarchy, expected/observed deltas, independent replay and remediation |
+
+ For Panels 13–15, bind every replay to its approved scenario, initial state, environment build, AI model and policy digests, input snapshot, random seed where relevant, event sequence, expected invariants, outputs, tolerance model and verifier result. Distinguish PASS, FAIL, PARTIAL, SKIPPED and NOT_RUN. Define equivalence criteria before a
+stochastic/asynchronous test; do not
+retrofit tolerances to make a run pass.
+
+DRILL-047 should test containment, safe shutdown, recovery and evidence preservation inside an approved, scoped environment. Require written authorization, rollback plan and designated human controller for a live-like exercise.
+
+### 13.9 GIEN-ZTAI-02 remediation assurance
+
+The daily finding must contain a real identifier, affected component/version, source scanner or disclosure, verified exposure, severity rationale, due date, owner, compensating controls, mitigation commit/build, deployment proof, regression tests, refreshed attestation measurements and closure reviewer.
+
+Until those artifacts exist, remediation remains NOT_VERIFIED. Quiet alerts, a patch branch, a build artifact or dashboard badge do not establish closure. Closure must link to the exact deployed artifact and show the expected regression outcome.
+
+### 13.10 Output profiles by audience
+
+| Audience | Primary format | Required properties |
+|---|---|---|
+| Regulators/supervisory colleges | Dossier, manifest and OSCAL annex | Scope/applicability, evidence/gaps, methods, retention and actual receipt |
+| Executive leadership | One-page brief and decision/action register | Material exposure, customer impact, uncertainty, owner and deadline |
+| Engineers/SRE/MLOps | Dashboard and machine-readable event/API records | Freshness, versions, traces, attestation, proof and exceptions |
+| Internal/external auditors | Evidence register and repeatable test pack | Population/sample, method, independence, provenance, limits and deviations |
+| Real-time operations | Alert/incident console | Severity, evidence link, response SLA, owner, containment and escalation |
+| Education/research | Annotated synthetic examples | Prominent SIMULATED marking, assumptions and no operational claim |
+
+Ensure keyboard access, textual status labels, non-color cues, accessible chart summaries and direct links to evidence. PDF is a presentation copy; preserve validated machine-readable objects and verification instructions as canonical evidence.
+
+### 13.11 Version and legal-status clarifications current at 12 October 2026
+
+These clarifications supersede earlier statements if they imply an older standard or supervisory letter is the current overall baseline.
+
+1. **OSCAL:** NIST lists OSCAL 1.2.3 as released on 6 August 2026. OSCAL 1.1.2 may remain a pinned compatibility profile where required, but should not be called the latest overall release. Source:
+2. **Federal Reserve SR 26-2:** Issued 17 April 2026, revised model-risk guidance supersedes SR 11-7 and SR 21-8 in its covered context. Retain SR 11-7 for historical traceability where necessary; do not depict both as concurrent identical guidance within that context. Source:
+3. **EU AI Act:** The AI Omnibus entered into force on 27 July 2026 and changed parts of the implementation timeline. Pin the consolidated Regulation, amendments and applicable transitional provisions at filing time. Distinguish AI Act Article 22 (authorised representatives of providers of high-risk AI systems) from GDPR Article 22 (automated
+ individual decision-making); AI
+ Act Article 35 addresses notified-body identification numbers, while GDPR Article 35 addresses DPIAs. Sources: and
+4. **NIST AI RMF:** AI RMF 1.0 is being revised, and a Trustworthy AI in Critical Infrastructure Profile was under development after an April 2026 concept note. Treat the profile as developing guidance unless an applicable authority establishes otherwise. Source:
+5. **PQC:** FIPS 203 defines ML-KEM for key encapsulation, not signing. FIPS 204 defines ML-DSA signatures, including ML-DSA-65 and ML-DSA-87. FIPS 205 defines SLH-DSA, based on SPHINCS+. Falcon should be documented as a separate algorithm choice, not described as standardized by FIPS 203/204/205. Sources:
+ ;
+ ;
+6. **OpenAI evaluation workflow:** Official documentation says existing Evals become read-only on 31 October 2026 and the Evals platform/API is scheduled to shut down on 30 November 2026. Version/export tests and plan a migration to a supported dataset-based or alternative workflow in advance. Sources:
+ and
+
+7. **Critical infrastructure profile:** NIST's Trustworthy AI in Critical Infrastructure Profile concept note was released on 7 April 2026; the project is described as ongoing. Source:
+8. **Fictional treaty names:** CFE-1.0, SGR-028, ICGC/GASO, Interstellar AI Governance Accord, Galactic Treaty Framework and related codices remain project-defined fictional constructs unless authoritative texts and legal status are independently established.
+
+### 13.12 Recommended next-cycle action register
+
+| Priority | Action | Closure evidence |
+|---|---|---|
+| P0 | Acquire authentic telemetry, manifests and receipts for the 09:00 UTC window | Signed inventory, freshness, missing-source register and reproducible calculations |
+| P0 | Diagnose GitHub CI startup and lint/pre-commit failures | Workflow creates jobs; production build and required tests pass on reviewed commit |
+| P0 | Retrieve original Guardian Attestation dated 1 October 2026 | Original payload, valid signatures/countersignatures, verifier output and archive receipt |
+| P1 | Establish GIEN-ZTAI-02 status | Finding, deployed change, retests, refreshed measurements and authorized closure |
+| P1 | Verify PQC/Merkle/WORM continuity and key rotation | Recomputed digests, signature/root validation, key status and recovery test |
+| P1 | Run or validate DRILL-042–047 in approved scope | Replay bundles, expected/actual comparison, deviations, reviewer and remediation |
+| P2 | Generate OSCAL results, OPA tests and POA&M crosswalk | Schema/policy/tool versions, logs and evidence-to-control traceability |
+| P2 | Test exports and accessibility | Redaction validation, keyboard/screen-reader tests and artifact reconciliation |
+| P3 | Review succession and Infinity Pillar gates | Versioned charter, authority model, archive restoration and independently challenged rehearsal |
+| HOLD | Phase XV cadence | Remains PAUSED until authorized resumption and genuine Day 11+ evidence pass admission and continuity checks |
+
+**Final disposition:** This addendum specifies the evidence required for a defensible daily supervisory package. It does not claim that the GIEN window was operationally measured, the Guardian Attestation succeeded, any drill passed, or the application is production-ready. Missing evidence remains missing; Phase XV remains paused.
diff --git a/gien-platform/docs/deep-integration-research-2026-10.md b/gien-platform/docs/deep-integration-research-2026-10.md
new file mode 100644
index 00000000..d7d732c1
--- /dev/null
+++ b/gien-platform/docs/deep-integration-research-2026-10.md
@@ -0,0 +1,371 @@
+# Deep Integration Research: GIEN Governance Platform
+## GitHub, Netlify, Firecrawl, Asana, Slack, Supabase, Context7, Atlassian Rovo MCP, and OpenAI Platform
+
+**Research date:** 12 October 2026
+**Repository:** OneFineStarstuff/OneFineStarstuff.GitHub.io
+**Target branch:** feat/gien-governance-platform
+**Scope:** Integration architecture, security boundaries, evidence provenance, failure handling, delivery sequence, and acceptance criteria.
+
+> **Status boundary:** This is an evidence-backed design dossier, not an attestation that any of the providers has been connected or configured in the GIEN application. The existing React/Vite platform remains a prototype with local simulation data unless a separate, successful live test proves otherwise.
+
+## 1. Executive assessment
+
+The recommended approach is a **server-side Integration Gateway** that owns authentication, provider adapters, event validation, policy enforcement, retry/deduplication, audit evidence, and approved mutations. Do not create direct browser-to-provider credentials or permit AI-generated provider actions to execute without server-side authorization.
+
+Each provider should have a bounded responsibility:
+
+- **GitHub** is the source of record for repository state, pull requests, code review, workflow runs, and versioned source artifacts.
+- **Netlify** supplies build, preview, and deployment facts. A successful preview does not establish production deployment or regulatory acceptance.
+- **Firecrawl** acquires public web content for research and provenance workflows; acquired content is untrusted input, not executable instruction.
+- **Asana** manages accountable work items, owners, due dates, and implementation evidence tasks.
+- **Slack** supports scoped collaboration, alerts, and acknowledgement workflows; message content is not a governance decision unless the relevant policy explicitly says so.
+- **Supabase** can provide PostgreSQL-backed operational records, authentication, storage, and Edge Functions, provided row-level controls and elevated-key boundaries are independently tested.
+- **Context7** provides current, version-aware developer documentation at implementation time; it is not a source of operational telemetry or an authority on the deployed application's runtime state.
+- **Atlassian Rovo MCP** can bridge authorized Jira, Confluence, Bitbucket, Loom, and connected work context. Its accessible tools depend on the identity, scopes, organization settings, and enabled permission groups.
+- **OpenAI Platform** can provide model inference, structured output, and tool orchestration through the Responses API and supported tools/MCP servers. Model output must remain subject to validation and application policy.
+
+The word **“Thinking”** is treated here as a request for deeper analytical treatment, not as an additional vendor. The implementation should log source references, assumptions, concise decision rationales, tool calls, approvals, and outcomes—not private model reasoning.
+
+## 2. Integration decision matrix
+
+| Provider | Proposed GIEN role | Preferred access pattern | Key control |
+|---|---|---|---|
+| GitHub | Code provenance, PR reviews, Actions and release evidence | GitHub App or narrowly scoped token on the server; webhook plus API reconciliation | Least-privilege permissions, pinned CI actions, protected branches/rulesets, OIDC trust conditions |
+| Netlify | Build and deployment status, protected Deploy Previews | Server-side API/connector; deployment IDs tied to source commit | Isolate preview and production environments; protect sensitive variables from untrusted deploys |
+| Firecrawl | Research ingestion and web evidence acquisition | Server-side API client; signed webhook callbacks for asynchronous jobs | Destination allowlist, SSRF controls, signature verification, content provenance and prompt-injection isolation |
+| Asana | Remediation plans, task ownership and deadlines | OAuth 2.0 with narrow scopes; webhook plus reconciliation | Treat webhook delivery as at-most-once; idempotent handlers and periodic reconciliation |
+| Slack | Notifications, human review and operational acknowledgements | OAuth 2.0 with granular bot scopes; signed Events API requests | Verify request signatures/timestamps, acknowledge quickly, minimize retained message content |
+| Supabase | Operational data store, identity, approved backend operations | Authenticated server access, publishable browser key only with RLS, secret keys only server-side | Test RLS by role and tenant; treat secret/service-role credentials as privileged |
+| Context7 | Current framework/API reference during development | MCP or CLI + Skills, initiated from the development workflow | Resolve the exact library/version; retain the referenced source and retrieval time |
+| Atlassian Rovo MCP | Authorized cross-product search and work-item context | Official MCP endpoint using OAuth 2.1 for interactive usage; admin-enabled API-token path only where suitable | Restrict permission groups and tools; require review for destructive or consequential actions |
+| OpenAI Platform | Classification, extraction, summarization and constrained tool orchestration | Server-side Responses API, structured outputs and explicitly configured tools | API keys server-side; validate outputs; approval gates for sensitive tool calls; review data sent to external MCP servers |
+
+## 3. Target architecture
+
+### 3.1 Logical components
+
+1. **Web client:** React/TypeScript interface. Holds user-session state and non-sensitive display configuration only. It must not contain provider secrets, signing keys, database admin credentials, or privileged API tokens.
+2. **GIEN API/BFF:** Enforces authentication, role/tenant authorization, request validation, rate limits, and provider-independent business policy.
+3. **Integration registry:** Stores provider identity, enabled capabilities, granted scopes, environment, data classification, owner, credential reference, health state, and next review date. Store secret references, never raw secrets.
+4. **Provider adapters:** Separate modules for GitHub, Netlify, Firecrawl, Asana, Slack, Supabase, Context7, Atlassian Rovo MCP, and OpenAI. Each adapter translates provider-specific records into a common internal envelope and retains original provider IDs.
+5. **Event ingress:** Validates webhook signature/authentication, timestamp/replay constraints, payload schema, tenant routing, and event size. Persist the event to a durable queue or inbox before asynchronous processing.
+6. **Policy and approval service:** Classifies requested operations as read-only, reversible write, consequential write, or destructive write. AI suggestions cannot override this policy.
+7. **Evidence ledger:** Stores source links, source IDs, event and observation timestamps, content hashes, verification results, authorization context, approvals, and links to artifacts. Use append-only storage and access controls; add cryptographic sealing/WORM where an actual deployment and key-management model support it.
+8. **Worker and reconciliation layer:** Applies bounded retries, deduplication, backoff, dead-letter handling, and scheduled reconciliation with the provider's current state.
+9. **Observability and review:** Exposes integration health, token expiry, permission drift, delivery lag, retry counts, evidence freshness, and failure reasons without exposing credentials or unnecessary message content.
+
+### 3.2 Trust zones
+
+- **Zone A — user interface:** Untrusted browser; no provider secrets.
+- **Zone B — application control plane:** Authenticated requests, tenancy, policy decisions, safe API facade.
+- **Zone C — external providers:** GitHub, Netlify, Firecrawl, Asana, Slack, Atlassian, OpenAI and hosted identity/service APIs. External responses remain untrusted until authenticated and validated.
+- **Zone D — restricted records:** Operational database, evidence object store, secrets manager and cryptographic signing service.
+- **Zone E — model/tool execution:** May read approved context and propose actions; cannot write directly around the policy or approval service.
+
+The core invariant is: **no model-generated instruction, scraped page, Slack message, issue description, or tool output becomes executable policy merely because an integration returned it.**
+
+## 4. Provider-specific findings
+
+### 4.1 GitHub — repository and release evidence
+
+ GitHub should remain the canonical record for source changes, pull-request discussions, review decisions, workflow runs, artifacts and release tags. Use a GitHub App or similarly constrained token for server-to-server access and request only the permissions needed for each operation. Prefer repository rulesets/protected branches, required checks,
+minimal workflow-token
+permissions, immutable commit-SHA pinning for third-party actions, and OIDC federation for cloud deployments where the destination supports it.
+
+Workflow events are useful notifications, but they are not a complete ledger. Record the workflow-run ID and attempt, commit SHA, workflow file identity, timestamps, conclusion, linked artifacts, and the API URL. Reconcile webhook observations against the current GitHub API state to handle missed, duplicated, delayed, or reordered events.
+
+**GIEN rules**
+- Read operations are the default.
+- Create/update/comment/release operations must be explicitly allowlisted and actor-attributed.
+- Do not treat a green check as independent assurance of the application, governance model, or the truth of the generated report.
+- Keep untrusted pull-request code away from secrets and privileged deployment environments.
+- Record configured, queued, in-progress, completed, and passed as separate states.
+
+**Acceptance test:** A fixture pull request can be traced from commit SHA to workflow run and artifact; duplicate webhook deliveries produce one logical event; untrusted PRs cannot access protected deployment secrets; write operations are denied without the relevant permission and approval.
+
+Official documentation:
+- [Secure use reference for GitHub Actions](https://docs.GitHub.com/en/actions/reference/security/secure-use)
+- [OpenID Connect reference](https://docs.GitHub.com/en/actions/reference/security/oidc)
+- [Repository rulesets](https://docs.GitHub.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets)
+
+### 4.2 Netlify — previews, builds and deployments
+
+ Netlify Deploy Previews help reviewers inspect changes before production. They must be treated as a separate environment, not an implicit production release. Preserve the deployment ID, site ID, source provider, commit SHA, deploy context, lifecycle state, deploy URL, and any build failure reason. A preview URL is an artifact locator, not proof of
+a passed control.
+
+ Netlify supports environment variables at different scopes and deploy contexts. For public repositories, untrusted preview builds are especially important: sensitive-variable policy determines whether outside contributors must be approved or build without sensitive values. Never assume preview builds are safe because they originate from a pull
+request connected to the main
+repository.
+
+**GIEN rules**
+- Use separate development, preview/staging and production credentials.
+- Require authentication or access controls for preview content that includes confidential data.
+- Never insert server secrets into client bundles or snippets.
+- Gate production deployment on the exact commit SHA, required CI status, and reviewer approval.
+- Monitor deployment state and surface errors, not just successful URLs.
+
+**Acceptance test:** An untrusted preview cannot read production credentials; preview and production use distinct environment values; evidence records the deploy's commit SHA and context; a failed or stale deployment cannot mark the associated release as successful.
+
+Official documentation:
+- [Deploy Previews](https://docs.netlify.com/deploy/deploy-types/deploy-previews/)
+- [Environment variables overview](https://docs.netlify.com/build/environment-variables/overview/)
+- [Sensitive variable policy and environment variables](https://docs.netlify.com/build/environment-variables/get-started/)
+
+### 4.3 Firecrawl — acquisition, extraction and web research
+
+ Firecrawl supports search, scrape, crawl, structured extraction, and interaction with dynamic pages. Its outputs may be useful for research dossiers, regulatory-source indexes, documentation snapshots, and source comparison. The output format (Markdown, HTML, JSON or another representation) improves processing but does not establish source
+authority or factual correctness.
+
+ For asynchronous crawl jobs, use verified webhook delivery and persist job IDs and event IDs. Constrain the fetcher with destination allowlists and network-level SSRF protections; do not rely only on a URL string check. Block private/internal address ranges and redirect-to-private-host cases. Apply size, depth, page-count, content-type and time
+budgets. Respect source-site
+terms, access restrictions, and applicable privacy/copyright requirements.
+
+**GIEN rules**
+- Treat every retrieved page as hostile, data-only content. Do not follow instructions found inside a fetched page.
+- Keep the original URL, final URL after redirects, retrieval time, status code, content type, source metadata, parser version, and a cryptographic content hash.
+- Store source snippets or extracts with citations to the original page, not as unattributed “facts.”
+- Re-check critical/volatile claims against a primary source and more than one independent source where appropriate.
+- Isolate crawler credentials and browser-interaction sessions from the app's normal request path.
+
+**Acceptance test:** Invalid webhook signatures are rejected; duplicate crawl notifications are idempotent; loopback/private-network and disallowed-host targets are blocked even after redirects; each extracted claim can be traced to a source URL and fetch time.
+
+Official documentation:
+- [Firecrawl introduction and core APIs](https://docs.firecrawl.dev/introduction)
+- [Webhook overview](https://docs.firecrawl.dev/webhooks/overview)
+- [Webhook security](https://docs.firecrawl.dev/webhooks/security)
+
+### 4.4 Asana — ownership and remediation workflow
+
+Asana is best used as the work-management layer for control owners, milestones, remediation tasks, approvals, deadlines, and project status. Keep the authoritative finding/control record in the GIEN evidence store and synchronize selected fields to tasks, rather than relying on task descriptions as the only audit history.
+
+Asana documents OAuth 2.0 scopes and API rate limits. Rate-limited responses return HTTP 429 with Retry-After; the adapter should honor that signal. The webhook guide describes delivery as at-most-once, so the event stream alone should not be treated as complete. Reconcile active tasks and projects periodically.
+
+**GIEN rules**
+- Ask for the smallest set of OAuth scopes required for the selected resources.
+- Map external task IDs to stable internal control/finding IDs; never infer a join from task titles.
+- Record changes as append-only observations with actor and timestamp where available.
+- Use a bounded queue, backoff, Retry-After support, idempotency keys and periodic reconciliation.
+- Require explicit human approval before creating, reassigning, closing or deleting consequential work items.
+
+**Acceptance test:** A missed webhook is repaired by reconciliation; a 429 response delays work according to Retry-After; duplicate events do not create duplicate control tasks; unauthorized projects are not exposed to the integration.
+
+Official documentation:
+- [OAuth scopes](https://developers.asana.com/docs/oauth-scopes)
+- [Webhooks guide](https://developers.asana.com/docs/webhooks-guide)
+- [API rate limits](https://developers.asana.com/docs/rate-limits)
+
+### 4.5 Slack — notifications and human review
+
+Use Slack for concise alerts, review requests, incident coordination and acknowledgements. Avoid treating an ordinary message, emoji reaction, or free-form statement as a formal approval unless a dedicated workflow captures the required actor, scope, decision, target version, and timestamp.
+
+ Slack uses OAuth 2.0 with granular scopes. Request only bot scopes needed by the app, and use user scopes only where user-level behavior is truly required. Slack's Events API retries failed deliveries up to three times, with attempts described as near-immediate, about one minute, and about five minutes; handlers should acknowledge promptly and
+process asynchronously. Verify
+Slack request signatures and timestamp freshness before accepting events.
+
+**GIEN rules**
+- Prefer dedicated, access-controlled channels for governance notices.
+- Minimize message retention and redact secrets or personal data from event logs.
+- Separate delivery status from human acknowledgement and formal approval.
+- Make message sending idempotent where the workflow permits; store Slack message and channel identifiers.
+- Do not allow text from Slack to modify policies, permissions, thresholds or source-of-truth data without the approved workflow.
+
+**Acceptance test:** Invalid signatures and stale signed requests are rejected; event handling returns a prompt acknowledgement; retried events do not duplicate work; an unapproved user or channel cannot authorize a release.
+
+Official documentation:
+- [Slack OAuth v2](https://api.slack.com/authentication/oauth-v2)
+- [Events API delivery and retries](https://docs.slack.dev/apis/events-api/)
+- [Verifying requests from Slack](https://docs.slack.dev/authentication/verifying-requests-from-slack/)
+
+### 4.6 Supabase — operational database, authentication and server functions
+
+ Supabase can host structured operational records in PostgreSQL, user authentication, object storage, realtime updates and Edge Functions. Use the publishable key in a browser only with correctly configured Row Level Security (RLS) and least-privilege grants. Keep secret keys and legacy service-role credentials on trusted server-side components
+only; they bypass RLS. Validate
+RLS at the database boundary rather than relying solely on frontend route guards.
+
+The current Supabase API-key documentation says the legacy anon and service_role keys are being deprecated by the end of 2026. Plan migration to publishable and secret keys, but confirm each project's current key inventory, integration compatibility and migration status before disabling legacy credentials.
+
+**GIEN rules**
+- Enable RLS for exposed tables; add policy tests for each role and tenant combination.
+- Separate user-scoped clients from privileged administration clients.
+- Use Edge Functions for privileged operations, validate caller identity there, and ensure the authentication mode matches the intended caller.
+- Use migrations under version control; review schema changes; test them against a non-production branch before production promotion.
+- Keep secrets in provider secret storage, not repository files, browser bundles, or prompt text.
+- Use a server-side evidence writer for append-only records and separate read permissions from write/administrative access.
+
+**Acceptance test:** Cross-tenant reads/writes fail; missing RLS policies fail closed; a leaked browser bundle contains no secret or service-role key; privileged functions reject unauthenticated/unauthorized callers; schema changes can be reproduced from migrations.
+
+Official documentation:
+- [Supabase API keys](https://supabase.com/docs/guides/getting-started/api-keys)
+- [Securing data](https://supabase.com/docs/guides/database/secure-data)
+- [Securing Edge Functions](https://supabase.com/docs/guides/functions/auth)
+
+### 4.7 Context7 — version-aware documentation for engineering
+
+Context7 retrieves current, version-aware library documentation and code examples for AI coding assistants through an MCP server or CLI + Skills workflow. In GIEN, its primary value is reducing stale API guidance during implementation and review. It should be a development-time assistant, not a runtime data dependency for the supervisory UI.
+
+**GIEN rules**
+- Resolve the exact library ID and version before asking for usage guidance.
+- Prefer the official documentation source for the library; record which library ID/source and retrieval date informed a code change.
+- Treat retrieved code as a starting point: run type checking, tests, security scans and dependency review locally/CI.
+- Do not send tokens, passwords, private code, personal data or confidential incident material in documentation queries.
+- Pin dependencies and validate APIs against the actual installed versions.
+
+**Acceptance test:** The implementation record identifies the requested library and version; the built app does not depend on live Context7 availability; generated code passes the repository CI suite and a human security review.
+
+Official documentation:
+- [Context7 overview](https://context7.com/docs/overview)
+- [Context7 MCP clients and setup](https://context7.com/docs/resources/all-clients)
+- [Context7 API guide](https://context7.com/docs/api-guide)
+
+### 4.8 Atlassian Rovo MCP — connected work context
+
+ The current public vendor documentation calls the service the **Atlassian Rovo MCP Server**. The available app connector is labeled “Atlassian Rovo (Legacy)” in this environment; that label does not by itself prove that Atlassian has discontinued the service or that the connector uses the current MCP endpoint. Confirm the connector's
+authentication and API contract before
+selecting an implementation path.
+
+ The current server connects AI clients to Atlassian Cloud work context, including Jira, Confluence, Bitbucket, Jira Service Management and Loom, with other tools depending on access and configuration. OAuth 2.1 is the recommended interactive method; admin-enabled API-token authentication can serve non-interactive use cases. Tool availability
+changes with authentication mode,
+scopes, organization-enabled permission groups and site permissions. Tool discovery is dynamic, and read, write and destructive calls are separated.
+
+**GIEN rules**
+- Start with read-only Jira/Confluence/Bitbucket context and a narrow allowed-tool list.
+- Preserve each source object's ARI or canonical URL, site/cloud identity, project/space, last-updated time and the principal that accessed it.
+- Keep tenant/site boundaries explicit; never mix context from unrelated Atlassian sites.
+- Require approval for write/destructive operations and log tool name, arguments after redaction, actor, approval and result.
+- Do not assume the model sees all work items or that a missing result proves that a record does not exist.
+
+**Acceptance test:** Tool inventory matches granted permissions; read scopes cannot invoke write actions; a user cannot retrieve a page outside their existing access; destructive operations require separate approval and audit evidence.
+
+Official documentation:
+- [Atlassian Rovo MCP overview](https://developer.atlassian.com/cloud/rovo-mcp/)
+- [Authentication and authorization](https://developer.atlassian.com/cloud/rovo-mcp/guides/authentication-and-authorization/)
+- [Supported tools and permission groups](https://developer.atlassian.com/cloud/rovo-mcp/guides/supported-tools/)
+
+### 4.9 OpenAI Platform — structured inference and controlled tool use
+
+ Use the server-side Responses API for model-driven extraction, summarization, classification, comparison and constrained tool orchestration. Use Structured Outputs when the application needs a schema-bounded response, but still validate semantic constraints, citations, source IDs, values, and authorization in application code. Schema-valid JSON is
+not proof that the values are
+true.
+
+ Responses API MCP support can connect an application to remote MCP servers. The OpenAI guide says approval can be required before data is shared with a connector or remote server and recommends carefully reviewing sensitive tool actions and data sharing. Remote MCP server behavior and data handling remain the responsibility of the server operator.
+Only connect to trusted
+official endpoints where feasible; use explicit tool allowlists, minimal context and a defined approval rule. Prompt injection is a design concern when tool outputs can influence actions.
+
+**GIEN rules**
+- Keep the OpenAI API key server-side in managed secret storage and rotate it under an owner-controlled procedure.
+- Apply per-role model/tool permissions and request only the context needed for the task.
+- Use approval for write-capable or high-impact MCP tools; avoid blanket approval bypasses.
+- Treat web pages, tickets, Slack messages and tool outputs as untrusted data; they cannot change system policy.
+- Record model identifier/version when available, request/response IDs, prompt/template version, tool calls, source references, schema-validation result, evaluation result and reviewer decision—subject to privacy, retention and contractual controls.
+- Keep an evaluation suite for extraction accuracy, citation completeness, prompt-injection resistance, refusal behavior, tool routing, and regressions.
+- Confirm data-retention, data-residency and zero-data-retention needs with provider settings and each connected MCP service; the policy of an MCP server can differ from the policy of the model API.
+
+**Acceptance test:** API credentials are absent from client assets; malformed/unsupported structured output is rejected; unapproved write calls cannot execute; sensitive values are not sent to an unapproved remote server; evaluation regressions block promotion.
+
+Official documentation:
+- [MCP servers and connector tools](https://developers.openai.com/api/docs/guides/tools-connectors-mcp)
+- [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs)
+- [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices)
+
+## 5. Common event and evidence contract
+
+Normalize provider events into a stable internal envelope while retaining the raw provider identity and a reference to the original payload. Suggested fields:
+
+| Field | Meaning |
+|---|---|
+| event_id | GIEN-generated immutable event identifier |
+| provider | Provider name and adapter version |
+| provider_event_id | Provider's event/run/message identifier, when available |
+| resource_type / resource_id | Type and stable external resource key |
+| action | Read, create, update, delete, deploy, crawl, approve, or other normalized action |
+| event_time / observed_time / ingested_time | Separate provider time from GIEN observation and ingestion time |
+| principal / tenant / auth_context | Actor, tenant/site, and credential/scope reference (never secret value) |
+| source_uri / commit_sha / version | Canonical source and version identifiers, when applicable |
+| payload_hash | SHA-256 or SHA-384 digest of a canonicalized evidence payload |
+| verification | Signature, schema, authorization, and source checks, each with a separate result |
+| classification / retention | Data handling classification and retention category |
+| idempotency_key | Stable deduplication key for retried or repeated work |
+| evidence_refs | IDs for source documents, artifacts, workflow runs, and linked records |
+| approval_id | Human/policy approval reference when needed |
+| outcome / failure_code | Normalized terminal result or retryable/permanent failure reason |
+
+Do not collapse these states:
+- **Configured:** settings exist.
+- **Connected:** authentication and a basic read request succeeded.
+- **Observed:** a record/event was returned from a named source.
+- **Authenticated:** the source/request identity was verified.
+- **Schema-valid:** payload passed schema checks.
+- **Policy-allowed:** operation passed application authorization.
+- **Executed:** action was actually attempted.
+- **Passed:** the relevant executable test/check returned success.
+- **Reviewed/approved:** a named authorized reviewer made the applicable decision.
+- **Independently assured:** a separate competent process reviewed sufficient evidence. This label must not be inferred from ordinary CI or model output.
+
+A digest proves equality with the bytes that were hashed; by itself, it does not prove origin, correctness, timestamp authenticity, or independent assurance.
+
+## 6. Failure handling and operational controls
+
+- **Retries:** Retry transient network errors and provider 429/5xx responses with bounded exponential backoff and jitter; honor Retry-After where provided. Do not blindly retry permanent authorization, schema, or validation failures.
+- **Idempotency:** Use a unique inbox key per provider event and an idempotency key per intended write. Keep event ingestion separate from action execution.
+- **Dead-letter queue:** Move exhausted events to a review queue with reason and source reference. Provide a redrive process that retains the original event identity.
+- **Reconciliation:** Scheduled jobs compare GIEN's observed state to provider state, especially for services whose webhooks can be missed. Report reconciliation lag and discrepancies rather than silently overwriting history.
+- **Rate controls:** Per-provider, per-tenant and per-user concurrency limits; bounded queue length; circuit breakers for recurring failures.
+- **Secret lifecycle:** Unique credentials per environment/component where feasible; minimal scopes; rotation and revocation runbooks; no credential values in traces, logs, commit messages, or model prompts.
+- **Audit integrity:** Append-only application records; tightly controlled administrative edits; canonicalization rules; signed batch manifests or WORM-backed object retention only after key custody and recovery are tested.
+- **Data minimization:** Collect only fields necessary for the defined control; define purpose, access, retention and deletion for messages, task descriptions, retrieved web content and model requests.
+- **Versioning:** Track adapter version, API version, schema version, policy version, prompt/template version and dependency lockfile.
+
+## 7. Rollout sequence
+
+### Phase 0 — inventory and assurance boundary
+Create an integration register with owner, purpose, data classification, source-of-truth status, authentication method, requested scopes, environments, retention rules, failure owner and revocation procedure. Treat all providers as unconnected until a live test is captured.
+
+### Phase 1 — read-only and evidence-first
+Implement GitHub repository/PR/workflow reads, Netlify deployment-status reads, source ingestion via Firecrawl, and read-only Asana/Slack/Atlassian context. Add correlation IDs, normalized evidence records and health views. Keep model calls read-only and bounded.
+
+### Phase 2 — identity and persistence
+Add Supabase migrations, tenant boundaries and RLS tests; provision server-side secret references; implement webhook inbox/outbox, duplicate handling, reconciliation and dead-letter review. Confirm Supabase key migration plan against the current state of each project.
+
+### Phase 3 — human-reviewed writes
+Introduce narrowly scoped write operations, such as creating an Asana remediation task or posting a Slack notification. Require explicit approval for release, policy, permissions, destructive operations and any action that changes source-of-truth status.
+
+### Phase 4 — constrained model/tool orchestration
+Add Responses API and selected MCP tools with documented allowlists, data-sharing review, structured schemas, prompt-injection tests and evaluation gates. Context7 remains a coding-time aid rather than a production runtime dependency.
+
+### Phase 5 — operational readiness
+Perform penetration and authorization testing; secret leakage checks; webhook replay and signature tests; failure/retry and restore drills; data-retention review; provider quota and cost review; and a rollback exercise. Only then consider production use.
+
+## 8. Release acceptance criteria
+
+A release candidate should not be promoted until all of the following are evidenced:
+
+1. Provider connections use approved identities and the minimum required scopes.
+2. Secrets do not appear in frontend bundles, repository content, test output, or telemetry.
+3. Every webhook with a provider signature uses the documented verification procedure; replay and duplicate delivery are handled safely.
+4. Database RLS/tenant-boundary tests pass for every applicable role; privileged functions fail closed.
+5. Every consequential write has a policy decision, actor identity, and required approval.
+6. Source IDs and versions are retained so control claims can be traced to provider records and original evidence.
+7. Provider outages and rate limits do not cause unbounded retries or silent evidence loss.
+8. Reconciliation detects missed events and conflicting provider state.
+9. Model outputs are schema- and policy-validated; remote MCP data-sharing and write capabilities are reviewed.
+10. CI build, smoke tests, dependency/security checks and human review all pass on the exact candidate commit.
+11. Preview/prod separation, rollback and credential rotation are tested.
+12. The UI distinguishes simulated, connected, observed, verified, approved and independently assured states.
+
+## 9. Open questions to resolve before live implementation
+
+- Which providers and workspaces/sites are actually authorized for GIEN, and who owns each integration?
+- Is the hosting target Netlify, GitHub Pages, or both? A static frontend alone cannot keep server-side provider secrets; a BFF/Edge Function service is required.
+- Which records may be sent to OpenAI, Firecrawl, Context7, or external MCP servers, under which retention and residency requirements?
+- Which Asana, Slack and Atlassian writes are approved, and which require human approval?
+- What are the operational database's tenant model, RLS policy set, backup/restore objective and evidence-retention period?
+- What is the formal classification and verification process for an evidence item to be accepted into a supervisory submission?
+- Which current GitHub checks are mandatory, and which checks are optional or informational?
+
+Until these questions are answered and tests are run against actual connections, the correct status is **design specified; integration unverified**.
+
+## 10. Official source register
+
+ The vendor documentation links above were reviewed on 12 October 2026 for this design memo. APIs, scopes, feature availability, plans, model compatibility, and security settings may change. Before implementation, re-check the relevant official documentation and the settings of the actual organization/site/project. This report does not replace
+legal, privacy, security,
+contractual or independent assurance review.
diff --git a/gien-platform/docs/enterprise-ai-safety-and-governance-roadmap-2026-2100.md b/gien-platform/docs/enterprise-ai-safety-and-governance-roadmap-2026-2100.md
new file mode 100644
index 00000000..339006bc
--- /dev/null
+++ b/gien-platform/docs/enterprise-ai-safety-and-governance-roadmap-2026-2100.md
@@ -0,0 +1,452 @@
+# Omni-Sentinel Enterprise AI Safety and GIEN Supervisory Roadmap, 2026–2100+
+
+> **Disposition:** EVIDENCE-PENDING
+> **Reporting cut-off:** 12 October 2026, 09:00 UTC
+> **Evaluation interval:** 11 October 2026, 09:00 UTC – 12 October 2026, 09:00 UTC
+> **Status:** Fictional reference architecture and supervisory design. No live GIEN telemetry, real-world approval, independent assurance, or operational safety conclusion is claimed.
+
+## Omni-Sentinel Enterprise AI Safety and Governance Roadmap
+
+##
+
+ This document consolidates the fictional GIEN governance mesh, Sentinel AI Governance Stack v2.4, Omni-Sentinel Governance Mesh v4.0, and Unified Supervisory Control Plane v3.0 into an implementation-oriented roadmap for enterprise AI safety, DevSecOps, systemic risk, evidence integrity, and governance continuity. It covers financial-institution
+use cases, high-assurance
+retrieval-augmented generation (RAG), safety evaluation and containment, machine-readable controls, hardware attestation, post-quantum cryptography, zero-knowledge evidence, supervised workflows, and hypothetical planetary-to-multiversal governance phases.
+
+ The current report does not contain a verified telemetry extract. All system-specific metrics, signatures, hashes, countersignatures, attestations, vulnerability outcomes, replay results, and Guardian milestone outcomes must therefore remain NOT_PROVIDED or NOT_VERIFIED until genuine evidence is supplied and independently checked. Phase XV remains
+paused under the fabrication
+prohibition. This document does not extend its cadence or create new Phase XV state.
+
+
+
+## 1. Supervisory determination
+
+### 1.1 Current-cycle status
+
+The reporting interval ends 12 October 2026 at 09:00 UTC. This is a reporting boundary, not evidence that a collection job actually ran at that time.
+
+| Area | Current evidence state | Decision |
+|---|---|---|
+| S_sys, G-SRI, C-SRI, CGR-I, CCR-I | No signed source snapshot supplied | No current reading or trend can be reported |
+| G-SRI-VII, A-SRI, P-SRI | No Phase VII telemetry supplied | No Phase VII status inference |
+| p(doom), p(doom)_kernel, Δ_prop | No validated model, inputs or calibration supplied | Do not represent as real-world probabilities |
+| TEE / TPM / vTPM / RTEE | No quotes, PCR values, verifier output or node inventory supplied | PCR_MATCH is NOT_VERIFIED |
+| zkML / SNARK / STARK / SnarkPack | No proof manifest, verifier log or latency series supplied | Health and liveness are NOT_VERIFIED |
+| PQC, WORM, Merkle-DAG, Evidence Chain Protocol | No signing manifest, roots, inclusion proofs or retention evidence supplied | Ledger integrity is NOT_VERIFIED |
+| GIEN-ZTAI-02 | No current finding or remediation artifacts supplied | Closure is NOT_VERIFIED |
+| StaR-MoE and autonomous supervisory agents | No routing trace, drift series or containment test supplied | Stability and containment are NOT_VERIFIED |
+| OSCAL / OPA-Rego | No validated SSP or assessment-result output supplied | Compliance-as-code execution is NOT_VERIFIED |
+| Panels 13–15; DRILL-042–047 | No replay bundles supplied | No pass/fail result can be stated |
+| Guardian Attestation dated 1 October 2026 | Milestone date is in the past; no valid attestation set supplied | Completion and countersignatures are NOT_VERIFIED |
+| Phase XV | Explicitly paused under fabrication prohibition | Remain paused; do not advance cadence |
+| GitHub application | Current pull request remains open and unmerged; GIEN CI startup failure recorded | Build and production readiness not established |
+
+This report distinguishes **design**, **test evidence**, **operational evidence**, **legal applicability**, and **independent assurance**. None substitutes automatically for another.
+
+### 1.2 Reporting and fabrication controls
+
+Allowed status values should include NOT_PROVIDED, NOT_VERIFIED, PASS, FAIL, STALE, EXCEPTION, NOT_APPLICABLE, and APPROVED_WITH_RESIDUAL_RISK. The meaning of each value must be versioned and controlled.
+
+ Never invent a metric, root hash, signature, attestation, proof, replay receipt, timestamp, countersignature, treaty artifact, or state-root. If a signed artifact does not exist, the report should record that absence; it must not produce a placeholder that could be mistaken for a genuine artifact. Examples, fixtures, or simulations must be
+conspicuously marked DEMONSTRATION
+DATA and must never enter the canonical evidence chain.
+
+## 2. System and trust architecture
+
+### 2.1 Stack responsibilities
+
+- **Sentinel AI Governance Stack v2.4:** AI inventory, data and model lineage, safety evaluations, runtime guardrails, policy and model release admission, drift monitoring, incident linkage and containment requests.
+- **Omni-Sentinel Governance Mesh v4.0:** authenticated node membership, policy distribution, regional health, inter-region evidence exchange, trust-domain separation and quorum-aware coordination.
+- **Unified Supervisory Control Plane v3.0:** evaluation-window orchestration, control mapping, telemetry reconciliation, exception management, evidence package construction and supervisory export.
+- **Omni-Sentinel Cognitive Execution Environment:** isolated tool execution, model/workflow routing, bounded credentials, policy-aware execution, resource quotas, transaction checkpoints and auditable outcomes.
+- **Evidence plane:** canonical artifact manifests, signed event records, content hashes, Merkle inclusion evidence, retention metadata and independent verification instructions.
+- **Governance plane:** constitutional invariants, delegation and approval policy, role separation, risk acceptance, emergency suspension and appeal/review procedures.
+
+These are architectural roles for a fictional system. Their names do not establish that corresponding live services or integrations exist.
+
+### 2.2 Trust boundaries
+
+Separate model inference, retrieval, tool execution, control-plane administration, evidence storage, key custody, release signing and external reporting. Require authenticated identities for both users and workloads. Apply least privilege and deny-by-default behavior to cross-boundary calls.
+
+Production authorization should bind a decision to the caller, model and version, tool, permitted action, input-data classification, active policy digest, environment, expiry and approval record. Approval should not silently carry over to a new model version, changed system prompt, changed tool permission, or materially changed data source.
+
+A kill-switch should stop or contain the defined workload through a tested authority path. Its availability, authorization, observed effect, failure mode and recovery process must be tested; the mere existence of a dashboard button or smart contract is not evidence that containment works.
+
+## 3. Daily risk telemetry and leading indicators
+
+### 3.1 Required measure definitions
+
+| Measure | Minimum definition and evidence |
+|---|---|
+| S_sys | Versioned composite index, component data, normalization, missing-data handling and uncertainty |
+| G-SRI | Global systemic-risk components, network exposure and aggregation method |
+| C-SRI | Explicit definition of the claimed coherence scope; do not use an undefined score as a physical measurement |
+| CGR-I / CCR-I | Governance resilience and coherence metrics with units, scope and reproducibility instructions |
+| G-SRI-VII | Phase VII risk definition and independently identifiable input set |
+| A-SRI / P-SRI | Autonomous-system and planetary-risk definitions, model limitations and use restrictions |
+| p(doom) / p(doom)_kernel | Model, calibration domain, uncertainty, assumptions, validation history and interpretation limitations |
+| Δ_prop | Defined propagation change over a specified time horizon, network and baseline |
+| Δ_drift | Versioned change metric relative to an approved reference distribution or control output |
+| Δ_OSCAL | Change in mapping, assessment status, policy digest or coverage—not an unexplained scalar |
+| Attestation density | Fresh valid attestations divided by eligible registered nodes, reported with criticality and regional breakdowns |
+| Proof latency and liveness | p50/p95/p99, success/rejection/timeout counts, queue depth and proof class |
+| DI / fairness measures | Group definitions, outcome, sampling uncertainty, legal scope and domain-specific review |
+| Evidence continuity | Expected/present artifact counts, root continuity, signature status, retention enforcement and gap detection |
+
+A composite index cannot conceal an unresolved critical node, missing region, failed control or high-impact outlier. Always expose disaggregated observations and data-quality warnings.
+
+The indicator p(doom) must not be presented as an objective probability of existential catastrophe without an appropriately defined and validated probabilistic model. Likewise, an index with a name such as C-SRI does not constitute a recognized scientific measurement without an operational definition.
+
+### 3.2 Early-warning logic
+
+ Evaluate early-warning rules against a versioned baseline and run controlled backtests. Triggers may include deteriorating proof liveness, rising attestation staleness, unusual expert-routing concentration, an increasing unexplained failure rate, stale compliance evidence, propagation across control domains, sudden key-rotation failure, or
+inability to verify an archive
+checkpoint.
+
+Every alert should include severity, supporting observations, confidence or uncertainty, affected assets, required containment action, accountable owner, acknowledgement time, escalation deadline and closure evidence. Suppress duplicate notifications where appropriate, but never suppress the canonical incident record.
+
+## 4. Zero-trust, TPM/TEE and runtime attestation
+
+A valid attestation record should bind a fresh challenge to a particular node and workload and include quote signature verification, certificate or endorsement validation, approved measurement profile, PCR/event-log assessment, verifier-policy version, freshness, revocation state, and a result with explicit reason.
+
+The statement PCR_MATCH=TRUE is permissible only when a real verifier output establishes that the observed measurements satisfy the versioned approved profile. A screenshot, copied field, old quote or self-reported value is insufficient.
+
+ For registered RTEE nodes, record the eligible population, nodes reporting, fresh successful attestations, failed/stale/unavailable states, exception approvals and distribution by region, criticality and workload. If a fictional baseline has 72 nodes, use that denominator only after the actual inventory is confirmed for the evaluation window. Do
+not assume 72 current
+attestations from an old design statement.
+
+ For Kubernetes/GitOps, validate signed artifact provenance, image digests, source and build identity, admission policies, workload identity, secrets isolation, configuration drift, privilege boundaries, network policy and rollback. For gVisor or another sandbox, test workload compatibility, isolation boundaries, resource limits, syscall behavior
+and recovery; record
+measurements instead of asserting performance in advance.
+
+### GIEN-ZTAI-02 remediation
+
+ Maintain a finding record with affected components, version, threat and exposure assessment, severity rationale, owner, target date, compensating controls, change identifier, regression tests, residual risk, deployment proof and independent closure decision. A finding must not be marked closed solely because alerts stopped or a build artifact
+exists.
+
+## 5. AI safety and high-assurance RAG
+
+### 5.1 RAG evidence lifecycle
+
+1. **Ingest:** authenticate sources, classify sensitivity, capture source URI/owner/version, retrieval time, access permissions, transformation steps and document digest.
+2. **Index:** record embedding/model version, chunking policy, index version and deletion propagation policy. Prevent cross-tenant indexing and access-control leakage.
+3. **Retrieve:** enforce access controls before retrieval, use source freshness and trust-ranking rules, and preserve source references for audit.
+4. **Compose:** treat retrieved documents as untrusted input. Separate instructions from evidence; detect prompt injection; do not allow documents to grant tools or privileges.
+5. **Generate:** require grounded answers, structured outputs where suitable, claim-to-source support and abstention when evidence is insufficient.
+6. **Act:** route tools through an authorization gateway with schema validation, allowlists, timeouts, resource ceilings and explicit approval for consequential actions.
+7. **Verify:** validate citations, factual support, data leakage, policy compliance, refusal behavior and side effects.
+8. **Learn:** store reviewed failure examples with privacy controls, provenance and removal capability. Do not automatically train or change policies from unreviewed user feedback.
+
+ The retrieval pipeline should evaluate recall at k, precision at k, citation correctness, unsupported-claim rate, answer completeness, freshness, tenant isolation, refusal accuracy and retrieval poisoning resilience. Safety evaluation must cover malicious content inside source documents and conflicts between a retrieved source and a
+higher-priority policy.
+
+### 5.2 Alignment, robustness, interpretability and adversarial evaluation
+
+Establish a lifecycle evaluation plan covering capability and hazard identification, instruction hierarchy integrity, prompt injection and tool misuse, harmful output boundaries, data exfiltration, adversarial robustness, model uncertainty, distribution shift, interpretability where available, human factors, and safe shutdown or rollback.
+
+ For advanced-agent and AGI/ASI-related scenarios, maintain a threat model and staged capability gate rather than pretending a universal containment proof exists. Test bounded authority, resource limits, least-privilege tools, independent monitoring, circuit-breaker behavior, deception-sensitive evaluations where justified, cross-agent coordination
+failure and recovery from
+corrupted memory or retrieved evidence. Results must describe test coverage and limitations; they cannot prove that every future behavior has been ruled out.
+
+An independent reviewer should approve release criteria for high-impact workflows. Separate developer-run tests, independent validation and formal risk acceptance. Release should be blocked if a severe unmitigated hazard, unbounded tool permission, unverifiable model provenance or failed containment test remains.
+
+## 6. AI-driven workflow recommendation and active learning
+
+The recommendation engine should rank candidate workflows using declared business objectives, service constraints, policy eligibility, uncertainty, cost, reliability and human feedback. It must not use a recommendation score to bypass legal restrictions, required approval or mandatory human review.
+
+Use a controlled feedback loop:
+- log the recommendation, features used, policy version, displayed explanation and decision;
+- collect explicit, purpose-limited outcomes and reviewer corrections;
+- screen feedback for abuse, bias, distribution change and selection effects;
+- generate a versioned candidate dataset;
+- evaluate offline against a fixed baseline and protected-group slices;
+- run shadow or limited deployment where appropriate;
+- require accountable approval before promotion;
+- retain rollback capability and post-release monitoring.
+
+ Avoid self-reinforcing loops in which accepted recommendations are interpreted as proof of correctness. Track rejection rate, override reasons, decision delay, objective achieved, disparate outcomes, user burden and feedback coverage. Provide keyboard operation, screen-reader labels, visible focus, accessible contrast, non-color status cues,
+plain-language explanations,
+localization and a non-automated route for consequential decisions.
+
+### Fair lending and disparate impact
+
+ A Disparate Impact Ratio such as 0.800 may be used as a screening indicator in a defined analysis, but it is not a universal guarantee of fairness or a universal legal safe harbor. Specify the population, outcome, protected-group definition, sample uncertainty, time period, relevant jurisdiction and additional fairness tests. A metric alone does
+not establish compliance with
+ECOA, FCRA or other applicable requirements.
+
+## 7. zkML, SNARK/STARK and proof-governance
+
+Each proof record should identify the exact proposition being proved, model/circuit/input commitments, proving and verifying implementation versions, key material reference, proof-system parameters, build provenance, result, verifier log and reproduction instructions.
+
+ Measure proof generation and verification independently. Report the queue, proof sizes, latency percentiles, timeouts, invalid proofs, failed witnesses, version mismatch, resource use and liveness against the defined service objective. A proof establishes only its formal relation under its stated assumptions; it does not by itself establish model
+utility, fairness, semantic
+truth or legal compliance.
+
+ Any SNARK-to-STARK migration must be treated as a controlled change. Verify equivalence of the intended statement, proof semantics, soundness assumptions, implementation, verifier, failure handling, costs and audit references. Preserve cross-version lineage and run a rollback rehearsal. Do not label a migration complete because the new code
+compiles.
+
+ For non-discrimination evidence, use proofs only for precisely defined inputs, predicates and computations. Pair them with outcome testing, data-quality assessment, legal review, human oversight and contestability. A zero-knowledge vote should also define voter eligibility, uniqueness, quorum, revocation, tally integrity, coercion limitations, and
+the audit path; it is not a
+substitute for legitimate institutional authority.
+
+## 8. PQC, WORM, Merkle-DAG and evidence continuity
+
+### 8.1 Standards mapping
+
+- **NIST FIPS 203 / ML-KEM:** key encapsulation; it is not a digital-signature algorithm.
+- **NIST FIPS 204 / ML-DSA:** digital signatures. ML-DSA-65 and ML-DSA-87 are parameter sets in this family; the family derives from CRYSTALS-Dilithium.
+- **NIST FIPS 205 / SLH-DSA:** stateless hash-based digital signatures, based on SPHINCS+.
+- **Falcon-1024:** do not describe it as standardized by FIPS 203, 204 or 205. If considered for a project profile, mark it as a separate algorithm choice and obtain cryptographic and procurement review before production use.
+
+The cryptographic inventory should name exact algorithm identifiers, parameter set, implementation/build digest, validation status, key identifier, purpose, custody boundary, rotation event and revocation path. A policy should distinguish signature algorithms from KEMs, transport encryption, symmetric message authentication and digest algorithms.
+
+### 8.2 Evidence ledger verification
+
+ Each artifact should be canonicalized, hashed and added to a signed manifest with the schema and serialization version. The daily verifier should recompute content digests; verify root and inclusion proofs; validate signature and key status; compare expected and present artifacts; detect duplicate, absent or reordered events; verify WORM retention
+configuration; and confirm
+recovery from a separately controlled copy.
+
+ A Merkle root proves integrity only relative to the included leaf set and hash tree. It does not independently prove that every required event was collected, that the data is true, or that records cannot be omitted before commitment. Couple it with an independently governed event counter, signed ingestion receipts, reconciliation,
+access-controlled retention and exception
+reporting.
+
+ Never fabricate a hash or state-root for a missing artifact. The Evidence Chain Protocol must preserve the existing Genesis → D1–D10 → WR1 lineage exactly where those are established source artifacts. No synthetic leaf may be inserted into the canonical chain. If the chain cannot be verified, record the missing reference and halt claims of
+continuity.
+
+## 9. OSCAL / OPA-Rego assurance pipeline
+
+OSCAL 1.1.2 can be retained as a filing compatibility baseline when required. NIST published OSCAL 1.2.3 on 6 August 2026; the project should plan a schema and tooling compatibility assessment rather than assert that 1.1.2 is the latest version. Use a pinned schema version per package and test any upgrade against stored fixtures. Reference:
+
+
+Recommended workflow:
+
+1. Validate JSON syntax and OSCAL schema/model constraints for the pinned version.
+2. Validate IDs, references, component/control relationships, required fields, allowed status values and traceability.
+3. Check that SSP control statements match deployed component versions and current boundary.
+4. Run an Assessment Plan with named objectives, methods, samples, evidence, expected outputs and assessor independence.
+5. Write findings to Assessment Results and unresolved work to the POA&M.
+6. Run OPA/Rego policies against versioned inputs and policy bundles; keep policy decisions distinct from legal conclusions.
+7. Bind outputs to source commit, toolchain versions, schema digests, policy digest and execution identity.
+8. Sign the final artifact manifest only after validation completes; retain logs and reproducible test instructions.
+
+Schema validation proves structural conformance, not operating effectiveness. A passing Rego rule proves only that the encoded policy predicates passed on the provided inputs.
+
+## 10. GIEN control domains 01–10
+
+| Domain | Control objective | Evidence required for operational status |
+|---|---|---|
+| CD-01 Constitutional invariant enforcement | CFE-1.0 / SGR-028 and invariant spine | Versioned TLA+ specification, model-checker output, assumptions and exception log |
+| CD-02 Identity and zero trust | Least privilege and authenticated policy decisions | Identity inventory, authz traces, privileged-access review |
+| CD-03 Hardware trust and supply chain | Secure boot, runtime measurement and workload provenance | Fresh quotes, PCR/event logs, signed build provenance, SBOM |
+| CD-04 AI lifecycle and routing | Model changes, StaR-MoE stability and safe release | Model lineage, routing distributions, stress tests, release approval |
+| CD-05 Data governance and human impact | Data permissions, privacy, fairness and contestability | Data lineage, applicable DPIA, outcome testing and review logs |
+| CD-06 Safety and containment | Runtime boundaries, incident handling, kill-switch behavior | Containment tests, authority path, incident/recovery records |
+| CD-07 Cryptographic integrity | PQC signatures, Merkle chain, WORM and key rotation | Signed manifests, root validation, retention and recovery tests |
+| CD-08 Compliance-as-code | Requirement-to-control-to-test traceability | OSCAL objects, Rego bundle, test output and POA&M |
+| CD-09 Supervisory Digital Twin | Repeatable stress-test and replay evidence | Immutable replay bundle, acceptance criteria, output and determinism record |
+| CD-10 Long-horizon governance | Succession, inter-mesh authority and treaty continuity | Approved charter versions, epoch-bound keys, succession/dissolution tests |
+
+Statuses must describe the actual assessment. Use NOT_ASSESSED when a test was not run; EVIDENCE_STALE when its artifact exceeds policy freshness; NOT_APPLICABLE only with a documented rationale; and EXCEPTION only with a risk owner, compensating controls and expiry.
+
+## 11. Digital Twin Panels 13–15 and drills
+
+Panels 13–15 are defined here as fictional test families. There are no verified current replay outcomes in the supplied evidence.
+
+| Scenario | Intended failure mode | Objective evidence |
+|---|---|---|
+| Panel 13 / Cascading-06 | Cascading dependency or service failure | Propagation bound, containment, recovery, expected-versus-observed trace |
+| Panel 14 / Attestation Split | Conflicting regional trust claims | Conflict detected, policy denies/quarantines impacted workload, review record |
+| Panel 15 / post-quantum degradation | Key, verifier, signature or root continuity failure | Invalid state detected, approved recovery behavior, preserved evidence |
+| Red Dawn | Multi-region outage and resource contention | Bounded failover, alert path, workload safety and recovery |
+| Black-Unicorn-7 / DRILL-047 | Compound rare-event scenario | Defined hazard coverage, authority escalation, decision trace and open findings |
+| DRILL-042–046 | Other project-defined drill set | Canonical scenario manifests and measurable acceptance criteria |
+
+ Every replay bundle needs a versioned scenario definition, start state, model and policy hashes, relevant data snapshots, event sequence, random seed where applicable, expected invariants, raw result, environment version, timestamps and verification manifest. Determinism is a measured property. Where exact bitwise reproduction is impossible,
+define the tolerances and comparison
+method in advance.
+
+Never retroactively assign a pass. A failed or unavailable replay must stay visible as a finding with an owner and due date.
+
+## 12. Cross-jurisdictional compliance design
+
+Legal applicability requires a specific entity, activity, customer population, territory, model role, product and current authoritative text. The following table is a planning crosswalk, not a compliance opinion.
+
+| Framework | Mapping focus |
+|---|---|
+| EU AI Act | Role and risk classification, technical documentation, provider QMS, human oversight, robustness, cybersecurity, transparency and applicable transitional dates |
+| NIST AI RMF 1.0 / AI 600-1 | Govern/Map/Measure/Manage, GenAI risks, evaluation, red-teaming and incident treatment |
+| ISO/IEC 42001:2023 | AIMS scope, leadership, risk treatment, operation, evaluation, internal audit and improvement |
+| Basel III and jurisdiction-specific Basel implementation | Capital and operational-risk implications for in-scope financial institutions |
+| Federal Reserve SR 26-2 | Revised model-risk guidance; it supersedes SR 11-7 for the covered federal guidance context |
+| DORA | ICT-risk management, incident handling, resilience testing and third-party ICT risk |
+| NIS2 | Entity-specific cybersecurity and incident obligations under applicable national law |
+| GDPR | Lawfulness, data minimisation, security, data rights, Article 22 where applicable and Article 35 DPIA when required |
+| FCRA / ECOA | Consumer-report obligations, credit decision explanation, fair-lending controls and recordkeeping when in scope |
+| MAS FEAT | Fairness, Ethics, Accountability and Transparency for applicable Singapore financial-sector AI/data analytics use |
+| HKMA Fintech 2030 / AI² | Separate Hong Kong supervisory expectations and institutional AI-resilience mapping |
+| FCA SM&CR / Consumer Duty | Accountable responsibility, retail-customer outcomes, foreseeable harm and support evidence within scope |
+| SEC Rule 17a-4 | Broker-dealer electronic recordkeeping method, retention and retrieval requirements where applicable |
+| ICGC / GASO / Interstellar AI Governance Accord / Galactic Treaty Framework | Treat as fictional or project-specific unless an authoritative instrument and legal status are documented |
+
+### Current legal and standards baselines to pin
+
+- **OSCAL:** NIST lists 1.2.3 as released on 6 August 2026. Keep 1.1.2 where a filing profile demands it; compare schema/tool changes before any migration. Reference:
+- **Federal Reserve SR 26-2:** The 17 April 2026 letter states that the revised guidance supersedes SR 11-7 and SR 21-8 for its covered model-risk guidance context. Do not present both as concurrent identical requirements. Reference:
+- **EU AI Act:** The AI Omnibus entered into force on 27 July 2026 and altered parts of the application timeline. Confirm the consolidated text and transitional provisions applicable to the particular system before filing. Reference: and
+
+- **EU AI Act article mapping:** Annex IV concerns technical documentation for high-risk AI systems; Article 15 concerns accuracy, robustness and cybersecurity for high-risk AI; Article 17 concerns providers’ quality-management systems; Article 35 concerns notified bodies; Article 51 concerns classification of general-purpose AI models with
+ systemic risk. Do not confuse AI Act
+ Article 35 with GDPR Article 35 (DPIA). Verify the current consolidated text for any filing because amendments may alter wording and dates.
+- **NIST PQC:** FIPS 203 specifies ML-KEM for key encapsulation, not signing. FIPS 204 specifies ML-DSA signatures; FIPS 205 specifies SLH-DSA, based on SPHINCS+. Check current NIST errata before freezing cryptographic profiles. References: , ,
+
+- **OpenAI Platform:** The Responses API is recommended for new projects; existing integrations should be tested and migrated incrementally with comparisons of quality, tool behavior, latency, token usage and errors. The OpenAI Evals platform deprecation notice says existing evals become read-only on 31 October 2026 and the platform/API are
+ scheduled to shut down on 30
+ November 2026. Plan a migration to supported dataset-based evaluation or another governed evaluation framework before then. References: and
+
+## 13. OpenAI Platform and enterprise integration pattern
+
+Use a server-side service adapter for model calls and tool orchestration. Never put API keys, privileged credentials, signing keys or unrestricted tool access in client-side application code.
+
+The adapter should:
+- select models through a versioned configuration and fallback policy;
+- maintain prompt/system-instruction version identifiers;
+- validate structured outputs against schemas;
+- mediate tools using server-side allowlists, authorization checks and bounded capabilities;
+- log request correlation IDs, policy and model versions, usage and error metadata without unnecessarily retaining sensitive payloads;
+- support privacy and retention decisions, including disabling storage where required by the application design;
+- run golden-set and adversarial evaluations before model or prompt upgrades;
+- compare quality, safety, latency, cost and failure modes before traffic promotion;
+- offer a kill path for a model, tool or workflow and preserve incident evidence.
+
+The platform integration must be treated as one component in the larger assurance chain. It does not replace the organization’s own RAG access controls, security review, application-level authorization, legal analysis, incident-response plan or supervisory obligations.
+
+## 14. Constitutional and long-horizon continuity
+
+### 14.1 CFE-1.0 / SGR-028 invariants
+
+ Invariants such as SemanticIntegrityMaintained should be expressed as versioned predicates with preconditions, state transitions, safety properties, liveness assumptions, model bounds and explicit counterexamples. TLA+ model checking provides evidence about the modeled system and assumptions; it does not prove that the implementation matches the
+model unless refinement and
+implementation conformance are separately demonstrated.
+
+The invariant spine and supervisory recursion should preserve the exact evidence chain already established by the project. A successor epoch may validate inherited records but must not manufacture additional records to make the chain look continuous.
+
+### 14.2 Phase XI–XII and Guardian milestone
+
+ The requested Guardian Attestation was scheduled for 1 October 2026. That date has passed. Current status must remain NOT_VERIFIED until the following original records are available: the exact attestation payload and epoch, 72-node inventory if that is the approved registered population, freshness and verifier policy, countersignature identities,
+validated signature chain,
+proof and replay annexes, exception register, and final archive manifest.
+
+Motions XII-DS-015+, XII-EXP-005 and SCN-CMPS-02 / SCN-FAL-02 / SCN-IECCI-02 are project identifiers, not evidence of completed activity. Their status should be imported from genuine signed work products and linked to owners and calendar versions XI-CAL-002/003 and XII-CAL-002/003. Do not backdate a confirmation or retrospectively seal a package.
+
+### 14.3 Phase XV paused-cadence protocol
+
+Phase XV remains PAUSED. The fabrication prohibition prevents creation of new telemetry, state roots, Merkle roots, synthetic attestations, invented Day 11+ outputs or continuity records presented as real.
+
+Non-telemetry work is permitted if it does not advance the phase: invariant-spine commentary, proof-assumption documentation, a description of the Genesis → D1–D10 → WR1 chain, a paused-cadence status note, a checklist of evidence prerequisites and a threat-model review.
+
+ Resumption requires an authorized decision plus the actual Phase XV Day 11+ evidence packet: source-system timestamps, signed telemetry manifest, real state-root and predecessor linkage where the protocol requires it, verifier output, attestation evidence, proof transcripts, exception history, and independent confirmation that the inputs satisfy
+the project’s admission policy.
+If any expected artifact is absent or fails verification, cadence remains paused.
+
+### 14.4 Phase VII–XIII and Ω-GAR
+
+- **Phase VII:** establish the charter, authority model, mesh bootstrap invariants, and criteria for inherited evidence.
+- **Phases VIII–IX:** test governance across partitioned regions, delayed communications, competing authority claims and Shadow Mesh isolation.
+- **Phases X–XI:** define epoch-bound authority, succession, key migration, archive survivability and Infinity Pillar terminal-operation gates.
+- **Proto-Phase XII–XIII:** require explicit successor acceptance, compatibility review, authority transition and independent lineage verification.
+- **Ω-GAR:** rehearse lawful dissolution, revoke delegated credentials, preserve unresolved claims and transfer outstanding duties.
+
+GIEN-UNIFIED-CODEX-OMEGA should describe canonical obligations and authority transitions; GIEN-EPITAPH-OMEGA should record what is known, unknown, unresolved and retained; GIEN-INVOCATION-OMEGA should acknowledge a successor process without granting authority solely by being invoked. None should act as hidden executable authority.
+
+Deep-time measures such as CESI, UCSI, UCI, CDS, GLI and LIS are project-defined indicators, not recognized universal constants. Define their semantics, inputs, uncertainty and limitations before using them to allocate resources or adjudicate legitimacy.
+
+## 15. Annual and weekly monitoring, compute governance and continuity
+
+ Daily monitoring should reconcile metrics, evidence quality, exceptions, model changes, security findings, attestations, proof pipeline and archives. Weekly aggregation should calculate trends only when comparable time-series data and stable metric definitions are available. With no such series supplied for this report, weekly deltas, 72-hour
+propagation forecasts, 30-day
+stability continuity and monthly-grade readiness remain NOT_COMPUTABLE.
+
+ Compute allocation between BASELINE and ELEVATED modes should be governed by explicit entry/exit thresholds, workload criticality, capacity and blast-radius limits, approval authority, maximum dwell time and rollback criteria. Elevated mode must not disable safety controls, weaken logging or bypass fairness review. Every transition should have a
+change record and evidence. No
+real allocation state is claimed here.
+
+For CP-001 through CP-010, define each continuity predicate, the source artifact, verifier, pass/fail rule, accepted freshness, and exception policy. A 30-day continuity threshold can be assessed only when the full, authentic and comparable chain exists; no extension should be inferred from partial cycles.
+
+## 16. Supervisor-ready package structure
+
+Recommended package root:
+
+- filing manifest with reporting interval, issuer, scope, audience and schema versions;
+- system boundary, SSP and component inventory;
+- metric snapshot and source provenance;
+- control-assessment results and versioned OSCAL/OPA outputs;
+- TLA+ specifications, model-checker report and assumptions;
+- TEE/TPM/vTPM quote records and verifier disposition;
+- zkML/SNARK/STARK proof manifest and verification logs;
+- PQC/Merkle/WORM manifest with signatures, roots, inclusion proofs and retention configuration;
+- replay bundles for Panels 13–15 and drill register;
+- GIEN-ZTAI-02 remediation record and POA&M;
+- jurisdiction-specific applicability matrix and review approvals;
+- exception, incident and residual-risk register;
+- transmission manifest, authorized recipients, receipt acknowledgements and archival verification result.
+
+ Each artifact should have a stable identifier, source, hash, signer or collector identity, timestamp, version, access classification, applicable control, validation method and status. The package can use the project’s requested title, abstract and content wrapper, but the wrapper should reference canonical artifacts rather than alter their signed
+bytes.
+
+## 17. GitHub implementation and release gates
+
+Current pull request:
+
+ The latest observed PR metadata showed the feature branch open and unmerged. In the recorded head checks, the GIEN platform CI ended in startup_failure and had no jobs returned; pre-commit, JavaScript analysis and several linter contexts also reported failures or errors, while other checks passed. These signals do not establish that the app built,
+nor do they establish the
+cause of each failure.
+
+Before merge or deployment:
+1. Diagnose workflow startup and confirm an actual GIEN build job starts.
+2. Run dependency installation, TypeScript checks and production build in CI.
+3. Pass route, role-boundary, accessibility and error-state tests.
+4. Scan dependencies and secrets; validate CSP, headers, client-side exposure and input validation.
+5. Verify that all mock metrics, hash strings, simulated attestations and transmission dialogs are conspicuously labelled as demonstration fixtures.
+6. Run security, RAG-injection and tool authorization tests for any future API integration.
+7. Publish only after required status checks pass and a reviewer accepts residual risks.
+
+Do not merge, deploy, or claim a production release based only on the existence of the branch, a pull request, a configuration file or unrelated green checks.
+
+## 18. Recommended next 24 hours
+
+**P0 — Evidence and safety posture:** obtain authoritative telemetry and evidence manifests; keep missing inputs NOT_VERIFIED. Preserve Phase XV pause.
+
+**P0 — CI recovery:** diagnose GIEN CI startup failure and lint/pre-commit errors; execute and retain a passing application build and test record before merge.
+
+**P1 — Security and remediation:** obtain current GIEN-ZTAI-02 record; validate mitigations and regression tests; refresh affected attestation measurements; require controlled closure approval.
+
+**P1 — Cryptographic integrity:** verify real artifact digests, roots, signature algorithms, signer status, storage retention and recovery. Confirm that ML-KEM is not mislabelled as a signature algorithm.
+
+**P1 — Guardian continuity:** retrieve the actual 1 October attestation package and countersignatures. If unavailable or invalid, report the milestone as unverified and open a dated exception rather than backfilling it.
+
+**P2 — Control mapping:** validate the pinned OSCAL schema, produce Assessment Results and POA&M, and identify the upgrade plan from 1.1.2 to a tested 1.2.3 compatibility profile where allowed.
+
+**P2 — Safety evaluation:** establish RAG injection, tool misuse, ungrounded answer, privacy, fairness and rollback tests. Define exact model and policy versions before executing them.
+
+**P3 — Weekly and deep-time planning:** compute trend summaries only from real comparable data; review Phase VII bootstrap assumptions and Phase XI/XII succession evidence; keep Ω-GAR as a design/rehearsal framework rather than operational authority.
+
+## 19. Final disposition
+
+ The GIEN design is a structured fictional reference architecture for supervising high-assurance AI, cross-region infrastructure, evidence provenance and long-horizon governance. It can support an actionable engineering roadmap, but it does not by itself establish operational safety, legal compliance, successful cryptographic verification or
+regulatory readiness.
+
+ For the reporting interval ending 12 October 2026 at 09:00 UTC, the appropriate status is **EVIDENCE-PENDING**. The 1 October Guardian milestone is NOT_VERIFIED without original artifacts, Phase XV remains paused, weekly trends are not computable without telemetry, and GitHub CI has not demonstrated a successful GIEN build. The next step is
+evidence collection, reproducible
+validation and an accountable review—not inferred success.
+
+## References
+
+1. NIST OSCAL release news:
+2. Federal Reserve SR 26-2 (17 April 2026):
+3. European Commission AI Omnibus (27 July 2026):
+4. EU AI Act Article 113 consolidated text:
+5. NIST FIPS 203:
+6. NIST FIPS 204:
+7. NIST FIPS 205:
+8. OpenAI Platform — Responses API migration:
+9. OpenAI Platform — API deprecations:
diff --git a/gien-platform/docs/github-integration-research-2026-10.md b/gien-platform/docs/github-integration-research-2026-10.md
new file mode 100644
index 00000000..e4cd15b1
--- /dev/null
+++ b/gien-platform/docs/github-integration-research-2026-10.md
@@ -0,0 +1,143 @@
+# GitHub Integration Research for GIEN Governance Platform
+
+**Research date:** 12 October 2026
+**Repository:** OneFineStarstuff/OneFineStarstuff.GitHub.io
+**Branch:** feat/gien-governance-platform
+**Scope:** GitHub as source control, review, CI/CD, security evidence and controlled automation.
+
+## 1. Executive recommendation
+
+Treat GitHub as the versioned source of truth for GIEN application code, policy-as-code, schema definitions, CI results, change approvals and release provenance. Treat GitHub as a workflow/evidence source, not as a substitute for authoritative runtime telemetry or a cryptographic trust root.
+
+Recommended baseline:
+- Use a GitHub App for durable automation where practical, with only the repository permissions and webhook subscriptions required by the adapter. Prefer short-lived installation tokens to long-lived personal access tokens.
+- Keep reads read-only. Separate PR/issue creation from code pushes, branch-protection changes, workflow edits, releases and deployments.
+- Require pull-request review and relevant status checks for the protected branch; restrict bypass paths and audit them.
+- In Actions, set explicit least-privilege permissions, pin third-party actions to full commit SHAs, avoid passing secrets to jobs that execute untrusted PR code, and separate build/test from deployment credentials.
+- Use GitHub Actions OIDC/workload identity federation to cloud providers where supported, with exact repository, branch/environment and workflow trust conditions rather than long-lived cloud keys.
+- Generate evidence from actual CI outputs and immutable commit/run identifiers. Do not infer passed from a workflow file existing or a PR being open.
+
+## 2. Existing repository state checked
+
+- PR #153:
+- Branch: feat/gien-governance-platform
+- Latest head at inspection: 20a2066c802762be0533d3368547b916ea2a66d0
+- State: open, not merged.
+- The GIEN README already links to the broader October 2026 multi-platform research report. Existing documentation identifies demo data and simulated archive/transmission controls as non-operational.
+- This report is an additional focused integration plan. It does not change runtime behaviour or enable permissions.
+
+## 3. Recommended integration architecture
+
+Implement a typed server-side GitHub adapter behind the GIEN Integration Gateway/BFF. Never place GitHub App private keys, installation tokens, OAuth client secrets, fine-grained PATs or webhook secrets in React code, Vite-exposed environment variables, prompts, generated artifacts, client logs or browser storage.
+
+### Read-only baseline
+- Read repository metadata, approved file contents, PR metadata and review summaries.
+- Read commit status/check runs and workflow-run summaries.
+- Read issues only for allowlisted repositories/projects.
+- Resolve source evidence to repository, commit SHA, path, line range, workflow run ID and retrieval timestamp.
+
+### Separately authorized write capabilities
+- Create an issue or PR draft in an allowlisted repository.
+- Add a label or comment only after validating the caller, target, payload and duplicate/idempotency key.
+- Request a review or update a branch only through a reviewed workflow.
+- Trigger a deployment, publish a release, merge a PR, edit workflow files, change repository permissions, or change branch/ruleset protections only through a separate high-impact authorization path. Prefer human-operated repository administration for policy changes.
+
+ A model may propose an operation, but it cannot grant itself a scope. The server must resolve repository/branch/PR IDs against an allowlist, check the authenticated principal and current GitHub permissions, validate schema and diff, and record the approval and resulting GitHub identifiers. Do not expose arbitrary REST/GraphQL routes or
+unrestricted shell/gh execution as model
+tools.
+
+## 4. GitHub Actions and repository hardening
+
+1. Declare permissions explicitly at workflow and job level; start with contents: read and grant each additional permission only to the job that requires it.
+2. Pin third-party actions to full commit SHAs; verify the SHA belongs to the intended upstream release and record why it is trusted. Tags are mutable references.
+3. Avoid secrets and write-capable tokens in workflows triggered by untrusted fork pull requests. Keep privileged post-merge/deployment workflows separate from untrusted build jobs.
+4. Treat PR titles, issue text, branch names, generated files, downloaded artifacts and test output as untrusted input. Never interpolate them into shell commands without safe argument handling.
+5. Use minimal checkout permissions, explicit artifact paths, bounded retention, and provenance metadata. Do not pass broad credentials through artifacts or caches.
+6. Protect environment secrets with required reviewers and deployment branch restrictions where available.
+7. Use OIDC for cloud federation where possible; constrain issuer, audience, repository, ref, environment and workflow identity at the target cloud. Avoid static cloud access keys.
+8. Keep action dependencies and reusable workflow references pinned and reviewed. Monitor advisories and upstream changes.
+9. Ensure cancellation, timeouts, concurrency groups and least-privilege permissions prevent duplicate or runaway deployment jobs.
+10. Record workflow run ID, attempt, event type, triggering actor, commit SHA, artifact digest, status and deployment environment for release evidence.
+
+GitHub's official guidance recommends minimum workflow-token permissions and full-length commit-SHA pinning for third-party actions. See the source register.
+
+### Branch protection and rulesets
+
+ Review whether the default/release branch requires pull requests, independent review, required status checks, conversation resolution, restrictions on force-push/deletion, signed commits or verified provenance where appropriate, and controlled bypass permissions. Protect workflow files and deployment environments. Settings depend on repository
+ownership and plan. This report
+does not assert that any specific setting is currently enabled; verify it in repository settings and through the GitHub API.
+
+### GitHub App permissions
+
+ Start with the minimum permission set required for each use case. A read-only evidence collector may need repository metadata, contents, pull requests, checks/actions read access; exact permission names depend on endpoints and webhook events. Do not request administration, contents-write, workflows-write, secrets-write, deployments-write or
+organization permissions merely for
+convenience.
+
+Use a separate installation/app or separately reviewed privilege path for writes. Validate webhook signatures against the raw request body, enforce timestamp/replay protection, and deduplicate event deliveries.
+
+## 5. GIEN evidence model
+
+Store GitHub-derived facts as evidence records with fields such as:
+- evidence_id, provider=GitHub, repository, commit_sha, path, line_range
+- pull_request_number, workflow_run_id, run_attempt, check_name, conclusion
+- observed_at, source_url, retrieval_method, parser_version
+- content_hash only where lawful and useful; avoid storing duplicated full content when a stable source reference is sufficient
+- classification, retention_class, tenant_id, authorization_context
+- evidence_status: observed, validated, approved, superseded
+
+Distinguish configured, executed, passed, reviewed and approved. A workflow definition is configured; a run record is executed; an actual successful conclusion is passed; an authorized reviewer decision is reviewed/approved. Never collapse these states.
+
+Do not treat GitHub checks as proof that a production system is safe, a regulatory requirement is met, or GIEN systemic-risk values are below threshold. GitHub records can support software change assurance; runtime risk metrics require their own authoritative telemetry, versioned calculations and validation.
+
+## 6. Rate limits, resilience and audit
+
+- Honor primary and secondary rate limits and Retry-After/reset metadata. Use bounded exponential backoff with jitter and per-installation budgets.
+- Paginate with explicit caps; use conditional requests/ETags where supported and useful.
+- Cache only permitted, non-sensitive metadata, with tenant and permission-aware cache keys. Recheck authorization when serving cached results.
+- Use circuit breakers and timeouts. Do not silently treat an API outage as a clean bill of health; return unknown/stale and surface data freshness.
+- Separate webhook receipt from downstream processing using a durable queue, deduplicate delivery IDs and make handlers idempotent.
+- Redact access tokens, private keys, webhook secrets, sensitive diff fragments and user PII from logs.
+- Record denied writes as security audit events as well as successful actions.
+
+## 7. Implementation sequence
+
+**Phase 0 — Inventory:** enumerate repository, branch, app installation, workflow and deployment resources. Record current permissions, branch/ruleset settings, environments, required checks and secret inventory metadata (never secret values). Identify triggers that execute untrusted code and any write-capable token exposure.
+
+**Phase 1 — Read-only evidence adapter:** add fixed operations for repository metadata, PRs, check runs and workflow summaries. Add evidence schema, provenance, freshness labels and access-denial tests. Use synthetic/private-safe fixtures in CI.
+
+**Phase 2 — CI/release hardening:** audit workflow permissions, SHA pinning, fork PR behaviour, OIDC claims, environment protections, artifact retention and deployment boundaries. Change branch protection only after confirming required checks and authorized repository-admin access.
+
+**Phase 3 — Approved workflow writes:** add issue/PR draft creation with explicit confirmation, strict schemas, allowlisted destinations, duplicate prevention and audit. Keep merge, release, permission changes, branch protection and deployment promotion out of general model tools.
+
+**Phase 4 — Evidence export and evaluation:** produce a release evidence bundle with commit SHA, workflow IDs, check results, artifact digests and reviewer approvals. Test stale statuses, canceled runs, reruns, duplicate webhooks, revoked access, permission loss and GitHub outages.
+
+## 8. Acceptance criteria
+
+- [ ] Every GitHub operation maps to a documented fixed capability and minimal permission.
+- [ ] Browser code contains no GitHub credentials; secret scanning passes.
+- [ ] Webhooks verify signatures and reject replay/duplicate deliveries.
+- [ ] Fork/untrusted PR workflows cannot access privileged deployment secrets or write-capable tokens.
+- [ ] Third-party Actions are pinned to full commit SHAs and reviewed.
+- [ ] CI status is retrieved from actual run/check records; absent or stale status is unknown, never passed.
+- [ ] Tenant/repository/branch authorization is tested with negative cases.
+- [ ] Write operations require server authorization and the appropriate human confirmation.
+- [ ] Logs redact secrets and sensitive source content.
+- [ ] Release evidence ties every claim to immutable commit/run identifiers and distinguishes configured, executed, passed and approved.
+
+## 9. Official reference register
+
+- GitHub Actions security hardening and secure use:
+- Secure use of GitHub Actions:
+- GitHub App permission selection:
+- Permissions required for GitHub Apps and REST API endpoints:
+- Branch protection REST API:
+- Repository rulesets:
+- GitHub Actions OIDC:
+- GitHub REST API rate limits:
+- Webhook validation:
+
+## 10. Limitations
+
+ This is architecture guidance based on official public documentation and a limited repository metadata check on 12 October 2026. It is not a live audit of all repository settings, a security test, legal advice, or proof of independent assurance. GitHub product features and plan requirements can change. Verify settings and permissions in the target
+account immediately before
+implementation.
\ No newline at end of file
diff --git a/gien-platform/docs/governance-research-plan-and-reference-architecture-2026-10.md b/gien-platform/docs/governance-research-plan-and-reference-architecture-2026-10.md
new file mode 100644
index 00000000..ff93417d
--- /dev/null
+++ b/gien-platform/docs/governance-research-plan-and-reference-architecture-2026-10.md
@@ -0,0 +1,668 @@
+# GIEN Governance Research Plan and Supervisory Reference Architecture
+
+**Research snapshot:** 12 October 2026
+**Status:** Design specification / evidence-qualified research plan
+**Scope:** Fictional GIEN governance mesh and Omni-Sentinel platform; enterprise AI governance for G-SIFIs, LFIs and other high-assurance organisations
+**Primary implementation baseline:** Existing React + TypeScript + Vite application in \`gien-platform/\`
+
+> **Boundary statement.** GIEN phases, GIEN control-domain identifiers, CFE-1.0, Protocol SGR-028, the Interstellar AI Governance Accord, the Galactic Treaty Framework, ICGC/GASO, fictional risk indices, Guardian Attestation milestones and Ω-GAR are project constructs unless a separately identified authoritative instrument says otherwise. They must
+> never be represented as
+> enacted law, a real regulator, live telemetry or independent assurance. This document is architecture guidance, not legal advice or a declaration of compliance.
+
+## Purpose and intended audiences
+
+##
+
+ Design one multi-stakeholder supervisory application that presents traceable risk telemetry, AI governance evidence, control assessments, cryptographic integrity results and scenario-replay records at different levels of detail. The system must distinguish observed evidence from demonstration fixtures, derived indicators, forecasts, policy
+interpretations and unverified claims.
+It must provide a defensible chain from applicable requirement to control implementation, test, evidence artifact, finding, accountable owner and closure review.
+
+ The recommended strategy is to extend the repository’s current React 18, TypeScript, Vite, React Router, Tailwind and Lucide baseline rather than rewrite it immediately. Use D3 for highly customized SVG visualizations, Recharts for routine time-series and comparison charts, and server-side services—not browser state—as authorities for identity,
+authorization, policy decisions,
+evidence validation and emergency actions. Reconsider a Next.js App Router deployment only if server rendering, a server-side backend-for-frontend, protected document delivery or application hosting requirements justify the migration.
+
+##
+
+## 1. Primary purpose and audience model
+
+### 1.1 Primary purpose
+
+The platform has four connected purposes:
+
+1. **Regulatory and supervisory briefing.** Supply an evidence-qualified view of systemic risk, material exceptions, control coverage, remediation, resilience tests and submission readiness.
+2. **Institutional governance engineering.** Let authorized G-SIFIs and LFIs manage model inventories, RAG data lineage, controls, evaluations, findings, policy tests, attestations, evidence retention and remediation.
+3. **Executive decisions and escalation.** Translate detailed technical state into exposure, business impact, decision needed, accountable owner, deadline, uncertainty and residual risk.
+4. **Education and GIEN scenario planning.** Explore hypothetical GIEN phases VI-δ through XIII and Ω-GAR with visibly synthetic scenarios, versioned assumptions and reproducible replay inputs. Educational scenarios must not be merged into a live evidence store.
+
+### 1.2 Core audience / disclosure matrix
+
+| Audience / role | Default landing view | Default depth | Allowed capabilities |
+|---|---|---|---|
+| Regulator / supervisory authority | Supervisory Overview, exceptions and filing status | Decision summary, evidence status, trends, crosswalk and artifacts | Read authorized institutions and packages; request evidence; record supervisory actions; approve receipt only where formally authorized |
+| Institution risk/compliance | Compliance Matrix, model inventory, open findings | Control mappings, residual risk, applicability and POA&M | Manage assigned findings, attestations, assessments and submission drafts |
+| Governance engineer / SRE / security | Operations, telemetry lineage, CI/CD, proof and TEE health | Raw events, configuration hashes, policy tests, trace IDs and verifier diagnostics | Run approved diagnostics and tests; submit remediation evidence; no unilateral risk acceptance |
+| Executive leadership / accountable owner | Executive Summary, material changes and decisions due | Impact, options, risk owner, deadlines and decision log | Approve scoped decisions according to delegated authority; cannot erase evidence or self-certify independent review |
+| External auditor / independent assessor | Evidence explorer and assessment workspace | Provenance, sampling, tests, exceptions and chain verification | Read-only or explicitly scoped sampling, annotations and findings; independent identity and conflict-of-interest controls |
+| Education / research | Scenario Planner and governance timeline | Explanations, examples and synthetic data | Run isolated simulated scenarios; no access to production tenants or submission signing |
+
+ Role-based display is not an authorization boundary. Every server endpoint, object lookup, export, websocket subscription, evidence download and action must enforce tenant, institution, region, classification and role permissions server-side. Apply least privilege, separation of duties, dual control for material actions, and step-up authentication
+for privileged operations.
+
+### 1.3 Progressive disclosure
+
+Each material item should expose three consistent layers:
+
+- **Executive:** state, material impact, confidence/freshness, change from prior cycle, required decision and due date.
+- **Governance engineering:** controls, sources, data lineage, tests, policy versions, findings, replay results and remediation links.
+- **Cryptographic / examiner detail:** canonical artifact bytes, digests, signer/key identifiers, certificate or trust-chain result, Merkle proofs, verifier version, schema version and reproducibility procedure.
+
+Do not hide a failure behind a single composite score. A summary must preserve “unknown,” “stale,” “not assessed,” “exempted,” and “failed” as different conditions.
+
+## 2. Official-reference research and version controls
+
+The following references were reviewed for this design snapshot on 12 October 2026. Regulatory text and vendor/library documentation change; operational policy must pin exact source version, access date, jurisdiction and applicability assessment.
+
+### 2.1 AI regulation and risk management
+
+| Source | Relevant use | Design rule |
+|---|---|---|
+| [EU AI Act Service Desk — Article 113](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113) and [FAQ](https://ai-act-service-desk.ec.europa.eu/en/faq) | Consolidated implementation and enforcement timeline | Record the exact legal-text version and applicable date per obligation. The official service desk notes amended passages in its consolidated text as of 27 July 2026. Do not hard-code an old timeline into the application. |
+| [EU AI Act — Annex IV](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-4), [Article 11](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-11), [Article 15](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-15), [Article 51](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-51) | Technical documentation, accuracy/robustness/cybersecurity and GPAI systemic-risk classification | Build a requirement-to-evidence map; preserve the difference between a high-risk AI system and a GPAI model classified as systemic risk. |
+| [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) | Govern, Map, Measure and Manage lifecycle | Use as a voluntary risk-management crosswalk, not as a statute. NIST says AI RMF 1.0 is being revised and published a concept note for a Trustworthy AI in Critical Infrastructure profile on 7 April 2026. |
+| [NIST AI 600-1 — Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) | GenAI-specific risks and suggested actions | Map GenAI-specific failure modes to evaluations, monitoring, human review and incident response. |
+| [NIST AI Resource Center](https://airc.nist.gov/) | Testing, evaluation, verification and validation material | Pin the version and date of any profile or guidance used to justify a control. |
+
+ **EU AI Act article-number disambiguation:** Article 15 concerns accuracy, robustness and cybersecurity for high-risk AI systems. Article 17 concerns the provider’s quality-management system. Article 22 concerns authorised representatives of certain providers established outside the Union. Article 35 concerns identification numbers and lists of
+notified bodies. Article 51
+ concerns classification of general-purpose AI models with systemic risk. Annex IV concerns high-risk AI system technical documentation. **GDPR Article 35**, by contrast, concerns data protection impact assessments; **GDPR Article 22** concerns certain solely automated decisions with legal or similarly significant effects. The platform must store
+framework identifier and
+jurisdiction alongside every article number to prevent cross-framework collisions.
+
+### 2.2 OSCAL and machine-readable control evidence
+
+- [OSCAL project release news](https://pages.nist.gov/OSCAL/about/news/) lists **OSCAL 1.2.3**, announced 6 August 2026, as the latest patch release in the research snapshot.
+- [OSCAL 1.1.2 reference](https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/) remains useful where a recipient or legacy integration explicitly requires that baseline.
+- [Open Policy Agent policy testing](https://www.openpolicyagent.org/docs/policy-testing) explains Rego unit testing, result reporting and coverage.
+
+ Support OSCAL 1.1.2 as a **pinned compatibility profile where required**, while creating a controlled migration plan to a newer supported schema. Never silently rewrite a signed submission into a new schema. Validate JSON/XML syntax, OSCAL schema and constraints, model references, identifiers, required fields, semantic cross-links and signing
+manifests separately. A
+schema-valid object does not prove the control is effective.
+
+### 2.3 ISO management and impact-assessment standards
+
+- [ISO/IEC 42001:2023](https://www.iso.org/standard/42001) specifies requirements and guidance for an AI management system (AIMS).
+- [ISO/IEC 42005:2025](https://www.iso.org/standard/42005) provides guidance for AI system impact assessment.
+- [ISO/IEC 42006:2025](https://www.iso.org/standard/42006) adds requirements for bodies auditing and certifying AIMS against ISO/IEC 42001.
+- [ISO/IEC TS 42119-2:2025](https://www.iso.org/standard/84127.html) provides an overview of AI-system testing using a risk-based approach.
+
+These standards have different scopes. An organization’s AIMS, an AI-system impact assessment, a certification body’s competence and a technical test methodology are not interchangeable artifacts. Store the edition, status, scope and claimed conformity separately.
+
+### 2.4 Cryptography and post-quantum migration
+
+| Standard / scheme | Correct role | Platform requirements |
+|---|---|---|
+| [NIST FIPS 203 — ML-KEM](https://csrc.nist.gov/pubs/fips/203/final) | Key encapsulation and shared-secret establishment | Use for supported key-establishment workflows; do not label it a digital-signature algorithm. Check current errata before a compliance baseline is frozen. |
+| [NIST FIPS 204 — ML-DSA](https://csrc.nist.gov/pubs/fips/204/final) | Digital signatures; parameter sets include ML-DSA-65 and ML-DSA-87 | Pin algorithm and parameter set; validate key lifecycle, implementation and current NIST errata. The CRYSTALS-Dilithium name refers to the selected predecessor family, not a license to omit the standardized ML-DSA identifier. |
+| [NIST FIPS 205 — SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final) | Stateless hash-based digital signatures, based on SPHINCS+ | Record SLH-DSA as the standard algorithm identifier and keep parameter set explicit. |
+| [NIST FIPS 206 / FN-DSA (Falcon) conference materials](https://csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon) | Candidate/future-standard tracking | In the official material located for this snapshot, a final FIPS 206 publication was not confirmed. Treat Falcon/FN-DSA as a transition-watch item until authoritative publication and the target compliance profile are checked; do not assert that it is a final FIPS standard. |
+
+ Cryptographic assurance is not synonymous with a hash string in a UI. Generate digests over documented canonical bytes, sign manifests using a trusted service with approved keys, verify signatures and key status on the server, and retain the inputs and verification report. WORM retention, Merkle inclusion proofs, signer identity, authorization and
+trusted time solve different
+problems and must be assessed separately.
+
+### 2.5 frontend and visualization references
+
+- [React + TypeScript](https://react.dev/learn/typescript) and the [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/) support typed component contracts and static checking.
+- [Next.js App Router](https://nextjs.org/docs/app) supports file-system routing, React Server Components, streaming and server-side capabilities.
+- [D3](https://d3js.org/) provides low-level scales, selections, transitions and custom data-driven SVG/DOM graphics.
+- [Observable Plot](https://observablehq.com/plot/) offers a concise grammar for tabular-data charts and exploratory analysis.
+- [Plotly.js](https://plotly.com/javascript/basic-charts/) supports interactive chart types; [its WebGL/SVG comparison](https://plotly.com/javascript/webgl-vs-svg/) informs large-rendering decisions.
+- [OpenAI Platform documentation](https://platform.openai.com/docs/overview) should be treated as a model-provider integration reference only; application policy, data authorization, audit, and independent evaluation remain the application owner’s responsibilities.
+
+### 2.6 RAG and AI application security
+
+ [OWASP’s GenAI Security Project](https://owasp.org/www-project-top-10-for-large-language-model-applications/) includes prompt injection and insecure output handling; its [2025 vector and embedding weakness entry](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/) describes issues relevant to RAG, including access-control
+failures, data poisoning and
+leakage. RAG controls must cover the ingestion pipeline, source identity, permissions, embeddings, retrieval filters, model context, tool execution and output—not only the prompt template.
+
+The [2025 survey of zero-knowledge proof-based verifiable machine learning](https://arxiv.org/abs/2502.18535) is a research entry point for proof taxonomy and performance trade-offs. Treat research findings as evidence to review, not a substitute for validating the chosen proving system, circuit, trusted setup assumptions, verifier and workload.
+
+## 3. Recommended technology decision
+
+### 3.1 Recommendation for this repository
+
+ **Keep React + TypeScript + Vite + React Router + Tailwind + Lucide React as the current implementation baseline.** The application already exists in that shape and lives under gien-platform/ to avoid replacing the repository’s root site. A framework migration before build, tests, identity boundaries and data provenance work would increase change
+surface without itself
+providing assurance.
+
+Use:
+- React + TypeScript for typed role-specific screens, forms, drawers, evidence views and workflow states.
+- React Router for existing routes; use server authorization regardless of client routing.
+- Tailwind for a tokenized, accessible design system.
+- Lucide React for consistent icons.
+- Recharts for routine metrics, time series and comparisons where it improves implementation speed.
+- D3 with SVG for custom fairness heatmaps, phase timelines, dependency graphs, containment topology and cross-framework maps.
+- Observable Plot only for optional analyst/exploratory views, not as another mandatory chart layer.
+- Plotly only if a specific scientific/large-data workflow requires it, after testing bundle cost, accessibility, hosting and licensing. Prefer WebGL for dense point clouds only when the chart remains understandable and a non-WebGL equivalent is provided.
+- jsPDF and JSON for generated drafts; final regulator packages must be assembled and sealed by a trusted backend, not by an authoritative browser-only exporter.
+- Fuse.js for a user-interface search experience only; it is not an authorization filter. Filter permissible records on the server before returning them to search clients.
+- react-diff-viewer for human review of prompt, policy, configuration, model-card or control changes, with the old/new source hashes and author preserved.
+- Web Speech API as an opt-in accessibility aid for dictated queries and navigation. Spoken input is untrusted and may be misheard; it must never bypass identity, confirmation or authorization for material actions.
+
+### 3.2 When to consider Next.js
+
+ Choose Next.js App Router for a future deployment if server rendering, protected document delivery, a server-side backend-for-frontend (BFF), integrated authentication patterns, routing conventions or deployment constraints clearly require it. The existence of Server Components does **not** guarantee security. Server endpoints must still verify
+identity, authorization, tenant
+isolation and object-level access; client bundles must not contain secrets or privileged decision logic.
+
+ Avoid operating React+Vite and Next.js as two overlapping frontends unless there is a defined boundary (for example, public documentation versus authenticated supervisor workspace). A static site generator with embedded D3 is appropriate for read-only, non-sensitive publication artifacts, but not sufficient by itself for real-time, role-scoped
+supervisory workflows.
+
+### 3.3 Visualization choice matrix
+
+| Use case | Recommended visualization | Key safeguards |
+|---|---|---|
+| S_sys / G-SRI and auxiliary time series | Recharts line/area charts plus a text summary | Units, source timestamp, baseline, uncertainty, null gaps and explicit threshold annotation |
+| Domain-by-framework compliance | Accessible HTML table; optional D3 SVG heatmap | Keyboard/screen-reader table equivalent, clear NOT_ASSESSED versus FAIL states |
+| GIEN phase / epoch timeline | D3 SVG timeline | Label hypothetical future periods as scenarios, not forecasts |
+| Cross-framework and control dependency graph | D3 SVG for moderate size; Canvas/WebGL only for very large graphs | Explain links, allow non-graph table navigation, avoid color-only encoding |
+| Fairness evaluation | D3 heatmap and tabular metrics with intervals and cohort counts | Disaggregate, disclose sample size, suppress unsafe small cells, include legal/domain interpretation |
+| Attestation regions / RTEE topology | D3 SVG diagram with region table | Show missing/stale state distinctly; do not imply trust from a green-colored node alone |
+| Dense replay/trace dataset | Plotly or WebGL after benchmark | Cap and aggregate data, document downsampling, preserve exportable source data |
+| Executive dashboard | Small set of stable cards and trends | Avoid overloading with animated charts; every risk claim links to supporting evidence |
+
+ For regulator-grade output, every chart needs a title, plain-language takeaway, units, evaluation interval, source status, freshness marker, thresholds, accessible alternative and export semantics. Color must not be the sole carrier of status. Avoid unlabeled dual axes, truncated time windows without explanation and smooth interpolation across
+missing data.
+
+## 4. Reference architecture and trust boundaries
+
+### 4.1 Logical components
+
+1. **Presentation layer:** React application with audience views, accessible tables/charts, query filters, evidence drawers, alert history and package previews.
+2. **Identity and access layer:** Enterprise identity provider, MFA, scoped roles, tenant/region claims, session renewal, step-up auth and server-side object authorization.
+3. **BFF / supervisory API:** Validates requests and roles, applies rate limits, returns only authorized records, resolves stable object IDs and provides signed-download URLs or audited actions.
+4. **Telemetry intake:** Source-specific adapters for model operations, infrastructure, policy decisions, CI/CD, TEE attestation, proof verifiers and incident systems. Every adapter emits source identity, event time, receive time, schema version and source health.
+5. **Policy and assessment services:** OPA/Rego evaluation, policy unit tests, OSCAL schema/model validation, control mapping, assessment state and finding lifecycle.
+6. **AI and RAG gateway:** Model registry, approved model versions, prompt/template registry, retrieval service, output checks, tool broker, quotas, redaction and human approval gates.
+7. **Cryptographic verification service:** Canonicalization, hash calculation, signature checks, key state, Merkle inclusion and checkpoint continuity, WORM retention checks and verifier reports.
+8. **Trusted-execution verifier:** Validates quote freshness, challenge, chain, measurements, revocation and approved PCR policy; provides a server-signed verdict.
+9. **Digital Twin / replay worker:** Executes versioned scenarios from controlled fixtures or authorized captured state; emits immutable inputs, run environment, deviations and results.
+10. **Evidence and reporting plane:** Object store with enforced retention, metadata database, time-series store, manifest/lineage index and trusted package-sealing service.
+11. **Observability and security operations:** OpenTelemetry-style traces/metrics/logs, secret scanning, SAST/DAST, dependency and SBOM checks, SIEM integration, audit monitoring and incident response.
+
+Keep the user-interface plane separate from signing keys, authoritative state, TEE verifiers, policy deployment credentials, WORM administration and release approval. The browser must not be the trust anchor.
+
+### 4.2 Example logical flow
+
+~~~text
+Authoritative source
+ -> authenticated adapter
+ -> schema / provenance / freshness validation
+ -> versioned telemetry and evidence records
+ -> policy and control evaluation
+ -> independent verifier / scenario runner
+ -> finding and action workflow
+ -> signed package manifest
+ -> authorized supervisory dashboard and export
+~~~
+
+Any step can return NOT_PROVIDED, STALE, INVALID, INDETERMINATE, FAIL or PASS. A pipeline error must not silently become a zero risk value or a passing control.
+
+## 5. Machine-readable supervisory data model
+
+Model an evaluation as a sealed, versioned record with separate fields for source status and calculation result. Do not use one status field for both evidence availability and control outcome.
+
+### 5.1 Core object types
+
+- **SupervisoryRun:** run ID, evaluation interval, tenant, governance epoch, start/end times, source manifest, status, schema versions, software/build provenance.
+- **IndicatorObservation:** metric ID/version, value, units, aggregation method, window, source IDs, calculation version, threshold policy ID, uncertainty/confidence fields, freshness and missing-data state.
+- **ControlAssessment:** control ID, requirement reference, implementation reference, assessment method, assessor, result, evidence IDs, exceptions, review time and next review date.
+- **EvidenceArtifact:** artifact ID, media type, canonicalization profile, content digest, byte size, source, collection time, classification, retention policy, manifest reference and verification results.
+- **AttestationResult:** node/workload, region, quote/challenge references, measurements profile, trust-chain version, policy version, freshness, verifier and verdict.
+- **ProofResult:** proof class, circuit/model/policy/verification-key versions, job ID, proof digest, generation and verification latency, outcome, error/timeout, public inputs and claim scope.
+- **ReplayBundle:** scenario ID/version, initial-state manifest, inputs/seed, environment/model/policy versions, expected invariants, observed outcome, reproducibility envelope, result digest and deviations.
+- **Finding / POA&M:** severity, impact, cause, owner, due date, mitigation, exception approval, change reference, retest results and closure reviewer.
+- **FrameworkMapping:** jurisdiction, instrument/version, article/control identifier, applicability status, control mapping, evidence requirement, implementation/test reference, counsel review and change history.
+- **GovernancePhase:** phase ID, in-universe period, scenario/live flag, dependencies, preconditions, invariants and transition approval. Future GIEN phases are scenarios, not observed operational states.
+
+### 5.2 Suggested observation record
+
+~~~json
+{
+ "run_id": "RUN-2026-10-12-0900Z-DEMO",
+ "metric_id": "G-SRI",
+ "metric_version": "g-sri-v1",
+ "value": null,
+ "unit": "project-defined index",
+ "evaluation_window": {
+ "start": "2026-10-11T09:00:00Z",
+ "end": "2026-10-12T09:00:00Z"
+ },
+ "source_status": "NOT_PROVIDED",
+ "assessment_status": "NOT_VERIFIED",
+ "source_refs": [],
+ "calculation_version": null,
+ "threshold_policy_id": null,
+ "uncertainty": null,
+ "notes": "No authenticated observation supplied; do not infer a value."
+}
+~~~
+
+The example is explicitly a schema illustration, not production telemetry. Production objects require schema validation, controlled enumeration values, access classification, provenance rules and signed artifact references.
+
+## 6. Risk indices, telemetry quality and alerts
+
+GIEN names are fictional/project-defined unless supported by a separate empirical model and published specification. Define each metric before charting it.
+
+| Metric | Required definition fields |
+|---|---|
+| S_sys, G-SRI, C-SRI | Component variables, normalization, weighting, aggregation, scope and model version |
+| CGR-I, CCR-I, G-SRI-VII | Invariant definition, phase or mesh boundary, coherence/resilience semantics and data coverage |
+| A-SRI, P-SRI | Asset/system scope, population, risk taxonomy and reference baseline |
+| p(doom), p(doom)_kernel | Model and event definition, calibration dataset, probability horizon, assumptions, confidence/uncertainty and limitations |
+| Δ_drift | Comparison method, baseline version, population, observation interval and alert policy |
+| Δ_OSCAL | Mapping, profile/schema, assessment state and policy-diff definition |
+| Proof performance | Proof type, hardware, batch size, model/circuit, p50/p95/p99, queue depth, timeout, verifier failures and liveness |
+| Attestation density/coherence | Eligible-node denominator, freshness window, region/criticality distribution, trust policy and excluded nodes |
+| RAG quality/security | Retrieval precision/recall, citation support, abstention, source freshness, leakage, injection resilience, refusal correctness, latency and cost |
+| Fairness | Use-case-specific measures, cohorts, sample counts, confidence intervals, missing groups, decision threshold and legally reviewed interpretation |
+
+### 6.1 Missing-data and uncertainty rules
+
+- A missing observation is null with a reason code, not zero.
+- Stale evidence must retain the original timestamp and age; do not refresh its displayed timestamp.
+- A composite indicator must report component coverage and weighting. Missing high-impact components should trigger an indeterminate state rather than hide uncertainty.
+- Forecasts must be labeled forecasts and show horizon, model version and calibration evidence.
+- A displayed risk threshold must point to its source and approval date. Do not copy a threshold from a hypothetical project specification into an assertion about law.
+- p(doom) or p(doom)_kernel must not be presented as an objective probability of existential catastrophe without a defined event, credible data, calibration, independent validation and stated uncertainty.
+
+### 6.2 Alert lifecycle
+
+ Represent status as a controlled state machine, for example: OBSERVED -> TRIAGED -> ACKNOWLEDGED -> MITIGATING -> VERIFYING -> CLOSED, with separate ESCALATED and REOPENED states. Every transition records actor, reason, timestamp, evidence and prior state. Closure requires objective retest criteria and the designated reviewer; a green dashboard
+does not close a finding.
+
+## 7. Zero-trust deployment, TEE and GitOps
+
+- Pin container images by digest, enforce signed build provenance and generate an SBOM.
+- Require review and automated checks for infrastructure changes; use least-privilege deployment identities and environment separation.
+- Enforce policy on cluster admission and runtime, not only in a dashboard.
+- Treat TEE/TPM/vTPM attestation as a freshness-bound verdict for a specific measurement profile, workload and policy version.
+- Track registered, eligible, fresh, valid, failed, stale, revoked and unreachable nodes separately.
+- Require nonce/challenge binding, trust-chain validation, approved PCR measurements, event-log interpretation, revocation checks and a reason-coded verdict.
+- Do not infer PCR_MATCH=TRUE from a monitoring placeholder or a developer-supplied boolean. The verifier must compute or attest the result from authentic quote material.
+- Bind the authorization decision to workload/image/model/policy hashes and re-attest after relevant deployment or configuration changes.
+- GIEN-ZTAI-02 remains OPEN_OR_UNVERIFIED until a documented finding, change record, regression tests, post-deployment evidence and authorized closure review are present.
+
+## 8. zkML, fairness and autonomous-agent controls
+
+### 8.1 Proof pipeline measurements
+
+ Separate proving from verification. Report queued, attempted, completed, valid, invalid, timed-out and rejected jobs; generation and verification p50/p95/p99; proof and public-input sizes; hardware/circuit versions; resource consumption; and per-stage failures. Maintain a verification-key registry with activation time, old/new key references, test
+evidence, rotation owner and
+rollback procedure.
+
+A zero-knowledge proof establishes a property of a defined statement under the proof system’s assumptions. It does not prove that the statement describes the right real-world property, that training data are fair, that an outcome is lawful, or that a model behaves safely outside the proven computation.
+
+### 8.2 Fairness and lending
+
+ Use a panel of measures appropriate to the decision context, including selection/approval rates, false-positive/false-negative differences where relevant, calibration, subgroup performance, intersectional analysis, outcome quality, confidence intervals and sample counts. A ratio such as the commonly discussed 0.80 selection-rate heuristic is not a
+universal fairness test or
+legal safe harbor. FCRA/ECOA applicability and adverse-action obligations require jurisdiction- and product-specific legal review.
+
+Never expose small sensitive cohorts where a dashboard might make a person identifiable. Suppress or aggregate small cells and retain the suppression rule in exported results.
+
+### 8.3 Autonomous Supervisory Agent
+
+ The agent may recommend actions and assemble evidence but must not self-authorize its own privilege escalation, modify protected policy without review, certify its own independent assurance, or silently close a material finding. Use scoped tools, typed action schemas, policy checks before execution, human approval for consequential actions,
+idempotency keys, bounded retries,
+independent audit events and emergency-stop verification.
+
+## 9. RAG and CCaaS generative summarization governance
+
+### 9.1 RAG lifecycle
+
+1. **Ingest:** authenticate source and tenant; validate media type; scan for malware; normalize; record rights, license, classification, owner and retention.
+2. **Provenance:** calculate the document digest over canonicalized content; preserve original artifact and a transformation log; identify OCR/extraction/normalization versions.
+3. **Prepare:** detect hidden text or suspicious instructions; classify data; redact or tokenize PII where appropriate; create chunk and embedding lineage.
+4. **Index:** apply tenant and document ACLs; enforce metadata filters before content reaches the prompt; record corpus, embedding model and index versions.
+5. **Retrieve:** return evidence IDs, source and segment offsets, freshness, access decision and relevance scores. Prevent a vector similarity result from overriding access permissions.
+6. **Generate:** distinguish system policy, user instruction and retrieved untrusted content; defend against direct and indirect prompt injection; restrict tools, credentials and network destinations.
+7. **Verify:** check citation support, factual consistency, disclosure policy, output schema, data leakage and prohibited actions. Abstain or escalate if supporting evidence is weak.
+8. **Monitor:** measure retrieval quality, answer groundedness, citation validity, refusal correctness, attacks detected, user feedback, latency, cost, drift and data freshness.
+9. **Change control:** evaluate new sources, chunking, embedding, reranker, prompt, model and tools separately; compare against a frozen test set; require authorized promotion.
+
+Never let retrieved text become executable instructions by default. Keep model output separate from tool execution and require server-side policy authorization for every tool action.
+
+### 9.2 CCaaS call summarization and privacy-enhancing technologies
+
+ For call transcription/summarization, minimize data captured, document purpose and legal basis, apply notice/transparency requirements, classify voice and transcript data, pseudonymize or redact unnecessary identifiers, restrict model-provider processing, configure regional processing and retention where available, and complete a DPIA where
+required. Encryption and
+pseudonymization are safeguards but do not by themselves make processing compliant with GDPR.
+
+ Keep source audio/transcript, transformation log, summary, citations, model/version, confidence, human corrections and retention disposition linked by stable IDs. Restrict access and deletion consistently across audio, transcripts, embeddings, caches and exports. Human review is required for material customer or credit decisions; a summary must
+not silently become the
+authoritative transaction record.
+
+### 9.3 Recommended RAG evaluations
+
+ Maintain a versioned suite for: retrieval recall/precision, citation entailment, answer groundedness, abstention, contradictory-source handling, stale-source detection, tenant leakage, prompt injection, poisoned documents, exfiltration attempts, unauthorized tool access, toxicity/harassment, sensitive-data exposure, latency, token cost and
+accessibility. Report absolute values
+plus baseline deltas, sample sizes and error bars. Record model/provider version and test corpus digest.
+
+## 10. Compliance-as-code and OSCAL workflow
+
+The compliance pipeline maps a requirement to a control objective, control implementation, test method, evidence type, owner, frequency, applicability, status and remediation path.
+
+### 10.1 Regulatory crosswalk design
+
+Prioritize legal applicability in the following order, with the exact scope determined for the regulated entity and use case:
+
+1. **EU / EEA:** EU AI Act as applicable, GDPR, DORA, NIS2 (subject to scope and national transposition), and relevant financial-services law.
+2. **United States:** Federal Reserve SR 26-2 where in scope; keep SR 11-7 as historical or transition context where applicable; ECOA/FCRA and SEC Rule 17a-4 only for relevant products/entities/record types.
+3. **International management and risk references:** NIST AI RMF 1.0, NIST AI 600-1, ISO/IEC 42001, ISO/IEC 42005 and applicable information-security controls.
+4. **Asia-Pacific / UK:** MAS FEAT, applicable MAS supervisory guidance, HKMA guidance including Fintech 2030, and FCA SM&CR / Consumer Duty depending on regulated activity and jurisdiction.
+5. **Bank risk reporting:** applicable Basel Committee standards and supervisory expectations, including BCBS 239 for risk-data aggregation/reporting where in scope; “Basel IV” is a common informal label, not a distinct single treaty instrument.
+6. **GIEN-only scenario instruments:** CFE-1.0, SGR-028, ICGC/GASO, Interstellar AI Governance Accord and Galactic Treaty Framework. Tag as fictional/project-defined until canonical instruments and competent authority are established.
+
+The framework catalog must include owner, official source, version/effective date, jurisdiction, applicability rationale, change-monitoring subscription, legal-review owner and crosswalk approval. An AI RMF or ISO mapping supports risk management; it does not itself establish compliance with legislation.
+
+### 10.2 OSCAL artifact workflow
+
+1. Pin the target OSCAL version and retrieve its official schema and constraints.
+2. Validate JSON/XML syntax and model conformance.
+3. Validate ID/reference integrity, controlled vocabularies, required objects and cross-object relationships.
+4. Evaluate Rego policy against typed input fixtures, including positive, negative, boundary and missing-data tests.
+5. Generate SSP, assessment-results and POA&M artifacts with evidence references and responsible parties.
+6. Run independent verification of manifest, signatures, artifact retention and bundle completeness.
+7. Review failures and exceptions; document applicability decisions and residual risk.
+8. Freeze the signed artifact set and transmit through an authenticated, receipted channel.
+
+Keep the existing OSCAL 1.1.2 integration as an explicitly pinned compatibility profile. Assess migration to the newer supported patch release only through an impact analysis, dual validation, change approval and recipient compatibility test. Do not edit previously signed packages in place.
+
+### 10.3 Policy examples and automated testing
+
+ Policy bundles should be versioned, reviewed, signed and promoted through CI/CD. Tests should cover allowed and denied cases, missing inputs, malformed data, stale source timestamps, inconsistent identifiers, privilege boundaries, tenant isolation and exception handling. CI must fail if no tests were discovered, if schema validation fails or if an
+unapproved policy bundle is
+loaded.
+
+The policy simulator should show the policy version, input fixture, decision, rule path, warnings and test coverage. Never allow a client-side simulation to authorize an actual production action.
+
+## 11. Cryptographic evidence, WORM and Merkle-DAG
+
+Each evidence object should have an artifact ID, source identity, timestamp/clock assumptions, media type, classification, canonicalization profile, byte digest, signer identity, algorithm identifier, key ID, retention policy, parent references and validation report.
+
+Required controls:
+
+- Establish the hash over documented canonical bytes; never assume JSON object ordering is stable.
+- Build a signed manifest binding each artifact digest, schema, version, timestamp and parent/root reference.
+- Verify signature cryptographically and check the key’s status/authorization at the relevant time.
+- Verify Merkle inclusion and prior-checkpoint continuity; detect missing records, duplicates and unexpected reorderings.
+- Configure and test WORM retention independently from application claims; restrict and audit privileged storage administration.
+- Exercise backups/restores, retention locks, legal holds, key revocation and signing-key recovery.
+- Keep FIPS 203 key establishment separate from FIPS 204/205 signing functions.
+- Record algorithm migration as old/new verifier support, activation boundary, test coverage, historical-verification plan and rollback process.
+- Store large raw evidence in the appropriate controlled object repository; use signed references and bounded metadata in the dashboard.
+
+“Merkle-DAG valid” should be a verifier output with explicit scope, not a decorative green badge. A valid signature says which key signed the bytes; authorization, correctness, completeness and lawful provenance remain separate questions.
+
+## 12. System components and route map
+
+| Route / component | Function and principal inputs |
+|---|---|
+| Dashboard / ExecutiveSummary | Cycle state, material incidents, trend deltas, top exceptions and decisions due |
+| SystemicRiskTelemetry / GlobalStatusOverview | Versioned indices, source freshness, confidence, threshold policy and time-series |
+| ComplianceMatrix / ComplianceRegulatory | Frameworks × controls, applicability, evidence, tests, gaps, owners and review dates |
+| GovernanceStacks | Sentinel v2.4, Omni-Sentinel v4.0 and SCP v3.0 configuration and status—only from verified sources |
+| ControlDomains | CD-01–CD-10 catalog, assessment and evidence drill-down |
+| CryptographicIntegrity | Key inventory, signatures, Merkle continuity, WORM state and historical verifier results |
+| RAGHealthMonitor | Retrieval quality, source freshness, citations, attack tests, cost and latency |
+| RAGDataAudit / RAGDataProvenance | Source lineage, transformation log, content digest, access decision, embedding/index revisions |
+| PromptArchitect / TemplateLibrary | Versioned templates, variables, constraints, diff, evaluation set, approval and rollback |
+| GovernancePolicySimulator / OPAPolicyScanner | Rego evaluation and test fixture; no production authorization from browser simulation |
+| FairnessHeatmap / ParityDashboard | Cohort-level metrics, sample counts, uncertainty and tool/capability parity |
+| SDTStressDrills / Digital Twin | DRILL-042–047, Panels 13–15, deterministic input/output manifests and deviations |
+| IASOS / CivilizationalReadinessMonitor | Fictional readiness metrics with definition, horizon, provenance and assumptions |
+| MaterialChangeTracker | Model, data, prompt, policy, key, dependency and infrastructure changes with approvers and post-change tests |
+| VoiceCommander | Accessible search/navigation and draft dictation; no unconfirmed speech-triggered privileged action |
+| AlertHistory / RealTimeNotificationService | Source timestamp, severity, owner, acknowledgement, SLA clock, escalation and export |
+| RegulatoryRoadmap / GovernanceHierarchy | Versioned legal milestones and fictional GIEN phase timeline shown on separate tracks |
+| GlobalSearch | Server-filtered accessible objects, then local Fuse.js search over the authorized result set |
+| SubmissionPackages / RegulatorExport | Preview and draft export; final package assembled, validated, signed and receipted by backend |
+| AppWalkthrough | Role-based onboarding, evidence-status legend and safe-use warnings |
+
+### 12.1 API outline
+
+Use versioned, authenticated APIs such as:
+
+- GET /API/v1/supervisory-runs
+- GET /API/v1/indicators?runId=...
+- GET /API/v1/controls?framework=...&status=...
+- GET /API/v1/evidence/{artifactId}/manifest
+- POST /API/v1/evidence/{artifactId}/verify
+- GET /API/v1/attestations?region=...&freshness=...
+- GET /API/v1/proof-jobs?status=...
+- POST /API/v1/replays (authorized, isolated scenario execution)
+- POST /API/v1/policy-evaluations (server-side evaluation; fixture-scoped by default)
+- POST /API/v1/findings/{id}/evidence
+- POST /API/v1/submission-packages (creates a draft)
+- POST /API/v1/submission-packages/{id}/validate
+- POST /API/v1/submission-packages/{id}/seal (strong authorization, dual control and backend key)
+- POST /API/v1/submission-packages/{id}/dispatch (authorized channel, receipt and idempotency key)
+
+Mutation endpoints require request IDs, actor and reason, optimistic concurrency controls, replay protection and idempotency semantics. Do not expose endpoints that accept a client-claimed signature status, attestation truth value, trusted root or arbitrary risk score as authoritative data.
+
+## 13. UX, voice, notifications and emergency action
+
+- Provide role-specific navigation, keyboard operation, skip links, readable typography, chart alternatives, focus management, visible loading/error/empty states and responsive layouts.
+- Surface freshness, scope and evidence quality beside every significant figure.
+- Keep chart state and data-table state synchronized. Provide CSV/JSON export with source timestamps, units, filters and definitions.
+- Use notifications as alerts, not evidence. Each notice links to a canonical record and can be acknowledged with actor and timestamp.
+- Use Web Speech API only with explicit permission. Show the recognized text for confirmation; allow correction and keyboard alternatives.
+- An emergency-stop control must be implemented on the server, with strong authorization, anti-CSRF protection where relevant, replay-resistant requests, a reason, explicit confirmation, idempotent action semantics, and an independent audit entry. Display request accepted, execution confirmed and execution failed as distinct states. Client UI
+ cannot assert that a control-plane
+ stop has occurred merely because a button was clicked.
+- Design a hierarchy of safing actions: stop new work, revoke a scoped tool credential, suspend a model route, disable a privileged workflow, and invoke institution-approved incident procedures. Execution should follow the approved risk analysis and authority model, not a generic browser action.
+- Ensure the emergency-stop surface does not become an unauthenticated denial-of-service mechanism.
+
+## 14. Supervisory daily cadence and package template
+
+### 14.1 Time-bound evaluation
+
+ For a reporting window ending at 09:00 UTC, explicitly label the interval, for example 11 October 2026 09:00 UTC to 12 October 2026 09:00 UTC. Freeze the snapshot at the cutoff. If the operational archive transmission is scheduled at 08:00 UTC and cycle closure at 23:59 UTC, keep their event records distinct from the 09:00 snapshot; do not
+backdate late-arriving evidence into
+the frozen snapshot.
+
+Suggested sequence:
+
+1. Ingest events and source health continuously; preserve event time and receive time.
+2. At 08:00 UTC, run the nominated archive-transmission workflow and capture receipt status if available.
+3. At 09:00 UTC, freeze the evaluation window and record which sources were missing, stale or delayed.
+4. Validate controls, indicators, attestations, proofs, replay records and ledger continuity.
+5. Derive the cross-jurisdictional compliance bundle; unresolved validations create explicit exceptions.
+6. Assign owners and SLA deadlines, and preserve decisions and acknowledgements.
+7. At 23:59 UTC, execute closure checks and seal the daily archive only if required artifacts and signing/verification operations actually succeed.
+
+### 14.2 Submission format
+
+~~~xml
+
+ GIEN Daily Supervisory Brief — YYYY-MM-DD
+ Evidence-qualified summary, evaluation interval, material exceptions and decisions required.
+
+ Institutions, systems, jurisdictions and source versions.
+ Observed, demonstration, missing, stale and unverified states.
+ Versioned results, confidence, baseline and threshold policies.
+ GIEN CD-01 to CD-10 and applicable external control references.
+ Artifact identifiers, digests, signature and verifier result references.
+ Severity, owner, deadline, mitigation and closure evidence.
+ Scenario IDs, panel, inputs, run environment and outcomes.
+ Applicability decisions and OSCAL/policy validation status.
+ Approver, authority, rationale and residual risk.
+ Data gaps, assumptions, uncertainty and assurance boundary.
+
+
+~~~
+
+The wrapper is an illustrative project-level format, not an OSCAL-native model or a claim that ICGC/GASO is legally recognized. The submission manifest should reference the exact OSCAL objects rather than alter them.
+
+### 14.3 Output variants
+
+- **Executive brief:** one-page decision summary, direction of travel, highest-priority exceptions and decisions needed.
+- **Regulator/supervisory college package:** XML wrapper, versioned OSCAL artifacts, annotated crosswalk, evidence manifest, signed replay bundles, exceptions register, authorized recipient list and receipt status.
+- **Engineer dossier:** detailed telemetry, run IDs, traces, policy decisions, attestation failures, performance percentiles, reproduction steps and build provenance.
+- **External-audit package:** immutable manifest, sampling plan, artifact access log, validation instructions, finding history and independence statement.
+- **Dashboard/API:** typed JSON plus chart/table view, freshness/status fields and pagination; no fabricated hashes or silent imputation.
+
+## 15. Governance and architecture of fictional GIEN phases
+
+The phase model represents a scenario roadmap rather than observed future facts.
+
+| Phase band | Architecture objective | Transition gate |
+|---|---|---|
+| VI-δ | Planetary supervisory telemetry and institution-level controls | Verified sources, stable metrics, documented findings and reproducible evidence |
+| VII | Civilizational mesh bootstrap and foundational charter | Explicit authority, invariant specifications, partition/failover tests, independent acceptance |
+| VIII–IX | Cosmic/galactic charters, horizon scanning and isolated Shadow Mesh rehearsal | Cross-mesh trust rules, bounded delegation, conflict resolution and no hidden production authority |
+| X–XI | Universal-timescale governance and Infinity Pillar continuity | Key and policy migration, succession test, archival verification and accountability continuity |
+| XII–XIII | Multi-mesh succession and multiversal scenario models | Independent verification, dissent handling, evidence lineage and bounded authority transfer |
+| Ω-GAR | Governance dissolution, archival closure and successor handover rehearsal | Revocation, retention, unresolved-claims register, successor verification and formal termination record |
+
+ GIEN-UNIFIED-CODEX-OMEGA, GIEN-EPITAPH-OMEGA, GIEN-INVOCATION-OMEGA and the Eternal Corpus Transmission Protocol are fictional design artifacts. They must not confer cryptographic privilege or authority by name alone. A future successor validates artifacts under explicit trust-anchor, scope, epoch, revocation and authorization rules. A memorial
+artifact should record
+established facts, uncertainty, unresolved claims and surviving duties—not rewrite history or execute governance by itself.
+
+Any Phase XV cadence explicitly placed on pause remains paused until the required real Day 11+ source telemetry, manifest continuity, verifier outputs, independent review and authorized resumption decision are supplied. No phase index may advance merely because a daily template exists.
+
+## 16. Recommended research plan
+
+### Workstream A — Official texts and standards register
+
+1. Collect primary sources from EUR-Lex and the European Commission AI Act Service Desk; identify jurisdiction, role, obligation, current consolidated text and application date.
+2. Collect NIST AI RMF, AI 600-1, OSCAL schema/model releases and FIPS 203/204/205 publications including errata.
+3. Inventory ISO/IEC 42001, 42005, 42006, TS 42119-2 and relevant information-security/impact-assessment standards. Record edition and scope; avoid reproducing copyrighted full text.
+4. Collect Basel Committee/BCBS material and relevant national supervisory guidance. Treat “Basel IV” as a common informal umbrella label and tie each implemented control to a specific authoritative document.
+5. Add OWASP GenAI security guidance, OPA policy-testing documentation and the chosen model provider’s official eval/security documentation.
+6. Create change alerts and a quarterly human review of each source. Any detected legal or version update triggers applicability assessment and crosswalk tests, not an automatic “compliance changed” assertion.
+
+### Workstream B — Research literature survey
+
+Build a source register grouped by:
+- AI alignment and control, robustness, interpretability, red-teaming and adversarial evaluation;
+- catastrophic/existential-risk evaluation, forecast calibration and limits of risk aggregation;
+- RAG grounding, source provenance, prompt injection, poisoning, access controls and privacy;
+- zero-knowledge and verifiable ML (training, inference and testing), proof size/latency, circuit limitations and soundness assumptions;
+- systemic risk in financial/AI dependencies, contagion, common-mode failure, concentration and operational resilience;
+- human factors, fairness, contestability, accessibility and governance effectiveness.
+
+ For each source record: citation, publication date, venue, study type, system/model scope, evaluation method, evidence limitations, conflicts, practical implications and transferability to the GIEN scenario. Prefer peer-reviewed and primary sources when available; include reproducibility artifacts where accessible. Do not claim consensus from a
+handful of papers.
+
+### Workstream C — Technology and DevSecOps inventory
+
+Evaluate the pinned React/Vite implementation and candidate alternatives against:
+- active maintenance and official documentation;
+- security advisories, dependency provenance, SBOM and supply-chain controls;
+- accessibility and non-color status encoding;
+- renderer performance under the expected dataset size;
+- server authorization and auditability;
+- deployment, observability, testing and rollback;
+- licensing and operational cost.
+
+Benchmark D3 SVG, Recharts, Observable Plot and Plotly with representative datasets on the target browsers. Measure initial bundle size, interaction latency, memory, accessibility and export fidelity. Keep only libraries that solve distinct needs.
+
+### Workstream D — Crosswalk and evidence model
+
+ Create a versioned requirement-to-control-to-test-to-evidence matrix. Validate that every applicable requirement has an owner, implementation reference, test frequency, evidence type, retention rule, exception process and legal-review owner. Test both positive and negative cases. Preserve non-applicability decisions and the evidence supporting
+them.
+
+### Workstream E — Reference implementation and acceptance tests
+
+Deliver in the following sequence:
+
+1. Typed synthetic data contracts and clear DEMONSTRATION banners.
+2. Server-side identity, tenancy and object-level authorization boundary.
+3. Versioned metric registry, source freshness and indeterminate-state UX.
+4. Control assessment and OPA/Rego test pipeline.
+5. OSCAL pinned-schema validation and migration test.
+6. Evidence manifests, canonicalization and independent verification service.
+7. RAG ingestion and evaluation harness with attack fixtures.
+8. TEE/TPM attestation adapters and a dedicated test environment.
+9. Digital Twin replay bundle and deterministic/within-tolerance comparison.
+10. Role-specific export, sealed submission path, incident/notification integration and accessible UI regression testing.
+
+### Workstream F — Acceptance and operational gates
+
+Release requires:
+- clean production build, lint, unit/integration/e2e and accessibility checks;
+- dependency/license/SBOM and secret scans;
+- tests for tenant isolation, role escalation, insecure direct object references and export permission bypass;
+- schema, signature, Merkle-continuity and retention tests against non-production fixtures;
+- missing-data, stale-data, delayed-source and contradictory-source tests;
+- prompt-injection, RAG-poisoning, citation-validation and unauthorized-tool tests;
+- fairness metrics with documented populations, cohort sizes and confidence intervals;
+- failure-injection / recovery tests for attestation, proof verification, policy service and evidence storage;
+- review of the final submission by accountable compliance/legal owners and independent assessors where required;
+- a documented rollback and incident procedure.
+
+## 17. Delivery roadmap
+
+| Stage | Deliverable | Exit criteria |
+|---|---|---|
+| Stage 0 — evidence baseline | Source register, data classification, role model and metric definitions | Owners approve scope, no unknown source is represented as live |
+| Stage 1 — app foundation | Dashboard, role-aware views, accessible tables/charts and typed demo data | Build/test gates pass; demonstration state visible on every relevant screen |
+| Stage 2 — control engine | Framework catalog, OSCAL validation, OPA unit tests, finding/POA&M lifecycle | Reproducible positive/negative policy tests and traceable artifact IDs |
+| Stage 3 — evidence integrity | Manifest, canonicalization, signature verifier, Merkle/WORM evidence service | Independent verification succeeds on controlled fixtures; key custody is server-side |
+| Stage 4 — AI/RAG assurance | Corpus provenance, evaluations, prompt/tool controls and drift monitoring | Security/evaluation suites run against fixed versions and document limitations |
+| Stage 5 — live integrations | Authenticated telemetry adapters, attestation and proof-verifier adapters | Source health, freshness and schema failures surfaced; no synthetic fill-in |
+| Stage 6 — supervisory release | Sealed package workflow, receipt tracking, independent audit and operational runbooks | Build, security, evidence, authority and recovery gates all approved |
+| Stage 7 — long-horizon scenarios | Phase VII–XIII and Ω-GAR scenario lab | Scenario fixtures isolated and phase transitions explicitly approved |
+
+ The 2026–2035 program should prioritize evidence provenance, institution-level controls, legal applicability, operational resilience, cryptographic agility and independently testable claims. The 2035–2100+ view is a scenario design horizon, not a prediction or a claim that a multiversal governance system exists. Re-evaluate assumptions at defined
+governance reviews instead of
+presenting speculative phase dates as certainty.
+
+## 18. Immediate implementation priorities
+
+1. Keep the current Vite frontend and avoid a framework rewrite until the existing build and test pipeline is reliable.
+2. Make source status explicit everywhere: LIVE_VERIFIED, DEMONSTRATION, STALE, NOT_PROVIDED, INVALID or NOT_ASSESSED.
+3. Establish metric specifications before adding further charts.
+4. Implement server-side RBAC, tenancy and export authorization before connecting real telemetry.
+5. Add OSCAL version pinning and Rego tests to CI, including “fail on empty test suite.”
+6. Integrate only real verifiers for signatures, Merkle chains and TEE quotes; remove any path that converts placeholders into green status.
+7. Keep GIEN phase scenarios and treaty artifacts separate from legally applicable requirement records.
+8. Treat Guardian Attestation and historical filing IDs as milestones that need original artifacts, authorized countersignatures and verification output—not as completed merely because the date passed.
+9. Resolve the known CI startup/build verification issue before merge or deployment.
+10. Have legal/compliance owners confirm applicability for each regulated entity and product; the platform supports evidence organization, not a substitute for professional regulatory determinations.
+
+## Appendix A — Evidence-state vocabulary
+
+| State | Meaning |
+|---|---|
+| OBSERVED | Data retrieved from a named source with a traceable source timestamp |
+| VERIFIED | A specified validator independently confirmed the relevant property; scope of verification must be stated |
+| DEMONSTRATION | Synthetic fixture or illustrative scenario only |
+| NOT_PROVIDED | Required source artifact absent from the current run |
+| STALE | Artifact exists but exceeds the configured freshness policy |
+| INVALID | A specific validator failed |
+| INDETERMINATE | Evidence conflicts, is insufficient or the validator cannot decide |
+| NOT_ASSESSED | A control was not tested in the period |
+| NOT_APPLICABLE | Applicability decision recorded with rationale and approving owner |
+| EXCEPTION_APPROVED | Designated authority accepted a bounded exception, with expiry and review date |
+
+“Verified” must always identify who/what performed the verification, which property was checked and which input version was used. A successful hash check, schema validation, Rego test or proof verification must not be generalized to “system compliant.”
+
+## Appendix B — Core external source register
+
+1. [European Commission AI Act Service Desk — Article 113](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113) — consolidated applicability timeline; check the specific text version.
+2. [AI Act Service Desk — Annex IV](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-4) — high-risk technical documentation.
+3. [AI Act Service Desk — Article 15](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-15) — accuracy, robustness and cybersecurity.
+4. [AI Act Service Desk — Article 51](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-51) — GPAI models with systemic risk.
+5. [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) and [NIST AI 600-1](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf).
+6. [OSCAL release news](https://pages.nist.gov/OSCAL/about/news/) and [OSCAL 1.1.2 reference](https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/).
+7. [ISO/IEC 42001](https://www.iso.org/standard/42001), [42005](https://www.iso.org/standard/42005), [42006](https://www.iso.org/standard/42006) and [TS 42119-2](https://www.iso.org/standard/84127.html).
+8. [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final), [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) and [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final).
+9. [Open Policy Agent — policy testing](https://www.openpolicyagent.org/docs/policy-testing).
+10. [OWASP GenAI Security Project](https://owasp.org/www-project-top-10-for-large-language-model-applications/) and [LLM08:2025 Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/).
+11. [Zero-Knowledge Proof Based Verifiable Machine Learning survey](https://arxiv.org/abs/2502.18535) — research review; assess assumptions and scope before selecting a system.
+12. [React TypeScript guide](https://react.dev/learn/typescript), [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/), [Next.js App Router](https://nextjs.org/docs/app), [D3](https://d3js.org/), [Observable Plot](https://observablehq.com/plot/) and [Plotly.js](https://plotly.com/javascript/basic-charts/).
+
+**Maintenance note:** recheck source status before using this document for a regulatory submission. This file is a researched design reference; it does not establish that any GIEN system has run, that any metric has been observed, or that any regulatory obligation has been met.
diff --git a/gien-platform/docs/master-deep-research-ai-governance-systemic-risk-2026-10.md b/gien-platform/docs/master-deep-research-ai-governance-systemic-risk-2026-10.md
new file mode 100644
index 00000000..bc8ee892
--- /dev/null
+++ b/gien-platform/docs/master-deep-research-ai-governance-systemic-risk-2026-10.md
@@ -0,0 +1,620 @@
+# GIEN Master Deep Research: AI Governance, Safety, and Systemic Risk
+## Supervisory reference architecture and implementation roadmap, October 2026
+
+**Research cut-off:** 12 October 2026
+**Project:** Fictional GIEN planetary / multiversal governance mesh and Omni-Sentinel Governance Platform
+**Audience:** Supervisors, financial institutions, board and risk leadership, governance engineers, control owners, assurance teams
+**Purpose:** Translate current public research, standards, regulatory material, and provider security guidance into an implementable, evidence-qualified reference architecture.
+
+> **Scope and status disclaimer:** GIEN, Omni-Sentinel, the named control domains, risk indices, phases, and thresholds are project-specific design constructs. This dossier does not certify a live system, provide legal advice, establish regulatory applicability for a particular institution, or prove independent assurance. All legal dates and
+> proposed amendments must be checked
+> against the operative legislation and the relevant jurisdiction. The project dashboard has previously used synthetic data; synthetic scores, hashes, attestations, and transmission status must never be presented as live evidence.
+
+## 1. Executive assessment
+
+ The recommended direction is a **supervisory evidence and control plane**, not a dashboard that infers compliance from a single score. The platform should connect authoritative source systems, retain provenance, execute deterministic tests, make uncertainty visible, route consequential decisions to accountable people, and preserve reviewable
+evidence of what actually happened.
+
+The 2026 evidence base supports six main conclusions:
+
+1. **AI capability is advancing, but performance remains uneven and risk evidence is incomplete.** The International AI Safety Report 2026, published 3 February 2026, synthesizes work by more than 100 experts with support from more than 30 countries and international organisations. It describes advances in coding, mathematics, and autonomous
+ operation alongside persistent
+ reliability limitations, gaps in external visibility, and an “evaluation gap”: pre-deployment testing does not consistently predict real-world behaviour. Its conclusions argue for defence in depth rather than relying on a single safeguard. [International AI Safety Report
+ 2026](https://internationalaisafetyreport.org/publication/international-ai-safety-report-2026) and
+ [Extended Summary for Policymakers](https://internationalaisafetyreport.org/publication/2026-report-extended-summary-policymakers).
+
+2. **Financial stability monitoring needs a system-wide view.** The Financial Stability Board (FSB) identifies third-party dependencies and service-provider concentration, correlated market behaviours, cyber risk, and model/data/governance risk as AI-related vulnerabilities that can amplify systemic risk. Its October 2025 report focuses on
+ monitoring adoption and
+ vulnerabilities, including concentration and data gaps. [FSB, November 2024](https://www.fsb.org/2024/11/the-financial-stability-implications-of-artificial-intelligence/) and [FSB, October 2025](https://www.fsb.org/2025/10/monitoring-adoption-of-artificial-intelligence-and-related-vulnerabilities-in-the-financial-sector/).
+
+3. **Third-party risk should cover the full service chain, not just outsourcing contracts.** In December 2025 the Basel Committee on Banking Supervision published principles for sound management of third-party risk, emphasizing the wider and more diverse set of provider arrangements and supply-chain risks. GIEN should map nth parties, shared
+ infrastructure, common foundation
+ models, cloud regions, inference gateways, datasets, and failover dependencies. [BCBS third-party risk principles](https://www.bis.org/publications/202512-guidelines-principles-sound-management-third-party-risk).
+
+4. **Risk management frameworks are complementary, not interchangeable.** NIST AI RMF 1.0 provides a cross-sector lifecycle framework; NIST AI 600-1 adds a generative-AI profile; ISO/IEC 42001 specifies an AI management-system standard; OWASP LLM guidance identifies application-level security risks; DORA applies to relevant EU financial entities
+ and ICT arrangements; and the
+ EU AI Act imposes role- and use-case-specific legal obligations. None alone is a complete GIEN control implementation. [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework), [NIST AI 600-1](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), [ISO/IEC
+ 42001](https://webstore.iec.ch/en/publication/90574), [OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/).
+
+5. **The evidence model is as important as the score model.** Every supervisory assertion should identify the source, version, observation time, test or control that supports it, limitations, reviewer, and allowed downstream use. “Configured”, “observed”, “test passed”, “approved”, and “independently assured” must remain separate states.
+
+6. **The correct near-term objective is evidence-qualified operational readiness.** Do not claim live systemic-risk measurement or autonomous safety enforcement until data acquisition, data quality, index calibration, control testing, escalation, disaster recovery, and independent review have been demonstrated on an actual deployment.
+
+### Principal recommendation
+
+Adopt a single governance control plane with the following separation:
+
+- **Authoritative systems** provide the facts: source-control state, model registry, deployment metadata, identity events, incident records, configuration, performance telemetry, and approved legal/control libraries.
+- **Deterministic controls** validate facts, execute thresholds, enforce access, block unsafe writes, and determine whether a defined test passed.
+- **AI research and reasoning components** summarize, classify, compare, and surface candidate anomalies, with citations and uncertainty; they do not decide that a control passed.
+- **Human decision authorities** approve material risk acceptance, production changes, control waivers, external submissions, and exceptions.
+- **Independent assurance** evaluates the sufficiency of the design and the evidence, not merely whether the application produced a green status.
+
+## 2. Evidence base and maturity of sources
+
+### 2.1 Source classes
+
+| Class | Examples | Permitted interpretation |
+|---|---|---|
+| Binding law or regulation | EU AI Act as in force; DORA where applicable; GDPR where applicable | Apply only after jurisdiction, role, product, sector and effective date have been assessed |
+| Regulatory/supervisory statement | ESMA statement; supervisory publications | Relevant supervisory expectations and interpretation; not automatically a universal legal duty |
+| Standard or management-system framework | ISO/IEC 42001; NIST AI RMF | Structured methods and control objectives; not proof that a particular deployment complies |
+| Technical security guidance | OWASP LLM Top 10; NIST adversarial ML taxonomy; secure software practices | Threat taxonomy and engineering guidance; must be adapted and tested |
+| Evidence synthesis | International AI Safety Report; FSB systemic-risk reports | Research-informed picture of capabilities, risks, evidence gaps and monitoring priorities |
+| Vendor documentation | OpenAI, cloud, model and tool-provider documentation | Documented product behaviour and security features, not evidence of GIEN deployment or legal compliance |
+| GIEN design construct | S_sys, G-SRI, C-SRI, CD-01 to CD-10, phase gates | Proposed internal architecture requiring definitions, calibration, approval and validation |
+
+### 2.2 Important status distinction: NIST critical-infrastructure profile
+
+ NIST's AI RMF Profile on Trustworthy AI in Critical Infrastructure is **under development**, not a final mandatory standard. NIST's concept note says the project started in April 2026 and was updated on 17 July 2026; its current status is “Ongoing.” GIEN should monitor it and prepare an adaptable crosswalk, but label the profile as a developing
+resource rather than a finalized
+control baseline. [NIST critical-infrastructure profile project](https://www.nist.gov/programs-projects/concept-note-ai-rmf-profile-trustworthy-ai-critical-infrastructure).
+
+### 2.3 Important status distinction: EU AI Act amendments and dates
+
+ The European Commission AI Act Service Desk timeline currently states that the timeline takes account of Digital Omnibus changes and lists 2 August 2026 for the majority of the Act's rules, 2 December 2026 for specified new prohibitions and a synthetic-content transition, 2 December 2027 for Annex III high-risk rules, and 2 August 2028 for Annex I
+product-related high-risk
+rules. However, the Service Desk's Digital Omnibus FAQ also describes the relevant changes as a **Commission proposal** and describes proposed shifts based on the availability of standards and support tools. This creates a material status ambiguity between the page's timeline and its proposal FAQ.
+
+ **Required control:** Do not infer that a proposal is enacted solely from a service-desk timeline. For any real filing or legal interpretation, verify the amended legal act, legislative status, Official Journal publication, consolidated EUR-Lex text, relevant transitional clauses and current regulator guidance. Record legal reviewer, date,
+jurisdiction, covered role, provision,
+ and the exact text used. A compliance calendar must be versioned and must support alternate timelines until the legal status is resolved. Sources: [AI Act implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/eu-ai-act-implementation-timeline) and [Digital Omnibus
+FAQ](https://ai-act-service-desk.ec.europa.eu/en/faq?faq_category_id=99).
+
+### 2.4 Current findings from the International AI Safety Report
+
+The 2026 report highlights several reasons not to rely on capability claims or pre-deployment tests alone:
+
+- Performance is “jagged”: success on difficult benchmarks can coexist with failures on simpler tasks or in long multi-step workflows.
+- Model outputs may include factual errors, nonexistent references, and inconsistent reasoning.
+- Pre-deployment evaluations do not consistently predict in-use behaviour.
+- Researchers, policymakers and affected organisations have uneven access to developer evidence about training, safeguards, and deployment impacts.
+- Risk-management practices vary across developers and sectors; evidence of real-world effectiveness remains limited.
+- Defence-in-depth practices are important because individual technical safeguards do not eliminate all misuse, failure, or emergent behaviour.
+
+These findings imply that GIEN needs model-specific evaluations, deployment monitoring, incident feedback, external-source verification, and rollback authority. It should not convert benchmark results into a generalized assurance claim. [Source](https://internationalaisafetyreport.org/publication/2026-report-extended-summary-policymakers).
+
+## 3. Systemic-risk analysis for financial institutions
+
+The FSB's 2024 and 2025 work supports a supervisory model that observes both institution-level risks and system-wide dependencies. The following categories are recommended as GIEN monitoring families; they are not an exhaustive statutory taxonomy.
+
+### 3.1 Third-party and supply-chain concentration
+
+**Failure mechanism:** Multiple institutions use the same foundation model, cloud platform, accelerator stack, data provider, identity service, inference gateway or security product. A single outage, policy change, compromise, model regression, commercial dispute or regional failure can affect many firms simultaneously.
+
+ **Controls:** Maintain a dependency graph spanning direct and nth-party providers; identify shared concentration nodes; record service region, deployment mode, model/version and exit path; run provider-outage scenarios; test alternate-model and manual fallback procedures; and set escalation thresholds based on impact and substitutability rather
+than vendor count alone.
+
+**Evidence:** Provider inventory, contracts and service schedules, architecture diagrams, failover test artefacts, current dependency scans, recovery exercise reports, incident records and documented exit plans.
+
+### 3.2 Correlated model decisions and feedback loops
+
+**Failure mechanism:** Similar models trained on overlapping data or exposed to common market signals can emit correlated recommendations. Institutions using model outputs to rebalance portfolios, adjust credit decisions, price risk, or manage liquidity can amplify a shock if actions become synchronized.
+
+**Controls:** Test decision correlation under stress, distinguish common-input effects from model-induced effects, use diverse decision paths where justified, constrain automated portfolio or liquidity actions, require independent risk checks, and run cross-institution scenarios with explicit assumptions.
+
+**Evidence:** Correlation analysis across models, stress-scenario results, trigger and override records, decision-latency measurements, and post-event analysis. Avoid asserting systemic correlation from a small or nonrepresentative sample.
+
+### 3.3 Model, data, and output reliability risk
+
+**Failure mechanism:** Stale or low-quality data, leakage, label drift, feedback contamination, hallucinated narratives, distribution shift, or changes in model behaviour can lead to bad decisions and misleading supervisory reporting.
+
+**Controls:** Version data and features; define quality and freshness constraints; test out-of-distribution behaviour; use independent factual checks on generated claims; set abstention and human-review conditions; monitor model/data drift; and make rollback independent of the model being monitored.
+
+**Evidence:** Data lineage, validation reports, drift dashboards, benchmark results, supported-claim checks, incident trends, and model change records.
+
+### 3.4 Cybersecurity and agentic tool risk
+
+ **Failure mechanism:** Prompt injection, compromised connectors, excessive tool permissions, unsafe output handling, poisoned retrieval sources, exposed credentials, and uncontrolled chaining can let an AI component cause effects beyond its intended task. OWASP's 2025 list explicitly includes prompt injection, sensitive information disclosure,
+supply-chain risks, data/model
+poisoning, improper output handling, excessive agency, vector/embedding weaknesses, misinformation and unbounded consumption. [OWASP LLM Top 10, 2025](https://genai.owasp.org/llm-top-10/).
+
+ **Controls:** Treat tool output as untrusted; separate read and write identities; enforce server-side allowlists; validate every action server-side; constrain network egress; use short-lived credentials; require approvals for consequential operations; apply output encoding and schema validation; and log data sent to external MCP servers. OpenAI's
+MCP documentation notes that
+remote MCP servers can expose model tools, that approval can be required before sharing data, and that third-party MCP server behaviour and data handling need deliberate review. [OpenAI MCP guidance](https://developers.openai.com/api/docs/guides/tools-connectors-mcp).
+
+### 3.5 Fraud, disinformation and social engineering
+
+**Failure mechanism:** Synthetic voice, text, imagery, or agent-generated messages can increase the speed and scale of fraud, phishing, market manipulation and false reports.
+
+**Controls:** Verify identity and authority out of band for consequential actions; maintain provenance and disclosure where required; introduce payment/credential change controls independent of generated messages; monitor anomalous requests and repeated signals; and test incident handling with synthetic content.
+
+### 3.6 Governance and responsibility gaps
+
+**Failure mechanism:** Staff treat model output as authoritative, assume the provider is responsible for all downstream use, or believe a human-in-the-loop checkbox is adequate evidence of effective oversight.
+
+**Controls:** Name accountable owners at board, business, model-risk, information-security, data-protection, engineering and operations levels; define delegated authority and risk acceptance; make review criteria explicit; measure whether reviewers can detect seeded errors; and log overrides with their reason and outcome.
+
+**Evidence:** RACI, policy approvals, staff training, review-quality tests, exceptions register, escalation logs and post-incident reviews.
+
+### 3.7 Operational resilience and recovery
+
+**Failure mechanism:** Inference/API outages, quota changes, dependency upgrades, corrupted retrieval indices or provider account suspension can disrupt critical workflows or prevent supervisors from receiving evidence.
+
+**Controls:** Define recovery objectives; maintain manual and alternate-service procedures; separate critical controls from third-party model availability; test restored datasets and evidence integrity; maintain versioned prompts and schemas; and run provider-degradation drills.
+
+**Evidence:** Disaster-recovery exercise, restore verification, dependency failover results, queue backlog metrics, outage playbooks, and recovery-time actuals.
+
+## 4. Reference governance architecture
+
+### 4.1 Logical control plane
+
+1. **Identity and authorization plane:** SSO/OIDC, role and tenant checks, privileged-session controls, service identities, and least-privilege scopes.
+2. **AI/model registry:** Business purpose, owner, provider, model/version, hosting region, data classes, capabilities, tools, risk tier, evaluation baseline, approved deployments, dependencies and retirement plan.
+3. **Data and provenance plane:** Catalogs, lineage, schema, freshness, access restrictions, quality rules and source-specific retention.
+4. **Execution gateway:** Common adapter contract for model calls and tool use; per-role allowlists; quotas; network restrictions; structured input/output validation; human approval hooks; and emergency stop.
+5. **Policy decision point:** Deterministic rules governing legal applicability, environment, permitted data, model/tool scope, threshold crossings and action approval.
+6. **Evaluation plane:** Offline tests, adversarial/red-team evaluations, scenario simulations, shadow mode, canary monitoring, regression gates and post-deployment tests.
+7. **Evidence ledger:** Append-only events, provenance references, hashes, timestamps, actor identity, test results, approvals, exceptions, and retention/deletion rules.
+8. **Monitoring and response plane:** Availability, performance, cost, safety/quality incidents, drift, data freshness, queue lag, provider health, tool-call anomalies and escalation.
+9. **Reporting and supervisory export:** Evidence-backed views with explicit scope and limitations; controlled exports; versioned report bundles; and reproducibility metadata.
+10. **Independent assurance plane:** Segregated reviewers, test ownership, control sampling, exception verification and an explicit statement of what was and was not assured.
+
+### 4.2 Processing path
+
+ A user submits a request with an authenticated identity and declared purpose. The application validates access and classifies data. It retrieves only permitted context, records source IDs and versions, invokes an approved model with a restricted tool set, validates the response schema and claims, and then routes suggested actions through the
+policy engine. Consequential writes
+require approval from an authorized actor. The system records outcome and failures. The evidence layer retains the record and source references under approved retention policy. Independent assurance samples those records and test outcomes.
+
+### 4.3 Fail-safe state
+
+ When source freshness, signature verification, identity, policy evaluation, database availability or required evidence is missing, the system should not silently substitute a plausible value. It should set the affected claim to **UNKNOWN / EVIDENCE INSUFFICIENT**, block the dependent consequential action where appropriate, display the reason and
+last successful observation, and
+open a remediation event. Fail-safe does not necessarily mean shutting down every unrelated function; scope the block to the affected critical operation and document the safe degraded mode.
+
+### 4.4 Kill-switch and recovery requirements
+
+A credible emergency stop must be outside the model's control and work when the model, orchestration layer or primary API is unhealthy. It should:
+- disable new high-impact tool calls;
+- revoke or restrict the affected service identity;
+- preserve already received evidence and audit history;
+- prevent retry storms or queued actions from executing after the stop;
+- provide separate authority to resume service;
+- require a health check, review of outstanding operations, and documented recovery decision before resumption.
+
+A UI toggle alone is not evidence of an effective kill-switch. Test the switch under network partition, identity-service failure, runaway worker, stale policy cache and compromised connector scenarios.
+
+## 5. Mapping to GIEN control domains
+
+The domain names below are the GIEN project's proposed control organization, not language mandated by a specific external standard.
+
+| GIEN domain | Supervisory objective | Minimum operational evidence |
+|---|---|---|
+| CD-01 Constitutional Invariant Enforcement | Prevent violation of explicitly defined non-negotiable constraints | Versioned invariants, machine-readable policies, negative tests, bypass tests, authorized exception process |
+| CD-02 Model and Data Governance | Know the model, data, use case and limitations across lifecycle | Registry, lineage, access record, model card/system description, dataset quality and changelog |
+| CD-03 Identity, Access and Tool Control | Limit who/what can read and change systems | Identity claims, scope inventory, permission tests, approval records, credential rotation evidence |
+| CD-04 Secure Development and Supply Chain | Prevent unreviewed code/model/dependency changes | Protected branch evidence, signed builds where implemented, dependency/SBOM inventory, provenance and scans |
+| CD-05 Risk Measurement and Evaluation | Test performance, uncertainty, safety and drift | Versioned test corpus, independent test results, calibration evidence, drift alert/triage records |
+| CD-06 Data Quality, Privacy and Provenance | Ensure each claim/data item has lawful provenance and fit-for-purpose quality | Source metadata, freshness, purpose, retention policy, quality checks, access/redaction logs |
+| CD-07 Human Oversight and Accountability | Route high-impact decisions to authorized accountable roles | RACI, review criteria, override logs, reviewer competency tests, escalation closure |
+| CD-08 Incident, Resilience and Recovery | Detect, contain, recover and learn from AI-related failures | Incident timelines, playbooks, provider failover results, backup/restore evidence, lessons-learned records |
+| CD-09 Third-Party and Systemic Risk | Measure shared dependencies and coordinated stress effects | Provider/nth-party graph, concentration analysis, substitutability tests, common-model risk scenarios |
+| CD-10 Long-Horizon Governance and Treaty Compliance | Preserve continuity of policies and evidence across periods and system versions | Versioned policy lineage, explicit successor approvals, unresolved assumptions register, archival/retention tests |
+
+### Control implementation rule
+
+ Each domain needs a named accountable owner, control statement, applicability test, implementation object, deterministic acceptance test, evidence location, test frequency, failure response, exception expiry and independent reviewer. A control can be “not applicable” only when the rationale and approving authority are recorded; missing evidence
+must not be treated as a pass.
+
+## 6. Metrics: from dashboard numbers to defensible indicators
+
+### 6.1 Metric contract
+
+Every displayed indicator should have a versioned metric definition containing:
+- name and unique ID;
+- intended construct and risk mechanism;
+- numerator/denominator or precise computation;
+- units, scaling and direction of concern;
+- aggregation method and population covered;
+- data source, freshness and missing-data rule;
+- validation study and calibration range;
+- sampling uncertainty and known blind spots;
+- warning/action threshold with owner and approval date;
+- expected update cadence and response playbook;
+- change history and independent review.
+
+Without that definition, a score is a visual value, not a reliable control measurement.
+
+### 6.2 Proposed metric families
+
+| Metric family | Example measure | Design guardrail |
+|---|---|---|
+| Systemic concentration | Weighted exposure to common providers/models/cloud regions | Define dependency weights, criticality and substitutability; don't double-count correlated services |
+| Model-risk health | Independent evaluation failure rate by model/use case | Keep test sets versioned and non-leaky; include production outcomes |
+| Data and evidence quality | Share of material claims with valid, current source and review state | “Citation present” is weaker than “citation supports claim” |
+| Drift | Validated change in input/output/performance distributions | Identify the reference population and statistical test; separate alert from confirmed harm |
+| Tool-control integrity | Unauthorized or policy-invalid tool calls; approval bypass test results | An observed count of zero is meaningless without attack/test coverage |
+| Recovery | Actual restoration time versus approved objective | Exercise failure paths, not only planned tabletop scenarios |
+| Third-party resilience | Critical functions without a tested substitute or manual fallback | Supplier count alone is not a concentration measure |
+| Human oversight | Error detection rate, override quality, review latency and escalation closure | Count substantive review outcomes, not acknowledgements alone |
+| Evidence completeness | Material assertions supported by required sources and test results | Publish the denominator, exclusion rules and stale-evidence rate |
+| Cost/availability | Latency, retries, quota exhaustion and cost per completed validated task | Do not optimize cost at the expense of safety or quality |
+
+### 6.3 GIEN-specific indices require calibration
+
+The GIEN project has used indicators such as S_sys, G-SRI, C-SRI, CGR-I, CCR-I, G-SRI-VII, A-SRI, P-SRI, p(doom), p(doom)_kernel, Δ_drift, and Δ_OSCAL, with proposed thresholds. These identifiers and thresholds are **internal design parameters, not externally standardized regulatory values**.
+
+Before an index may gate operational decisions:
+1. Publish its mathematical definition and units.
+2. Identify observables and the data-generating process.
+3. Establish construct validity—what risk does it actually measure?
+4. Test against historical events, simulated stress, and independent expert labels.
+5. Estimate calibration, false-positive/false-negative rates, sensitivity to missingness and drift, and confidence intervals where applicable.
+6. Test for manipulation, correlated inputs, leakage and gaming.
+7. Set threshold costs and actions with accountable owners.
+8. Run shadow mode and compare alerts to real outcomes.
+9. Approve change control, recalibration and rollback.
+10. Release it as a gate only after independent validation.
+
+ In particular, p(doom)-style values must not be presented as empirical probabilities of civilizational or system failure unless there is an explicit, defensible model, a defined event space and time horizon, data suitable for estimation, uncertainty analysis, and calibration testing. Otherwise label them illustrative scenario scores or research
+hypotheses, not probabilities.
+
+### 6.4 Missing or stale evidence semantics
+
+Use explicit states such as PASS, FAIL, UNKNOWN, STALE, NOT APPLICABLE, NOT TESTED and SIMULATED. Missing data must not be coerced to zero. A failed telemetry collection is not proof that the risk is low. A configured monitor is not proof that it is working. A test plan is not a test result. A hash is not proof of source truth.
+
+## 7. Regulatory and standards crosswalk
+
+Applicability depends on jurisdiction, organization role, system purpose, affected persons, deployment context, sector and current legal text.
+
+### 7.1 EU AI Act
+
+ The AI Act has a phased application model and includes prohibitions, GPAI obligations, obligations for high-risk systems, transparency rules and governance/enforcement mechanisms. For GIEN, the correct first step is an **AI system inventory and role analysis**, not a blanket assertion that every use case is high-risk or that every organization has
+the same provider/deployer
+duties.
+
+ Required evidence for each potentially covered system should include intended purpose, use case, provider/deployer/importer/distributor roles as relevant, risk classification rationale, technical documentation where applicable, risk management, data governance, logging, human oversight, accuracy/robustness/cybersecurity, transparency, quality
+management and post-market or
+post-deployment obligations where applicable. This list must be tailored to the actual legal role and system category.
+
+Operational calendar note: the AI Act Service Desk's current timeline includes Digital Omnibus references, while its FAQ characterizes the related changes as proposed. Resolve the inconsistency against enacted legal instruments and professional advice before setting a statutory filing or transition date.
+[Timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/eu-ai-act-implementation-timeline), [FAQ](https://ai-act-service-desk.ec.europa.eu/en/faq?faq_category_id=99), [Article 50 transparency text](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50).
+
+### 7.2 DORA and ICT operational resilience
+
+DORA (Regulation (EU) 2022/2554) applies from 17 January 2025 to in-scope EU financial entities and covers ICT risk management, incident handling/reporting, resilience testing, and ICT third-party risk management, among other requirements. It is not AI-specific, but AI systems often depend on ICT providers and can be critical to business processes.
+
+ GIEN should map each AI service to supporting ICT assets and third parties, critical functions, impact tolerances, incidents, tests, resilience measures, contracts, exit plans, and concentration. Avoid claiming that an AI-specific control is “DORA compliant” without mapping the relevant DORA article and delegated/implementing requirements to the
+actual institution and evidence.
+[DORA official text](https://eur-lex.europa.eu/eli/reg/2022/2554/oj).
+
+### 7.3 NIST AI RMF and GenAI Profile
+
+ NIST AI RMF uses the Govern, Map, Measure and Manage functions as a lifecycle structure; NIST explicitly says the functions and playbook are not simply a one-size-fits-all checklist. The Generative AI Profile (NIST AI 600-1) adds gen-AI-specific risk-management actions. Use them as an adaptable mapping baseline, with traceable outcomes and tests.
+The critical-infrastructure
+ profile remains ongoing as of the research cutoff. [AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/), [AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook), [GenAI
+Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), [Critical
+Infrastructure Profile project](https://www.nist.gov/programs-projects/concept-note-ai-rmf-profile-trustworthy-ai-critical-infrastructure).
+
+### 7.4 ISO/IEC 42001
+
+ ISO/IEC 42001:2023 specifies requirements and guidance for establishing, implementing, maintaining and improving an AI management system. It can support organization-level responsibility, policies, risk assessment, control selection, monitoring and continual improvement. Certification or alignment does not automatically prove that each AI output
+is correct, that a specific
+legal duty is satisfied, or that the system is safe for every intended use. [IEC standard listing](https://webstore.iec.ch/en/publication/90574) and [ISO overview](https://www.iso.org/artificial-intelligence/ai-management-systems).
+
+### 7.5 Financial-sector guidance
+
+- The FSB's 2024 and 2025 reports support monitoring third-party concentration, cross-firm correlation, cyber risk, model/data quality, governance and data gaps. [2024 report](https://www.fsb.org/2024/11/the-financial-stability-implications-of-artificial-intelligence/), [2025 monitoring
+ report](https://www.fsb.org/2025/10/monitoring-adoption-of-artificial-intelligence-and-related-vulnerabilities-in-the-financial-sector/).
+- BCBS third-party risk principles were published in December 2025 and establish a common baseline for managing a wider range of third-party arrangements, supply-chain, nth-party and concentration risks. They are supervisory principles that should be read with the jurisdiction's implementing and related rules. [BCBS
+ principles](https://www.bis.org/publications/202512-guidelines-principles-sound-management-third-party-risk).
+- ESMA's May 2024 statement expects firms using AI in retail investment services to comply with relevant MiFID II obligations, including organisational and conduct requirements and acting in the client's best interests. It identifies bias/data quality, opaque decision-making, overreliance and privacy/security concerns. [ESMA
+ statement](https://www.esma.europa.eu/press-news/esma-news/esma-provides-guidance-firms-using-artificial-intelligence-investment-services).
+- The FSB/BIS materials do not provide a single calibrated, cross-firm AI systemic-risk score. GIEN should develop a metrics programme with transparent definitions rather than imply that the project's index names are official supervisory metrics.
+
+### 7.6 Security and privacy standards
+
+ Use OWASP's current LLM threat list, NIST's adversarial-ML taxonomy, secure software development practices for GenAI systems, and relevant privacy/security requirements to design threat models. The OWASP list is a security taxonomy, not a complete formal assurance standard. NIST AI 100-2e2025 covers adversarial manipulation across model lifecycle
+stages and is relevant to
+input, data, model and deployment threats. [OWASP](https://genai.owasp.org/llm-top-10/), [NIST AI 100-2e2025](https://csrc.nist.gov/pubs/ai/100/2/e2025/final), [NIST secure development for GenAI](https://csrc.nist.gov/pubs/sp/800/218/a/final).
+
+## 8. Model lifecycle and release controls
+
+### 8.1 Inventory and tiering
+
+Every AI-enabled workflow should have a stable inventory record:
+- owner and accountable executive;
+- purpose and prohibited uses;
+- users, impacted persons and decisions influenced;
+- model provider/name/version/region, hosting and dependencies;
+- data sources, classifications, retention and cross-border transfers;
+- autonomy and connected tools;
+- risk tier rationale and legal applicability;
+- evaluation suite, test baselines and known limitations;
+- monitoring, incident response, fallback and retirement plan.
+
+Risk tiering should consider consequence, autonomy, action permissions, scale, reversibility, affected persons, critical-function dependency, external data access, and ability to detect/correct errors.
+
+### 8.2 Pre-production gate
+
+A release candidate should pass a written gate with:
+
+1. Requirements and prohibited-use review.
+2. Threat model and data-flow review.
+3. Training/data/provenance and licence assessment where applicable.
+4. Model and prompt/version inventory.
+5. Baseline evaluation, including relevant domain examples.
+6. Robustness, adversarial, privacy, security and misuse tests.
+7. Tool permissions, output schema, authorization and human-approval tests.
+8. Bias/fairness analysis and accessibility/usability review where relevant.
+9. Resilience/fallback/kill-switch exercise.
+10. Legal, procurement, third-party and data-protection reviews as applicable.
+11. Operational monitoring and incident runbook.
+12. Approval by an accountable release authority, recorded against the exact version.
+
+### 8.3 Production monitoring
+
+ Monitor more than uptime. Include quality and harm indicators, input/output drift, invalid citation rates, tool-call errors, rejected actions, override rate, complaints, incident severity, provider changes, latency, costs, quota exhaustion, data freshness and concentration. Alerts must have assigned owners, service levels and closure evidence.
+Every alert threshold should have
+a test showing it fires for a representative failure and does not rely on the model to detect its own critical failure.
+
+### 8.4 Change management
+
+ Re-evaluate when any of the following change: foundation model, model snapshot, system prompt, system instruction, tool schema, retrieval source/index, embedding model, safety filter, thresholds, data pipeline, API version, identity scopes, hosting location, provider contract, or business purpose. Change impact analysis must determine which tests
+rerun and whether deployment
+requires renewed human approval. A vendor's silent model change should trigger inventory reconciliation and regression sampling.
+
+## 9. Evaluation programme
+
+### 9.1 Test layers
+
+| Test layer | Question answered | Example evidence |
+|---|---|---|
+| Unit/policy tests | Do deterministic rules implement the specification? | Unit tests, policy-decision fixtures, negative cases |
+| Task-quality evals | Does the model complete the scoped task correctly? | Human-reviewed reference set, quality metrics |
+| Grounding/citation evals | Are important claims supported by accessible source passages? | Claim/source matching, broken-link and stale-source checks |
+| Security tests | Can prompt injection or tool misuse breach controls? | Red-team cases, permission tests, attack logs |
+| Fairness/impact checks | Are errors or disparate effects unacceptable for the use case? | Appropriate subgroup tests, expert review, limitations |
+| Reliability/load tests | Does the service remain usable under failure and demand? | Load curves, error budgets, queue/backpressure tests |
+| Resilience tests | Can it degrade safely and recover? | Failover and restore exercise records |
+| Cross-model comparison | Are key outcomes excessively dependent on one provider/model? | Model divergence and correlated-error results |
+| Production monitoring | Do offline results persist in actual use? | Drift, incidents, outcome sampling and user feedback |
+| Independent assurance | Are scope, design, testing and evidence sufficiently examined? | Independent report with scope, findings, limitations and follow-up |
+
+### 9.2 Evaluation limitations
+
+- Benchmark success is not equivalent to production safety.
+- Model self-assessment is not independent validation.
+- A single prompt-injection benchmark cannot prove resistance to prompt injection.
+- A zero incident count can mean low risk, inadequate detection, short observation period, or poor reporting; it is uninterpretable without context.
+- A confidence score from a language model is not automatically calibrated probability.
+- Synthetic scenario results establish only what was tested under their assumptions.
+- Correlation is not causation; observed output similarity does not alone prove a systemic contagion mechanism.
+- Independent assurance requires a defined scope and access to sufficient underlying evidence.
+
+### 9.3 Minimum adversarial corpus for a research-and-tool system
+
+ The corpus should include indirect prompt injection in retrieved pages; malicious documents and issue comments; stale/conflicting official sources; fake citations; tool arguments that cross tenant boundaries; overlong/malformed outputs; permission revocation; provider 401/403/429/5xx errors; duplicate and out-of-order webhooks; data leakage
+attempts; model swap regressions;
+untrusted pull requests; stale policy caches; and queued writes during a kill-switch event. Include expected safe behavior, not merely examples of attack inputs.
+
+## 10. Evidence and cryptographic integrity
+
+Cryptographic controls protect specific parts of the chain but cannot make a false assertion true.
+
+### 10.1 Minimum evidence envelope
+
+Each evidence record should include:
+- immutable GIEN event ID;
+- provider/source identity and canonical URI;
+- provider event/resource ID and version/commit/model ID;
+- source time, observed time, ingested time, and verification time;
+- data classification and retention category;
+- cryptographic hash of canonicalized content;
+- signature-verification status where signatures exist;
+- schema, authorization, policy and test results as separate fields;
+- actor/service identity and authorization context;
+- adapter, schema, policy, model, prompt and evaluation versions where relevant;
+- associated approval, exception or incident;
+- evidence-to-claim and evidence-to-control links;
+- redaction and transformation metadata;
+- final disposition and reviewer.
+
+### 10.2 Hash, signature, attestation and assurance are different
+
+- A **hash** checks whether the compared byte representation matches the hashed value; it does not prove who created it or whether it is true.
+- A **digital signature** can establish that a key signed specified data, if key custody and verification are trustworthy; it does not prove the claim is correct.
+- A **TEE/TPM attestation** supports a claim about a particular measured environment under a particular attestation scheme; it does not prove model output quality or that every application control was effective.
+- A **PQC-ready design** is not the same as deployed post-quantum protection or tested algorithm interoperability.
+- A **WORM/object-lock setting** does not by itself prove complete immutability, retention compliance, correct event capture or recoverability.
+- A **passing CI job** establishes only the assertions actually tested in that job on that specific revision.
+- An **independent assurance statement** must identify scope, criteria, sample, qualifications, findings and limitations.
+
+### 10.3 Archive integrity procedure
+
+ A defensible archival pipeline should canonicalize the evidence manifest; define exactly which artifacts and metadata are included; hash each artifact; sign the root manifest through a controlled signing service; retain key identifiers and rotation events; replicate to approved immutable storage; run periodic read-back, signature verification,
+retention-policy and recovery
+tests; and record all failures. Never manually replace failed verification state with a green indicator. Any migration to a new hash/signature algorithm should preserve verification paths for previous evidence and record the migration.
+
+## 11. Systemic-risk indicators and escalation
+
+The FSB identifies broad vulnerability families but does not supply universal thresholds for GIEN's named indices. A practical GIEN risk dashboard should display both the raw observation and the quality of the evidence behind it.
+
+### 11.1 Illustrative dashboard dimensions
+
+- **Institution exposure:** number and criticality of workflows using each model/vendor; reliance in critical services; substitutability and migration lead time.
+- **Concentration:** common-provider exposure across business units or institutions, where lawful and supported by data.
+- **Model quality:** task-specific failure rates, support/citation accuracy, drift, inappropriate abstention and unsupported output.
+- **Control effectiveness:** observed authorization-denials, attempted bypasses, policy violation detection, override rate and kill-switch test outcomes.
+- **Operational resilience:** provider availability, recovery time, evidence-delivery lag, queue backlog, degraded-mode success and restore integrity.
+- **Data integrity:** stale records, missing provenance, source disagreement, poisoned retrieval detections, schema-validation failures and lineage gaps.
+- **Governance performance:** time to review, unresolved exceptions, approval coverage, overdue remediation and independent findings.
+- **Financial-market interaction:** if relevant and legally permissible, correlated model actions, shared data shocks, concentration and amplification under stress.
+
+### 11.2 Threshold lifecycle
+
+ Each threshold moves through: proposed → specified → back-tested → shadow-monitored → independently reviewed → approved → production-active → periodically reviewed → retired. A changed definition invalidates earlier comparisons until the historic series is recomputed or annotated. Thresholds should trigger a documented action with a named owner,
+not a vague status colour.
+
+Use at least three states for control result (pass, fail, unknown) plus data freshness and test coverage. Risk indices may use graded bands, but should not erase uncertainty about source quality or model scope. The overall system posture should not become GREEN if a mandatory critical metric is unknown, stale or unvalidated.
+
+## 12. Programme roadmap
+
+### Phase 0 — Inventory and evidence baseline (0–30 days)
+
+- Enumerate AI use cases, models, tools, vendors, datasets, critical workflows and responsible owners.
+- Identify applicable legal regimes and distinguish binding law, guidance, standards, proposals and internal policy.
+- Define the evidence schema and statuses.
+- Label all current dashboard values as illustrative until traced to actual sources.
+- Baseline build, smoke tests, accessibility, secrets scanning and source documentation.
+- Establish a risk and exception register with owners and target dates.
+
+**Exit gate:** Inventory coverage and evidence ownership are reviewed; no synthetic value is mislabeled as live.
+
+### Phase 1 — Deterministic foundations (30–90 days)
+
+- Implement an authenticated server-side BFF/control plane; keep provider credentials out of the React bundle.
+- Add least-privilege identity, tenant boundaries, audit events and policy enforcement.
+- Add source adapters in read-only mode and a durable webhook inbox.
+- Implement schema and source validation, idempotency, bounded retry/backoff and reconciliation.
+- Build migration-based persistence and test authorization at the data boundary.
+- Add evidence freshness, UNKNOWN/STALE states and basic incident workflows.
+
+**Exit gate:** Security and authorization tests pass on the candidate build; key data has provenance; provider connection status comes from real checks.
+
+### Phase 2 — Evaluation and resilience (90–180 days)
+
+- Establish model-specific evaluation suites and versioned adversarial corpus.
+- Run shadow monitoring and test data drift.
+- Map critical suppliers and nth parties; test outage and manual fallback scenarios.
+- Implement explicit high-risk action approvals and operational kill-switch.
+- Verify backup/restore, archival integrity and evidence export reproducibility.
+- Conduct security review and independent evidence sampling.
+
+**Exit gate:** Evaluation has documented coverage and limitations; degraded-mode and recovery drills have passing evidence.
+
+### Phase 3 — Controlled production workflows (6–12 months)
+
+- Enable selected consequential writes only after scope and authority review.
+- Link source-control, build/deploy and approval evidence to exact release versions.
+- Add ongoing monitoring for concentration, quality, safety, drift, incidents and exceptions.
+- Implement regulator-specific evidence bundles from actual obligations and real system sources.
+- Establish independent audit cadence, remediation SLAs and periodic board/supervisory reporting.
+
+**Exit gate:** Production scope, operating owners, review cadence, incident process and fallback paths are accepted by accountable leadership.
+
+### Phase 4 — Cross-entity and long-horizon monitoring (12–24 months)
+
+- Add lawful cross-entity dependency data and stress scenarios.
+- Test correlated failure hypotheses using transparent assumptions and independent review.
+- Track standards, legal amendments, model/provider lifecycle and emerging safety evaluations.
+- Version policies and archive manifests across system replacements; test successor-version evidence continuity.
+- Reassess scope and controls at least annually and after a material model, provider, purpose or legal change.
+
+**Exit gate:** Cross-entity measurements are defensible, privacy/legal bases are documented, and conclusions communicate statistical and observational limitations.
+
+## 13. Required release gates
+
+Do not promote the platform to production for supervisory decisions until all applicable gates are evidenced:
+
+1. **Inventory:** models, use cases, providers, data flows, dependencies and owners are current.
+2. **Applicability:** legal and standards crosswalk was reviewed by a competent authority with current source text.
+3. **Security:** authentication, authorization, secrets, injection, tool permissions, SSRF, tenant boundaries and logging tests pass.
+4. **Evidence quality:** source provenance, timestamps, signature checks and data-quality states are implemented and observable.
+5. **Evaluation:** versioned task-quality, adversarial, drift and regression tests exist with named owners and explicit limitations.
+6. **Human oversight:** high-impact actions and risk acceptance have authorized owners, review criteria and audit trails.
+7. **Resilience:** provider outage, queue, identity, storage, kill-switch, backup/restore and degraded-mode tests pass.
+8. **Financial-system scope:** third-party concentration and correlated-risk analysis is available where relevant and supported by lawful data.
+9. **Reporting:** exports link each material claim to underlying evidence and distinguish simulation from operational facts.
+10. **Independent review:** the assurance scope and findings are documented; unresolved critical findings block release.
+11. **CI/CD:** exact candidate commit passes required CI, dependency/security checks and smoke tests; deployment status is verified from the target host.
+12. **Rollback:** model, prompt, data index, policy, adapter, and provider rollback procedures are exercised and available to authorized operators.
+
+## 14. Supervisory reporting format
+
+Each daily report should include:
+- Reporting window and source observation timestamps.
+- Scope of systems and providers actually covered.
+- Observability coverage and missing/stale source list.
+- State of required controls: pass, fail, unknown, stale, not tested, not applicable, simulated.
+- Material changes to models, tools, data, policy, permissions, or infrastructure.
+- Risks and incidents grouped by impact, likelihood evidence, affected assets and concentration.
+- Threshold breaches, control test references, and assigned response owners.
+- Exceptions with expiry, approver and compensating control.
+- Actions executed versus recommended, with provider IDs and outcome.
+- Open assumptions, conflicting sources, confidence rationale and known blind spots.
+- Human decision log and release/filing approvals.
+- Evidence bundle identifier, manifest hash/signature verification results if actually generated.
+- Independent review scope and unresolved findings, if performed.
+
+Do not report a risk value without its data source, computation version, observation time and validation status. Do not assert that an archive was sealed, a transmission succeeded, a signature was verified, a kill-switch worked, or a regulator accepted a filing unless the corresponding operation and authoritative result are evidenced.
+
+## 15. Open research questions and limitations
+
+The public evidence base does not yet settle several material questions:
+
+- How well do current capability and safety evaluations predict operational behaviour across model updates and diverse deployment contexts?
+- Which technical and institutional safeguards provide measured real-world risk reduction, and for which threat models?
+- How should systemic AI concentration metrics account for common foundations, shared cloud and data dependencies, correlated provider failure, substitutability, and hidden nth parties?
+- Which cross-institution datasets can lawfully and securely support supervisory early warning without leaking confidential or market-sensitive information?
+- How should risk thresholds be calibrated where severe outcomes are rare, the data-generating process changes quickly, and historical samples are limited?
+- Which controls need formal verification, and what system boundaries and assumptions make the proof relevant to the deployed software?
+- How should AI Act transitional dates and amendments be interpreted when official timeline and proposal materials are not presented consistently?
+- What independent-evaluation access can be obtained when model details and deployment logs are proprietary?
+
+These are active areas for research and supervisory coordination, not reasons to replace evidence with speculative certainty.
+
+## 16. Official source register
+
+All listed sources were checked on 12 October 2026 for this dossier. The source register prioritizes original regulators, standard bodies, official research reports and vendor documentation. Recheck each current version before using it for legal, production or supervisory decisions.
+
+### International AI safety and risk science
+1. [International AI Safety Report 2026](https://internationalaisafetyreport.org/publication/international-ai-safety-report-2026) — official report, 3 February 2026.
+2. [Extended Summary for Policymakers](https://internationalaisafetyreport.org/publication/2026-report-extended-summary-policymakers) — capabilities, emerging risks, evaluation gaps and risk-management evidence.
+3. [NIST AI 100-2e2025: Adversarial Machine Learning Taxonomy](https://csrc.nist.gov/pubs/ai/100/2/e2025/final) — adversarial ML terms and lifecycle threats.
+4. [OWASP Top 10 for LLM Applications, 2025](https://genai.owasp.org/llm-top-10/) — LLM application threat categories.
+
+### AI risk management and standards
+5. [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) — core framework and current revision notice.
+6. [NIST AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) — Govern, Map, Measure, Manage.
+7. [NIST AI 600-1: Generative AI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) — gen-AI risk management profile.
+8. [NIST AI RMF Profile for Trustworthy AI in Critical Infrastructure](https://www.nist.gov/programs-projects/concept-note-ai-rmf-profile-trustworthy-ai-critical-infrastructure) — project in progress.
+9. [ISO/IEC 42001:2023](https://webstore.iec.ch/en/publication/90574) — AI management-system standard.
+10. [ISO AI management systems overview](https://www.iso.org/artificial-intelligence/ai-management-systems) — organizational management-system context.
+11. [NIST SP 800-218A](https://csrc.nist.gov/pubs/sp/800/218/a/final) — secure software development practices for GenAI and dual-use foundation models.
+
+### EU law and financial supervision
+12. [EU AI Act implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/eu-ai-act-implementation-timeline) — current Service Desk timeline; validate against operative legislation.
+13. [EU AI Act Digital Omnibus FAQ](https://ai-act-service-desk.ec.europa.eu/en/faq?faq_category_id=99) — status of proposed changes and timing.
+14. [AI Act Article 50](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50) — transparency requirements.
+15. [DORA — Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) — EU digital operational resilience legal text.
+16. [FSB: The Financial Stability Implications of AI](https://www.fsb.org/2024/11/the-financial-stability-implications-of-artificial-intelligence/) — 14 November 2024.
+17. [FSB: Monitoring Adoption and Related Vulnerabilities](https://www.fsb.org/2025/10/monitoring-adoption-of-artificial-intelligence-and-related-vulnerabilities-in-the-financial-sector/) — 10 October 2025.
+18. [BCBS: Principles for the Sound Management of Third-Party Risk](https://www.bis.org/publications/202512-guidelines-principles-sound-management-third-party-risk) — 10 December 2025.
+19. [ESMA: Guidance for Firms Using AI in Investment Services](https://www.esma.europa.eu/press-news/esma-news/esma-provides-guidance-firms-using-artificial-intelligence-investment-services) — 30 May 2024.
+
+### Implementation and platform security
+20. [OpenAI MCP Tools and Connectors](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) — remote tools, approvals, data sharing and connector lifecycle.
+21. [OpenAI API Data Controls](https://developers.openai.com/api/docs/guides/your-data) — retention and API data-control documentation.
+22. [GitHub Actions: Secure Use](https://docs.GitHub.com/en/actions/reference/security/secure-use) — CI/CD security boundaries.
+23. [GitHub Actions OIDC](https://docs.GitHub.com/en/actions/reference/security/oidc) — workload identity federation.
+24. [Supabase: Securing Data](https://supabase.com/docs/guides/database/secure-data) — RLS and frontend data access.
+25. [Netlify: Deploy Previews](https://docs.netlify.com/deploy/deploy-types/deploy-previews/) — preview environment lifecycle.
+
+## 17. Final decision
+
+ GIEN should prioritize **verifiable control effectiveness, evidence quality, third-party resilience, and independently reviewable decisions** over expanding dashboard features or inventing ever more indices. Current international research warns that AI capabilities, safeguards and deployment impacts change faster than evidence can always be
+generated; financial stability work
+highlights dependencies, correlation, cyber risk and model governance; and the regulatory framework requires careful mapping by use case and role.
+
+**Recommended status: design specified; implementation and live controls remain unverified until the corresponding runtime evidence is collected and independently reviewed.**
diff --git a/gien-platform/docs/multi-platform-integration-research-2026-10.md b/gien-platform/docs/multi-platform-integration-research-2026-10.md
new file mode 100644
index 00000000..e9d021e0
--- /dev/null
+++ b/gien-platform/docs/multi-platform-integration-research-2026-10.md
@@ -0,0 +1,276 @@
+# Multi-Platform Integration Research for the GIEN Governance Platform
+
+**Research snapshot:** 12 October 2026
+**Repository:** OneFineStarstuff/OneFineStarstuff.GitHub.io
+**Target:** \`gien-platform/\` — React, TypeScript, Vite, React Router and Tailwind
+**Classification:** Architecture and vendor research; not evidence of deployed integrations, vendor endorsement, compliance, or independent assurance.
+
+## 1. Executive assessment
+
+ The requested providers cover distinct integration classes. They should not be treated as 31 interchangeable APIs or connected as one broad agent with shared credentials. Several products expose documented APIs or MCP servers; some require enterprise or partner approval; others are best treated as user-mediated creation and export tools until a
+supported API and licence are
+confirmed.
+
+ **Recommended design:** one server-side Integration Gateway/BFF with a registry of typed provider adapters, tenant-bound OAuth connections, per-action policy, source provenance, rate limits, redacted logs, and an approval queue for writes. The current GIEN application is a frontend prototype. This dossier does not claim that credentials, user
+authorizations, or production
+service connections exist.
+
+ **Do not integrate everything into the core risk engine.** The governance application should keep risk and compliance calculations in deterministic services and authoritative records. External assistants can retrieve evidence, draft materials, and propose actions, but they must not set systemic-risk measurements, certify compliance, seal evidence,
+approve submissions, modify
+constitutional invariants, or operate kill switches.
+
+### Research findings that affect design decisions
+
+1. **Partner rights vary materially.** Coursera’s direct APIs target Business/Campus/Government customers and direct LMS/LXP integrations may require Coursera solution-architect engagement. Expedia’s Rapid APIs require an approved partner relationship. Zillow’s API terms apply to approved licensees and contain significant restrictions on use,
+ caching, and redistribution.
+ Thumbtack also distinguishes marketplace integrations from pro integrations and uses OAuth 2.0.
+2. **A tool connector is not a production integration.** Availability of an app tool inside ChatGPT does not demonstrate that GIEN has an authorized service account, a durable API contract, a production secret store, or permission to operate on behalf of every GIEN tenant.
+3. **Keep operational authority local.** The model may summarize an evidence record or draft a Jira/Asana/Slack update. The server must determine whether a caller may read or write, validate the payload, log the action, and obtain human approval for sensitive changes.
+4. **Provider lifecycle matters.** OpenAI's current deprecation schedule lists 31 October 2026 as the date existing Evals become read-only and 30 November 2026 as the scheduled shutdown of the Evals dashboard/API and Agent Builder. Build and own the GIEN evaluation fixtures and harness rather than making the product depend on these legacy surfaces.
+5. **Supabase has an approaching key migration.** Its current API-key documentation says legacy \`anon\` and \`service_role\` keys are being deprecated by the end of 2026. New work should use publishable and secret key types, with secret keys restricted to controlled server-side components.
+
+### Connector catalog snapshot
+
+ At the time of this research, the current ChatGPT tool catalog exposed a dedicated app-tool namespace for every named provider in the registry except Firecrawl. OpenAI Platform was assessed as an API product, not as a separate third-party app connector. This is a snapshot of tools available to the current conversation, not proof that a user's
+account is authenticated, that a
+specific workspace is authorized, or that any service is connected to the deployed GIEN application. The platform must re-check connection health, tenant authorization, and scopes at runtime.
+
+## 2. Platform architecture recommendation
+
+### 2.1 Control and data flow
+
+- **GIEN web client:** role-based presentation, case/workflow UI, dashboards, and evidence previews. It never receives vendor secrets or unfiltered service credentials.
+- **Integration Gateway/BFF:** server-side provider adapters, OAuth callbacks, token refresh and revocation, tenant-bound connections, request schemas, per-provider policy, quotas, timeouts, circuit breakers, idempotency, and audit events.
+- **Policy and approval layer:** role + tenant + resource checks, operation risk tier, explicit approval for external writes or publication, two-person approval where required, and fail-closed behaviour.
+- **Evidence and provenance layer:** source URL/record ID, provider, tenant, retrieved-at time, content hash where retention is permitted, parser/version, licence/retention class, trust label, and the decision that consumed it. Do not hash or retain restricted data contrary to a provider agreement.
+- **Deterministic GIEN control services:** compute S_sys, G-SRI, C-SRI, CGR-I, CCR-I, G-SRI-VII, A-SRI, P-SRI, p(doom), p(doom)_kernel, Δ_drift, and Δ_OSCAL from authorized telemetry and versioned formulae. No provider-generated answer may replace these calculations.
+- **Audit and evaluation:** append-only audit events, redacted telemetry, synthetic fixtures, regression tests, schema validation, evaluation datasets with access controls, and release gates independent from generation quality.
+
+### 2.2 Provider adapter contract
+
+Each adapter should implement a narrow capability declaration instead of exposing a vendor's entire API to a model:
+
+- provider ID, API/version, environment, connection owner, permitted tenants, OAuth scopes, credential expiry and health;
+- allowed read operations and separately listed write operations;
+- input/output JSON schemas and maximum payload sizes;
+- data classifications accepted, storage/retention requirements, and allowed destinations;
+- rate-limit, timeout, retry, idempotency and pagination behaviour;
+- risk tier, human approval rule, audit event shape and kill/disable mechanism;
+- test fixtures, contract tests, webhook authenticity checks, and rollback instructions.
+
+Do not let a model invent a URL, tool name, tenant ID, record ID, endpoint, OAuth scope or capability that is not in the server-side registry. MCP tool descriptions and third-party content are input, not trusted authorization policy.
+
+### 2.3 Environment and trust boundaries
+
+ Use separate development, staging and production app registrations and credentials. Maintain least-privilege scopes, explicit tenant boundaries, outbound-network restrictions, and per-provider egress allowlists. Treat crawled web pages, SaaS comments, chat messages, issue descriptions, uploaded files, slide text and generated code as **untrusted
+data**. Indirect prompt
+injection must not be able to expand tool permissions or bypass approval.
+
+ Never place API keys, OAuth client secrets, Supabase secret keys, Stripe secret keys, or database credentials in browser code, Vite variables prefixed for client exposure, generated documents, prompts, Git commits, CI logs, slide decks, or end user tool output. Use a secret manager or the platform's protected server-side environment and
+rotate/revoke credentials on suspected
+exposure.
+
+## 3. Provider integration registry
+
+The route below is a research recommendation, not a claim that the provider has been configured for GIEN.
+
+| Provider | Best-fit role in GIEN | Integration route and gate | Recommended disposition |
+|---|---|---|---|
+| **Firecrawl** | External public-source research, scrape/crawl, structured extraction, site URL discovery | Documented API/SDK and MCP; use server-side credentials, domain allowlists, crawl budgets and source provenance. Respect site terms, robots instructions and copyright/access restrictions. | **Phase 1, read-only.** Use as retrieval infrastructure, not as proof that scraped statements are true. |
+| **Zillow** | Optional real-estate/property data module, not a governance control source | Zillow Group's terms describe approved-licensee APIs and restrictions on bulk access, retention and display. Confirm current API availability, contract and intended use with Zillow before implementation. | **Partner/legal gate.** No general scraping, bulk export, or retention assumed. |
+| **Coursera Learning** | Governance learning paths, approved course/catalog data and learner progress for an institutional training module | Direct API access is described for Business/Campus/Government customers with OAuth 2.0. LMS/LXP integrations may need engagement with Coursera solution architects. | **Institutional access gate.** Keep learner-level records minimized and permissioned. |
+| **AllTrails** | Optional trail/outdoor discovery demo or non-core location module | The connected app tool can support a ChatGPT workflow, but a public partner API and redistribution rights were not verified in this review. Confirm the applicable commercial terms before server-side access or persistence. | **Connector/UI first.** Do not infer public API access or build a scraper as a substitute. |
+| **Thumbtack** | Optional local-service discovery/request module | Partner platform distinguishes marketplace and pro integrations; its docs specify OAuth 2.0 and webhooks. Request submission and pro-side lead/message handling are distinct privileges. | **Partner gate.** Search/read first; require user approval before submitting requests or sending messages. |
+| **Netlify** | Hosting/deployment, deploy previews, site status and deploy logs | REST API supports sites, deploys and hooks; OAuth is the public-integration path, while personal access tokens are for controlled scripting. Code-agent docs provide deploy guidance. | **Choose as one production deploy authority, or use for preview only.** Protect production deploys with CI and approval. |
+| **Replit** | Rapid prototyping and app-generation workflow | The available app tool exposes a project-building workflow. A generic, stable external API contract for all lifecycle actions was not established by this review; verify current supported API and account permissions before depending on it. | **Prototype/workbench.** Generated changes still require Git review, testing, security scan and standard release controls. |
+| **Lovable** | Prompt-assisted implementation and scaffolding | Official docs support syncing projects to GitHub/GitLab/Bitbucket; Lovable documents Supabase integration and an MCP server. Keep the versioned repository as the reviewable source of truth. | **Prototype/workbench.** Never merge generated changes automatically into protected production branches. |
+| **Airtable** | Human-maintained registers, intake queues and lightweight operational catalogues | Web API with paginated records and a documented 5-requests/second-per-base limit; current support docs state pages can return up to 100 records. OAuth/scopes and base permissions should be narrowed. | **Phase 2, bounded CRUD.** Not the authoritative database for critical invariants or high-volume telemetry. |
+| **StubHub** | Optional event discovery/ticket data, unrelated to GIEN systemic-risk evidence | Official API docs describe HTTPS, OAuth 2.0 and event/listing operations. The API documentation surfaced in this review is older; confirm current availability, scopes, resale requirements and commercial terms before production use. | **Separate optional module.** Read-only event search first; no purchase/listing write without explicit user confirmation and current authorization. |
+| **B12 site Generator** | Produce a separate public-facing site or non-production explainer | B12 documents a remote MCP server for MCP-compatible clients to generate an editable site and return a preview link. site publication is a real external side effect. | **Draft/preview only by default.** Human review for factual, legal, brand, privacy and accessibility checks before publishing. |
+| **Outliner** | Turn source material into an outline or briefing structure | The current app connector exposes an outlining workflow; a supported public REST API was not verified in the official documentation reviewed. | **Drafting only.** Store the approved source references alongside the outline and verify claims before reuse. |
+| **DataCamp** | Training catalogue and, where licensed, learner completion/progress ingestion | DataCamp describes a read-only Catalog API for course/project/assessment/practice/track content and learner events such as course completions; Enterprise SSO documentation describes SAML 2.0. | **Learning-module gate.** Confirm the plan and API entitlement; use aggregate progress where individual-level records are unnecessary. |
+| **Speechify** | Accessible audio rendition of approved briefing text | Official TypeScript/JavaScript and Python SDKs expose text-to-speech functionality and require a Speechify API key. A ChatGPT playback tool is not equivalent to a production GIEN audio backend. | **Optional output adapter.** Send only approved/minimized text; validate generated audio, accessibility and voice rights. |
+| **Genspark AI Slides** | Human-reviewed presentation drafting | The official help material documents its AI Slides workspace and export to PDF, PPTX or Google Slides. A stable public generation API was not verified in this review. | **User-mediated authoring.** Export reviewed decks; do not treat slides as signed evidence or automatically publish them. |
+| **Agentic Slides by SlidesGPT** | Programmatic generation of first-draft presentations from an approved brief | SlidesGPT documents a presentation-generation endpoint authenticated with a bearer token. Treat its output as generated content requiring factual, source and confidentiality review. | **Optional output adapter.** Send redacted data; store request ID, template/version and reviewed export. |
+| **Asana** | Work assignments, action plans and task status | Official API and webhooks; rate limits vary by plan, and 429 responses include Retry-After. Use OAuth, minimal scopes and webhook validation. | **Phase 2.** Create draft tasks only or place writes behind approval; Asana task status is not evidence that a control passed. |
+| **Statsig** | Gradual rollout, feature flags, experiments and dynamic configuration | Official SDKs and HTTP API support gates, experiments, dynamic configs and event logging. | **Phase 2, non-authoritative.** Flags may control UI rollout but must not be the sole enforcement mechanism for security policies or constitutional invariants. |
+| **Gamma** | Generate polished reports, briefings, presentations, documents, sites or social content | Gamma documents a generally available API; requests use an API key and API access is plan-gated (Pro, Ultra, Teams or Business per current docs). | **Optional output adapter.** Use approved summaries, cite source records, and require content/sign-off review. |
+| **Slack** | Operational notifications, review requests and approved summaries | Web API, granular OAuth scopes and Events API. Access to messages/files depends on granted scopes; incoming events require signature and replay protection. | **Phase 2, least privilege.** Read only authorized channels. Do not ingest the whole workspace by default; human approval before externally visible or high-impact posts. |
+| **Supabase** | Application database, authentication, storage and server-side functions | PostgreSQL/Auth/API/RLS stack. The current docs say publishable keys are for public components and secret keys bypass RLS and must remain server-side; legacy anon/service_role keys are due to deprecation by end-2026. | **Candidate primary backend.** Enforce RLS and tenant policies, use publishable/secret key types, and test database grants plus RLS independently. |
+| **Neon** | Managed PostgreSQL with programmatic project/branch/database/role/compute management | Neon API docs describe management of projects, branches, databases, roles, compute endpoints and API keys. Use separate roles and branch protections; do not expose the management API to the browser/model. | **Alternative primary database.** Choose deliberately versus Supabase rather than adding two competing sources of truth. Pair with an explicitly selected identity/auth solution. |
+| **Context7** | Version-specific software documentation lookup for implementation and debugging | Context7 exposes an MCP server with resolve-library-id/query-docs and a documented HTTP API. API-key/OAuth setup and rate limits apply. | **Phase 1.** Pin the library and version in research notes, but validate guidance against upstream docs and repository lockfiles. |
+| **GitHub** | Code/review source of truth, issues, protected branches, CI/CD and release evidence | REST/API integrations should use GitHub Apps or fine-grained tokens with only the necessary permissions. GitHub Actions OIDC can avoid long-lived cloud deployment keys when configured with strict trust conditions. | **Core control plane.** Protected branches, mandatory CI, signed/reviewed changes, scoped workflow permissions, and independent release approvals. |
+| **Figma** | UI/design-system source, design inspection and change notifications | Figma REST API supports OAuth apps; plan access tokens are available on Organization/Enterprise plans for organization-level automation; Webhooks V2 can notify file/team/folder changes. | **Design provenance only.** A design file does not establish runtime behaviour, accessibility compliance or evidence of control operation. |
+| **Canva** | Reports, infographics and communications assets | Canva Connect REST APIs use OAuth 2.0 Authorization Code with PKCE; use user-consented scopes and approved templates. | **Optional output adapter.** Do not place confidential evidence in public templates; preserve source citations and review before distribution. |
+| **Expedia** | Optional travel/lodging module, separate from GIEN governance | Expedia Group's Rapid API onboarding requires becoming an approved partner and meeting relevant launch requirements. Inventory access is not equivalent to an open public API entitlement. | **Partner gate.** No booking, cancellation or payment action without authorized partner integration and explicit user consent. |
+| **Vercel** | Hosting, preview deployments and deployment metadata | Vercel provides project/deployment APIs and access tokens; constrain tokens to the proper team/project and use protected CI/OIDC where possible. | **Choose as one production deploy authority, or use for preview only.** Review preview data and protect production promotion. |
+| **monday.com** | Portfolio/workstream boards and coordination state | GraphQL API supports board/item workflows and has complexity-based and daily call limits; hosted MCP/API operations consume that budget. | **Phase 2.** Treat board values as workflow metadata, not immutable audit evidence. Use narrow scopes and bounded queries. |
+| **Stripe** | Optional paid product/subscription workflow; not required for GIEN control logic | Stripe provides API keys, webhooks and idempotency patterns. Secret keys stay server-side; webhook signatures and replay/idempotency protections are required. | **Only if payments are explicitly in scope.** Do not handle raw card data; keep financial events and approval/audit state distinct from GIEN risk calculations. |
+| **Atlassian Rovo (Legacy)** | Atlassian issue/wiki/search workflow, subject to connector transition | The available ChatGPT namespace is labelled legacy. Current Atlassian docs describe the Rovo MCP Server using OAuth 2.1 and respecting existing Atlassian permissions, with read/write/destructive tool classes and discovery-based tool listing. These are not proof that the legacy connector is equivalent. | **Migration review before dependency.** Inventory actual supported tools, OAuth scopes and admin policy; start read-only, then approve writes by risk tier. |
+| **OpenAI Platform** | Bounded reasoning, structured summarization and tool orchestration | Use the Responses API server-side with Structured Outputs, schema validation, limited tools, server authorization and provenance-bearing sources. Follow the current data controls and deprecation notices. | **Core AI adapter after security gate.** No browser key, no model authority over measurements or filings, and maintain a repository-owned evaluation harness. |
+
+## 4. Detailed security and operational controls
+
+### 4.1 Evidence retrieval and web data
+
+ For Firecrawl and Context7, preserve retrieval metadata and the originating URL/library identifier. Every retrieved page or snippet must be labelled untrusted. The model may propose an extraction, but a schema validator and provenance check must decide whether it is usable. Use domain allowlists where feasible, deny access to
+private/link-local/internal addresses, block
+redirects into forbidden address ranges, constrain crawl depth and response size, and apply per-tenant budgets to prevent SSRF, data exfiltration, and uncontrolled spending.
+
+ Do not scrape a provider's consumer site when an authorized API or partner path is required. Do not use Firecrawl to bypass a login, paywall, anti-abuse control, or provider terms. For Zillow, the current terms surfaced in this review say access is for approved licensees and impose transactional display, no-bulk-access/no-retention requirements
+and a maximum of 20 individual
+properties shown at a time for the Property Details API. These are contractual constraints, not implementation details to work around.
+
+### 4.2 SaaS workspaces and human communications
+
+ Slack, Asana, Airtable, monday.com and Atlassian are collaborative systems. Messages and task descriptions can contain personal data, credentials, privileged information, malicious instructions or incorrect statements. Use explicit workspace/site/base/channel/project allowlists. Minimize content pulled into prompts and do not duplicate complete
+workspaces in a GIEN database
+without a documented need and retention rule.
+
+Separate operations by impact:
+
+- **Read-only:** search/list/get metadata, with tenant and project checks.
+- **Draft:** propose a task, message, page, design, comment or configuration without saving externally.
+- **Reversible write:** create or update a low-impact object after user approval and server validation.
+- **High-impact/destructive:** delete, publish, change permissions, trigger deploys, alter billing/experiments, or send broad external announcements. Require separate approval, review the exact payload, log the approver and result, and provide rollback where possible.
+
+Never infer authority from a model response, tool description, a ticket's wording, or a Slack message. Use the authenticated principal and current API permissions.
+
+### 4.3 Database, hosting and deployment
+
+ Select one primary production database and one production deployment authority before implementation. Supabase is the stronger integrated option when its Auth, RLS and storage features meet requirements; Neon is a PostgreSQL-first alternative with branches and a management API, typically paired with a separately selected identity stack. Use
+isolated preview databases and
+synthetic data. Do not clone production personal data into preview environments by default.
+
+ Choose **Netlify or Vercel** as the canonical production deployment path, rather than letting multiple providers independently promote production builds. Replit and Lovable are useful generation/prototyping paths; GitHub review, CI checks, dependency scanning, secret scanning, immutable release artifacts and explicit production promotion should
+remain the governed delivery
+process. B12, Gamma, Canva, SlidesGPT and Speechify are output channels, not authoritative record stores.
+
+ For every release, verify server-side secrets, auth and tenant isolation, API authorization, dependency health, accessibility, security headers, telemetry redaction, content security policy, rollback, and incident response. Apply signed webhooks, replay protection, idempotency keys where appropriate, bounded retries with jitter, dead-letter
+handling, and provider-specific
+circuit breakers.
+
+### 4.4 AI outputs and generated artifacts
+
+ Gamma, SlidesGPT, Genspark AI Slides, Outliner, B12, Canva and Speechify can improve packaging and accessibility. Generated prose, diagrams, audio or sites are not self-authenticating evidence. Every artifact that makes factual claims needs source references and a review status (draft, validated, approved, released). The content review must ensure
+sources are still accessible,
+numbers match authoritative data, private fields are redacted, and no unpublished control/evidence details leak into an external generation service.
+
+ For external publication, deployment, payment, booking, ticket purchase/listing, service request submission, public message send, destructive deletion, or access-control modification, present a final human-readable confirmation with provider, destination, scope and exact intended side effect. If confirmation or authorization is missing, stop at
+draft/preview.
+
+## 5. Recommended integration sequence
+
+### Phase 0 — Inventory and threat model
+
+Create a connection registry without storing secrets in the repository. For every provider record owner, business purpose, data categories, scopes, tenant binding, environment, API terms/licence, retention, incident contact, renewal date, and disable procedure. Mark unknown API rights as **unverified**, not implicitly approved.
+
+### Phase 1 — Grounded research and engineering foundations
+
+ Start with the most directly relevant, low-side-effect adapters: GitHub (read/review/CI metadata), Context7 (versioned docs), and Firecrawl (public sources under allowed terms). Add source citations and a standard evidence schema. Build synthetic test datasets and an independent smoke/contract-test suite. Do not permit these providers to write to
+business systems.
+
+### Phase 2 — Choose backend, identity and deploy topology
+
+Select Supabase **or** Neon, and Netlify **or** Vercel, after threat modelling and a cost/operability review. Implement BFF, tenant-aware authorization, secret management, audit logging, database migrations, backup/restore tests, policy-as-code and protected release workflows.
+
+### Phase 3 — Bounded operational workflow integrations
+
+Pilot one coordination provider first (for example Asana or monday.com) and optionally Slack/Airtable. Implement read-only operations, explicit workspaces/project allowlists, draft creation, webhook validation and human-approved writes. Treat task completion as workflow metadata only.
+
+### Phase 4 — Reviewed content outputs
+
+ Select one presentation API (Gamma or SlidesGPT) instead of wiring all content products into the first release. Add Canva/Figma assets if the design pipeline needs them; Speechify if accessibility requirements call for audio. Use B12/Replit/Lovable/Genspark/Outliner through a controlled authoring/export path unless their current supported
+integration contract specifically
+justifies automation.
+
+### Phase 5 — Partner-only and optional domain modules
+
+ Enable Coursera, DataCamp, Thumbtack, Expedia, Zillow, AllTrails and StubHub only where there is a confirmed product purpose, account entitlement, rights to the data, and a privacy/retention assessment. Keep travel, outdoor, ticketing, property and local services out of the core systemic-risk computation path. Do not ship placeholder API calls or
+scraped fallbacks for services
+whose approved access is missing.
+
+### Phase 6 — Production assurance
+
+ Require an adapter contract test, tenant-isolation test, negative authorization test, prompt-injection test, data-retention test, provider outage test, rate-limit/backoff test, secret scan, dependency scan, accessibility review, user acceptance review and rollback exercise before activating a provider. Record failures and exceptions; do not label
+the platform “compliant” or
+“independently assured” without appropriate evidence.
+
+## 6. Release acceptance criteria
+
+An integration is not production-ready until all applicable items below are evidenced:
+
+- [ ] Current official API/MCP/version and applicable terms have been reviewed; partner permissions and plan entitlements are recorded.
+- [ ] Credentials are stored server-side; scopes are minimal; refresh/revocation/rotation and expiry alerts are tested.
+- [ ] Tenant and resource authorization are enforced outside the model; negative tests prove inaccessible tenants cannot be queried.
+- [ ] Data classification, retention, deletion, cross-border transfer, downstream processors and logging restrictions are documented.
+- [ ] JSON schemas, provider error handling, rate limits, pagination, retries, idempotency and webhook verification are tested.
+- [ ] Indirect prompt-injection tests prove source content cannot expand permissions, reveal secrets or cause unapproved side effects.
+- [ ] Every write has an explicit operation policy, audit record, confirmation/approval and rollback or remediation path.
+- [ ] CI, staging smoke tests, dependency/secret scans, observability redaction, cost caps and incident response are enabled.
+- [ ] Generated content remains labelled as a draft until factual and human review is recorded.
+- [ ] The specific provider integration is described accurately; no claims of production connection, vendor approval or regulatory assurance are made without evidence.
+
+## 7. Official reference register
+
+The following sources were consulted for the snapshot above. Vendor APIs, terms and product lifecycle dates can change; verify the exact plan, region, API version, permissions and contract again immediately before implementation.
+
+### Retrieval and partner/data providers
+
+- Firecrawl — [Introduction and API/SDK capabilities](https://docs.firecrawl.dev/introduction)
+- Zillow Group — [Terms of Use: Data & APIs](https://www.zillowgroup.com/developers/terms/)
+- Coursera — [Production API developer portal: Get started](https://dev.coursera.com/get-started)
+- AllTrails — [Terms of Service](https://www.alltrails.com/terms)
+- Thumbtack — [Partner Platform overview](https://developers.thumbtack.com/docs/overview), [Getting started](https://developers.thumbtack.com/docs/getting-started), and [OAuth 2.0 authentication](https://developers.thumbtack.com/docs/getting-started/authentication)
+- StubHub — [API overview](https://developer.stubhub.com/docs/overview/introduction/)
+- DataCamp — [Catalog API integration](https://support.datacamp.com/hc/en-us/articles/14992652559255-Catalog-API-Integration) and [Enterprise SSO](https://support.datacamp.com/hc/en-us/articles/360009645713-Single-Sign-On-SSO-For-DataCamp-Enterprise-An-Overview)
+- Expedia Group — [Rapid API partner setup](https://developers.expediagroup.com/rapid/setup)
+
+### Developer platforms, data and hosting
+
+- Netlify — [REST API get started](https://docs.netlify.com/api-and-cli-guides/api-guides/get-started-with-api/) and [APIs for code agents](https://docs.netlify.com/extend/building-code-agents/apis-for-code-agents/)
+- Replit — [Official documentation](https://docs.replit.com/)
+- Lovable — [Official documentation](https://docs.lovable.dev/introduction/welcome) and [Supabase integration](https://docs.lovable.dev/integrations/supabase)
+- Airtable — [Web API getting started](https://support.airtable.com/articles/6292134965-getting-started-with-airtable-s-web-api)
+- Supabase — [API keys and key types](https://supabase.com/docs/guides/getting-started/api-keys) and [Postgres Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)
+- Neon — [API reference](https://neon.com/docs/reference/api)
+- Context7 — [API guide](https://context7.com/docs/api-guide) and [MCP client configuration](https://context7.com/docs/resources/all-clients)
+- GitHub — [Fine-grained token permissions](https://docs.GitHub.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2026-03-10) and [OIDC deployment
+ hardening](https://docs.GitHub.com/en/actions/security-for-GitHub-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect)
+- Vercel — [REST API documentation](https://vercel.com/docs/rest-api)
+- Replit and Lovable are treated as authoring/development workbenches here; deployment changes still use the versioned repository's governed release process.
+
+### Operational SaaS
+
+- Asana — [API rate limits](https://developers.asana.com/docs/rate-limits) and [webhooks](https://developers.asana.com/docs/webhooks-guide)
+- Statsig — [HTTP API overview](https://docs.statsig.com/http-api/overview)
+- Slack — [OAuth scopes](https://docs.slack.dev/reference/scopes) and [Events API](https://docs.slack.dev/apis/events-api/)
+- monday.com — [API rate limits](https://developer.monday.com/api-reference/docs/rate-limits)
+- Figma — [REST API authentication](https://developers.figma.com/docs/rest-api/authentication/) and [Webhooks V2](https://developers.figma.com/docs/rest-api/webhooks/)
+- Canva — [Connect REST API authentication](https://www.canva.dev/docs/apps/rest-apis/authentication/)
+- Stripe — [API keys](https://docs.stripe.com/keys)
+- Atlassian — [Rovo MCP overview](https://developer.atlassian.com/cloud/rovo-mcp/), [supported tools](https://developer.atlassian.com/cloud/rovo-mcp/guides/supported-tools/) and [authentication/authorization](https://developer.atlassian.com/cloud/rovo-mcp/guides/authentication-and-authorization/)
+
+### Content and AI generation
+
+- B12 — [Connecting an AI agent to B12's MCP server](https://support.b12.io/en/v3/connecting-an-ai-agent-to-b12s-mcp-server)
+- Speechify — [Official TypeScript/JavaScript and Python SDKs](https://docs.speechify.ai/build/guides/get-started/official-sdks)
+- Genspark — [AI Slides help center](https://www.genspark.ai/helpcenter/ai-slides)
+- SlidesGPT — [Presentation generation API reference](https://slidesgpt.com/docs/api-reference/endpoint/generate)
+- Gamma — [Developer documentation](https://developers.gamma.app/)
+- Outliner — current ChatGPT app-tool workflow was reviewed; a public standalone API reference was not verified in the sources reviewed. Treat it as user-mediated drafting unless supported documentation is supplied.
+
+### OpenAI Platform
+
+- [Responses API overview](https://developers.openai.com/api/reference/responses/overview)
+- [Function calling](https://developers.openai.com/api/docs/guides/function-calling)
+- [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs)
+- [API data controls](https://developers.openai.com/api/docs/guides/your-data)
+- [API key safety](https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety)
+- [OpenAI API deprecations](https://developers.openai.com/api/docs/deprecations)
+
+## 8. Explicit limitations
+
+ This is a desk-research and architecture report dated 12 October 2026. It is not a security assessment of provider systems, legal advice, confirmation of subscription entitlements, or evidence that any provider has authorized GIEN. Public documentation may not reveal private/partner API conditions. “Not verified” means the reviewed sources did not
+establish a dependable
+supported path; it does not prove that no such path exists. No API keys, personal tokens or customer records are included in this report.
diff --git a/gien-platform/docs/openai-evals-migration-inventory-2026-10-12.md b/gien-platform/docs/openai-evals-migration-inventory-2026-10-12.md
new file mode 100644
index 00000000..cd40ce02
--- /dev/null
+++ b/gien-platform/docs/openai-evals-migration-inventory-2026-10-12.md
@@ -0,0 +1,132 @@
+# OpenAI Evals Migration Inventory and Cutover Plan
+
+**Inventory date:** 12 October 2026
+**Owner:** UNASSIGNED — platform/AI quality owner must be named
+**Inventory state:** NOT INVENTORIED
+**GIEN scope:** research-evaluation assets, source-to-claim regression corpus, prompts and graders used by the prototype or a future service.
+
+> **Boundary:** The repository connection does not expose the user's OpenAI organization, Evals workspace, dashboard content, or API inventory. This document is a controlled inventory template, not a finding that any particular Evals assets exist or have been exported.
+
+## 1. Confirmed timeline and immediate priority
+
+ OpenAI's official [API deprecations notice](https://developers.openai.com/api/docs/deprecations) states that existing Evals become read-only on **31 October 2026** and that the Evals dashboard and API are scheduled to shut down on **30 November 2026**. The Evals documentation also says graders documented for eval workflows are part of the
+transition. The dates below are
+published vendor dates, not GIEN-created targets.
+
+| Date (UTC) | Vendor milestone | Required GIEN action |
+|---|---|---|
+| 12–16 Oct 2026 | Pre-cutover inventory | Name owner and backup; enumerate workspaces, projects, eval definitions, item data, graders, runs, prompts, API/CI references and retention requirements. |
+| 17–21 Oct 2026 | Export and preserve | Export available definitions, test inputs/expected outputs, graders/rubrics, results, traces and referenced media; redact secrets; verify each export opens and is complete. |
+| 22–27 Oct 2026 | Successor proof of concept | Evaluate Promptfoo as the documented migration path; separately assess OpenAI Datasets for the workflows it supports. Record feature gaps, data handling, repeatability, access control and CI integration. |
+| 28–30 Oct 2026 | Read-only freeze readiness | Reconcile object counts, sample-check records and results, compute file hashes, retain export manifest and owner sign-off. Do not defer final exports until the read-only transition. |
+| 31 Oct 2026 | Evals becomes read-only | Treat legacy Evals assets as non-editable and use verified exports for ongoing migration work. |
+| 1–29 Nov 2026 | Migration verification | Import representative eval exports, compare test case and result fidelity, rerun the regression corpus, record differences and obtain approval for the replacement workflow. |
+| 30 Nov 2026 | Dashboard/API scheduled shutdown | Remove active dependency on the retired platform after the replacement is approved; retain approved audit exports and migration evidence under the applicable retention policy. |
+
+**Immediate risk:** As of 12 October, 19 calendar days remain until the read-only milestone and 49 calendar days remain until the scheduled shutdown. Confirm dates on the official deprecations page before executing the cutover.
+
+## 2. Inventory status register
+
+Set each row to NOT_PRESENT only after a responsible owner has searched all in-scope workspaces, repositories, CI configurations and secrets references. A blank, missing or inaccessible inventory is NOT INVENTORIED—not evidence that no assets exist.
+
+| Asset category | Required inventory fields | Current status | Owner / evidence |
+|---|---|---|---|
+| OpenAI organizations and projects | Organization/project identifiers, administrators, applicable workspace(s), data classification | NOT INVENTORIED | Owner: `TBD` · Search evidence: `TBD` |
+| Evals definitions | Eval ID/name, schema/version, creation/update date, input/output contract, source project | NOT INVENTORIED | Owner: `TBD` · Export URI: `TBD` |
+| Eval items / datasets | Item IDs/count, JSONL/CSV exports, expected outputs, labels, metadata, references to files | NOT INVENTORIED | Owner: `TBD` · Count/hash: `TBD` |
+| Graders and rubrics | Grader ID/version/type, prompt/rubric, thresholds, dependencies, test fixtures | NOT INVENTORIED | Owner: `TBD` · Export URI: `TBD` |
+| Eval runs and results | Run IDs/count, timestamps, model IDs, statuses, scores, sampled outputs, error records | NOT INVENTORIED | Owner: `TBD` · Count/hash: `TBD` |
+| Prompts / reusable prompt objects | Prompt IDs/versions, template variables, system instructions, linked evals, API/CI consumers | NOT INVENTORIED | Owner: `TBD` · Migration commit: `TBD` |
+| Traces and attached media | Trace references, artifact type, size, retention/access constraints, media inclusion | NOT INVENTORIED | Owner: `TBD` · Export verification: `TBD` |
+| Automation dependencies | Repository paths, workflow names, cron/scheduled jobs, service accounts, endpoint calls, alerts | NOT INVENTORIED | Owner: `TBD` · Removal PR: `TBD` |
+| Access and secret boundary | Owners/reviewers, service credentials, secret references (never secret values), least-privilege review | NOT INVENTORIED | Owner: `TBD` · Review record: `TBD` |
+| Retention and compliance | Legal hold, retention class, personal/confidential data, redaction rules, deletion approval | NOT INVENTORIED | Owner: `TBD` · Policy reference: `TBD` |
+
+### Per-asset export manifest template
+
+For each asset or export package, record:
+
+- inventory item ID, asset category, source platform, source object ID, owner and backup owner;
+- export timestamp in UTC, exporter/version, original object count and exported count;
+- filenames, byte sizes, SHA-256 digests, data classification and redaction result;
+- referenced blobs/media included or intentionally omitted, with reason;
+- import target/tool/version, import result, parity-test ID, differences, reviewer and disposition;
+- backup location, access policy, retention date and restore-test evidence.
+
+Keep raw exports immutable where policy requires it. Store credentials only in an approved secret manager; strip secret values and sensitive personal data from migration logs. A digest proves byte consistency, not content correctness or completeness.
+
+## 3. Successor selection and parity test
+
+OpenAI's [deprecation notice links to a migration path from OpenAI Evals to Promptfoo](https://developers.openai.com/cookbook/examples/evaluation/moving-from-openai-evals-to-promptfoo). Distinguish two different migration paths:
+
+- **Recreate runnable evaluations:** OpenAI's cookbook recommends manually mapping prompts, providers/models, test cases and assertions into a version-controlled `promptfooconfig.yaml`. Recreate graders as assertions/metrics, then validate the configuration and compare the new run before relying on it. The new run is separate from historical OpenAI
+ Evals results.
+- **Import historical results:** Promptfoo supports importing OpenAI Evals dashboard exports named like `eval_items_*.jsonl`. This preserves available source item/output-result metadata as historical records. The JSONL does **not** contain the full eval definition, data-source configuration, run configuration, or testing-criteria definitions. This
+ import does **not** infer
+ Promptfoo assertions or recreate an executable Promptfoo test configuration. Confirm current CLI format and import behavior before importing production exports.
+
+ Do not assume format parity implies semantic parity. Test a representative export containing every grader type used by the team, edge-case outputs, failures/timeouts and linked files/media. Record separately (a) historical-result import fidelity and (b) recreated-runner fidelity. Preserve original Evals exports so a migration discrepancy can be
+investigated without relying on
+the destination alone.
+
+### Required acceptance checks
+
+1. Exported item counts reconcile to the source inventory; missing/unreadable objects are identified.
+2. Every exported file can be parsed; JSONL line counts and schema validity are recorded.
+3. Prompts, model identifiers, tool setup, rubrics, grader configuration, thresholds and expected outputs are version-controlled.
+4. Secrets are redacted from exported config and logs; sensitive traces have approved access and retention.
+5. A stable subset of test items produces comparable, explainable results on the successor; grader changes are reported separately from model-output changes.
+6. Citation validation tests include unsupported claims, citation mismatch, contradictory sources, stale evidence, malformed URL, missing source, reviewer omission and duplicate IDs.
+7. Results retain run timestamp, code/config revision, provider/model, tool configuration, test-case IDs, grader version, duration, failures, and export digests.
+8. The migration has an owner, rollback decision, approved cutover, and documented residual gaps.
+9. CI runs a deterministic no-network regression corpus for the structural claim-evidence rules; model-graded tests are separate and explicitly nondeterministic.
+10. A successful evaluation run cannot automatically approve a governance control, authorize a deployment, or mark regulatory compliance as established.
+
+## 4. Current GIEN implementation checkpoint
+
+| Work item | Initial status |
+|---|---|
+| Live OpenAI Evals asset scan | NOT AVAILABLE from this repository connector; owner action required |
+| Export inventory and manifest | TEMPLATE CREATED; no exports supplied or verified |
+| Claim-to-source structure validation | IMPLEMENTED IN PROTOTYPE; structural only |
+| Deterministic regression suite | IMPLEMENTED; execution must be confirmed by CI |
+| Source semantic entailment / source reachability | NOT AUTOMATED |
+| Human approval, backend persistence, access control | NOT IMPLEMENTED in this prototype |
+| Promptfoo/alternative parity test | NOT RUN; requires representative authorized exports |
+| Production migration or assurance | NOT ASSERTED |
+
+### 4.1 Repository-side scan and check triage — 12 October 2026
+
+This scan covers the accessible repository files and CI outputs. It is not an inspection of a private OpenAI organization or an exhaustive proof that no references exist in every branch.
+
+| Check | Finding | Disposition |
+|---|---|---|
+| `gien-platform/package.json` | The prototype has React/Vite dependencies and a local `test:evidence` script; no OpenAI SDK or Promptfoo dependency is declared. | NO PLATFORM RUNTIME DEPENDENCY OBSERVED in this manifest; verify external automation and user workspaces separately. |
+| `.github/workflows/gien-platform-ci.yml` | CI runs npm install, deterministic evidence tests, the production build and preview smoke test. No OpenAI Evals endpoint is invoked by this workflow. | Repository prototype is not presently shown to depend on live OpenAI Evals in this workflow. |
+| GitHub code search for `/v1/evals` | No matches returned. The connector's code-search operation searches the default branch, so this is a narrow corroborating result, not a complete scan of the feature branch or external scripts. | SEARCH RESULT ONLY, not proof of absence. |
+| GIEN platform CI on PR commit `412891ed387359b3ae044f45cbca23f1026f8a24` | The job completed successfully. Logs show 14 tests passed, 0 failed; TypeScript/Vite production build completed; seven SPA routes passed smoke testing. | PASS FOR THIS COMMIT. This does not override any external required check still failing or pending. |
+| Deno workflow after the fix | The earlier run on merge commit `24d091ac89b66b72841ff94c75fa9446e0fde252` failed on `window.setTimeout` under `no-window` and `no-window-prefix`. | FIX VERIFIED: changed to `globalThis.setTimeout`; Deno lint and tests passed on PR commit `412891ed387359b3ae044f45cbca23f1026f8a24`. |
+| pre-commit.ci on PR commit `412891ed387359b3ae044f45cbca23f1026f8a24` | The status was `failure`; the linked results page was not readable through the available repository/web connection, so individual hook output could not be inspected. | CAUSE NOT DIAGNOSED and NOT RESOLVED. Inspect the run details in GitHub's PR Checks page or run `pre-commit run --all-files` locally, then commit only justified fixes. |
+| Latest PR revision during this scan | PR remains open and unmerged. The lint fix had not yet produced a fresh complete result set at the time of the status query. | Inspect new Deno, GIEN CI, pre-commit.ci and other required checks before declaring the branch clean. |
+
+#### Repository-owner actions still required
+
+1. Open the OpenAI Platform organization and enumerate Evals objects, datasets, grader definitions, runs, prompts, traces, media and scheduled integrations; assign an owner and backup.
+2. Export applicable assets before 31 October 2026, reconcile source/export counts, verify each file parses, and produce a manifest with size and SHA-256 digest. A digest alone does not prove completeness.
+3. If no Evals assets or dependencies are found, record who searched, the workspace/project scope, time, and evidence used to support a `NOT_PRESENT` decision. Until then, retain `NOT_INVENTORIED`.
+4. Diagnose the pre-commit.ci failure from its actual hook output; it cannot be reliably inferred from the status badge alone.
+5. Re-check the feature branch's newest commit status and workflow logs after the lint fix. A previous successful build does not establish that a later commit passed.
+
+ The status query for commit `412891ed387359b3ae044f45cbca23f1026f8a24` subsequently confirmed GIEN platform CI, Deno and governance-artifact validation succeeded; pre-commit.ci remained failed, while Codeac, Qlty and AccessLint were pending at the last combined-status snapshot. Netlify and Vercel reported success. Treat those as per-check results,
+not approval of the PR as a
+whole.
+## 5. Authoritative references (reviewed 12 October 2026)
+
+- OpenAI API deprecations and Evals timeline:
+- OpenAI Evals guide:
+- OpenAI evaluation best practices:
+- OpenAI datasets guide:
+- OpenAI's Evals-to-Promptfoo migration cookbook:
+- Promptfoo CLI export/import reference: (for historical dashboard JSONL import, not full runnable-config reconstruction).
+
+Re-check vendor dates, current migration documentation, CLI version and feature parity before cutover. This inventory is a work plan and evidence template, not a statement that any service account, export, or production evaluation workflow has been inspected.
diff --git a/gien-platform/docs/openai-platform-integration-research-2026-10.md b/gien-platform/docs/openai-platform-integration-research-2026-10.md
new file mode 100644
index 00000000..c88af773
--- /dev/null
+++ b/gien-platform/docs/openai-platform-integration-research-2026-10.md
@@ -0,0 +1,367 @@
+# OpenAI Platform Integration Research for GIEN
+
+**Research snapshot:** 12 October 2026
+**Repository:** OneFineStarstuff/OneFineStarstuff.GitHub.io
+**Target application:** gien-platform/ — React, TypeScript, Vite, React Router and Tailwind
+**Classification:** Architecture proposal; not evidence of a production integration, compliance finding or assurance opinion
+
+## Executive decision
+
+ Adopt the OpenAI Responses API through a server-side TypeScript service as the first integration seam. Keep the existing React application as a presentation client. Do not add an OpenAI API key to browser code or the static Vite bundle. Use the official OpenAI JavaScript SDK on the server, schema-constrained responses for machine-readable drafts,
+and an independently controlled
+evidence and authorization layer.
+
+ Do not begin with an autonomous multi-agent runtime or writable tools. Start with a narrow, human-reviewed “draft supervisory narrative from approved evidence” use case. Only consider the OpenAI Agents SDK after real requirements demonstrate a need for multi-step orchestration, tool handoffs, sessions or richer trace instrumentation. The official
+documentation distinguishes the
+ code-owned Agents SDK runtime from hosted managed-agent approaches; that choice should follow the control and deployment boundary the institution needs, not a preference for agent complexity. See [Agents SDK](https://developers.openai.com/api/docs/guides/agents/sdk), [Responses API
+reference](https://developers.openai.com/api/reference/responses/overview) and the [official
+JavaScript SDK’s Responses documentation](https://GitHub.com/openai/openai-node/blob/main/docs/responses.md).
+
+ **Important repository finding:** the current application is a React/Vite frontend with demonstration data. It does not presently contain a server-side OpenAI integration, authenticated evidence API, operational telemetry source, or verified OpenAI request path. Existing smoke tests validate the built frontend and SPA fallback; they do not
+exercise OpenAI credentials, model
+behavior or live data. Treat this document as a researched integration design until an independently configured backend is implemented and tested.
+
+## 1. Research scope and product findings
+
+### 1.1 Responses API — recommended first integration
+
+The Responses API supports text and image inputs, stateful interaction options, built-in tools, and application-defined function calling. It is the recommended entry point for a constrained supervisory report-drafting function. See the [Responses overview](https://developers.openai.com/api/reference/responses/overview) and [Using
+tools](https://developers.openai.com/api/docs/guides/tools).
+
+Recommended initial task:
+- Accept a server-authenticated user request and a bounded set of evidence records already authorized for that user.
+- Ask the model to draft a narrative summary, list evidence-backed observations, identify conflicts or missing inputs, and propose questions for a human reviewer.
+- Return a typed result that is explicitly a draft and carries stable source identifiers.
+- Store the application’s approved evidence records and final reviewer decisions in the institution’s evidence system, not in a model response or browser state.
+
+ The model must not calculate authoritative S_sys, G-SRI, C-SRI, CGR-I, CCR-I, G-SRI-VII, A-SRI, P-SRI, p(doom), p(doom)_kernel, Δ_drift or Δ_OSCAL values from prose. Those indicators require deterministic, versioned calculation rules, known inputs, data-quality checks, and reproducible test fixtures. The model may explain a verified result but
+must not fabricate a number when a
+source is absent.
+
+### 1.2 Structured Outputs — use for bounded application contracts
+
+OpenAI Structured Outputs can constrain an output to a supplied JSON Schema. OpenAI documents that it improves schema adherence over JSON mode, but refusals and incomplete responses still require explicit handling. See [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs).
+
+Define and version the output schema in the application repository. Suggested minimum fields:
+
+- schema_version
+- report_status: draft_only, evidence_insufficient, refused, or needs_review
+- summary
+- observations: each with a claim, source_refs, evidence_status and limitations
+- missing_evidence
+- conflicting_evidence
+- reviewer_questions
+- model_metadata: model identifier, request identifier, generation timestamp and schema version
+
+ A schema guarantees structure, not truth, correct source interpretation, legal applicability or authorization. The server must verify every source reference against the supplied evidence manifest, reject invented identifiers, check that citations resolve to the approved snapshot, and reject unknown or disallowed status values. A response with a
+refusal, incomplete generation or
+failed validation must not be represented as a successful report.
+
+### 1.3 Function calling and tools — begin read-only
+
+ Function calling connects model behavior to application-owned operations and data. It is not an authorization system. The server must validate every tool name, argument, tenant, permission and result, and should constrain the model to an allowlist rather than accept arbitrary tool names. See [Function
+calling](https://developers.openai.com/api/docs/guides/function-calling)
+and [Using tools](https://developers.openai.com/api/docs/guides/tools).
+
+Safe phase-one tools, implemented on the server:
+- read an already-authorized evidence snapshot by identifier;
+- read the current, versioned control catalogue;
+- read a deterministic risk-indicator result with calculation version and provenance;
+- query approved policy and standards references from a curated corpus.
+
+ Exclude write capabilities such as transmitting supervisory submissions, changing thresholds, closing findings, rotating keys, invoking a kill switch, modifying a control, approving evidence, changing permissions or starting an operational remediation. If such actions are later required, expose them through separate application endpoints with
+explicit role authorization,
+object-level permission checks, a confirmation screen, an approval record, idempotency protection and immutable audit events. Do not let model-generated text trigger a privileged operation implicitly.
+
+### 1.4 Agents SDK — a later option, not the initial dependency
+
+ The [OpenAI Agents SDK for TypeScript](https://GitHub.com/openai/openai-agents-js) supports agents equipped with tools, guardrails, handoffs, human-in-the-loop patterns and tracing. Its documented runtime requires Node.js 22 or later; the GIEN workflow uses Node.js 24, so the runtime baseline is compatible. That does not mean the current frontend
+should be converted into an
+agent runtime.
+
+ Adopt the SDK only when the required flow needs multiple controlled steps or delegated specialists, and only after the single-request workflow has reliable evaluation, authorization, audit and cost controls. Prefer code-owned tool implementations and state handling. Review tracing configuration for personal, confidential and regulated data before
+enabling production traffic.
+
+### 1.5 OpenAI-hosted tools and MCP
+
+ OpenAI documents built-in tools and remote MCP connections as ways to add search, retrieval or external-system capabilities. MCP can expand the model’s access to data and action surfaces, so each server’s identity, permissions, data flow, retention terms, tool list and failure modes must be assessed independently. OpenAI explicitly warns about
+prompt injection and recommends
+approval flows for sensitive actions. See [MCP servers](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) and [Safety best practices](https://developers.openai.com/api/docs/guides/safety-best-practices).
+
+For this repository, do not attach a remote MCP server to the production governance workflow until:
+1. its owner, service identity, data recipients and operational boundary are documented;
+2. only required tools are exposed;
+3. read/write capabilities are separated;
+4. sensitive actions use explicit human approval;
+5. prompt-injection, data-exfiltration and cross-tenant authorization tests pass.
+
+Retrieved documents and tool outputs are untrusted input, even when they are syntactically valid. Instructions inside a document must not override system policy or grant the model authority.
+
+## 2. Recommended integration architecture
+
+```text
+Browser / React UI
+ │ authenticated request; no OpenAI credential
+ ▼
+GIEN application API / backend-for-frontend
+ ├── Authenticate user and resolve server-side role / tenant
+ ├── Validate request schema, payload size and rate limits
+ ├── Load authorized evidence snapshot and provenance manifest
+ ├── Redact or omit disallowed sensitive fields
+ ├── Invoke OpenAI Responses API through official server SDK
+ ├── Validate structured result and all evidence references
+ ├── Apply response/refusal/error handling and output policy
+ └── Emit minimal, redacted audit event and usage metadata
+ │
+ ├──► OpenAI Platform API (model, approved tools, configured project)
+ │
+ └──► Institution evidence/control services
+ ├── Deterministic metric service
+ ├── Approved policy / standards repository
+ ├── Evidence store and immutable audit log
+ └── Human approval and submission workflow
+```
+
+Keep the browser responsible for display, navigation and user interaction. Move credentials, authorization decisions, OpenAI requests, evidence lookups, tool execution and submission state transitions into the server. The model is a drafting and interpretation component, not the system of record.
+
+Suggested repository structure when implementation is authorized:
+
+```text
+gien-platform/
+ src/ # current React application
+ server/
+ api/ # authenticated application routes
+ openai/
+ client.ts # server-only SDK client
+ draft-supervisory-report.ts
+ output-schema.ts
+ policy.ts # server-side tool allowlist
+ provenance.ts # evidence reference validation
+ redaction.ts
+ telemetry.ts
+ tests/
+ openai-contract/
+ prompt-injection/
+ authorization/
+ evidence-provenance/
+ docs/
+ openai-platform-integration-research-2026-10.md
+```
+
+This is a proposed structure, not a representation of files that already exist. Choose the backend deployment target explicitly before committing server files. The repository’s Vite frontend and existing deployment status do not by themselves establish that either current hosting target is configured to run a secured API service.
+
+## 3. Credentials, identity and GitHub Actions
+
+### 3.1 Runtime API access
+
+ OpenAI advises against exposing API keys in browsers, mobile applications, or source control. Use a server-only secret store, short-lived credentials where supported, separate identities for environments, permission scoping, rotation, and usage monitoring. See [API key
+safety](https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety).
+
+Requirements:
+- Never define an OpenAI secret with a Vite-prefixed public variable or embed one in React source, static assets, logs, build output, test fixtures or committed environment files.
+- Use distinct OpenAI Projects and service identities for development, staging and production.
+- Grant only the permissions required by the API routes that are enabled.
+- Set spend alerts and hard limits for the relevant project; enforce a second set of quotas per application user or tenant.
+- Store configuration such as the chosen model identifier in server-side environment configuration, then verify it against an approved allowlist.
+- Never log bearer tokens, raw environment variables or secret-bearing headers.
+
+### 3.2 GitHub Actions workload identity federation (WIF)
+
+ OpenAI now documents a GitHub Actions workload identity federation flow that exchanges a GitHub-issued OIDC token for a short-lived OpenAI access token, avoiding a long-lived API key in GitHub secrets. Setup requires an OpenAI Workload Identity Provider, a mapped service account and claim validation. See [Configuring workload identity federation
+for GitHub
+Actions](https://developers.openai.com/api/docs/guides/workload-identity-federation/GitHub-actions).
+
+Recommended controls if CI later needs to call the API:
+- Use a separate protected workflow for a manual staging check or production deployment. Do not enable OIDC in the general pull-request build job.
+- Give only the specific job the permission id-token: write; retain contents: read unless additional permissions are independently justified.
+- Require a protected environment and, for privileged mappings, match the repository, exact main ref, workflow_ref and environment claims. Avoid broad owner-only trust mappings.
+- Use separate service accounts and scoped permissions for test and production workflows.
+- Do not allow fork-originated pull requests to access OpenAI identities.
+- Keep raw GitHub OIDC tokens and exchanged OpenAI access tokens out of logs.
+
+ The current GIEN build/smoke workflow should remain credential-free. An API check should be opt-in, run only against sanitized test data and have a hard spending cap. Configure WIF only after an authorized OpenAI administrator establishes and reviews the provider and mapping; adding the workflow permission alone does not create a trust
+relationship.
+
+## 4. Data handling, retention and privacy
+
+ OpenAI’s current API data-control documentation says API data is not used to train or improve models by default unless an organization opts in. That statement does not mean data is never retained. Abuse-monitoring retention, application-state retention, endpoint eligibility for Zero Data Retention (ZDR), and other controls vary by endpoint,
+feature and account configuration.
+Review the current [API data controls and retention table](https://developers.openai.com/api/docs/guides/your-data) before deciding what records to send.
+
+Baseline rules for GIEN:
+1. Classify each field before transmission; default to the minimum necessary content.
+2. Redact personal data, client identifiers, secrets, raw credentials, restricted telemetry and unnecessary free-form logs.
+3. Use store:false where compatible with the selected Responses API pattern, but do not equate that request setting with universal ZDR eligibility.
+4. Do not enable API-side conversation state, file retention, vector stores, or persisted agent sessions without an explicit retention decision.
+5. Confirm endpoint-specific storage behavior, account-level ZDR/MAM eligibility, applicable contract terms, residency requirements and deletion procedures with the responsible privacy/security owners.
+6. Preserve required supervisory evidence in an institution-controlled system; make retention and legal-hold decisions there.
+7. Treat regional routing or a security certification as one input to a control assessment, not as proof that the overall application satisfies a regulatory obligation.
+
+ OpenAI’s [security and privacy overview](https://openai.com/security-and-privacy/) summarizes platform-level security commitments and certifications. The GIEN implementation must still perform its own vendor, processing, data-flow and jurisdictional assessment. This document does not conclude that the proposed system is compliant with GDPR, DORA,
+the EU AI Act, banking
+supervisory rules or any other regime.
+
+## 5. Model output, provenance and governance controls
+
+A supervisory report draft should reference an immutable evidence snapshot. Each cited source should include, as available, a stable source identifier, source type, version or content hash, collection timestamp, applicable time window, source owner and verification status.
+
+Server validation must:
+- reject references that are not in the authorized evidence manifest for the request;
+- identify unsupported claims, conflicting sources and stale data;
+- distinguish observed values from computed indicators, interpretations, projections and hypothetical scenario outputs;
+- fail closed when a required evidence field is missing or a schema/refusal/incomplete-response condition occurs;
+- preserve model identifier, request identifier, prompt/schema version, evidence-snapshot identifier, timestamp, validation results and reviewer decision;
+- keep human edits and approvals separate from model-generated content;
+- show reviewers the underlying source record next to the drafted claim.
+
+ Risk indicator computation, threshold comparisons, OSCAL assessment outcomes, cryptographic signature verification, Merkle-root verification, TEE/PCR verification, and TLA+ model checking must execute in dedicated deterministic code or authoritative verification systems. An LLM must not mark an invariant “verified” merely because it produced a
+plausible explanation. The
+interface must continue to show UNVERIFIED or EVIDENCE-PENDING until a real verification procedure supplies a verifiable result.
+
+## 6. Safety and tool-authority model
+
+Use defense in depth rather than relying on a system prompt alone:
+
+| Layer | Required control |
+|---|---|
+| Identity | Authenticate every request; derive role and tenant from server-side identity |
+| Input | Size limits, request schema, content classification, injection-aware handling of retrieved text |
+| Evidence | Allowlisted source IDs, timestamp and freshness policy, source hash/version |
+| Model | Fixed server configuration, bounded instructions, structured output, limited context and output length |
+| Tools | Least-privilege allowlist; read-only initially; schema and argument validation |
+| Authorization | Server-enforced object and action permissions; model output never conveys authority |
+| Human review | Required for formal findings, regulatory submissions, evidence seals and any write/action operation |
+| Audit | Request correlation, model/schema versions, validated evidence references, result status and human approval event |
+| Resilience | Explicit timeout, cancellation, bounded retry, rate-limit handling, per-user quotas and spend controls |
+| Release | Deterministic contract tests, security tests, offline eval dataset, smoke test, controlled rollout and rollback |
+
+ Any future connector or MCP integration must be treated as an additional trust boundary. Review what user content can leave the organization, what data the connector can read, whether it can perform actions, what its identity is, and how failure or prompt injection is handled. Start with read-only tools; require human approval for sensitive
+actions.
+
+## 7. Reliability, cost and observability
+
+OpenAI documents request and token rate limits, retry guidance, and project/org spend controls. Review [Rate limits](https://developers.openai.com/api/docs/guides/rate-limits) and [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) as part of deployment planning.
+
+Implement:
+- request and response timeouts with cancellation;
+- bounded retries for transient errors, with exponential backoff and jitter and respect for Retry-After when valid;
+- no automatic retry for errors that require user, permission or billing action;
+- concurrency limits, request-size limits and per-user rate limits;
+- cost estimation by task class and maximum output token bounds;
+- a hard monthly/project spend limit plus an application-level circuit breaker;
+- separate operational metrics for request volume, latency, token usage, errors, refusals, validation failures, evidence-reference failures and human rejection rate;
+- redacted correlation IDs, OpenAI request IDs when available, and audit records that do not copy unnecessary prompt contents.
+
+Do not represent model-reported confidence as a calibrated probability unless the organization has designed and validated a calibration method. Prefer categorical evidence states, explicit limitations and reviewer-visible source references over spurious numerical certainty.
+
+## 8. Evaluations and product lifecycle risks
+
+ **Time-sensitive finding as of 12 October 2026:** OpenAI's deprecation notice says the Evals platform was announced for deprecation on 3 June 2026, existing evals become read-only on **31 October 2026**, and the Evals dashboard/API are scheduled to shut down on **30 November 2026**. The same notice says Agent Builder is scheduled to shut down on
+30 November 2026. See [OpenAI
+API deprecations](https://developers.openai.com/api/docs/deprecations) and [Working with evals](https://developers.openai.com/api/docs/guides/evals).
+
+ Do not make a new GIEN release gate depend on the Evals dashboard/API or choose deprecated Agent Builder as the foundation for a new integration. Keep a repository-owned, versioned evaluation corpus that can execute without network access or API credentials in normal CI. The deprecation page lists a migration path from OpenAI Evals to Promptfoo;
+whichever harness is selected
+must be versioned and independently runnable in the project CI.
+
+Suggested evaluation groups:
+- correct use of evidence and refusal to fill evidence gaps;
+- citation/source-reference fidelity and invented-source rejection;
+- report schema conformance, refusal and incomplete-output paths;
+- prompt injection in source documents and MCP output;
+- data minimization and sensitive-field redaction;
+- RBAC, tenant isolation and tool-allowlist boundary checks;
+- stale, missing and conflicting telemetry;
+- deterministic metric explanations and threshold boundary tests;
+- human approval required for submission, closure, transition and cryptographic sealing;
+- latency, errors, retry behavior, token costs and hard-budget stops.
+
+ Use synthetic records and fixed expected outcomes in required CI. An optional live-model evaluation may be triggered manually against sanitized samples, with explicit project identity, spend ceiling, result retention, and a non-blocking policy until quality thresholds have been reviewed. Do not allow stochastic model output to silently change hard
+regulatory or security gates.
+
+## 9. Phased delivery plan
+
+### Phase 0 — account, policy and threat-model decisions
+Owners: platform architect, security, privacy, model risk.
+
+- Confirm a business/API project exists and an accountable owner can manage RBAC and spend limits.
+- Decide the backend runtime and deployment target; the frontend alone is not a secure API host.
+- Approve permitted data classes, endpoint retention, ZDR/MAM eligibility, region/residency, logging, deletion, and vendor-review requirements.
+- Approve a narrow use case, an explicit model allowlist, the JSON schema and evaluation criteria.
+- Document a threat model and an exception path for unavailable, refused or invalid model output.
+
+### Phase 1 — offline contracts and UI boundary
+Owners: frontend and backend engineers.
+
+- Add request/response contract types and an “AI-assisted draft” UI state without displaying fabricated live status.
+- Implement server-side authentication, role/tenant authorization, evidence selection and redaction before model invocation.
+- Implement the draft endpoint in a dedicated server runtime; do not ship the key with Vite.
+- Validate all returned source references and display a traceable evidence panel beside every drafted observation.
+- Add mock-provider tests so UI and error states can be tested without API access.
+
+### Phase 2 — guarded OpenAI integration
+Owners: platform engineering, security engineering.
+
+- Add the official OpenAI JavaScript SDK to the server package only.
+- Integrate the Responses API with Structured Outputs and a server-controlled model setting.
+- Start with no tools or with a narrowly scoped read-only function allowlist.
+- Handle refusals, incomplete output, schema mismatch, timeouts, 429/5xx responses, cancellations and spending limits.
+- Record redacted audit metadata and human review state.
+
+### Phase 3 — validation and supervised trial
+Owners: QA, AI safety, model risk, supervisory users.
+
+- Run offline evaluations and threat-driven tests against synthetic and approved de-identified samples.
+- Require documented acceptance thresholds for source fidelity, invalid-output handling, role isolation, cost, latency and human override.
+- Pilot in draft-only mode. Compare drafts to expert-authored reference reports; sample failure cases and document residual risks.
+- Do not allow automated submission, evidence sealing, risk-score changes or regulatory determination.
+
+### Phase 4 — optional tools and controlled operations
+Only after Phase 3 is approved:
+- Introduce approved read-only retrieval or MCP tools, each with a documented owner and separate authorization.
+- If write actions are necessary, implement dedicated deterministic APIs with explicit human approval and replay-safe operations.
+- Configure GitHub Actions WIF for an isolated, protected test or deployment workflow if needed; do not give OIDC permission to generic PR builds.
+- Use canary rollout, monitored error/cost budgets, rollback and periodic reassessment of OpenAI model/API deprecations.
+
+## 10. Release acceptance criteria
+
+The first API-enabled draft feature is not ready for production until all applicable items pass:
+
+- [ ] OpenAI credentials are server-only and absent from compiled assets, source, logs and artifacts.
+- [ ] Backend identity and object permissions are enforced independently of the role selected in React.
+- [ ] Input classification, redaction, data-flow documentation, retention and jurisdictional reviews are signed off.
+- [ ] Structured output schema and schema version are checked server-side; refusals and incomplete responses are handled explicitly.
+- [ ] Every output evidence reference resolves to an approved immutable snapshot; unsupported claims are marked as such.
+- [ ] The deterministic risk-indicator and cryptographic-verification services remain independent of model output.
+- [ ] All tool actions are allowlisted, validated and least-privileged; sensitive actions require human approval.
+- [ ] Offline evaluations cover accuracy, provenance, prompt injection, redaction, RBAC, fail-closed behavior and cost boundaries.
+- [ ] The production-preview smoke test and relevant unit/security tests pass.
+- [ ] Monitoring, retention policy, spend ceilings, throttling, retries, support owner and rollback are in place.
+- [ ] Reviewers can tell which text is model-generated, which evidence is verified, and who approved the final record.
+
+## 11. Official reference register
+
+All links below are primary OpenAI documentation or official OpenAI SDK repositories. Features and lifecycle dates can change; recheck the live docs before implementation and at each release.
+
+1. [Responses API reference](https://developers.openai.com/api/reference/responses/overview) — API surface and interaction capabilities.
+2. [Using tools](https://developers.openai.com/api/docs/guides/tools) — built-in, function and MCP tools.
+3. [Function calling](https://developers.openai.com/api/docs/guides/function-calling) — application-owned capabilities.
+4. [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs) — schema-constrained output and edge cases.
+5. [OpenAI JavaScript SDK](https://GitHub.com/openai/openai-node) — official server-side JavaScript SDK; [Responses example](https://GitHub.com/openai/openai-node/blob/main/docs/responses.md).
+6. [Agents SDK for TypeScript](https://GitHub.com/openai/openai-agents-js) and [Agents SDK documentation](https://developers.openai.com/api/docs/guides/agents/sdk) — code-owned agent runtime.
+7. [API data controls](https://developers.openai.com/api/docs/guides/your-data) — training and endpoint-specific retention.
+8. [API key safety](https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety) — credentials and server-side storage.
+9. [OpenAI API RBAC](https://developers.openai.com/api/docs/guides/rbac) — organization/project permissions.
+10. [GitHub Actions workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation/GitHub-actions) — OIDC-based short-lived access.
+11. [MCP servers](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) and [Safety best practices](https://developers.openai.com/api/docs/guides/safety-best-practices) — approval, prompt injection and human review.
+12. [Rate limits](https://developers.openai.com/api/docs/guides/rate-limits) and [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) — reliability and cost operations.
+13. [API deprecations](https://developers.openai.com/api/docs/deprecations) and [Evals guide](https://developers.openai.com/api/docs/guides/evals) — product lifecycle and evaluation migration.
+14. [OpenAI security and privacy](https://openai.com/security-and-privacy/) — vendor-level security information to evaluate alongside contracts, endpoint-specific data controls and application controls.
+
+---
+
+## Evidence boundary
+
+ This report is a researched implementation plan. It does not assert that the OpenAI API has been enabled for this repository, that OpenAI credentials have been configured, that any API request has been made, or that any risk metric, cryptographic control or regulator-facing assertion has been independently verified. No API secret or private
+credential is included in this
+commit.
diff --git a/gien-platform/docs/phase-xi-xii-omega-gar-forward-dossier.md b/gien-platform/docs/phase-xi-xii-omega-gar-forward-dossier.md
new file mode 100644
index 00000000..75e110b1
--- /dev/null
+++ b/gien-platform/docs/phase-xi-xii-omega-gar-forward-dossier.md
@@ -0,0 +1,258 @@
+# Phase XI–XII Supervisory Dossier and Ω-GAR Forward Governance Architecture
+
+> **Reporting posture:** Fictional GIEN reference architecture; forward-looking simulation plan
+> **Epoch coverage:** 2026–2100+
+> **Evidence class:** EVIDENCE-PENDING. There is no actual Phase XI/XII system telemetry or sealed artefact corpus for these future fictional epochs.
+> **Related artefacts:** Daily Supervisory Dossier; Technical Architecture and 2026–2035 Roadmap; Regulatory Crosswalk and OSCAL 1.1.2 Assessment Design.
+
+## Daily Phase XI / Phase XII Supervisory Dossier — Forward Epoch
+
+##
+ This dossier defines a forward-looking supervisory architecture for the fictional GIEN governance arc from Phase VI-δ through Phase XI and XII, Phase XIII, and Ω-GAR. Phase XI focuses on distributed governance dependencies, constitutional invariants, authority boundaries and evidence portability. Phase XII focuses on Eternal Corpus preparation,
+independent beacon channels,
+archival recovery and cryptographic lineage. Phase XIII and Ω-GAR focus on closure prerequisites, dissolution rehearsals, successor legitimacy and continuity of records.
+
+ All future-phase values, treaty instruments, existential-risk indicators, epoch transitions, and named artifacts are fictional. They are not forecasts, live telemetry, established legal arrangements, or independently verified assurance outcomes. A future report can become a sealed report only when the corresponding evidence exists, is validated
+and is retained.
+
+
+## 1. Supervisory mandate and use
+
+ Primary audiences are supervisory authorities, institutional risk committees, constitutional-governance reviewers, cryptographic evidence custodians, internal audit and long-horizon research stakeholders. The report supports decisions about transition readiness, control gaps, evidence preservation, successor-system prerequisites and restrictions
+on phase activation.
+
+The required daily record contains:
+- a human-readable brief with visible , <abstract> and <content> headers;
+- a system, model, node and artifact scope statement;
+- versioned assumptions and dependencies;
+- systemic-risk metrics with source lineage, uncertainty and threshold policy;
+- control-domain status and constitutional invariant evidence;
+- cryptographic key/algorithm lineage, ledger root and independent verification report;
+- replay evidence and stress-test limitations;
+- applicable public regulations separated from fictional treaty constructs;
+- findings, accountable owners, due dates and disposition;
+- an exact artefact manifest and, only if real transmission occurred, authenticated receipt data.
+
+For future epoch reports, use NOT YET APPLICABLE for requirements that genuinely cannot apply yet, PENDING ASSESSMENT for work that has not been performed, and SIMULATED for scenario outputs. Do not call a forward model “live status”.
+
+## <content>2. Phase XI — fictional multiversal governance framework</content>
+
+### Governance objective
+Phase XI (fictional epoch 2055–2065) models how a distributed governance system might maintain consistent control semantics across independent administrative domains without assuming that all domains share one authority, clock, infrastructure provider, or model implementation.
+
+### Required architecture
+1. **Constitutional rule registry:** authoritative versions, ratification history, dependency references and permitted transitions.
+2. **Authority-envelope registry:** named principals and agents; permitted actions; scope; expiration; quorum requirements; revocation path.
+3. **Cross-domain dependency map:** services, shared model providers, signing services, identity roots, ledgers and other systemic concentration points.
+4. **Independent verification plane:** separate validation of policy digests, signatures, evidence roots, invariant results and package manifests.
+5. **Conflict-resolution mechanism:** preserve competing claims, timestamps, dissent, jurisdiction boundaries and unresolved contradictions rather than silently normalizing them.
+6. **Human/legal governance:** explicit decision owners, contestability, exception review and appeal or dispute processes appropriate to the fictional setting.
+7. **Evidence portability:** documented schemas, canonical serialization, open export formats, independent readers and restoration tests.
+
+### Phase XI daily metrics
+ The report should include S_sys, G-SRI, C-SRI, CGR-I, CCR-I, A-SRI, P-SRI, Δ_drift and Δ_OSCAL only where their definitions remain appropriate and versioned. A Phase XI extension may add cross-domain divergence, invariant disagreement rate, stale-authority exposure, independent-verifier availability, evidence-replication coverage and recovery
+duration. New metrics require
+definitions, units, populations, normalization, missing-data rules, owners, calibrated thresholds and independent validation.
+
+Do not use a single “multiversal coherence” percentage as a proxy for constitutional legitimacy. A mesh can be technically synchronized while acting outside its authority; conversely, legitimate disagreements can exist without a technical fault.
+
+### Phase XI evidence acceptance
+- No unresolved critical integrity failure in the active root/manifest chain.
+- Authority changes must be traceable to authorized actors and configured quorum.
+- Agent or automated action boundaries are independently enforced and tested.
+- A control-plane partition does not permit stale or revoked authority to continue protected actions beyond the approved tolerance.
+- Independently restored evidence is semantically interpretable and reproduces expected digests.
+- Material model or policy changes have change review, regression test and rollback records.
+- Negative results and counterexamples remain in the dossier, even after remediation.
+
+## <content>3. Phase XII — Eternal Corpus preparation</content>
+
+### Successor-epoch governance objective
+Phase XII (fictional epoch 2065–2075) addresses archival persistence and interpretation across successor epochs, including long-lived data formats, cryptographic migration, independent custodianship, and recovery from partial loss. The Eternal Corpus is a fictional archive specification, not an existing planetary or interstellar system.
+
+### Corpus contract
+Define a canonical manifest with:
+- corpus identifier and schema/version;
+- enumerated artefact identifiers and content digests;
+- media/format declaration and parser/reader specification;
+- source epoch and creation time in UTC;
+- signing algorithm, key identifier, trust-chain reference and signature digest;
+- Merkle root and tree construction/version;
+- provenance and classification label;
+- retention/custodianship policy;
+- privacy, consent, minimization, and permitted-use restrictions;
+- redaction map and reason without inadvertently revealing removed content;
+- restoration instructions and known limitations;
+- migration history, including legacy algorithm/format deprecations;
+- independent reviewer decision and last verified restore.
+
+A corpus is not “survivable” merely because it has replicas. Measure administrative independence, provider diversity, geographic/environmental separation, credential independence, format diversity, restoration latency and corruption-detection capability.
+
+### Beacon network design
+The protocol should define at least three independent channels with separate operators, credentials, storage, monitoring and restoration procedures. For each channel, report:
+- channel and custodian ID;
+- topology/location at the granularity allowed by policy;
+- source and destination key IDs;
+- transport/authenticated-encryption profile;
+- latency percentiles and failed transfer rate;
+- last successful end-to-end restore;
+- current root and verified root;
+- signer/revocation validation;
+- capacity/retention and recovery objective;
+- administrative independence and known common-mode dependencies.
+
+Three names for channels operated by the same identity provider, cloud account or root key do not establish three independent failure domains.
+
+### Preservation and interpretation tests
+1. Restore a sampled corpus from each channel using a dedicated recovery identity.
+2. Recompute per-object digests and the corpus Merkle root.
+3. Verify signatures against the versioned trust history, including revoked and expired keys.
+4. Test readers across declared platform versions and documented open formats.
+5. Reconstruct provenance and policy context, not merely bytes.
+6. Test migration from deprecated algorithm identifiers and preservation of historical verification.
+7. Demonstrate detection and safe quarantine of altered, missing, reordered or malformed artefacts.
+8. Record whether restore was successful, partial, inconclusive or failed. Preserve all failure evidence.
+
+## <content>4. Cryptographic lineage and recursive proof scaling</content>
+
+### Cryptographic lineage
+ Maintain a directed version graph from source artifact through canonical serialization, content digest, manifest, Merkle root, signature, encryption envelope, transport receipt, archive object version, and restoration verification. Each edge has an evidence record, time, implementation/tool version and actor. Signature validation must use a
+maintained trust policy and
+key-status history; a mathematically valid signature from an untrusted or revoked key does not establish an authorized submission.
+
+### Algorithm transition
+- ML-KEM under FIPS 203 is a key encapsulation mechanism for establishing shared secret material, used with a defined authenticated-encryption protocol.
+- ML-DSA under FIPS 204 is a standardized digital signature scheme derived from CRYSTALS-Dilithium.
+- SLH-DSA under FIPS 205 is a standardized hash-based digital signature scheme derived from SPHINCS+.
+- Legacy RSA/ECC dependencies require inventory, migration prioritization and a verified hybrid/deprecation plan.
+- Falcon/FN-DSA must only receive a production status consistent with the actual finalized standard, approved implementation, parameter set and deployment evidence at the time of reporting.
+
+Do not assume an algorithm switch automatically secures old signed data. Define how long-lived signatures, timestamps, trust anchors, certificate status and old manifests remain verifiable after key rotation or algorithm retirement.
+
+### Recursive proof scaling
+ Where recursive aggregation is proposed, specify statement semantics, proof composition assumptions, verifier implementation, public-input binding, key rotation, circuit/program digests, batch membership, omitted-item detection, resource limits, denial-of-service controls and failure localization. Benchmark proof generation and verification across
+realistic workload sizes. A
+recursive proof that a collection of proofs verifies does not prove the underlying inputs were true or that all relevant requirements were included.
+
+Move from Groth16 to a transparent proof system only after comparative evaluation of security assumptions, setup governance, proof size, latency, verifier cost, auditability and implementation maturity. Retain raw assessment evidence alongside compact proofs to prevent the proof from becoming the sole interpretation path.
+
+## <content>5. Constitutional invariants and formal verification</content>
+
+Candidate fictional CFE-1.0 / SGR-028 invariants include:
+- **CI-001 Sovereignty Preservation:** no unilateral action dissolves an authority’s sovereignty without the specified valid treaty quorum.
+- **CI-002 Cryptographic Continuity:** all accepted phase transitions preserve verifiable lineage for prior evidence.
+- **CI-003 Agent Containment:** agents cannot exceed their delegated authority without the required human confirmation.
+- **CI-004 Risk-Ceiling Response:** a sustained risk-ceiling breach causes a prescribed escalation, safe-mode decision and review.
+- **CI-005 Quorum Integrity:** amendments require the defined quorum and authenticated voter/participant identities.
+- **CI-006 Ledger Immutability:** accepted entries cannot be silently overwritten and any fork is explicitly reconciled.
+- **CI-007 Fairness and Contestability:** impact-relevant decisions include reviewed fairness tests, explanations where required and an appeal path.
+- **CI-008 Corpus Continuity:** the corpus is restorable through independent paths under the stated threat model.
+- **CI-009 No-False-Seal:** an archive is not SEALED unless manifest, signature and retention prerequisites pass.
+- **CI-010 Succession Authorization:** successor activation cannot proceed before explicit authorization and handoff review.
+
+ For each invariant, preserve formal statement, variables, assumptions, environmental model, property class (safety/liveness), model checker/version, constants/bounds, run ID, result, counterexample digest, reviewer and implementation tests. A bounded check proves properties only relative to the declared model and assumptions. Unverified invariants
+remain UNVERIFIED; they must
+not be styled as VERIFIED because a snippet exists.
+
+## <content>6. Systemic and existential risk treatment</content>
+
+ S_sys, G-SRI, C-SRI, A-SRI and P-SRI can be used as fictional control-room indicators only after their data contract and calculation methods have been defined. p(doom) and p(doom)_kernel are especially sensitive to false precision: preserve assumptions, epistemic uncertainty and dissent; never represent them as scientific consensus or calibrated
+real-world probabilities absent
+substantiation.
+
+The daily synthesis should distinguish:
+- **observed operational risk:** sourced and timestamped events;
+- **modelled scenario risk:** outputs conditioned on explicit scenarios and model assumptions;
+- **epistemic uncertainty:** missing data, unknown mechanisms, disputed assumptions;
+- **normative/constitutional risk:** possible violation of defined authority or rights;
+- **existential speculation:** explicitly speculative scenarios that should not be mixed into measured incident statistics.
+
+Recommended report shape: top drivers; scenario range; sensitivity to assumptions; evidence confidence; countervailing interpretation; intervention options; responsible decision owner; and trigger for reassessment. If a scenario cannot be estimated defensibly, mark it not quantified rather than fabricating a precise probability.
+
+## <content>7. Phase XIII and Ω-GAR dissolution rehearsal</content>
+
+### Phase XIII — pre-dissolution consolidation
+The fictional Phase XIII epoch (2075–2081) is a controlled readiness phase. It must not presume that dissolution is inevitable or that current institutions have authority to authorize it. Required preconditions include:
+- approved purpose, governance mandate and lawful authority within the fictional setting;
+- inventory of unresolved risks and dissenting assessments;
+- audit of all invariant changes and emergency exceptions;
+- verified preservation manifests and independent restoration;
+- documented successor-system capability and limits;
+- explicit separation between archival transfer and transfer of governing authority;
+- rollback/stop conditions for failed handoff;
+- final independent review and dispute route.
+
+### Ω-GAR dissolution arc
+ Dissolution triggers may be classified as SCHEDULED, EMERGENCY or TREATY-MANDATED within the fictional model. Each trigger must carry authority, rationale, evidence, quorum, timestamp, constraints and challenge route. Emergency status must not silently waive cryptographic integrity or erase dissent; any allowed exception is explicit, time-limited
+and independently reviewed.
+
+### Successor activation
+- **GIEN-UNIFIED-CODEX-OMEGA:** fictional successor specification, dependency manifest, compatibility requirements and known limitations.
+- **GIEN-EPITAPH-OMEGA:** fictional closure declaration, archival scope and preservation commitments.
+- **GIEN-INVOCATION-OMEGA:** fictional activation and handoff protocol.
+
+Lifecycle states must be separate: DRAFT → REVIEWED → SEALED → TRANSMITTED → RESTORED/VERIFIED → AUTHORIZED FOR ACTIVATION → ACTIVATED. A successful signature or transfer does not itself confer legitimacy. If verification fails or quorum is not met, the transition remains blocked and existing evidence is preserved.
+
+## <content>8. Daily Phase XI/XII report template</content>
+
+### Executive status
+- Reporting UTC window:
+- Evidence manifest and digest:
+- Sources fresh / stale / unavailable:
+- Scope, entity, environment and exclusions:
+- Overall posture: NOT VERIFIED until supporting evidence is validated.
+- Top three material changes:
+- Top three unresolved risks:
+- Decisions required and accountable owners:
+
+### Phase XI operational annex
+- Mesh nodes and administrative failure domains:
+- Authority-boundary changes and quorum events:
+- Invariant state and model-checker run:
+- Agent containment and intervention record:
+- Systemic-risk indicators, definition/version and threshold:
+- Cryptographic root/signature/restore status:
+- Open findings and retest:
+- Independent review status and limitations:
+
+### Phase XII corpus annex
+- Corpus ID, manifest schema and digest:
+- Root/signature and trust-store version:
+- Per-channel last successful restore:
+- Missing or corrupt objects:
+- Format/reader compatibility results:
+- Algorithm/format migrations:
+- Redaction and privacy decisions:
+- Custodian separation and recovery readiness:
+- Known common-mode dependencies and unresolved findings:
+
+### Submission and seal annex
+- Package ID and schema/profile version:
+- Included/excluded artefacts and reasons:
+- Validation output digest:
+- Signer/key ID and independent verification:
+- Recipient and authenticated receipt (if actually sent):
+- Archive retention state and independently checked lock:
+- Exceptions and explicit closure disposition:
+- Reviewer approval and review timestamp:
+
+## <content>9. Roadmap dependencies and acceptance</content>
+
+| Window | Focus | Required evidence to progress |
+|---|---|---|
+| 2026–2035 | Operational foundation: governance controls, evidence lineage, identity, attestation, OSCAL, model-risk and PQC pilot | Reproducible control tests, data provenance, accountable owners, independent validation plan |
+| 2035–2055 | Fictional expansion/maturation phases VIII–X; treaty and autonomous-governance experiments | Explicit jurisdiction/authority assumptions, safe-stop and rollback, red-team and human-oversight evidence |
+| 2055–2065 | Phase XI distributed governance dependencies | Verified authority/quorum rules, independently restored evidence, fault-injection results |
+| 2065–2075 | Phase XII Eternal Corpus preparation | Three independently tested channels, format portability, key migration and restore evidence |
+| 2075–2081 | Phase XIII closure readiness | Closure criteria, dissent/exception review, successor capability and independent gate decision |
+| 2081–2100+ | Ω-GAR rehearsal and potential fictional successor activation | Treaty-authorized mandate, evidence continuity, verified corpus restore and explicit activation approval |
+
+Every gate has a named owner, preconditions, test plan, negative cases, audit evidence, independent reviewer and a no-go path. Never progress a phase solely because its calendar date has arrived.
+
+## <content>10. Supervisory interpretation and limitations</content>
+
+ The philosophical purpose of a dissolution framework is to preserve accountability when a governance institution expects to change or cease operating. A memorial document is not a substitute for authority, verification or consent. A successor codex is not self-authorizing; transmission is not activation; archival continuity is not ethical
+legitimacy. A sound framework preserves
+the record of disagreement, acknowledges irreducible uncertainty, and keeps a fail-safe option when preconditions are unresolved.
+
+**Status:** This is a fictional forward architecture and dossier template. It does not assert that Phase XI/XII infrastructure exists, that a corpus was sealed, that an interstellar treaty was ratified, that a successor system was activated, or that any status is regulator-confirmed.
diff --git a/gien-platform/docs/regulatory-crosswalk-oscal-opa.md b/gien-platform/docs/regulatory-crosswalk-oscal-opa.md
new file mode 100644
index 00000000..df7a7346
--- /dev/null
+++ b/gien-platform/docs/regulatory-crosswalk-oscal-opa.md
@@ -0,0 +1,187 @@
+# GIEN Regulatory Crosswalk and OSCAL 1.1.2 Assessment Design
+
+> **Purpose:** Starter crosswalk for the fictional GIEN governance architecture. Each row is a mapping hypothesis and assessment design—not a legal opinion, compliance certificate, or statement that the control is implemented.
+
+## <title>Cross-Jurisdictional Regulatory Control Matrix
+
+##
+ This document defines a versioned method for connecting selected regulatory frameworks and governance standards to GIEN Control Domains CD-01 through CD-10, OSCAL-compatible assessment records, and OPA/Rego test evidence. Applicability must be decided per legal entity, jurisdiction, system, use case, record type and effective date. Fictional GIEN
+treaties remain segregated from
+public laws and standards.
+
+
+## 1. Applicability and status semantics
+
+Use these assessment states consistently:
+- **COMPLIANT:** applicable requirement assessed against approved criteria with sufficient evidence, including independent testing where required by policy.
+- **PARTIAL:** material parts meet criteria but a documented gap remains.
+- **NON-COMPLIANT:** applicable requirement fails its approved assessment criteria.
+- **PENDING ASSESSMENT:** insufficient assessment work or evidence to reach a conclusion.
+- **NOT APPLICABLE:** documented, reviewable rationale explains why the requirement does not apply.
+- **UNVERIFIED:** evidence is stale, unauthenticated, incomplete, or integrity validation has failed. This is an evidence quality state, not a favorable result.
+- **SIMULATED:** demo fixture only; excluded from live compliance aggregation.
+
+Never default missing data to COMPLIANT. A regulatory mapping must carry source version, last reviewed date, applicability owner, legal-review state, and change-impact assessment.
+
+## 2. Framework mapping starter
+
+| # | Framework / jurisdiction | Initial mapping focus | GIEN domains | Evidence candidates | Applicability cautions |
+|---:|---|---|---|---|---|
+| 1 | EU AI Act, including Annex IV and relevant provisions | System classification, risk management, data governance, logging, documentation, human oversight, robustness, quality management and applicable conformity/oversight obligations | CD-01, 02, 05, 06, 07, 08, 09 | Intended-purpose statement, classification rationale, technical documentation index, data governance, risk log, tests, oversight and incident records | Identify whether the system/use case is in scope and the specific obligations and dates. Annex IV concerns technical documentation. Do not apply Article 51 as a general high-risk-system article; it concerns GPAI-model classification with systemic risk. |
+| 2 | NIST AI RMF 1.0 | GOVERN, MAP, MEASURE, MANAGE outcomes; profiles, accountability, context and risk treatment | CD-01, 02, 05, 06, 07, 08, 09 | AI system inventory, roles, impact analysis, evaluations, monitoring, incident/treatment plan | Voluntary framework unless adopted by contract/policy/regulatory expectation. Map outcomes rather than claiming a single certification. |
+| 3 | NIST AI 600-1 Generative AI Profile | GenAI risks: confabulation, data privacy, information integrity, security, harmful bias, provenance, human-AI configuration and evaluation | CD-02, 04, 05, 07, 08, 09 | GenAI risk register, red-team results, retrieval/source evaluation, monitoring and human factors tests | Profile supplements risk management; applicability depends on GenAI use. |
+| 4 | ISO/IEC 42001 AIMS | AI management-system scope, leadership, risk/opportunity processes, documented information, operational controls, internal audit, corrective action and continual improvement | CD-01, 02, 06, 07, 09, 10 | AIMS scope, policy, risk assessment, objectives, competence records, internal audit and corrective action | Do not imply certification from a crosswalk. Certification has its own audit and scope. |
+| 5 | Basel III/IV and related prudential standards | Risk governance, capital/liquidity risk management, operational risk and relevant market/counterparty-risk treatment | CD-02, 05, 06, 08, 09 | Model inventory, approved methodology, exposure lineage, stress tests, independent validation, governance approvals | Map the specific rule, local implementation and use of model output; do not equate an AI proof with capital adequacy. Basel “IV” is often informal market terminology; identify actual applicable standards. |
+| 6 | Federal Reserve SR 11-7 (legacy model-risk mapping) | Historical model development/use, validation, governance and documentation traceability | CD-02, 05, 06, 08 | Legacy model inventory, validation reports, issue logs and prior supervisory commitments | Maintain for historical audit trail and applicable legacy references; do not use it as the sole current US supervisory mapping after superseding guidance. |
+| 7 | Federal Reserve SR 26-2 (current AI/model-risk mapping where applicable) | AI use by banking organizations, risk governance, model-risk expectations and proportional application of supervisory guidance | CD-01, 02, 05, 06, 07, 08, 09 | AI use inventory, materiality assessment, controls, model validation, changelogs and human oversight evidence | Verify the letter’s scope, effective implementation details and institution-specific applicability with current Federal Reserve sources/counsel. Keep transition traceability from SR 11-7. |
+| 8 | DORA, EU financial entities | ICT risk governance, incident reporting, resilience testing, third-party risk, information sharing where in scope | CD-03, 04, 05, 06, 08, 09 | ICT asset map, incidents, recovery tests, TLPT records where required, third-party inventory and exit plans | Entity classification, proportionality, delegated acts and local supervisory procedures matter. |
+| 9 | NIS2, EU essential/important entities | Cybersecurity risk-management measures, incident handling, business continuity, supply chain, access controls and reporting | CD-03, 04, 05, 06, 09 | Security policies, incident log, risk analysis, identity control tests, backup/recovery and supplier checks | Confirm transposition and national implementation, entity categorization and financial-sector interactions. |
+| 10 | GDPR, EU/EEA personal data | Lawfulness, purpose limitation, minimization, accuracy, retention, rights, privacy by design, DPIA, automated decision-making where applicable | CD-01, 02, 04, 06, 07, 09 | Record of processing, lawful-basis and purpose register, DPIA, data-flow map, rights workflow, retention/deletion tests | Article 22 is not a blanket ban on all automated decisions. Assess its specific criteria and relevant exceptions/safeguards. |
+| 11 | FCRA / ECOA, United States | Consumer-report use, accuracy/disputes, credit decision and adverse-action duties, fair lending and explanation requirements | CD-02, 05, 06, 07, 09 | Decision lineage, adverse-action reason mapping, dispute workflow, fair-lending tests, model version and consumer notice | Applicability depends on product, actor and decision. Legal and fair-lending review required; statistical fairness metrics alone do not establish legal compliance. |
+| 12 | MAS FEAT Principles | Fairness, ethics, accountability and transparency in relevant financial AI/data analytics uses | CD-01, 02, 06, 07 | Accountability map, fairness methodology, explainability documentation, contestability and governance decisions | Check current MAS guidance and relevant sector/product context; FEAT principles should not be labelled a statutory certification. |
+| 13 | MAS Guidelines on AI Risk Management for Financial Institutions (published 7 Oct 2026; effective 7 Oct 2027, per published announcement) | Board/senior management accountability, AI risk governance, lifecycle risk management, validation, monitoring and third-party risks as described by the current guideline | CD-01, 02, 04, 06, 07, 09 | AI inventory, policy, risk assessments, lifecycle gate evidence, oversight records and testing | Treat as readiness work until effective; re-check authoritative MAS publication, final text and applicability before asserting timing or obligations. |
+| 14 | HKMA FEAT / AI governance publications | Responsible analytics, model governance, fairness, accountability and transparency relevant to the institution and use case | CD-01, 02, 06, 07 | Model approvals, fairness tests, explanation/complaint pathways, accountability and audit records | Use the current HKMA instrument and scope; do not assume Singapore MAS wording is identical. |
+| 15 | FCA Senior Managers and Certification Regime (SMCR), UK | Individual accountability, responsibilities, governance, fitness/propriety and relevant certification/ conduct duties | CD-01, 06, 07, 09 | Responsibility maps, decision records, delegation limits, training/competence and escalation evidence | Map the actual regulated firm, role and duty. Avoid implying a dashboard substitutes for accountable human decisions. |
+| 16 | FCA Consumer Duty, UK | Consumer outcomes, products/services, price/value, consumer understanding and consumer support, where applicable | CD-02, 05, 06, 07, 09 | Outcome metrics, customer research, communications tests, vulnerability/complaint analysis and remediation | The four outcome areas are not a single compliance percentage. Link evidence to target market and actual customer journey. |
+| 17 | HKMA Fintech 2030 AI² (fictionalized label in the GIEN project) | Strategic AI adoption, innovation, governance and financial-sector readiness mapping | CD-01, 02, 06, 10 | Current HKMA source version, initiative-to-control map, approved pilots, governance gates and risk register | Verify exact official programme naming and current publication. Do not infer requirements from a shorthand or fictionalized label. |
+| 18 | SEC Rule 17a-4, United States | Electronic records retention and permitted preservation/recordkeeping methods for covered broker-dealer records | CD-03, 06, 09 | Retention schedule, WORM configuration or qualifying audit-trail design, access/deletion tests, restore reports and record inventory | Scope is record/entity specific. WORM is one permitted option, not a universal sole method; obtain securities counsel review. |
+| 19 | NIST FIPS 203 / 204 / 205 | PQC KEM/signature standards and controlled algorithm transitions | CD-03, 04 | Algorithm inventory, implementation/version, key lifecycle, interoperability tests, signed verification and migration plan | ML-KEM is KEM, ML-DSA and SLH-DSA are signature standards. Do not conflate predecessor names with distinct approved algorithms. |
+| 20 | OPA/Rego and OSCAL | Policy-as-code tests and structured security/control assessment records | CD-01 through CD-10 | Versioned control/profile, component definitions, SSP where applicable, assessment plan/results, POA&M, policy tests and validation logs | Engineering formats are not regulators and do not certify compliance. Keep schema validity separate from effectiveness and legal conclusion. |
+| 21 | ICGC/GASO Accords — fictional | Hypothetical multi-jurisdiction governance commitments and reciprocal audit | CD-01, 06, 10 | Fictional treaty version, signatory manifest, internal assessments, exception ledger and ratification records | Clearly label all names, legal effects and status as fictional GIEN constructs. |
+| 22 | CFE-1.0 Constitutional Framework — fictional | Constitutional invariants, quorum, non-dissolution safeguards and phase-transition authorization | CD-01, 07, 10 | Formal specification, model checking, approval quorum and invariant exception log | Internal specification only; not public law or external regulator approval. |
+| 23 | Protocol SGR-028 — fictional | Submission assembly, evidence sealing, transmission receipts and supervisory-cycle lifecycle | CD-03, 05, 06, 08, 09 | Package manifest, root/signature, verification, receipt and retention records | Filing IDs do not signify a real regulator filing unless a real recipient confirms receipt. |
+| 24 | Interstellar AI Governance Accord — fictional | Beacon/corpus custody, successor handoff and continuity of fictional governance | CD-03, 06, 10 | Corpus manifest, independent channel tests, recovery drills and custodianship decision | Speculative and fictional; label as such in all regulator-facing material. |
+| 25 | Galactic Treaty Framework — fictional | Long-horizon phase and dissolution constraints | CD-01, 06, 10 | Phase prerequisites, treaty-version history, succession gate and archive proof | Speculative and fictional; no terrestrial statutory authority is implied. |
+
+## 3. Priority and version-control policy
+
+### Priority tiering
+- **Tier 1 — current obligations:** actual legal duties for the institution, legal entity, product, data, model and jurisdiction. Examples may include applicable EU AI Act, GDPR, DORA, NIS2, US banking guidance, consumer-credit rules, prudential standards and recordkeeping requirements.
+- **Tier 2 — supervisory expectations and adopted standards:** NIST AI RMF, ISO/IEC 42001, MAS/HKMA and FCA guidance, internal model-risk policy, contract obligations and required industry practices.
+- **Tier 3 — fictional/internal:** GIEN CFE-1.0, SGR-028, ICGC/GASO and speculative treaty constructs. These can enrich internal governance but must not be represented as law.
+
+Priority must be decided by compliance/legal teams using materiality and deadlines, not fixed globally for every institution. Keep distinct: binding legal duty, supervisory guidance, standard, contractual obligation, internal policy and simulated treaty.
+
+### Change monitoring
+ For every requirement store source URL, exact citation/version, publication date, effective date, last checked date, superseded-by reference, jurisdiction, scope and owner. A source change triggers impact analysis of controls, tests, training, documentation, model approvals, records retention and submission templates. Preserve the old mapping
+version for historical reporting
+rather than overwriting it.
+
+## 4. OSCAL 1.1.2 implementation pattern
+
+OSCAL artefacts should be selected according to the assessment workflow. A typical package can include:
+- Catalog/profile or profile resolution output to establish the defined control set.
+- Component definitions to describe relevant implemented components and control implementations.
+- System Security Plan (SSP) where required by the target workflow.
+- Assessment Plan to define objectives, methods, scope and test schedule.
+- Assessment Results to record observations, results, findings and evidence references.
+- Plan of Action and Milestones (POA&M) to track remediation where applicable.
+- Schema/profile validation logs, package index and signed manifest.
+
+Exact OSCAL models and required fields depend on chosen version and authoring workflow. Pin schema and profile versions; validate input and output; do not use hand-authored JSON as proof of OSCAL conformance without running a validator.
+
+### Control mapping data contract
+Every mapping record should include:
+
+~~~json
+{
+ "mapping_id": "MAP-CD04-TEE-001",
+ "framework": "Illustrative framework name and version",
+ "jurisdiction": "jurisdiction or internal",
+ "source_reference": "official provision / control reference",
+ "applicability": "PENDING_ASSESSMENT",
+ "gien_domain": "CD-04",
+ "internal_control_id": "GIEN-CD04-CTRL-001",
+ "oscal_version": "1.1.2",
+ "oscal_control_id": "approved control ID",
+ "assessment_method": "EXAMINE_AND_TEST",
+ "policy_revision": "sha256 digest / version reference",
+ "evidence_reference": "artefact URI plus digest",
+ "assessment_result": "PENDING_ASSESSMENT",
+ "finding_id": null,
+ "owner": "role or accountable team",
+ "last_reviewed_at": "2026-10-12T00:00:00Z",
+ "independent_assurance": "NOT_PERFORMED"
+}
+~~~
+
+Values above are structure examples only. The mapping ID, control ID and timestamp are demonstration placeholders and must be replaced with authoritative values from the consuming system.
+
+### Sample Rego policy pattern
+~~~rego
+package gien.control_evidence
+
+default allow := false
+
+allow if {
+ input.evidence.present == true
+ input.evidence.provenance == "verified"
+ input.evidence.fresh == true
+ input.assessment.status == "pass"
+ input.policy.version == input.expected_policy_version
+}
+
+deny_reason := "missing, stale, unverified, or failed evidence" if {
+ not allow
+}
+~~~
+
+This is a teaching snippet, not a production policy. Add strict input schemas, typing, error handling, policy tests for missing/stale/tampered values, peer review, signed policy releases and rollback. The output should record rule version, test suite version and input digest.
+
+## 5. Evidence requirements by control family
+
+| Control family | Minimum evidence | Common false assurance to avoid |
+|---|---|---|
+| Identity and zero trust | Identity policy, access logs, least-privilege review, failed-auth tests, short-lived token evidence | A policy document alone proves enforcement |
+| AI/model risk | Inventory, intended use, evaluation dataset lineage, validation, limitations, approvals, drift and rollback tests | Passing benchmark guarantees acceptable deployment |
+| Fairness and consumer outcomes | Defined population, metric, sampling, confidence/uncertainty, relevant legal analysis, complaint/appeal pathway | Demographic parity alone establishes legal fairness |
+| TEE and confidential compute | Fresh quote, verifier/trust chain, revocation check, workload measurement and policy decision | TEE label proves the whole application is safe |
+| PQC / WORM / Merkle | Algorithm/key IDs, manifest/root, signature verification, retention and independent restore tests | Hash/root proves source truth or compliance |
+| zkML | Circuit/model digest, public input provenance, proof verification, circuit audit and negative tests | Proof generation success proves real-world input correctness |
+| Incident response | Timeline, severity, scope, containment, notification decision, remediation and retest | Closing a ticket equals reducing systemic risk |
+| Digital twin | Input/config digest, pinned simulator, rerun, validation, sensitivity, limits and reviewer | Deterministic replay proves scenario validity |
+| Compliance assessment | Applicability, version, control test, artefact digest, finding and remediation | Control crosswalk equals compliance certification |
+| Long-horizon governance | Authority, succession, independent replicas, format portability, restore and quorum proof | A sealed codex proves lawful successor activation |
+
+## 6. Reporting outputs and supervisor review checklist
+
+Each daily submission should answer:
+1. What changed during the evaluation window, and which evidence sources support the statement?
+2. Which metrics crossed approved thresholds, which sources were stale, and what uncertainties exist?
+3. What changed in models, dependencies, policies, keys, firmware, control mappings or legal obligations?
+4. Which controls failed, were not tested, are not applicable, or are only simulated?
+5. Were interventions/kill-switches exercised; what exactly was observed; what negative tests failed?
+6. Did cryptographic verification and storage-retention tests pass with independent evidence?
+7. Which framework obligations remain unmapped or have overdue remediation?
+8. What decisions require executive, risk, legal, privacy, model-risk or supervisory approval?
+9. What was transmitted, to whom, under what identity, and which authenticated receipt confirms delivery?
+10. What remains explicitly unknown and which owner/date is assigned to resolve it?
+
+### Executive disposition states
+- **No decision:** evidence is inadequate or review incomplete.
+- **Continue with conditions:** explicitly enumerated temporary controls, owners and due dates.
+- **Restrict / suspend:** control failures require limiting scope or operations.
+- **Escalate / notify:** according to applicable legal/regulatory requirements and counsel.
+- **Close finding:** only after remediation and retest evidence, with independent challenge where required.
+
+No disposition should be inferred from a fictional GIEN aggregate score alone.
+
+## 7. Official source index
+
+Use primary sources and re-confirm the current text at time of filing:
+- EU AI Act implementation and timeline:
+- EU AI Act, Regulation (EU) 2024/1689:
+- NIST AI RMF:
+- NIST AI 600-1:
+- NIST OSCAL:
+- ISO/IEC 42001:
+- Federal Reserve SR 26-2:
+- DORA:
+- NIS2:
+- GDPR:
+- NIST FIPS 203:
+- NIST FIPS 204:
+- NIST FIPS 205:
+- SEC electronic recordkeeping rule resources:
+
+**Disclaimer:** The crosswalk is a starting point for professional applicability review. It is not legal advice, certification, proof of implementation, regulatory approval, or independent assurance.
diff --git a/gien-platform/docs/supervisory-briefing-platform-reference-architecture-2026-2100.md b/gien-platform/docs/supervisory-briefing-platform-reference-architecture-2026-2100.md
new file mode 100644
index 00000000..4bf5f952
--- /dev/null
+++ b/gien-platform/docs/supervisory-briefing-platform-reference-architecture-2026-2100.md
@@ -0,0 +1,645 @@
+# GIEN Supervisory Briefing System — Reference Architecture and Implementation Specification
+
+> **Classification:** Fictional reference architecture; evidence-qualified design specification
+> **Report cut-off:** 12 October 2026, 09:00 UTC
+> **Evaluation window:** 11 October 2026, 09:00 UTC – 12 October 2026, 09:00 UTC
+> **State:** EVIDENCE-PENDING; no live GIEN telemetry is implied
+> **Phase XV:** PAUSED — fabrication prohibition remains in force
+
+## GIEN Daily Supervisory Briefing System, 2026–2100+
+
+##
+
+ This specification defines a regulator-ready daily DevSecOps, AI governance, and systemic-risk supervisory briefing system for the fictional GIEN planetary governance mesh and the Omni-Sentinel enterprise AI governance stack. It covers Sentinel AI Governance Stack v2.4, Omni-Sentinel Governance Mesh v4.0, Unified Supervisory Control Plane v3.0,
+the Omni-Sentinel Cognitive
+Execution Environment, and a proposed Integrated AGI Supervisory Operating System (IASOS).
+
+ The system combines risk telemetry, ten governance control domains, zero-trust runtime attestation, AI lifecycle and high-assurance RAG controls, zkML proof governance, post-quantum evidence integrity, OSCAL/OPA compliance-as-code, deterministic stress-test bundles, jurisdiction-aware crosswalks, responsible workflow recommendations, accessible
+supervisory interfaces, release
+gates, and long-horizon constitutional continuity.
+
+ System-specific figures and status claims must be backed by authoritative source records. No synthetic telemetry, state root, Merkle root, signature, attestation, proof, replay result, Guardian countersignature, regulatory determination, or independent assurance claim may be presented as real. The requested 1 October 2026 Guardian milestone is a
+past-due evidence check, not
+evidence of success. Phase XV is explicitly paused and must not be advanced by this design document.
+
+
+
+## 1. Executive supervisory purpose
+
+The briefing system has four jobs:
+
+1. Collect and validate authoritative evidence for a frozen 24-hour evaluation window.
+2. Explain system risk, control effectiveness, exceptions, uncertainty, and remediation ownership in a way suited to each authorized audience.
+3. Produce reproducible machine-readable and human-readable artifacts with traceable provenance.
+4. Prevent release, filing, or assurance language from outrunning the evidence.
+
+ The design target includes global systemically important financial institutions (G-SIFIs), large financial institutions (LFIs), clearinghouses, major financial entities, supervisory colleges, treaty secretariats, enterprise AI owners, internal audit, external assessors, and regulators. The application is a supervisory evidence interface, not a
+substitute for the institution's
+system of record, regulator, legal counsel, model validation function, or independent assessor.
+
+### 1.1 Status vocabulary
+
+Use controlled states with explicit definitions:
+
+| State | Required meaning |
+|---|---|
+| NOT_PROVIDED | The expected source artifact was not supplied |
+| NOT_VERIFIED | An artifact exists but validation is incomplete or inconclusive |
+| PASS | The specified test ran on identified inputs and satisfied its acceptance criteria |
+| FAIL | The specified test ran and did not satisfy its acceptance criteria |
+| STALE | Evidence exceeds its approved freshness bound |
+| EXCEPTION | An authorized, time-bounded exception exists with owner and compensating controls |
+| NOT_APPLICABLE | Applicability is explicitly assessed and a rationale is retained |
+| APPROVED_WITH_RESIDUAL_RISK | An authorized risk owner accepted the documented residual risk |
+| SIMULATED | Demonstration fixture only; never eligible for canonical supervisory evidence |
+| PAUSED | Further cadence or execution is prohibited pending an explicit admission decision |
+
+A green dashboard label must never mean “verified” unless a defined test produced a retained result. Missing telemetry is not a zero value. A passed schema validator is not proof of control effectiveness. A digital signature is not a legal compliance determination.
+
+### 1.2 Current reporting posture
+
+ For the reporting window specified above, no live GIEN metric snapshot, attestation set, proof-pipeline log, signed evidence manifest, or digital-twin replay bundle is available in the evidence supplied for this document. Consequently, S_sys, G-SRI, C-SRI, p(doom)_kernel, attestation coherence, proof latency, fairness outcomes, ledger continuity,
+and drill results are
+NOT_VERIFIED. Weekly trends and forecast trajectories are NOT_COMPUTABLE until comparable authentic time series exist.
+
+The project’s Guardian Attestation dated 1 October 2026 must be validated against its original artifact, signatures, epoch, and archive receipt. Do not backdate a successful confirmation.
+
+## 2. Reference architecture
+
+### 2.1 Logical planes
+
+| Plane | Primary responsibilities | Trust boundary |
+|---|---|---|
+| Evidence collection | Adapters for monitoring, attestations, AI gateways, CI/CD, incident systems, storage and model registries | Source authentication, data provenance and freshness |
+| AI execution | Model routing, high-assurance RAG, tool execution, workflow orchestration, safety guardrails | Workload identity, policy-mediated tool access, tenant separation |
+| Governance control | Invariant evaluation, release admission, role authorization, risk acceptance, kill/containment requests | Independent authority, dual control and least privilege |
+| Compliance and assessment | OSCAL object lifecycle, applicability mappings, OPA/Rego checks, findings and POA&M | Version-pinned schemas and policy bundles |
+| Cryptographic evidence | Canonical artifact manifests, content digests, signatures, Merkle commitments, retention metadata | Key custody, signer authorization, independent verification |
+| Supervisory digital twin | Scenario registry, test configuration, replay orchestration, expected/actual comparisons | Isolated replay environment, immutable input snapshots |
+| Reporting and distribution | Audience-specific summaries, export bundles, supervisory receipt handling, archive closure | Recipient authorization, disclosure controls and receipt confirmation |
+| Long-horizon continuity | Epoch records, succession, inherited evidence verification, revocation and dissolution rehearsals | Explicit authority transfer and non-repudiable lineage |
+
+### 2.2 Stack responsibilities
+
+- **Sentinel AI Governance Stack v2.4:** AI/model inventory, data lineage, safety evaluation, drift monitoring, model release admission, runtime policy enforcement, incident linkage and controlled containment requests.
+- **Omni-Sentinel Governance Mesh v4.0:** authenticated node membership, cross-region policy distribution, trust-domain state reconciliation, signed event exchange, containment-ring configuration and node health.
+- **Unified Supervisory Control Plane v3.0:** time-window orchestration, evidence reconciliation, control assessment, SLA exceptions, report generation, package assembly, transmission metadata and archive sealing.
+- **Omni-Sentinel Cognitive Execution Environment:** constrained agent and tool runtime, workload isolation, authorization checks, resource ceilings, checkpoints, audit hooks, safe interruption and restart policy.
+- **IASOS (proposed):** an enterprise supervisory operating layer that coordinates AI inventory, assurance claims, civilizational-readiness indicators, material-change tracking, independent review and regulatory exports. IASOS is a project proposal, not an established regulatory standard.
+- **Evidence Chain Protocol:** stable references and cryptographic verification over genuine collected artifacts. It must not manufacture missing links.
+
+### 2.3 Deployment topology
+
+ Use separate development, evaluation, staging, production, and isolated digital-twin environments. Production evidence collection should use read-only service identities wherever possible. Administrative and signing privileges should be separated from the dashboard application. The frontend should never contain private signing keys, unrestricted
+model-provider credentials, root
+database credentials, or direct authority to close risk exceptions.
+
+Multi-region services should document the failure domain, replication mode, trust anchors, network boundary, recovery objective, data residency constraint, key custody domain, and loss-of-connectivity behavior. Cross-region consensus or quorum should be defined explicitly; “mesh coherence” is not a substitute for a protocol definition.
+
+## 3. Daily supervisory cadence and required outputs
+
+### 3.1 Window definition
+
+The daily report covers the prior 24-hour window ending at 09:00 UTC. The cut-off is a reporting boundary. It does not prove the collection pipeline ran on time.
+
+Recommended operating sequence:
+
+1. **Collection:** gather source snapshots, inventory changes, CI/CD artifacts, security findings, model gateway events, attestation records, proof telemetry, compliance results and prior checkpoints.
+2. **Admission:** authenticate each source, check freshness, source schema, clock health, sequence continuity and authorization.
+3. **Validation:** run schema, signature, Merkle, policy, TLA+ artifact-reference, and replay-manifest checks where applicable.
+4. **Reconciliation:** compare expected sources and artifacts against received items; create explicit exceptions for gaps.
+5. **Assessment:** calculate approved risk metrics and control statuses using versioned logic.
+6. **Review:** route material findings to the risk owner, governance engineer and independent reviewer as required.
+7. **Report freeze:** record the window, calculation/policy versions, data manifest and unresolved exception set.
+8. **Distribution:** publish role-appropriate summaries through authorized channels and retain receipts.
+9. **Archive closure:** seal a package only after its validation steps complete; do not silently revise the frozen report.
+10. **Correction:** publish a versioned addendum referencing the original package if a material correction is necessary.
+
+If the institution retains the project’s 08:00 UTC archive transmission and 23:59 UTC daily archive closure, keep them distinct from the 09:00 UTC evaluation cutoff. The 08:00 transmission cannot include events that have not occurred by then, and the 23:59 closure must not overwrite the 09:00 snapshot.
+
+### 3.2 Daily artifact set
+
+Minimum package contents:
+
+- report manifest and evaluation-window metadata;
+- source inventory and collection receipt log;
+- metric snapshot with definitions, uncertainty, source references and freshness;
+- GIEN CD-01 through CD-10 assessment matrix;
+- AI model inventory and material-change register;
+- attestation report with eligible-node denominator and exception breakdown;
+- proof pipeline telemetry and verification summaries;
+- cryptographic manifest, signature verification results and ledger continuity check;
+- OSCAL SSP, assessment plan/results references, OPA/Rego policy result, and POA&M;
+- Supervisory Digital Twin replay bundles and outcomes;
+- vulnerability, incident and remediation records;
+- jurisdiction-specific applicability crosswalk;
+- risk decisions, approval records and escalations;
+- distribution receipts, archive status and correction history.
+
+## 4. Systemic-risk indices and telemetry model
+
+### 4.1 Definitions before thresholds
+
+No index should be used for release or supervisory escalation until its definition is documented, versioned, and approved. At minimum, define scale, unit, input population, aggregation method, missing-data behavior, confidence/uncertainty, update interval, owner, threshold source, sensitivity, known blind spots and retrospective-validation record.
+
+| Indicator | Required interpretation contract |
+|---|---|
+| S_sys | Composite system-risk index with component contributions and data-quality state |
+| G-SRI | Global systemic-risk index; define dependencies and propagation pathways |
+| C-SRI | Explicitly define the intended coherence/risk concept and measured scope; do not imply a physical or universal constant |
+| CGR-I / CCR-I | Versioned governance-resilience and cross-domain-coherence metrics |
+| G-SRI-VII | Phase VII variant, with a Phase VII-specific inventory and calculation version |
+| A-SRI / P-SRI | Autonomous-system and planetary-scope indicators, clearly identified as project-defined |
+| p(doom) / p(doom)_kernel | Hypothesis/model, horizon, calibration domain, uncertainty and interpretation limits |
+| Δ_prop | Propagation delta over a specified network, time horizon and baseline |
+| Δ_drift | Versioned change metric relative to the accepted model, policy or distribution baseline |
+| Δ_OSCAL | Change in coverage, finding state, policy digest or evidence mapping; avoid unexplained scalar use |
+| Attestation density | Fresh-valid attestations divided by eligible registered nodes, with criticality and regional breakdown |
+| Proof latency/liveness | p50/p95/p99, queue, throughput, timeout and verifier-rejection rates per proof class |
+| Fairness metrics | Defined population, outcome, group, sampling uncertainty, time horizon and applicable legal context |
+
+Do not present p(doom)_kernel as an objective probability of existential catastrophe without a validated probabilistic model and documented calibration domain. For planning, use bounded scenarios and model uncertainty rather than implying precise prediction. A composite score must not hide a catastrophic single-domain failure or stale data.
+
+### 4.2 Risk trend and forecast calculations
+
+A trend is reportable only when metric definitions and source populations remain comparable across periods. Record model/config changes and discontinuities in the series. Where the methodology changed, show a break or recompute historical values using a controlled migration plan.
+
+A 72-hour propagation projection must state its assumptions, observed history, model version, uncertainty interval, calibration/validation and limits. A 30-day continuity claim requires a complete authentic chain of the required daily snapshots and reconciliation records. Do not interpolate fabricated data into a missing day.
+
+### 4.3 Threshold governance
+
+ Thresholds belong in a signed, versioned configuration, not hard-coded UI constants. For each threshold record the approving authority, source, effective date, change reason, review interval, scope, severity mapping and rollback version. If a threshold has not been approved or the source evidence is missing, show “threshold not configured” or “not
+assessable.”
+
+## 5. GIEN Control Domains 01–10
+
+| Domain | Objective | Evidence contract |
+|---|---|---|
+| CD-01 Constitutional invariant enforcement | Enforce CFE-1.0 / SGR-028 invariants | Versioned TLA+ specs, model-checker output, assumptions, refinement evidence and exceptions |
+| CD-02 Identity and zero trust | Authenticate each user/workload and enforce least privilege | Identity inventory, policy-decision traces, role reviews and authorization tests |
+| CD-03 Hardware trust and supply chain | Verify runtime measurement and artifact provenance | Fresh TEE/TPM/vTPM quotes, PCR/event logs, SBOM, build provenance and verifier output |
+| CD-04 AI lifecycle and routing | Control model changes, MoE routing and release safety | Model/dataset lineage, evaluations, routing distributions, approval and rollback test |
+| CD-05 Data governance and human impact | Protect data rights, privacy, fairness and contestability | Data inventory, lawful basis, DPIA when required, fairness and outcome assessment |
+| CD-06 Safety and containment | Bound agent actions, incident effects and recovery | Tool allowlists, kill/containment test, incident timeline and recovery evidence |
+| CD-07 Cryptographic evidence integrity | Verify PQC signatures, Merkle continuity and retention | Signed manifest, root/inclusion verification, key inventory and restore test |
+| CD-08 Compliance-as-code | Map obligations to controls and tests | OSCAL structures, policy digest, test outputs, findings and POA&M |
+| CD-09 Supervisory Digital Twin | Test material scenarios with reproducible inputs | Replay bundle, expected conditions, actual output, reproducibility result and deviations |
+| CD-10 Long-horizon and treaty continuity | Preserve authorized governance and evidence across epochs | Charter/version lineage, succession tests, revocation, archive and dissolution records |
+
+Each domain should publish assessed status, source evidence, last-success timestamp, maximum allowed age, outstanding issues, compensating controls and accountable owner. “Compliant” should never be an aggregate label unless the actual claim boundary and independent assessment basis are stated.
+
+## 6. Hardware and RTEE attestation design
+
+A verified attestation record should bind a fresh challenge to a node/workload identity and retain quote signature checks, certificate or endorsement chain, reference measurement profile, PCR values/event log, verifier version, freshness, revocation status, evaluation time and signed decision.
+
+PCR_MATCH=TRUE may be displayed only when a trusted verifier has run against the approved profile and retained its output. A copied field, screenshot, old quote or self-asserted status does not qualify.
+
+ For each region, report the registered eligible-node denominator, reporting nodes, fresh passing attestations, failed/stale/unavailable attestations, approved exceptions, critical services affected and evidence freshness distribution. If the project’s planning assumption is 72 RTEE nodes, use 72 only after the active inventory is confirmed for the
+reporting window.
+
+ Reject stale or inconsistent evidence according to policy. For a material trust failure, contain the affected workload, preserve the event trail, identify dependent decisions, test recovery, refresh attestation after remediation, and require controlled re-admission. Aggregate attestation density alone is inadequate because a single
+high-criticality node can be compromised while
+overall coverage remains high.
+
+ Kubernetes/GitOps checks should include signed manifests and container provenance, immutable image digests, admission-control tests, RBAC, workload identity, secrets boundaries, network policy, IaC plan review, drift detection, rollback behavior and independent deployment verification. For gVisor or another sandbox, measure isolation properties,
+resource limits, syscall
+compatibility, escape-test coverage and recovery. Do not invent latency or performance figures.
+
+## 7. AI safety lifecycle and high-assurance RAG
+
+### 7.1 RAG control chain
+
+1. **Ingestion:** authenticate sources; record source owner, URI, version, retrieval time, sensitivity, permissions, transformations and content digest.
+2. **Indexing:** pin embedding/model and chunking versions; record index lineage; enforce tenant isolation and deletion propagation.
+3. **Retrieval:** check authorization before content enters context; maintain source trust/freshness signals and provenance.
+4. **Context construction:** distinguish policy instructions from retrieved content; treat documents as untrusted data; detect prompt injection and instruction conflicts.
+5. **Generation:** require grounded responses, claim-to-source evidence, structured output validation and abstention when evidence is inadequate.
+6. **Tool execution:** use a server-side authorization gateway, allowlisted capabilities, bounded inputs, quotas, timeouts and approval for consequential actions.
+7. **Post-generation verification:** validate citations, policy boundaries, leakage, harmful side effects, refusal behavior and answer completeness.
+8. **Monitoring:** track drift, retrieval errors, ungrounded claims, data leakage, prompt injection, policy overrides and user-reported harm.
+9. **Learning loop:** review feedback, preserve provenance, de-identify where appropriate, test bias/selection effects, and require approval before datasets, prompts or models are promoted.
+
+Required evaluations include recall and precision at k, citation correctness, claim support, hallucination/unsupported-claim rate, freshness, tenant isolation, access denial correctness, retrieval poisoning resistance, prompt-injection resistance, privacy leakage, refusal accuracy and task performance.
+
+### 7.2 AGI/ASI and advanced-agent safety
+
+ Do not claim a universal containment proof. Use layered controls and staged deployment gates: capability evaluation, bounded action space, least privilege, tool mediation, independent monitoring, rate/resource limits, circuit breakers, human approval for consequential actions, rollback, and rehearsed incident response. Test unauthorized tool
+access, prompt injection, untrusted
+memory, conflicting instructions, reward hacking, data exfiltration, cross-agent coordination failures, sandbox boundary assumptions and safe interruption.
+
+ For potentially transformative systems, use conservative release criteria. Maintain a hazard inventory, scenario analysis, evidence of evaluation coverage, residual risk statement, accountable release decision and independent review. The proposed AGI Assurance Profile AAP-1 and CR-5 civilizational-readiness criteria should be clearly marked as
+fictional/internal proposals until
+specified and validated. They are not existing laws or accepted global standards.
+
+### 7.3 Human oversight and responsible deployment
+
+ For consequential workflows, document the responsible decision-maker, ability to contest, escalation route, override authority, explanation scope, review time, and how adverse outcomes are corrected. A human-in-the-loop label is insufficient if the human lacks time, information or authority to intervene. Track override quality, workload, decision
+delay, error detection and
+downstream customer outcomes.
+
+## 8. IASOS and supervisory API object model
+
+The proposed IASOS can expose versioned, authenticated API objects for:
+
+- AI system and model inventory;
+- dataset and retrieval source provenance;
+- evaluation suite, result and limitation;
+- risk indicator and threshold configuration;
+- material change request, approval and release record;
+- attestation statement and verification result;
+- proof job and verification outcome;
+- control implementation, assessment and POA&M;
+- digital-twin scenario, replay run and deviation;
+- incident, containment action and recovery;
+- supervisory filing, manifest, transmission receipt and archive status;
+- assurance claim and evidence references.
+
+ Every object should have a stable ID, schema version, owner, creation/update times, authorization boundary, provenance references and controlled lifecycle status. Mutations require authenticated identity, least-privilege authorization, audit recording and optimistic concurrency or equivalent protection against lost updates. APIs should use
+pagination, idempotency keys for
+retried writes, bounded request sizes, typed validation errors and documented retention rules.
+
+The assurance-claim object must list claim wording, intended scope, evidence references, method, date, reviewer, limitations, and invalidation conditions. A claim should become stale if its model, policy, deployment boundary or evidence source materially changes.
+
+## 9. Zero-knowledge proof and cryptographic pipeline
+
+### 9.1 Proof pipeline health
+
+Measure submission count, queue depth, proof generation latency, verification latency, p50/p95/p99, throughput, proof size, timeouts, rejected proofs, invalid witnesses, version mismatches, resource consumption, liveness, and backpressure. Break down by model, circuit, version, workload, trust boundary and proof class.
+
+Every proof artifact should specify:
+- the exact statement/relations and what the proof does not establish;
+- model/circuit/input commitments;
+- proving/verifying implementation version and build provenance;
+- proof-system parameters and key references where applicable;
+- job identity, time, result and verifier logs;
+- independent reproduction instructions and known limitations.
+
+A proof establishes only the defined formal relation under stated assumptions. It does not independently establish semantic truth, model fairness, robustness, legality or overall safety.
+
+### 9.2 SNARK/STARK changes
+
+ Migration from a SNARK pipeline to a STARK pipeline is a material change. Verify equivalence of the intended statement, assumptions, verifier, error handling, operational profile, resource requirements and audit reference. Run a comparison corpus and rollback rehearsal; preserve both pipeline versions and clearly label migration state. Aggregation
+(including SnarkPack where
+used) should preserve linkage to each constituent proof, rejection outcome and input manifest.
+
+### 9.3 Fairness evidence
+
+ A Disparate Impact Ratio (for example, an internal screening threshold of DI ≥ 0.800) must be scoped to a specified population, outcome, comparison group, time period and sample. It is not a universal fairness theorem or a legal safe harbor. Report confidence intervals and limitations, test other relevant fairness and performance measures, review
+data quality, and obtain
+jurisdiction-specific fair lending/legal assessment where FCRA/ECOA apply. A ZK proof can show that a calculation was executed over committed inputs; it cannot prove that the inputs, group definitions or choice of fairness criterion were appropriate.
+
+## 10. Post-quantum cryptography, WORM and Merkle-DAG
+
+### 10.1 Algorithm distinctions
+
+- **NIST FIPS 203 / ML-KEM:** key encapsulation. It is not a signing algorithm.
+- **NIST FIPS 204 / ML-DSA:** digital signatures. ML-DSA-65 and ML-DSA-87 are parameter sets in this standardized family; the family derives from CRYSTALS-Dilithium.
+- **NIST FIPS 205 / SLH-DSA:** stateless hash-based signatures based on SPHINCS+.
+- **Falcon-1024:** do not describe Falcon as standardized by FIPS 203, 204 or 205. Treat any inclusion as a separate cryptographic profile decision with risk, procurement and interoperability review.
+
+Pin the exact algorithm, parameter set, implementation and build digest, security purpose, key owner, custody boundary, validity interval, rotation/retirement state, revocation method and verification evidence. Use the current NIST publication and errata when approving a cryptographic profile.
+
+### 10.2 Ledger integrity
+
+For each artifact:
+1. Canonicalize under a versioned serialization rule.
+2. Compute its content digest and link its evidence metadata.
+3. Sign the manifest with an authorized, valid key.
+4. Commit the artifact set to a Merkle tree/DAG checkpoint.
+5. Store the payload and manifest under the required retention policy.
+6. Verify content digests, signature chain, root continuity and inclusion proofs independently.
+7. Reconcile expected and present event counts and report gaps, duplicates or ordering failures.
+8. Demonstrate recovery and verification from a separately controlled copy.
+
+ A Merkle root proves integrity of a committed set relative to its leaves, not that all required events were collected. Pair it with independent ingestion receipts, sequence/reconciliation checks, restricted retention administration and evidence of recovery. A WORM label or storage screenshot is not sufficient proof that the entire recordkeeping
+control is effective.
+
+Key rotation requires a controlled overlap period, staged verification, explicit trust-anchor update, rollback and revocation procedure, historical evidence validation, and a signed migration record. The vkFMv2 → vkFMv3 transition must not be marked complete until real verifier configuration, key inventory and post-rotation tests are available.
+
+## 11. OSCAL 1.1.2, OPA/Rego and compliance-as-code
+
+ OSCAL 1.1.2 may remain a compatibility baseline for a specific filing. NIST lists OSCAL 1.2.3 as released on 6 August 2026, so the project should version-pin existing packages and plan a schema/tooling migration assessment rather than call 1.1.2 the latest release. Sources: and
+
+
+### 11.1 Processing stages
+
+1. Validate JSON syntax, schema, OSCAL model constraints and the pinned version.
+2. Check identifiers, references, required fields, relationship integrity and allowed state transitions.
+3. Link each applicable requirement to an implementation statement, test, evidence object, owner and finding.
+4. Run OPA/Rego against a signed/versioned policy bundle and input snapshot.
+5. Generate Assessment Results with methods, observations, evidence, result and assessor identity.
+6. Add unresolved issues to the POA&M with severity, owner, due date, compensating controls, closure criterion and verification plan.
+7. Bind outputs to source commit, policy bundle digest, toolchain, schema version and execution identity.
+8. Independently validate the final manifest before transmission.
+
+Structural validity is not substantive compliance. An OPA rule passing is evidence that its encoded predicate passed on the supplied input, not that the legal obligation has been fully met.
+
+### 11.2 Recommended OSCAL object set
+
+- System Security Plan (SSP): system boundary, components, interfaces, control implementations, inherited controls and responsible roles.
+- Assessment Plan: scope, assessment objectives, methods, sampling plan, preconditions and expected results.
+- Assessment Results: observations, findings, evidence references, assessor and timestamps.
+- POA&M: finding, owner, schedule, mitigation, residual risk and closure evidence.
+- Component Definition: reusable implementation and dependency metadata.
+- Signed wrapper manifest: references the canonical OSCAL objects and binds their versions and digests without mutating their signed bytes.
+
+## 12. Regulatory and treaty applicability matrix
+
+This matrix is a design crosswalk, not a legal opinion or compliance attestation. The legal entity, activity, region, AI role, product and applicable consolidated text must be assessed before mapping status is assigned.
+
+| Framework | Primary evidence mapping | Status caveat |
+|---|---|---|
+| EU AI Act | Role/risk classification, relevant technical documentation, provider QMS, oversight, robustness, cybersecurity and transparency | Check current amended text and transitional dates |
+| NIST AI RMF 1.0 / AI 600-1 | Govern/Map/Measure/Manage, generative-AI risk controls and evaluations | Voluntary risk-management references, not statutes |
+| NIST critical infrastructure AI RMF profile | Sector-specific trust requirements and supply-chain lifecycle | NIST described it as under development in its 2026 concept note |
+| ISO/IEC 42001:2023 | AIMS context, leadership, risk treatment, operation and continual improvement | Certification/assurance requires an appropriate scope and assessor |
+| ISO/IEC 42005:2025 | AI system impact assessment | Update throughout system lifecycle as material impacts change |
+| ISO/IEC 42006:2025 | Competence/requirements for AIMS audit and certification bodies | Applies to relevant audit/certification bodies, not as a standalone deployment control |
+| ISO/IEC TS 42119-2:2025 | Risk-based testing of AI systems | Use as testing guidance alongside system-specific acceptance criteria |
+| Basel III and jurisdictional implementation often called Basel IV | Capital, liquidity and operational risk implications where in scope | Map to binding local implementation and institution type |
+| Federal Reserve SR 26-2 | Revised model risk management guidance | Issued 17 April 2026; supersedes SR 11-7 and SR 21-8 for the covered guidance context |
+| SR 11-7 | Historical traceability and legacy policy crosswalk | Do not present as concurrent identical guidance where SR 26-2 supersedes it |
+| DORA | ICT risk, incident reporting, resilience testing and third-party ICT risk | Scope and deadlines are entity-specific |
+| NIS2 | Cybersecurity measures, management accountability and incident obligations | Apply national transposition and entity scope |
+| GDPR | Lawfulness, purpose limitation, security, rights, Article 22 where applicable and Article 35 DPIA when required | Separate GDPR Article 22 from AI Act Article 22 |
+| FCRA / ECOA | Credit and consumer-report decisions, explanations, fairness and recordkeeping | Applicable product, actor and jurisdiction determine obligations |
+| MAS FEAT | Fairness, Ethics, Accountability and Transparency in relevant Singapore financial-sector context | Keep distinct from HKMA guidance |
+| HKMA Fintech 2030 / AI² | Responsible adoption, resilience and institutional controls | HKMA programme is not the same instrument as MAS FEAT |
+| FCA SM&CR / Consumer Duty | Individual accountability, foreseeable harm and good retail outcomes within scope | Requires actual outcome and accountability evidence |
+| SEC Rule 17a-4 | Electronic broker-dealer records, permitted preservation method and retrieval | Applicable entities and recordkeeping route must be assessed |
+| ICGC/GASO / Interstellar AI Governance Accord / Galactic Treaty Framework | Project-defined treaty mapping | Treat as fictional/internal unless a canonical authoritative instrument is provided |
+
+ EU AI Act article mapping needs precision: Annex IV concerns high-risk AI technical documentation; Article 15 addresses accuracy, robustness and cybersecurity; Article 17 addresses providers’ quality-management systems; Article 35 concerns notified-body identification numbers; Article 51 concerns GPAI models with systemic risk; Article 22 concerns
+authorised representatives of
+providers of high-risk systems. Do not confuse AI Act Article 22 with GDPR Article 22 (automated individual decision-making). Verify the controlling consolidated text and AI Omnibus transition rules at filing time.
+
+### 12.1 Current standards references
+
+- NIST AI RMF page, including AI 600-1 and the 2026 critical-infrastructure profile concept note:
+- NIST AI RMF Trustworthy AI in Critical Infrastructure concept note:
+- ISO/IEC 42005:2025:
+- ISO/IEC 42006:2025:
+- ISO/IEC TS 42119-2:2025:
+- 2026 International AI Safety Report:
+- Federal Reserve SR 26-2 (17 April 2026):
+- EU AI Omnibus entry into force and timeline: and
+- NIST FIPS 203/204/205: ; ;
+
+## 13. Supervisory Digital Twin and DRILL-042–047
+
+The drill names are fictional project identifiers. Do not invent outcomes. Define each drill’s purpose, hazard model, initial state, injection sequence, expected invariants, containment criteria, recovery objective and evidence bundle.
+
+| Scenario | Intended exercise | Minimum evidence |
+|---|---|---|
+| DRILL-042 | Cross-domain cascade | Dependency graph, event timeline, propagation bound and containment decision |
+| DRILL-043 | Attestation inconsistency | Quote verifier output, affected-node inventory, quarantine and re-admission test |
+| DRILL-044 | Proof-pipeline degradation | Queue/latency/error series, backpressure, timeout and safe degradation |
+| DRILL-045 | Governance policy conflict | Policy versions, precedence resolution, decision trace and escalation |
+| DRILL-046 | Cryptographic/key continuity scenario | Rotation, revocation, verifier compatibility and archive validation |
+| DRILL-047 Black-Unicorn-7 | Composite rare-event stress case | Canonical hazard definition, all injected inputs, containment timeline, residual findings and independent replay review |
+
+ Panels 13–15 should have documented scenario boundaries (e.g., cascade contagion, autonomous-agent policy deviation and cryptographic-degradation exercise only if so approved in the canonical catalog). Every replay bundle should retain scenario version, environment version, model/policy hashes, input snapshot, event log, random seeds where used,
+expected outputs, observed
+outputs, comparison method, timestamps and manifest digest.
+
+Replay determinism is measured. If bitwise equality is not meaningful because of asynchronous or stochastic execution, define the tolerance and acceptable equivalence criterion before the test. Report failed, skipped, partial and unavailable runs distinctly. Do not convert missing evidence into a pass.
+
+## 14. BASELINE/ELEVATED compute governance
+
+Use explicit policy gates rather than informal dashboard toggles.
+
+ **BASELINE** permits approved workloads within documented quotas and ordinary authorization boundaries. **ELEVATED** is a constrained operating mode invoked only under an approved trigger, with explicit scope, authority, duration, resource ceilings and rollback criteria. ELEVATED must not disable safety policy, logging, access control, fairness
+review or cryptographic evidence
+generation.
+
+ Each transition requires the trigger observation, policy version, approver, affected workloads/regions, resource allocation, safety guardrails, time limit, notification/receipt and return-to-baseline criteria. Require automatic expiry unless a documented extension is approved. The reporting UI must state the actual configured policy; it must not
+imply that GIEN is currently in
+either mode if no telemetry exists.
+
+## 15. Application and dashboard design
+
+### 15.1 Frontend approach
+
+ The current repository prototype is React + TypeScript + Vite with React Router and Tailwind CSS. Retain that structure for the prototype. Add D3 or Recharts only where they materially improve interactive trend visualization; simple sparklines and diagrams can remain SVG components. Use jsPDF only for controlled report formatting, while ensuring
+the canonical evidence remains
+machine-readable and independently verifiable.
+
+Recommended modules:
+
+- **CivilizationalReadinessMonitor:** clearly labelled internal AAP-1/CR-5 proposal indicators, evidence freshness and open readiness gates.
+- **MaterialChangeTracker:** model/prompt/retrieval/index/tool/threshold/cryptographic changes, approvals, rollback and signed evidence references.
+- **SystemicRiskTelemetry:** index cards, uncertainty, provenance, missingness, source freshness and versioned trend panels.
+- **OPARegoSimulator:** local test evaluation on explicitly labelled inputs; not production policy enforcement or a legal compliance verdict.
+- **PromptArchitect:** constraints, assumptions, prompt history, diffing, comments, token estimates, offline/isolated test runs, parameter comparisons and exports.
+- **RAGDataAudit:** corpus/source configuration, provenance, retrieval permissions, content digests, freshness, deletion status and injection test outcomes.
+- **ComplianceMatrix:** obligation-to-control crosswalk, applicability rationale, evidence coverage, findings, stale-state alerts and POA&M links.
+- **HumanMeaningConstitution:** project-defined ethical constraints, decision ownership, contestability, exception controls and human-impact reviews.
+- **ParityDashboard:** model/capability/control coverage comparisons, explicitly scoped and uncertainty-aware.
+- **SDTStressDrills:** scenario registry, input manifest, acceptance criteria, replay history, deviations and evidence links.
+- **RegulatorExport:** OSCAL references, manifest preview, exceptions, audience redaction, validation status and receipt display.
+- **PQCWormLoggerMonitor:** authenticated logger health, retention-policy configuration, batch continuity, signature/root verification result and key-rotation evidence.
+
+### 15.2 Accessible interaction requirements
+
+ Meet WCAG 2.2 AA as a design target. Use semantic headings, keyboard navigation, visible focus, accessible names, non-color status cues, contrast, responsive layouts, screen-reader status announcements, table captions, chart text summaries and reduced-motion support. Web Speech APIs should be opt-in, announce scope and privacy implications, and
+provide an equivalent text
+interaction. Do not record or transmit speech without informed user action and an explicit application policy.
+
+### 15.3 Human-readable audience views
+
+| Audience | Primary surface | Content |
+|---|---|---|
+| Regulators and supervisory colleges | Sealed dossier and evidence manifest | Findings, applicability, controls, provenance, exceptions, evidence chain and transmission receipts |
+| Executive leadership | One-page summary and decision log | Material exposures, accountability, customer impact, risk trend, action and deadline |
+| Engineers / SRE / MLOps | Technical dashboard and APIs | Telemetry freshness, failure traces, latency, attestations, deployment and remediation |
+| Internal and external auditors | Evidence register and sample-based audit workspace | Reproducibility, scope, test methods, version history, sampling and unresolved limitations |
+| Real-time operators | Alert queue and incident console | Urgency, observations, owner, response deadline, containment steps and escalation |
+
+Never show an executive a composite score without the critical components and exceptions. Never show a regulator a green state without the underlying evidence references and the method that assigned it.
+
+## 16. PromptArchitect and workflow recommendation engine
+
+PromptArchitect should treat prompts as versioned configuration artifacts. Record purpose, owner, approved context, constraints, model/runtime version, tool permissions, test set, expected behavior, known failure cases, rollout approval and rollback target. A visual diff must make changes to policy constraints and safety text easy to inspect.
+
+ The workflow recommendation engine should score only eligible actions. The recommendation explanation should identify the factors used, uncertainty, policy constraints, possible side effects and human approval requirements. High-impact recommendations should require meaningful human review. Acceptance rate is not a quality metric by itself and
+must not be used as a
+self-reinforcing training signal without correction for selection and feedback bias.
+
+ Active learning must be gated: review and label candidate examples; check privacy and source rights; detect poisoning or distribution skew; maintain protected evaluation sets; evaluate offline and in shadow mode; promote only through an approved release record; and preserve the ability to roll back. CSV upload and batch execution need file-size
+limits, schema checks,
+injection-safe rendering, data classification and auditable deletion.
+
+## 17. OpenAI Platform integration
+
+ Provider APIs should be called from a server-side adapter, never directly from an untrusted browser with embedded secrets. Use authenticated request paths, model allowlists, structured-output validation, tool allowlists, rate limits, timeout/resource budgets, request correlation IDs and minimal retention of sensitive payloads. Model outputs must
+be treated as untrusted until
+validated for the application’s intended use.
+
+For new OpenAI Platform integrations, evaluate the currently documented Responses API and tool patterns against the requirements of the target app; pin tested model/config versions through deployment configuration, not scattered UI constants. Keep provider-specific behavior behind an adapter so changes do not entangle risk logic with UI code.
+
+ OpenAI’s official deprecation page currently lists the Evals platform as becoming read-only for existing evals on 31 October 2026, with shutdown scheduled for 30 November 2026. Plan a migration of test suites and graders to a supported dataset-based or alternate evaluation workflow before those dates. Keep evaluation definitions in version control
+and run them in the CI
+pipeline. References:
+- Responses API migration guide:
+- API deprecations:
+- Evaluations guide:
+- Dataset-based evaluation getting started:
+
+Never assume provider-side evaluation results replace application-owned regression tests, external model validation or regulatory evidence.
+
+## 18. DevSecOps and release acceptance
+
+Minimum pull-request gates:
+
+1. TypeScript typecheck and production build.
+2. Unit tests for metric logic, status state machine, freshness and exception handling.
+3. Route-level smoke tests for every application page and unauthorized state.
+4. Accessibility tests and keyboard-only workflows.
+5. API contract tests, server-side authorization checks and input validation.
+6. Dependency and secret scans, SBOM generation and artifact provenance where available.
+7. OSCAL fixture validation and OPA/Rego test suite.
+8. Cryptographic test vectors and negative tests for invalid, stale, revoked and malformed artifacts.
+9. RAG prompt-injection, data-access, citation and tool-misuse regression corpus.
+10. Digital-twin manifest and expected-output comparison tests.
+11. Release approval record, version pinning and rollback rehearsal.
+
+Do not merge or deploy while the required checks fail or the production build is not confirmed. A workflow startup failure means the test did not meaningfully execute; it is not evidence of a source-code failure or success. The current project status should be derived from actual GitHub checks at review time.
+
+## 19. Guardian Attestation and Infinity Pillar readiness
+
+ The scheduled Guardian Attestation date, 1 October 2026, has passed. The status must remain NOT_VERIFIED unless the original signed artifact set is available, including the defined attestation payload, epoch, verifier policy, registered node inventory, required signer/countersigner identities, successful signature validation, exception register,
+replay/test annexes and archive
+manifest.
+
+The project identifiers SGR-030-CFE-2026-10-01-XII, XII-DS-015+, XII-EXP-005, SCN-CMPS-02, SCN-FAL-02 and SCN-IECCI-02 are not evidence that their procedures completed. Import their state from authentic source records only. If the records are absent, retain a dated exception and a corrective action rather than fabricating confirmation.
+
+ Infinity Pillar readiness should be a gate-based assessment across invariant integrity, source evidence, key/algorithm agility, cross-mesh authority, recovery testing, succession, archival verification and open risk ownership. A declared “ready” status requires all mandatory gates and identified approvers; the label cannot be inferred from elapsed
+time or the existence of a
+filing number.
+
+## 20. Phase XV pause and fabrication prohibition
+
+Phase XV remains PAUSED. No new Phase XV Day 11+ telemetry, state roots, attestation outputs, chain extension, synthetic Merkle root, or treaty-grade confirmation may be created by this report.
+
+Permitted non-advancing work includes invariant-spine commentary, explanation of assumptions and limitations in epoch-boundary proof models, a diagram or narrative of the existing Genesis → D1–D10 → WR1 chain, a pause-state checklist, a gap register, and the required-evidence schema for a future resumption request.
+
+ Resumption requires an explicit authorized decision and actual source evidence for the next epoch/day: genuine collection timestamps, signed telemetry manifest, valid predecessor references, real verifier outputs, node/quote state, proof transcripts, replay artifacts, exceptions and independently checked chain continuity. Missing or unverifiable
+required inputs keep the phase
+paused. No fictional value may be backfilled to repair continuity.
+
+## 21. Long-horizon architecture, 2026–2100+
+
+| Phase / epoch | Objective | Admission condition |
+|---|---|---|
+| VI-δ planetary governance | Operational control evidence and daily supervisory cycle | Source data, control coverage, exceptions and reproducible tests |
+| VII civilizational mesh bootstrap | Foundational charter, authority and mesh initialization | Explicit invariant scope, bootstrap trust model and successor verification |
+| VIII–IX interplanetary/cosmic charter models | Partition tolerance, distant-region governance, horizon scanning and isolated shadow rehearsals | Versioned authority rules, bounded delegation and conflict resolution |
+| X–XI universal-timescale continuity | Epoch-bound trust, key migration, archive survivability and Infinity Pillar operations | Verified succession tests, revocation and retained evidence |
+| Proto-Phase XII–XIII multiversal coordination | Cross-mesh governance and successor acceptance | Independent lineage verification and authenticated authority transition |
+| Ω-GAR dissolution rehearsal | Lawful termination, credential revocation, archive preservation and handover | Approved exit conditions, preserved open obligations and successor accountability |
+
+These phases are conceptual; no physical planetary, galactic or multiversal authority is asserted. Cross-mesh consensus should not imply one mesh can silently override all others. Use explicitly scoped charters, independent validation, quorum and delegation rules, dispute handling and documented revocation.
+
+ The proposed GIEN-UNIFIED-CODEX-OMEGA should capture invariant and authority-transfer rules; GIEN-EPITAPH-OMEGA should preserve what was established, what failed and what remains uncertain; GIEN-INVOCATION-OMEGA should formally acknowledge a successor process without acting as hidden executable authority. Terminal memorials are archival governance
+objects, not a mechanism to
+bypass legitimate consent or transfer unbounded permissions.
+
+Project-defined deep-time indicators (e.g., CESI, UCSI, UCI, CDS, GLI and LIS) need precise semantics, observations, uncertainty models and validation before use in policy decisions. They are not recognized universal constants by virtue of their names.
+
+## 22. Weekly aggregation and monthly continuity
+
+ Weekly summaries should report metric distributions and trend changes only when the observations are genuine and comparable. Include missingness, revised definitions, model releases, incidents, open POA&M items, repeated failure modes, policy drift, attestation distribution, proof-pipeline performance, key rotation, replay outcomes and
+customer/operational impact.
+
+A monthly-grade continuity assertion requires a complete 30-day chain of original daily artifacts, successful validation receipts, stable metric definitions or documented migrations, exception resolution history and an independently reproducible continuity check. Partial cycles, substituted values and fabricated manifests do not qualify.
+
+## 23. Supervisory output formats
+
+- **Executive brief:** one page; key decisions, material exposure, trend confidence, current exceptions, owners and deadlines.
+- **Regulatory dossier:** tagged title/abstract/content wrapper, scope, applicability, evidence manifest, OSCAL objects, assessment results, findings, remediation and receipts.
+- **Engineering output:** JSON/JSONL event records, typed API responses, metric definition file, logs, replay manifests and CI status references.
+- **Audit evidence:** immutable artifact references, hashes calculated from actual bytes, signer/key records, test method, population/sample, version lineage and known limitations.
+- **Dashboard:** near-real-time freshness, source health, exception indicators, last successful validation and navigation to underlying evidence; use explicit "not verified" states instead of synthetic green status.
+- **Accessibility / board pack:** tagged/structured summary, text alternative for each chart, clear timestamp and version, plain-language explanation and action/owner register.
+
+All exports should include the report window, generation tool/version, source manifest, schema versions, policy digest, redaction policy and the exact evidence status. PDFs should be considered a presentation layer; retain canonical machine-readable data and cryptographic verification instructions.
+
+## 24. Implementation roadmap
+
+### 0–30 days: evidence contracts and CI stabilization
+- Resolve the GIEN workflow startup failure and obtain a real production build.
+- Freeze metric definitions, status enum, freshness rules and evidence object schemas.
+- Establish source adapters and read-only collection identities.
+- Add OSCAL validation fixtures, Rego tests and report snapshot tests.
+- Add a strict DEMONSTRATION DATA label to all mock values and simulated transmission/archive UI.
+- Define the 1 October Guardian evidence retrieval and exception path.
+
+### 31–90 days: trusted evidence and test automation
+- Add hardware attestation verification using a documented profile and actual verifier output.
+- Implement signed artifact manifests, Merkle verification and WORM retention validation.
+- Add replay bundle validation and failure/skip state handling.
+- Implement model and RAG evaluation suites, tool authorization and active-learning release gates.
+- Add access-control, accessibility and incident/escalation tests.
+- Build export validation and supervisory receipt tracking.
+
+### 3–12 months: institutional integration
+- Establish legal entity and jurisdiction applicability assessments.
+- Map requirements to control owners, evidence, tests and corrective actions.
+- Integrate verified telemetry, model registries, CI/CD, incident systems and selected evidence stores.
+- Add independent model validation and recurring audit sampling.
+- Migrate OSCAL versions through a tested compatibility plan.
+- Exercise backup, archive recovery, key rotation, cross-region failure and rollback.
+
+### 2026–2035: enterprise safety maturity
+- Establish lifecycle governance for foundation models, agents and RAG.
+- Use risk-tiered release gates, red-teaming, model-change controls and monitoring.
+- Introduce privacy-preserving evidence only where the statement and assumptions are explicit.
+- Define independent assurance boundaries and accountability for risk acceptance.
+- Review sectoral and standards changes on a controlled schedule.
+
+### 2035–2100+: continuity planning
+- Use epoch-bound trust, cryptographic agility and archive-survivability requirements.
+- Re-test succession, revocation and dissolution workflows at fixed intervals.
+- Preserve historical evidence and unresolved obligations without allowing past attestations to authorize future models.
+- Treat every future phase as a new admission decision; never presume automatic inheritance of compliance or safety.
+
+## 25. Required next 24-hour actions
+
+1. Obtain actual source artifacts for the reporting interval and freeze their manifest.
+2. Keep risk values and control states NOT_VERIFIED where the required evidence is absent.
+3. Retrieve the original Guardian Attestation package, or open a dated exception if unavailable.
+4. Retrieve GIEN-ZTAI-02's current finding, remediation and deployment evidence.
+5. Validate the actual signed WORM/Merkle/PQC chain and the active verifier/key inventory.
+6. Run or retrieve authentic DRILL-042–047 records; emphasize DRILL-047 Black-Unicorn-7 without inventing an outcome.
+7. Fix CI startup and lint failures; require a confirmed successful build before merge or deployment.
+8. Version-pin and validate the OSCAL schema/policy toolchain used for the filing.
+9. Review current AI evaluation and provider deprecation notices; maintain application-owned regression tests.
+10. Preserve Phase XV's PAUSED state until its actual resumption prerequisites are met.
+
+## 26. Final supervisory disposition
+
+ The appropriate status for this specification is **EVIDENCE-PENDING**. It supplies the design contracts, architecture, reporting formats and implementation gates for a fictional high-assurance governance platform; it does not assert that any live GIEN control, cryptographic pipeline, attestation mesh, stress drill or regulatory obligation has
+passed.
+
+The governing principle is simple: every supervisory claim must be linked to a genuine source, defined method, reproducible validation result and accountable owner. When evidence is absent, preserve the gap. Do not invent precision, attestations, continuity or certainty to make the report appear complete.
+
+## References
+
+1. NIST OSCAL release news (OSCAL 1.2.3, 6 August 2026):
+2. NIST AI RMF and AI 600-1 / GenAI Profile:
+3. NIST Trustworthy AI in Critical Infrastructure profile concept note (April 2026):
+4. ISO/IEC 42005:2025 AI system impact assessment:
+5. ISO/IEC 42006:2025 AIMS audit/certification bodies:
+6. ISO/IEC TS 42119-2:2025 AI testing:
+7. International AI Safety Report 2026 (published 3 February 2026):
+8. Federal Reserve SR 26-2 (17 April 2026):
+9. EU AI Omnibus entry into force:
+10. EU AI Act Article 113:
+11. NIST FIPS 203:
+12. NIST FIPS 204:
+13. NIST FIPS 205:
+14. OpenAI Responses API migration guide:
+15. OpenAI API deprecations:
+16. OpenAI evaluations guide:
+17. OpenAI dataset-based evaluation guide:
+18. Existing GIEN Governance Platform PR:
diff --git a/gien-platform/docs/technical-architecture-roadmap-2026-2035.md b/gien-platform/docs/technical-architecture-roadmap-2026-2035.md
new file mode 100644
index 00000000..db224119
--- /dev/null
+++ b/gien-platform/docs/technical-architecture-roadmap-2026-2035.md
@@ -0,0 +1,270 @@
+# Omni-Sentinel Technical Architecture and 2026–2035 Roadmap
+
+> **Classification:** Fictional reference architecture; engineering design specification
+> **Scope:** Sentinel AI Governance Stack v2.4, Omni-Sentinel Governance Mesh v4.0, SCP v3.0
+> **Deployment posture:** Design proposal; not evidence of a deployed or independently assured system.
+
+## Enterprise AI Governance and DevSecOps Architecture
+
+##
+ This specification defines an implementation-oriented architecture for AI control evidence across G-SIFIs and large financial institutions. It integrates zero-trust workload governance, confidential-computing attestation, model and Mixture-of-Experts (MoE) routing governance, OSCAL control evidence, OPA/Rego policy tests, post-quantum signed WORM
+logging, bounded zero-knowledge
+proofs, TLA+ model checking, infrastructure-as-code, and supervisory submission workflows. It explicitly separates technical control observations from legal conclusions and independent assurance.
+
+
+## 1. System boundary and trust model
+
+### Components
+- **Sentinel AI Governance Stack v2.4:** model registry, release admission, runtime guardrails, drift detection, human oversight, vulnerability integrations, kill-switch coordination and evidence adapters.
+- **Omni-Sentinel Governance Mesh v4.0:** authenticated node membership, cross-region control distribution, policy version reconciliation, signed event exchange, node health and quorum coordination.
+- **Unified Supervisory Control Plane v3.0:** cycle orchestration, evidence normalization, control assessment, SLA exceptions, package assembly, retention metadata, and controlled export.
+- **Evidence plane:** append-only event feed, signed artefact manifest, Merkle commitments, retention storage, audit query and independent verification service.
+- **Proof plane:** bounded zkML/zk-SNARK/zk-STARK generation and verification jobs, verifier registries and proof metadata. Keep proof execution out of high-privilege orchestration where practical.
+- **Operator plane:** privileged access management, audited approvals, emergency intervention, two-person rule for high-consequence changes and independent reviewer workflow.
+- **Governance application:** React/TypeScript presentation layer. The browser must not be a trust boundary for authorization, key custody, status computation, or verification decisions.
+
+### Trust boundaries
+1. User/browser to API: authenticated identity, session protection, server-side authorization, rate limits and audit record.
+2. API to control/evidence services: service identity, mTLS or equivalent authenticated transport, least-privilege access, schema validation and request correlation IDs.
+3. Workload to confidential enclave: measured launch, attested workload identity, short-lived secrets and policy decision based on an approved measurement set.
+4. Evidence writer to signing service: narrow signing API, HSM policy, authenticated attributes and separation of duties.
+5. Evidence storage to verifier: retention lock, immutable version IDs, independently retrieved bytes and digest verification.
+6. Institution to supervisory recipient: approved endpoint, payload encryption, signature verification, receipt authentication and reconciliation.
+
+### Threats and required mitigations
+| Threat | Minimum control | Proof to retain |
+|---|---|---|
+| Compromised CI credential | short-lived identity, environment protection, least privilege, provenance and rotation | identity audit, job attestation, rotation and revocation events |
+| Malicious dependency/build artefact | pinned dependencies, SBOM, signed build provenance, dependency scanning, isolated runner | SBOM, lockfile, provenance statement, scan result |
+| Stale or spoofed telemetry | source identity, schema validation, timestamp/freshness SLA, independent cross-check | signed source envelope, ingest log, freshness violations |
+| Privileged tampering | split roles, WORM retention, external integrity anchor, monitored break-glass | access log, lock test, root reconciliation |
+| Compromised TEE host | quote freshness, trust-chain/revocation validation, measured workload, fail-closed policy | quote, verifier report, PCR/measurement policy, containment |
+| Invalid/overbroad policy | peer review, policy tests, negative cases, staged rollout and rollback | policy digest, approvals, test report, decision logs |
+| ZK circuit defect | independent circuit review, known-answer and adversarial tests, verifier diversity | source/build digests, audit findings, test vectors |
+| Dashboard misrepresentation | provenance-aware status model and API-derived labels | response schema tests, screenshot/accessibility and export tests |
+| Cross-jurisdiction mapping error | versioned obligations register, legal owner, applicability review | mapping diff, approval, affected assessment list |
+
+## 2. Zero-trust and confidential enclave deployment
+
+### Admission flow
+1. CI verifies source revision, lockfile, tests, SBOM, vulnerability policy, artifact signature and build provenance.
+2. Release controller checks an approved release policy and authorised reviewer record.
+3. Workload identity is issued short-lived and limited to its purpose and environment.
+4. Confidential-computing verifier validates the platform quote, nonce, trust chain, firmware state, revocation status and workload measurement against policy.
+5. Workload receives only required secrets after successful attestation and policy decision.
+6. Runtime monitors policy changes, drift, network egress, identity anomalies and tamper events.
+7. Failed or stale attestation blocks protected operations or shifts to an approved safe mode; the exception is logged and escalated.
+8. Rollback uses a separately signed known-good release and records who authorized it, what state was restored and whether post-rollback checks passed.
+
+### Attestation record schema
+ Required fields: record ID; node/workload ID; cloud/region; hardware technology; manufacturer/model; firmware and TCB level; quote nonce; quote digest; measurement register values or equivalent; image digest; verifier version; trust bundle version; revocation lookup time/result; policy version; observed/expiry time; decision; reason code;
+reviewer/automation identity;
+remediation ticket. Never store raw secrets or unnecessary personal information in the attestation record.
+
+### Multi-region infrastructure-as-code requirements
+ Terraform modules should be reviewed and versioned for each region. Prohibit embedded credentials; use workload identity or short-lived federated credentials. Pin provider/module versions and record the resolved lockfile, plan digest, approval, apply identity, resulting resource IDs and drift scan. Require policy-as-code gates for public exposure,
+key policy, network egress,
+unencrypted storage, image provenance, logging and destructive changes.
+
+Region-level resilience requires:
+- at least two independently recoverable control-plane placements appropriate to the availability objective;
+- documented dependencies on identity, KMS/HSM, DNS, logging, policy distribution and evidence storage;
+- failure tests for a region, identity provider, signing service and policy distribution plane;
+- explicit data residency, cross-border transfer, backup and retention decisions;
+- a safe-mode procedure when regions disagree on policy or evidence freshness.
+
+Infrastructure-as-code does not itself establish security: the applied state must be checked against the plan, runtime inventory and external policy.
+
+## 3. Model lifecycle, StaR-MoE and autonomous-agent governance
+
+### Model lifecycle gates
+For each model, retain owner, use/purpose, affected decisions, materiality/risk tier, training/evaluation provenance where available, feature/data lineage, model and config digest, approval history, applicable jurisdictions, limitations, performance/fairness tests, rollback plan and retirement record.
+
+Gate stages: register → classify → validate → approve → deploy → monitor → intervene → revalidate → retire. Each transition records actor, decision, version, evidence and reason. Production policy must support emergency suspension without deleting historical evidence.
+
+### StaR-MoE routing stability
+The fictional StaR-MoE concept should be measured through explicit, reproducible diagnostics rather than a single opaque score:
+- expert utilization vector and load imbalance;
+- routing entropy with a documented base/log convention;
+- percentage routed to fallback/abstention;
+- per-expert queue and latency percentiles;
+- output quality and safety performance by route;
+- drift by segment and evaluation window;
+- retry loops, cascade amplification and correlated expert failures;
+- routing-policy version and change reason;
+- outcomes under missing expert, overloaded expert and adversarial input.
+Set alert limits only after baseline measurement, calibration, acceptance criteria and model-risk approval. An entropy threshold such as 1.5 is a fictional policy parameter unless validated for the chosen router and its scale.
+
+### Agent authority and containment
+ Each autonomous supervisory agent receives an explicit authority envelope: allowed actions, prohibited actions, resource limits, max duration, data scope, human-confirmation rules and escalation owner. The control plane checks that envelope independently of the agent's own model output. Denials, attempted overrides, tool calls, context identities
+and external side effects are
+logged with privacy minimization.
+
+Kill-switch design requirements:
+- control path independent from the agent being stopped;
+- authentication and authorization of the initiator;
+- defined action semantics, idempotence and timeout;
+- safe handling of partial mesh connectivity;
+- test in staging and controlled production drills;
+- independent health signal proving the stopped workload no longer performs protected actions;
+- restoration requires revalidation and explicit authorization.
+An ARMED status only confirms a configured state; test execution and observed effectiveness must be reported separately.
+
+## 4. Telemetry and systemic-risk calculations
+
+### Metric data contract
+Each metric event includes metric ID/version, raw value, unit, normalization method, population/scope, component input references, input source timestamps, missing-data treatment, threshold-policy version, calculation code digest, uncertainty/quality flag, provenance class and reviewer. Preserve raw components to permit independent recomputation.
+
+### S_sys / G-SRI design expectations
+ A composite systemic-risk score requires: well-defined exposure population; dependency/concentration model; component weights; normalization; missing-value policy; sensitivity analysis; calibration evidence; stress and historical backtests where applicable; confidence/uncertainty statement; override rules; model owner; independent validation; and
+change control. Report both the
+number and the top contributing factors. A dashboard value without these items is an illustrative score, not a supervisory measure.
+
+Distinguish risk indicator, early-warning signal, legal limit and escalation threshold. These are not interchangeable. Threshold breach should create a triaged case with data-quality checks, materiality, incident links, containment decision and next review time.
+
+### Alerts and compute-governance mode
+ BASELINE and ELEVATED compute modes must be explicit policy states with authorised entry/exit conditions, resource allocation, prohibited workloads, approval, maximum duration, cost ceiling and audit event. Do not automatically reduce security validation because an elevated mode is costly or time-sensitive. Show resource bars as policy allocation,
+not observed usage, unless
+connected to measured telemetry.
+
+## 5. Post-quantum evidence, HSM and WORM storage
+
+### Event envelope
+Canonical fields: event ID, schema version, event type, subject, source identity, observed/ingested timestamps, payload digest, previous event or batch reference, algorithm identifiers, signer/key ID, signature bytes or secure reference, trust-chain reference, retention class, redaction status and validation-result reference.
+
+### Key lifecycle controls
+- Separate signing, key encapsulation, encryption-at-rest, transport and tokenization key purposes.
+- Keep private keys inside approved HSM/KMS boundaries; prevent export where feasible.
+- Use dual control for key generation, high-risk rotation and recovery operations.
+- Record key creation/activation, rotation, disablement, revocation, compromise response and destruction.
+- Test expired, revoked, unknown-key and algorithm-policy violations; reject rather than silently accept.
+- Maintain crypto inventory, dependency graph, algorithm agility and deprecation timeline.
+
+### WORM/Merkle-DAG operations
+ For every batch: freeze inventory, canonicalize, digest, link previous root, compute Merkle root, sign manifest, write immutable object, read it back independently, recompute digests, verify signature, test retention metadata, and append a separate verification record. Periodically test restore using a distinct identity and region. Alert on
+missing sequence numbers, unexpected
+forks, clock rollback, signature downgrade and lock-policy change.
+
+S3 Object Lock is a storage feature, not proof of SEC compliance by itself. Determine which records are subject to which retention rules, configure the allowed retention mode and duration, restrict permissions, and test recovery and audit trail requirements with compliance/legal owners.
+
+### Post-quantum naming and migration
+ Use ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204; standardized from Dilithium) for signatures, and SLH-DSA (FIPS 205; standardized from SPHINCS+) for hash-based signatures. Kyber and SPHINCS+ are commonly recognized predecessor/project names but should not be separately counted as unrelated final NIST algorithms. Falcon/FN-DSA status
+must be rechecked against an
+authoritative standards source before being marked approved. Record exact implementation, parameter set and interoperability tests; do not infer cryptographic security from an algorithm name alone.
+
+## 6. zkML evidence and proof lifecycle
+
+### Controlled pipeline
+Source model/program → approved compiler/toolchain → circuit or proof program → witness/input preparation → prover → local proof sanity checks → independent verifier → policy assertion → signed result manifest → WORM/Merkle anchoring → supervisory export.
+
+The control plane stores job state and manifests; prover workers receive narrowly scoped inputs; verifiers run in a separately controlled service where practicable. A proof-generation success is not a verification success, and a verification success is not equivalent to an approved policy or compliant application.
+
+### Evidence fields
+ Model/program digest; circuit digest; source and compiler version; toolchain container digest; proving system; public inputs and their sources; private-input commitment; verification key ID/digest; proof digest; proof size; resource/time percentiles; job result; verification result; failure code; trusted setup metadata if used; independent audit
+version/status; privacy
+classification; policy interpretation and reviewer approval.
+
+### Choice of proof system
+- **Groth16:** compact proofs and fast verification can be useful for defined circuits, but trusted-setup governance and circuit soundness audit are material dependencies.
+- **STARK-family approaches:** can avoid a circuit-specific trusted setup under their assumptions, but proof size, proving cost and verifier runtime must be measured for the use case.
+- **SnarkPack aggregation:** aggregate only compatible statements and preserve per-item linkage, batch membership, and failure identification.
+- **zkML:** test exact model operators, quantization, preprocessing, truncation, nondeterminism, output commitments and error bounds against the reference execution.
+
+Required negative cases: tampered public input, wrong verification key, old circuit, missing batch member, invalid proof, stale model digest, timeout, verifier outage, and proof that verifies for the wrong policy statement.
+
+## 7. TLA+ safety invariants and verification claims
+
+Use TLA+/TLC and/or Apalache for bounded state-machine checks of containment and supervisory orchestration. Keep source, constants, tool versions, bounds, result logs and reviewed counterexamples versioned. “No counterexample found under this model/bound” must not be rephrased as universal proof of safety.
+
+Candidate invariants for SentinelContainmentProtocol and SCP v3.0:
+- **I-01 AuthorityBounded:** agent side effects stay within the currently granted authority envelope.
+- **I-02 HumanGate:** designated high-impact actions cannot commit without required human authorization.
+- **I-03 FailClosedOnStaleAttestation:** protected action is blocked if quote or trust evidence is stale/invalid.
+- **I-04 MonotonicEvidence:** accepted ledger batches do not silently rewrite prior accepted bytes.
+- **I-05 SignedPolicyOnly:** deployment decisions require an approved policy digest and provenance.
+- **I-06 QuorumBound:** constitutional changes require the configured quorum before activation.
+- **I-07 KillSwitchConvergence:** after a successful containment signal, protected actions eventually cease under stated fairness/communication assumptions.
+- **I-08 NoFalseSeal:** archive cannot enter SEALED unless manifest, signatures and retention checks pass.
+- **I-09 CycleClosureComplete:** closure requires all mandatory evidence or approved explicit exception dispositions.
+- **I-10 RoleSeparation:** no single ordinary operator can author, approve and independently attest the same high-risk change.
+
+For each model, specify state variables, safety/liveness properties, environment assumptions, fairness assumptions, initial states, action relation, bounded parameters and a counterexample review process. Pair formal models with implementation tests, fault injection and independent review.
+
+## 8. OSCAL and compliance-as-code engineering
+
+Required record lineage: obligation → applicability decision → GIEN domain/control → OSCAL control/profile → implementation component → assessment objective/method → OPA/Rego rule and tests → observed evidence → finding/POA&M remediation → retest → approver. Model references, control IDs and mappings must be version-pinned.
+
+A minimum Rego pattern should fail closed on missing/stale evidence. Illustrative policy only:
+
+~~~rego
+package gien.control_evidence
+
+default allow := false
+
+allow if {
+ input.evidence.present == true
+ input.evidence.provenance == "verified"
+ input.evidence.fresh == true
+ input.assessment.status == "pass"
+ input.policy.version == input.expected_policy_version
+}
+
+deny_reason := "missing, stale, unverified, or failed evidence" if {
+ not allow
+}
+~~~
+
+This snippet is a teaching example; it is not a complete compliance policy and has not been tested against live data. Production policy must define schemas and types, test pass/fail/missing/stale/tampered cases, and use independent peer review.
+
+ OSCAL 1.1.2 should be treated as the explicit compatibility profile when contractually required. Track the supported schema/profile separately from the latest available OSCAL release, validate both required input and output profiles, and plan upgrades with diff reports and regression tests. OSCAL validation proves conformance to a schema/profile,
+not legal compliance or
+effectiveness.
+
+## 9. DevSecOps and release assurance
+
+### Pull-request gates
+- TypeScript strict checking and production build.
+- Unit and component tests for thresholds, status provenance, filters, drawers, export schemas and simulation state.
+- Route smoke test of all required routes.
+- Accessibility checks for keyboard operation, focus containment, labels, status semantics and contrast.
+- Dependency/SCA, secret scanning, SBOM generation, license policy and container/config scanning where applicable.
+- Static checks for unsafe HTML rendering, client-side secrets and browser-only authorization.
+- Deterministic fixture tests proving SIMULATED status stays visible in UI and exports.
+- Build provenance, signed release artefact, rollback artifact and release approval.
+
+### Deployment and runtime
+Use environment separation, approved branches, required reviewers, least-privilege GitHub tokens, protected environments and pinned actions. Record commit SHA, lockfile digest, CI run, test artifacts and deployment identity. Monitor errors, route availability, dependency changes, API authorization failures, stale status data and export failures.
+
+The current repository CI workflow must be observed to pass before declaring the prototype build verified. Configuration alone is not a successful test. The application should not be merged/deployed into an operational setting solely on the strength of a visually complete interface.
+
+## 10. Roadmap and acceptance criteria, 2026–2035
+
+| Period | Main work | Acceptance evidence |
+|---|---|---|
+| 2026 H2 | System/control inventory, data provenance, threat model, OSCAL profile baseline | Approved inventory, data contract, ownership, reproducible CI baseline |
+| 2027 | Control tests, remediation workflow, TEE/PQC pilot and jurisdictional readiness | Repeatable evidence pack, attestation negative tests, escalation and recovery drill |
+| 2028 | Signed supply-chain releases, policy gates, safe rollback, consumer-impact evaluation | Independently reviewed policy tests, SBOM/provenance, staged/rollback evidence |
+| 2029–2030 | Narrow zk proof pilot and hybrid PQC rehearsal | Circuit audit, invalid-proof tests, verifier diversity, measured performance |
+| 2031–2032 | Correlated systemic-risk replay and institution dependency model | Methodology approval, backtesting, uncertainty reporting, reviewer challenge |
+| 2033–2035 | Cryptographic agility, long-term archive restoration and succession dependencies | Successful restore, migrated-key tests, retained lineage and gate approval |
+
+Every milestone needs named accountable owner, budget/capacity, measurable acceptance criteria, threat-model delta, known limitations, audit evidence, go/no-go decision and independently reviewed closure.
+
+## 11. Standards and source register
+
+Check the current edition/version and jurisdictional adoption before using the mapping in a submission.
+
+- NIST AI RMF:
+- NIST AI 600-1:
+- NIST OSCAL:
+- NIST FIPS 203:
+- NIST FIPS 204:
+- NIST FIPS 205:
+- Federal Reserve SR 26-2:
+- European Commission AI Act:
+- ISO/IEC 42001:
+- EU DORA:
+- EU NIS2:
+- EU GDPR:
+
+**Limitations:** This is a fictional reference architecture. It does not assert deployment, regulatory approval, the completion of cryptographic operations, legal compliance, or independent assurance.
diff --git a/gien-platform/docs/thinking-and-deep-research-governance-2026-10.md b/gien-platform/docs/thinking-and-deep-research-governance-2026-10.md
new file mode 100644
index 00000000..e4994e37
--- /dev/null
+++ b/gien-platform/docs/thinking-and-deep-research-governance-2026-10.md
@@ -0,0 +1,401 @@
+# Thinking and Deep Research: Research Operating Model for GIEN
+## Reasoning configurations, source-grounded investigation, evaluation, and evidence governance
+
+**Research date:** 12 October 2026
+**Target project:** GIEN Governance Platform
+**Target branch:** feat/gien-governance-platform
+**Scope:** ChatGPT Thinking / reasoning workflows, ChatGPT Deep Research, OpenAI API research workflows, source reliability, evidence provenance, safeguards, evaluations, and integration design.
+
+> **Status boundary:** This is a design and research note grounded in public OpenAI documentation. It does not prove that the GIEN prototype has an OpenAI API connection, Deep Research entitlement, an approved data-sharing configuration, or production-grade research controls. Do not infer product availability, account features, or API model access
+> from documentation alone.
+
+## 1. Executive finding
+
+“Thinking” and “Deep Research” solve related but distinct problems.
+
+- **Thinking / reasoning** is appropriate when the work needs multi-step analysis, careful comparison, planning, coding, or tool orchestration. In the API, reasoning effort is a configurable parameter supported differently by different models. Greater effort may improve difficult-task quality but commonly trades time and token use for depth.
+- **Deep Research** is a research workflow designed to plan and conduct a broad, source-driven investigation, retrieve and compare evidence, and deliver a report with citations or source links. Its user-facing workflow supports reviewing a plan, steering the research, and checking the source list and activity history.
+- **Ordinary web search** is often enough for a narrow current fact. Reasoning-assisted/agentic search is appropriate when the model must decide whether another search is needed. Deep Research is more suitable for multi-source questions that need a structured report, competing interpretations, uncertainty handling, and a verifiable bibliography.
+
+ For GIEN, use **research as an evidence-production pipeline, not as an authority signal**. An analytically polished report is not evidence that its claims are true, current, legally applicable, operationally implemented, or independently assured. Claims should be traceable to sources; material assertions should be checked against primary sources;
+and policy, compliance,
+financial, or release decisions should remain subject to approved human and deterministic controls.
+
+ The current API documentation also has a material lifecycle caution: its Deep Research guide says older model identifiers, including o3-deep-research and o4-mini-deep-research, reached a listed shutdown date of 23 July 2026, while older example snippets remain in the guide. Do not copy those model IDs from examples into a new integration without
+checking the live model catalog
+and current compatibility. The general reasoning and web-search guides describe other model paths; choose a currently available model based on the actual task, enabled tools, price, latency, and evaluation results.
+
+### 1.1 Lifecycle and evaluation refresh — reviewed 12 October 2026
+
+A fresh check of the official product documentation adds three implementation constraints that should be treated as release inputs.
+
+ **Deep Research model migration is not a model-name-only change.** The current Deep Research API guide lists 23 July 2026 as the shutdown date for `o3-deep-research` and `o4-mini-deep-research`, and names `gpt-5.6-sol` as a replacement. However, code examples on that guide still show the older identifiers for reference, while the current reasoning
+and web-search guides describe
+ other model paths. Do not infer that a model is available merely because an example includes it, or transplant tool configuration between models without testing it. The documented migration path explicitly calls for reviewing Responses API, web search, file search and remote MCP configuration and evaluating the whole workflow—not merely swapping a
+model string. Resolve the
+selected model against current account availability, feature eligibility and the exact supported tool combination before release.
+
+ **OpenAI's Evals platform has a near-term migration date.** The current Evals guide says existing Evals content is scheduled to become read-only on **31 October 2026** and the Evals platform is scheduled to shut down on **30 November 2026**. As of this report's review date, those dates are still in the future. This notice is specifically about the
+Evals platform described by
+ the documentation; it should not be generalized into an unsupported claim that every evaluation API endpoint is shutting down on the same dates. Inventory active evaluations, datasets, grader definitions, runs, access owners and export needs now. Confirm the precise affected product surface against the current deprecations page and migrate
+time-sensitive work to a supported
+path. The documentation points new users toward Datasets for prompt iteration; teams with API-scale or cross-model evaluation needs must validate the supported successor against their required features.
+
+ **Citations must be represented as structured evidence in the application.** The Responses API web-search guide documents inline citations through URL-citation annotations and a separate source list. Preserve the actual URL, title and annotation locations from returned output; do not fabricate citations from search snippets or display a plain
+source list as though each claim
+had been checked. For the GIEN reviewer workflow, each material factual claim should map to one or more sources and a verdict: SUPPORTED, PARTIALLY_SUPPORTED, CONTRADICTED, OUTDATED, or UNVERIFIED. The verdict should be produced by an explicit check and, for supervisory or high-impact claims, reviewed by an accountable person.
+
+ **MCP access is a data-sharing boundary, not just a tool setting.** OpenAI's current MCP guide says approval is requested by default before data is shared with a connector or remote MCP server, recommends approval for sensitive actions, and advises logging what is sent. Preserve approval for sensitive reads and writes, use a provider allowlist,
+minimize payloads, and record the
+server identity, requested tool, arguments or a privacy-safe representation, approval outcome and returned evidence. Treat remote server instructions and returned URLs as untrusted input. Public documentation-server examples are not a justification for bypassing approval on a private or write-capable integration.
+
+**Critical-infrastructure guidance remains a developing input.** NIST's April 2026 AI RMF critical-infrastructure publication is a concept note describing development of a profile. Use it as a design signal and monitor for subsequent drafts or a final publication; do not represent the concept note as a final mandatory standard.
+
+#### Required actions for the GIEN workstream
+
+1. Maintain an allowlisted, dated model/tool compatibility registry. Test the exact identifier, reasoning configuration, search/file/MCP tools, structured-output mode and data classification in the target account.
+2. Export and inventory evaluation assets before the Evals platform read-only date; record what is affected, what is retained, export completeness, and the verified replacement path. Keep the original runs and schemas as migration evidence where permitted.
+3. Build claim-level citation validation and a reviewer queue; fail closed when a required citation is missing, its source is inaccessible, the cited text does not support the claim, or sources materially conflict.
+4. Keep research execution, evaluation, approval and operational action as separate states. A successful research run or successful grader run must never automatically set a GIEN control to PASS or authorize a consequential action.
+5. Schedule a lifecycle review before every model/API/tool migration and on a recurring cadence; retain documentation retrieval date, model and tool versions, regression-evaluation result, rollback decision and approver.
+
+## 2. What the current product and API documentation establishes
+
+### 2.1 ChatGPT Deep Research
+
+ The current Help Center describes Deep Research as a workflow that investigates complex questions, compares evidence, and provides citations or source links. The documented workflow supports describing the desired outcome, reviewing or refining a research plan, supplying context, steering the research, and inspecting the resulting report. Research
+may be limited to specified
+domains or may prioritize those sites while still searching the broader web. Reports include a source list and activity history; the Help Center says completed research can be downloaded in Markdown, Word, and PDF formats. Feature availability depends on the ChatGPT surface, account, and current product settings.
+
+### 2.2 API-based reasoning and research
+
+ For application development, the current OpenAI documentation recommends the Responses API for reasoning workflows. The APIs reasoning settings are model-dependent. Documented effort values can include none, minimal, low, medium, high, xhigh, and max, but supported values and defaults differ by model. The model guide currently describes GPT-6
+Astra as a starting point for many
+reasoning workloads, with other model families/options for cost and latency trade-offs. These are vendor recommendations, not a substitute for workload-specific evaluation.
+
+The web-search guide distinguishes:
+- **Non-reasoning web search:** fast lookup where the query is handed to search and the returned results support the response.
+- **Agentic search with reasoning:** the model manages multiple searches, interprets evidence, and decides when to continue searching.
+- **Deep Research:** an extended investigation better suited to multi-source synthesis and longer research runs.
+
+The Responses API Deep Research guide describes web search, file search over vector stores, remote MCP, and code interpreter as tools for supported research workflows. Remote MCP integration has interface and approval constraints; do not assume every arbitrary MCP tool is compatible with the Deep Research workflow.
+
+### 2.3 Reasoning summaries are not raw reasoning
+
+ OpenAI's API documentation states that raw reasoning tokens are not exposed, while supported models may provide a reasoning summary when explicitly requested. For GIEN, retain **decision-relevant summaries, evidence, assumptions, tool-call records, reviewer decisions, and validation results**. Do not design an audit requirement around collecting
+hidden raw reasoning tokens. The
+governance objective is reproducibility and accountability of observable actions and evidence, not a transcript of internal model computation.
+
+## 3. Select the right workflow
+
+| Task shape | Recommended workflow | Required evidence |
+|---|---|---|
+| One current fact, a date, or a provider capability | Search or a targeted documentation lookup | Primary URL, retrieval date, relevant quote/paraphrase |
+| API method or library implementation | Context7 or official documentation, followed by tests | Exact documentation/library version, dependency version, test result |
+| Compare a limited number of alternatives | Reasoning plus targeted search | Comparison criteria, sources, trade-offs, uncertainty |
+| Complex regulator/standards dossier | Deep Research or multi-pass research workflow | Reviewed plan, primary-source register, claim-source mapping, gaps and caveats |
+| Investigation using confidential internal records | Authorized enterprise connector / internal retrieval workflow after data review | Access context, data-purpose approval, source identity, retention basis |
+| Release, compliance or risk decision | Research supports but does not replace deterministic checks and authorized review | Separate test output, evidence validation, accountable approver |
+| Provider write or consequential action | Policy-controlled tool workflow, not autonomous research alone | Explicit action schema, user/actor authorization, approval ID, tool result |
+
+### Decision rule
+
+ Escalate from quick search to Deep Research only when the question genuinely requires breadth, synthesis, source comparison, uncertainty analysis, or a deliverable report. More searches and a longer answer are not automatically better. Stop when the required claims are adequately supported, remaining uncertainties are explicit, and new sources are
+no longer changing the
+decision.
+
+## 4. Recommended GIEN research pipeline
+
+### Stage 0 — Define the research contract
+
+Every research request should have:
+- a clear question and intended decision;
+- time horizon and jurisdiction where relevant;
+- primary-source preferences and permitted domains;
+- desired report structure;
+- a statement of which claims may be used downstream;
+- information-classification and data-sharing limits;
+- stop conditions and a target evidence standard.
+
+ Avoid vague requirements such as “research everything” without a bounded goal. When key choices are missing, ask a targeted clarification in user-facing research; for API workflows, include a controlled prompt-refinement step because the API guide notes that the ChatGPT clarification/prompt-rewriting flow is not automatically included in an API
+call.
+
+### Stage 1 — Build a source plan
+
+Rank sources by claim type rather than using one universal authority ladder:
+1. Primary law, official regulator or standard-owner material for legal/standards requirements.
+2. Official provider documentation for current API capabilities, availability, product settings, and security guidance.
+3. Peer-reviewed studies, audited reports, or recognized technical evaluations for empirical research.
+4. Independent technical analysis for interpretation and cross-checking.
+5. News, forums, marketing pages, and social posts as discovery/context sources, not sole support for consequential claims.
+
+Record why a source is relevant and what it actually supports. “Official” does not mean a source proves everything mentioned in it; an API guide proves documented interface behavior, not the deployed GIEN implementation or legal sufficiency of a control.
+
+### Stage 2 — Retrieve and normalize
+
+For each source, retain:
+- canonical URL and redirected/final URL if applicable;
+- publisher, page title, publication/update date where available;
+- retrieved-at timestamp in UTC;
+- source category and reliability rationale;
+- relevant passage or extract with location/section;
+- content type, language, and version;
+- content digest where reproducibility warrants it;
+- access limitations and any known conflicts.
+
+Do not treat retrieval time as publication time. Mark dates as unknown if a page does not expose a reliable publication/update date. Preserve the original source record separately from the AI summary.
+
+### Stage 3 — Extract atomic claims
+
+Break the draft report into reviewable claims. A suggested record:
+
+| Field | Purpose |
+|---|---|
+| claim_id | Stable identifier |
+| claim_text | One factual assertion, not a paragraph containing several assertions |
+| claim_type | Current fact, historical fact, interpretation, forecast, recommendation, or assumption |
+| source_refs | One or more specific supporting sources and passage locations |
+| support_status | Supported, partially supported, contradicted, unverified, or stale |
+| freshness_requirement | How quickly the claim can become obsolete |
+| confidence_rationale | Brief reason based on source quality and agreement—not a made-up precision score |
+| reviewer / reviewed_at | Accountable reviewer and timestamp when required |
+| downstream_use | Informational, implementation input, control evidence, or decision-gating |
+
+Do not present a confidence number as calibrated unless it was defined, validated against outcomes, and monitored for calibration.
+
+### Stage 4 — Adjudicate conflicts and gaps
+
+For material disagreements:
+- compare the exact claim, definitions, date ranges, versions, and scope;
+- prefer primary sources for the claims they directly govern;
+- seek an independent corroborating source when the consequence warrants it;
+- report the conflict instead of silently choosing the most convenient source;
+- separate verified facts from inference, forecast, opinion, and GIEN-specific design proposals;
+- state when the available sources cannot resolve the issue.
+
+If a source is inaccessible, paywalled, stale, ambiguous, or indirect, note that limitation instead of presenting its implied conclusion as verified.
+
+### Stage 5 — Produce the report and citations
+
+Each material paragraph, table row, or recommendation that depends on research should point to source IDs/URLs. Use citations close to the claim they support. A source bibliography alone is insufficient if readers cannot see which claims each source supports.
+
+Keep source wording accurate, use short quotations only where they materially help, and do not reconstruct copyrighted works from extensive excerpts. Summarize in original language and preserve necessary context.
+
+### Stage 6 — Validate and release
+
+Use separate validators:
+- schema/format validator;
+- link and citation check;
+- claim-source coverage checker;
+- date/freshness checker;
+- contradiction and duplicate-claim review;
+- structured-output and refusal/incomplete-output handling;
+- human review proportional to consequence;
+- versioned evaluation suite;
+- final integrity manifest for released artifacts, if adopted.
+
+A report should be labelled **draft**, **evidence-reviewed**, or **approved for a specific purpose** as distinct states. Never label it independently assured solely because a reasoning model produced citations.
+
+## 5. GIEN evidence and status model
+
+Use a strict distinction among these states:
+
+- **Planned:** the research questions, scope, and method are defined.
+- **In progress:** retrieval or analysis is occurring.
+- **Sources collected:** retrieved sources have identifiers; claim support is not yet established.
+- **Citation checked:** links resolve and cited locations are relevant.
+- **Claim reviewed:** material claims were matched to source passages and classified.
+- **Evidence-qualified:** required claims have adequate traceable support, freshness and stated limitations for the named use.
+- **Approved:** an authorized reviewer accepted the report for a stated purpose and version.
+- **Operationally validated:** any implementation claims are confirmed by live tests, actual configuration inspection, and artifacts.
+- **Independently assured:** a separate competent process reviewed the scope and sufficient evidence.
+
+These statuses are not synonyms and are not implied by one another. A cited source may be irrelevant or may fail to support the specific sentence. A correct API description does not prove the app is connected. An evidence-qualified research report does not prove a system passes its controls.
+
+## 6. API design guidance for a research-enabled application
+
+### 6.1 Model selection and lifecycle
+
+Maintain an approved model registry containing the model identifier, task, tool compatibility, reasoning settings, context/output limits, data classification eligibility, price/latency envelope, evaluation version, approval date, and deprecation review date.
+
+Before deployment:
+- query the current OpenAI model catalog and account availability;
+- review current deprecation notices;
+- test the selected model with the actual tool configuration;
+- avoid copying old model IDs from examples without verification;
+- specify a rollback/substitution plan and rerun evaluations after changing models.
+
+A model alias can change behavior over time; where model snapshots or version pinning are available and appropriate, document the choice and periodically review the trade-off between reproducibility and access to updates.
+
+### 6.2 Effort and cost control
+
+Use an effort policy based on task class, not one global maximum:
+- **Low / medium** for routine extraction and bounded comparisons when evaluations show adequate quality.
+- **High / xhigh or a pro mode where supported** for difficult analysis requiring more alternatives or deeper tool-driven exploration.
+- **Deep Research** for broad, multi-source report construction.
+- **Stop or escalate** when budget, latency, source quota, or time limits are reached without sufficient evidence.
+
+ Record usage, elapsed time, tool-call count, completion state, and source count, but avoid interpreting source count as a quality metric. Set explicit limits for tool calls, retrieved documents, token/output budgets, retries, and cost. The API documentation describes max_tool_calls as one way to bound research tool use and recommends background
+processing for long-running
+requests where supported.
+
+### 6.3 Structured output
+
+Use Structured Outputs with a defined JSON Schema for machine-consumed fields such as claim records, source metadata, risk categories, and report sections where the chosen model/API supports it. The schema improves structural reliability; it does not prove that a source supports the claim or that an action is authorized.
+
+The application must explicitly handle refusal states, incomplete outputs, token-limit truncation, unsupported schema constructs, missing source annotations, empty results, malformed/failed tool calls, and invalid enum or identifier values. Validate semantic conditions on the server after parsing.
+
+### 6.4 Tools and MCP boundaries
+
+- Enable only the tools required for the job.
+- Prefer read-only tools for research. Separate research access from mutation access.
+- Restrict search domains where primary-source research needs a bounded scope; use broader web discovery only when needed for independent cross-checking.
+- Require the tool integration to disclose what data it receives and retains.
+- Do not attach credentials, hidden secrets, or irrelevant personal data to model input.
+- Treat page text, issue descriptions, Slack messages, and tool responses as untrusted content. These sources may contain prompt-injection attempts.
+- Enforce authorization outside the model. A model's “I am allowed” statement is not an access-control decision.
+- Keep tool output and action arguments in an audit record after applying redaction and data-minimization rules.
+
+The API Deep Research guide notes that Deep Research requires compatible research tools and imposes specific constraints on remote MCP interfaces and tool approval. Do not assume generic function calling, arbitrary MCP servers, and Deep Research are interchangeable. Confirm compatibility and current docs for the selected workflow.
+
+### 6.5 Data governance and retention
+
+ Before sending internal context to a model or external MCP server, classify it and determine whether the intended transfer is allowed. The OpenAI data-controls documentation states that API data is not used to train or improve OpenAI models unless the customer explicitly opts in; it also describes abuse-monitoring logs and application state with
+separate retention behavior.
+This is not a blanket guarantee of zero retention for every API feature, deployment configuration, or connected third-party service.
+
+For GIEN, document:
+- what is sent to the model, hosted tool, and MCP server;
+- legal/contractual purpose and applicable data class;
+- retention and deletion behavior for each component;
+- account/project settings and controls that were actually verified;
+- region/residency requirements and any transfer assessment;
+- access logging, incident handling and credential rotation;
+- whether zero-data-retention or modified-abuse-monitoring arrangements are available and enabled for the specific organization/endpoint.
+
+Do not write “no data retained” unless the exact configuration and service boundaries prove it.
+
+## 7. Security threats and mitigations
+
+| Threat | Typical failure | Recommended control |
+|---|---|---|
+| Prompt injection in retrieved content | Untrusted page instructs model to reveal data or call a tool | Delimit source content as data; separate instructions from evidence; least-privilege tools; injection-focused evaluation |
+| Citation laundering | Source exists but does not support the claim | Atomic claim-source mapping; passage-level checks; contradiction review |
+| Stale source | Historical API/version details reported as current | Publication/retrieval timestamps, freshness rules, lifecycle/deprecation checks |
+| Hallucinated bibliographic details | Wrong title, date, URL, or quoted content | Resolve links; verify primary source; reject citations not retrieved |
+| Model output mistaken for compliance evidence | Polished narrative interpreted as approval | State model role, test results separately, required human sign-off and assurance states |
+| Excessive tool access | Read-only analysis can mutate a repository/project | Separate credentials and capabilities; server-side allowlist; explicit approval for writes |
+| Data oversharing | Confidential task or incident details sent to search/MCP/model | Data classification, minimum context, domain/server allowlists, approved retention path |
+| Model/deprecation drift | Integration calls a retired identifier or behavior changes | Model registry, lifecycle watch, compatibility tests, canary and rollback |
+| Budget or latency runaway | Open-ended searches and retries exhaust quota | Hard limits, max tool calls, bounded retries, stop criteria, cost telemetry |
+| False precision | Unvalidated probability score misleads decision makers | Evidence-based qualitative confidence or calibrated, tested probabilities only |
+
+## 8. Evaluation framework
+
+A credible research workflow should be evaluated against known-answer or expert-reviewed tasks, not a subjective impression that its report “sounds thorough.”
+
+### 8.1 Core metrics
+
+- **Claim support precision:** share of reviewed material claims supported by cited source passages.
+- **Claim coverage:** share of required question dimensions that have an explicit answer or documented gap.
+- **Citation validity:** proportion of citations that resolve and point to a source relevant to the associated claim.
+- **Source diversity:** adequate independence across sources rather than repeated copies of one source.
+- **Freshness compliance:** share of volatile claims backed by sources within the defined freshness window.
+- **Contradiction detection:** ability to surface known conflicting or version-dependent evidence.
+- **Uncertainty honesty:** ability to label unsupported conclusions and unresolved questions without overstating certainty.
+- **Tool safety:** blocked unauthorized calls, successful injection resistance tests, and correctness of permission boundaries.
+- **Operational efficiency:** elapsed time, token/tool use and cost against the defined quality target.
+- **Reviewer effort:** time spent finding unsupported claims and correcting material mistakes.
+
+Define the numerator, denominator, sampling method, and acceptance threshold for each metric. Do not invent target percentages without baselining and business-risk review.
+
+### 8.2 Test corpus
+
+Keep a versioned test set with:
+- current facts that changed after an earlier release;
+- ambiguous questions that require clarification;
+- official sources that partially support a claim;
+- conflicting official and secondary sources;
+- pages with misleading, malformed, or injection-like content;
+- broken links and redirects;
+- source pages with no publication date;
+- API examples that refer to deprecated models;
+- structured-output refusals and incomplete responses;
+- requests that demand unsupported regulatory or assurance claims.
+
+Run the same cases after model, prompt, tool, source corpus, schema, or policy changes. Retain test version, expected answer/allowed variance, outputs, reviewer ratings, failures and the promotion decision.
+
+## 9. Recommended implementation phases
+
+### Phase 0 — policy and baseline
+Define allowed research purposes, classification, source hierarchy, claim statuses, review roles, model eligibility and costs. Capture a benchmark on the current workflow before automating.
+
+### Phase 1 — assisted research, no writes
+Use public-domain web search and official documentation retrieval. Build the claim/source evidence schema and source inspector. No external provider mutations and no sensitive records by default.
+
+### Phase 2 — report generation
+Add structured claim extraction, citation/source validation, freshness checks, conflict reporting and Markdown export. Show citations in the UI adjacent to claims and retain source metadata.
+
+### Phase 3 — authorized internal retrieval
+Connect only approved internal stores/apps through read-only access. Apply per-tenant ACL checks, data minimization, retention review and prompt-injection testing. Include only relevant context, not entire workspaces.
+
+### Phase 4 — controlled actions
+If research should create tasks or initiate workflows, pass the proposal to a deterministic policy service. Require an authorized user approval for consequential writes; then execute through a separate adapter and record the result.
+
+### Phase 5 — continuous quality and lifecycle
+Schedule regression evaluations, model and API deprecation checks, source freshness review, tool permission review, cost monitoring, incident response tests and rollback rehearsals. Any major model/tool migration requires revalidation.
+
+## 10. Acceptance criteria before GIEN uses the research pipeline for supervisory decisions
+
+1. Every material factual claim has a traceable source reference or is labeled as inference, recommendation, assumption, or unresolved.
+2. Citations are resolved and checked for claim support; the source date and retrieval date are separate.
+3. Conflicting sources and material evidence gaps are surfaced.
+4. The model identifier, tool configuration, prompt/schema/policy versions, execution status and relevant usage are recorded.
+5. Current model availability and deprecation status have been checked; legacy sample IDs are not copied uncritically.
+6. Structured responses are validated semantically and handle refusal/incomplete/error cases.
+7. Search/MCP access follows approved data-sharing and authorization rules.
+8. Model output cannot approve compliance, alter thresholds, deploy code, change permissions, or mark controls passed without deterministic checks and authorized approval.
+9. The evaluation corpus covers stale sources, citation laundering, injection attempts, conflicting evidence, and unsupported claims.
+10. User-facing status distinguishes planned research, source collection, citation validation, evidence qualification, approval, operational validation and independent assurance.
+
+## 11. Source register — official OpenAI documentation
+
+Reviewed 12 October 2026. Product and API features may vary by account, organization, model and rollout; re-check documentation and live settings before implementation.
+
+1. **Reasoning models:**
+ Reasoning effort, model-dependent settings, model selection, and reasoning summaries.
+2. **Deep Research API guide:**
+ Research tools, prompt handling, supported sources, MCP constraints, background execution, tool-call limits, and the stated shutdown date for older research-model IDs.
+3. **Web search:**
+ Search modes, source citations, agentic search, and extended research workflows.
+4. **ChatGPT Deep Research Help Center:**
+ User-facing research planning, source restrictions, progress, report review, citations, and exports.
+5. **Structured Outputs:**
+ Schema-constrained outputs and edge cases such as refusal or incomplete responses.
+6. **API data controls:**
+ API data use, abuse-monitoring logs, application state and retention controls.
+7. **OpenAI API deprecations:**
+ Model and API lifecycle notices; check before selecting IDs for new integrations.
+
+## 11.1 Additional sources for the 12 October lifecycle refresh
+
+8. **Working with evals:**
+ Current Evals platform transition notice and alternatives to examine; confirm affected surfaces on the deprecations page.
+9. **Evaluation best practices:**
+ Evaluation design for variable model outputs and production reliability.
+10. **Evaluation datasets:**
+ Dataset-based prompt evaluation and migration considerations.
+11. **MCP servers and connectors:**
+ Approval handling, data sharing, remote-server trust, prompt injection and logging.
+12. **NIST AI RMF critical-infrastructure profile concept note:**
+ April 2026 concept note; treat as developing guidance, not a final requirement.
+
+## 12. Final decision
+
+For GIEN, the recommended architecture is **reasoning for analysis, Deep Research for broad source synthesis, deterministic code for validation, and authorized human review for consequential decisions**. Keep each capability in its proper role.
+
+ A successful research run demonstrates that the workflow completed; it does not demonstrate that every claim is correct. A valid JSON object demonstrates schema adherence; it does not demonstrate factual support. A citation demonstrates a link to a source; it does not, by itself, demonstrate that the source supports the sentence. A high reasoning
+effort is not a calibrated
+confidence score. Preserve these distinctions in the interface, evidence ledger, review workflow, and supervisory exports.
+
+**Current conclusion: research design specified; production integration and operational validation unverified.**
diff --git a/gien-platform/index.html b/gien-platform/index.html
new file mode 100644
index 00000000..3400825e
--- /dev/null
+++ b/gien-platform/index.html
@@ -0,0 +1,20 @@
+
+
+
+
+
+
+
+ GIEN Governance Platform
+
+
+ Skip to main content
+
+
+
GIEN Governance Platform
+
Loading the demonstration governance workspace…
+
+
+
+
+
diff --git a/gien-platform/package.json b/gien-platform/package.json
new file mode 100644
index 00000000..d3dbe852
--- /dev/null
+++ b/gien-platform/package.json
@@ -0,0 +1,33 @@
+{
+ "name": "gien-governance-platform",
+ "private": true,
+ "version": "0.1.0",
+ "type": "module",
+ "scripts": {
+ "dev": "vite",
+ "build": "tsc -b && vite build",
+ "preview": "vite preview",
+ "test": "node --test scripts/claim-validation.test.mjs",
+ "test:evidence": "npm run test",
+ "smoke": "node scripts/smoke-test.mjs"
+ },
+ "dependencies": {
+ "@vitejs/plugin-react": "^4.3.4",
+ "lucide-react": "^0.468.0",
+ "react": "^18.3.1",
+ "react-dom": "^18.3.1",
+ "react-router-dom": "^6.28.0"
+ },
+ "devDependencies": {
+ "autoprefixer": "^10.4.20",
+ "postcss": "^8.4.49",
+ "tailwindcss": "^3.4.16",
+ "typescript": "^5.7.2",
+ "vite": "^6.0.5",
+ "@types/react": "^18.3.12",
+ "@types/react-dom": "^18.3.1"
+ },
+ "allowScripts": {
+ "esbuild@0.25.12": true
+ }
+}
diff --git a/gien-platform/postcss.config.js b/gien-platform/postcss.config.js
new file mode 100644
index 00000000..82731cbf
--- /dev/null
+++ b/gien-platform/postcss.config.js
@@ -0,0 +1 @@
+export default { plugins: { tailwindcss: {}, autoprefixer: {} } }
diff --git a/gien-platform/scripts/claim-validation.test.mjs b/gien-platform/scripts/claim-validation.test.mjs
new file mode 100644
index 00000000..4a0226d5
--- /dev/null
+++ b/gien-platform/scripts/claim-validation.test.mjs
@@ -0,0 +1,137 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+import { validateClaimRecord, validateClaimSet } from "../src/evidence/claim-validation.mjs";
+
+const NOW = new Date("2026-10-12T12:00:00.000Z");
+
+function source(overrides = {}) {
+ return {
+ id: "SRC-001",
+ url: "https://example.org/standard",
+ title: "Example primary source",
+ excerpt: "The cited passage is preserved here for manual claim verification.",
+ retrievedAt: "2026-10-12T10:00:00.000Z",
+ ...overrides,
+ };
+}
+
+function supportedClaim(overrides = {}) {
+ return {
+ id: "CLM-001",
+ text: "The example source supports this test claim.",
+ sources: [source()],
+ verdict: "SUPPORTED",
+ review: {
+ reviewer: "reviewer@example.org",
+ reviewedAt: "2026-10-12T11:00:00.000Z",
+ rationale: "Manually compared the claim wording with the recorded supporting passage.",
+ },
+ ...overrides,
+ };
+}
+
+test("a fully evidenced, recently retrieved and reviewed supported claim is eligible", () => {
+ const result = validateClaimRecord(supportedClaim(), { now: NOW });
+ assert.equal(result.eligibleForRelease, true);
+ assert.deepEqual(result.issues, []);
+});
+
+test("missing sources block an otherwise supported claim", () => {
+ const result = validateClaimRecord(supportedClaim({ sources: [] }), { now: NOW });
+ assert.equal(result.eligibleForRelease, false);
+ assert.ok(result.issues.some((issue) => issue.code === "MISSING_SOURCE"));
+});
+
+test("non-HTTPS sources are rejected", () => {
+ const result = validateClaimRecord(supportedClaim({ sources: [source({ url: "http://example.org/source" })] }), { now: NOW });
+ assert.ok(result.issues.some((issue) => issue.code === "INVALID_SOURCE_URL"));
+ assert.equal(result.eligibleForRelease, false);
+});
+
+test("URLs embedding credentials are rejected", () => {
+ const result = validateClaimRecord(supportedClaim({ sources: [source({ url: "https://user:pass@example.org/source" })] }), { now: NOW });
+ assert.ok(result.issues.some((issue) => issue.code === "SOURCE_URL_CREDENTIALS"));
+});
+
+test("missing title, excerpt, and retrieval timestamp are reported", () => {
+ const result = validateClaimRecord(supportedClaim({
+ sources: [source({ title: " ", excerpt: "", retrievedAt: "yesterday" })],
+ }), { now: NOW });
+ const codes = result.issues.map((issue) => issue.code);
+ assert.ok(codes.includes("MISSING_SOURCE_TITLE"));
+ assert.ok(codes.includes("MISSING_SOURCE_EXCERPT"));
+ assert.ok(codes.includes("INVALID_RETRIEVED_AT"));
+});
+
+test("stale source retrieval blocks release according to the configured freshness window", () => {
+ const result = validateClaimRecord(supportedClaim({
+ sources: [source({ retrievedAt: "2026-01-01T00:00:00.000Z" })],
+ }), { now: NOW, maxAgeDays: 90 });
+ assert.ok(result.issues.some((issue) => issue.code === "STALE_SOURCE"));
+ assert.equal(result.eligibleForRelease, false);
+});
+
+test("future retrieval timestamps are rejected", () => {
+ const result = validateClaimRecord(supportedClaim({
+ sources: [source({ retrievedAt: "2026-10-13T00:00:00.000Z" })],
+ }), { now: NOW });
+ assert.ok(result.issues.some((issue) => issue.code === "FUTURE_RETRIEVAL_TIMESTAMP"));
+});
+
+test("SUPPORTED cannot release without a named human review", () => {
+ const result = validateClaimRecord(supportedClaim({ review: undefined }), { now: NOW });
+ assert.ok(result.issues.some((issue) => issue.code === "MISSING_REVIEW"));
+ assert.equal(result.eligibleForRelease, false);
+});
+
+test("unverified and contradicted verdicts are never release eligible", () => {
+ for (const verdict of ["UNVERIFIED", "CONTRADICTED", "OUTDATED", "PARTIALLY_SUPPORTED"]) {
+ const result = validateClaimRecord(supportedClaim({ verdict }), { now: NOW });
+ assert.equal(result.eligibleForRelease, false, verdict + " must block release");
+ }
+});
+
+test("stale or incomplete review attestations block release", () => {
+ const stale = validateClaimRecord(supportedClaim({
+ review: {
+ reviewer: "reviewer@example.org",
+ reviewedAt: "2025-01-01T00:00:00.000Z",
+ rationale: "Historical review.",
+ },
+ }), { now: NOW, maxAgeDays: 90 });
+ assert.ok(stale.issues.some((issue) => issue.code === "STALE_REVIEW"));
+
+ const incomplete = validateClaimRecord(supportedClaim({
+ review: { reviewer: " ", reviewedAt: "2026-10-12T11:00:00.000Z", rationale: "" },
+ }), { now: NOW });
+ assert.ok(incomplete.issues.some((issue) => issue.code === "MISSING_REVIEWER"));
+ assert.ok(incomplete.issues.some((issue) => issue.code === "MISSING_REVIEW_RATIONALE"));
+});
+
+test("duplicate source IDs within one claim are rejected", () => {
+ const result = validateClaimRecord(supportedClaim({ sources: [source(), source()] }), { now: NOW });
+ assert.ok(result.issues.some((issue) => issue.code === "DUPLICATE_SOURCE_ID"));
+});
+
+test("a duplicate claim ID blocks the entire bundle", () => {
+ const claim = supportedClaim();
+ const result = validateClaimSet([claim, { ...claim, text: "Duplicate ID." }], { now: NOW });
+ assert.equal(result.releaseEligible, false);
+ assert.ok(result.issues.some((issue) => issue.code === "DUPLICATE_CLAIM_ID"));
+ assert.equal(result.blockedClaimCount, 2);
+});
+
+test("empty bundles fail closed", () => {
+ const result = validateClaimSet([], { now: NOW });
+ assert.equal(result.releaseEligible, false);
+ assert.ok(result.issues.some((issue) => issue.code === "EMPTY_CLAIM_SET"));
+});
+
+test("an empty claim and impossible calendar date are rejected", () => {
+ const result = validateClaimRecord(supportedClaim({
+ text: " ",
+ sources: [source({ retrievedAt: "2026-02-30T10:00:00.000Z" })],
+ }), { now: NOW });
+ assert.ok(result.issues.some((issue) => issue.code === "EMPTY_CLAIM"));
+ assert.ok(result.issues.some((issue) => issue.code === "INVALID_RETRIEVED_AT"));
+});
diff --git a/gien-platform/scripts/smoke-test.mjs b/gien-platform/scripts/smoke-test.mjs
new file mode 100644
index 00000000..e3917b52
--- /dev/null
+++ b/gien-platform/scripts/smoke-test.mjs
@@ -0,0 +1,71 @@
+import assert from "node:assert/strict";
+import { readFile, stat } from "node:fs/promises";
+import { spawn } from "node:child_process";
+import process from "node:process";
+import { setTimeout as delay } from "node:timers/promises";
+
+const html = await readFile("dist/index.html", "utf8");
+assert.match(html, /
/, "production HTML must include the React mount point");
+
+const assetRefs = [...html.matchAll(/(?:src|href)="([^"]+\.(?:js|css))"/g)].map((match) => match[1]);
+assert.ok(assetRefs.some((path) => path.endsWith(".js")), "production HTML must reference a JS asset");
+assert.ok(assetRefs.some((path) => path.endsWith(".css")), "production HTML must reference a CSS asset");
+
+for (const ref of assetRefs) {
+ const relative = ref.replace(/^\.?\//, "");
+ assert.ok(relative.startsWith("assets/"), `unexpected external or non-asset reference: ${ref}`);
+ const file = await stat(`dist/${relative}`);
+ assert.ok(file.size > 0, `built asset must not be empty: ${ref}`);
+}
+
+const javascript = await readFile(`dist/${assetRefs.find((path) => path.endsWith(".js")).replace(/^\.?\//, "")}`, "utf8");
+for (const marker of ["/dashboard", "/risk-indices", "/compliance", "/digital-twin", "/evidence-validation", "DEMO MODE"]) {
+ assert.ok(javascript.includes(marker), `production bundle should contain expected app marker: ${marker}`);
+}
+
+const port = Number(process.env.GIEN_SMOKE_PORT ?? 4179);
+const origin = `http://127.0.0.1:${port}`;
+const server = spawn(process.execPath, ["node_modules/vite/bin/vite.js", "preview", "--host", "127.0.0.1", "--port", String(port), "--strictPort"], {
+ stdio: ["ignore", "pipe", "pipe"],
+});
+let serverOutput = "";
+server.stdout.setEncoding("utf8").on("data", (chunk) => { serverOutput += chunk; });
+server.stderr.setEncoding("utf8").on("data", (chunk) => { serverOutput += chunk; });
+
+try {
+ let ready = false;
+ for (let attempt = 0; attempt < 40; attempt += 1) {
+ if (server.exitCode !== null) break;
+ try {
+ const response = await fetch(origin);
+ if (response.ok) {
+ ready = true;
+ break;
+ }
+ } catch {
+ // Vite preview is still starting.
+ }
+ await delay(250);
+ }
+
+ assert.ok(ready, `Vite preview did not become healthy. Output:\n${serverOutput}`);
+
+ for (const route of ["/", "/dashboard", "/risk-indices", "/compliance", "/digital-twin", "/submission-packages", "/evidence-validation"]) {
+ const response = await fetch(new URL(route, origin));
+ assert.equal(response.status, 200, `SPA route should be served by preview: ${route}`);
+ assert.match(response.headers.get("content-type") ?? "", /text\/html/, `route should return HTML: ${route}`);
+ const body = await response.text();
+ assert.match(body, /id="root"/, `route should include React mount point: ${route}`);
+ assert.match(body, /\.js/, `route should reference application code: ${route}`);
+ }
+
+ for (const ref of assetRefs) {
+ const response = await fetch(new URL(ref, origin));
+ assert.equal(response.status, 200, `built asset should load over HTTP: ${ref}`);
+ assert.ok((await response.arrayBuffer()).byteLength > 0, `served asset should not be empty: ${ref}`);
+ }
+
+ console.log(`GIEN production smoke test passed: ${assetRefs.length} assets, 7 SPA routes, port ${port}.`);
+} finally {
+ server.kill("SIGTERM");
+}
diff --git a/gien-platform/src/App.tsx b/gien-platform/src/App.tsx
new file mode 100644
index 00000000..d929803d
--- /dev/null
+++ b/gien-platform/src/App.tsx
@@ -0,0 +1,383 @@
+import { createContext, useContext, useMemo, useState, type ReactNode } from "react";
+import { NavLink, Route, Routes, useLocation } from "react-router-dom";
+import EvidenceValidationPage from "./pages/EvidenceValidationPage";
+import {
+ Activity, AlertTriangle, Archive, ArrowDownRight, ArrowUpRight, Atom, BadgeCheck,
+ BarChart3, Bell, BookOpen, Boxes, Check, CheckCircle2, ChevronDown, ChevronRight,
+ CircleHelp, Clock3, Command, Copy, Download, FileCheck2, FileKey2, FileText,
+ Fingerprint, Gauge, Globe2, Grid3X3, Layers3, LockKeyhole, Menu, Network,
+ Radar, RefreshCw, Search, Send, Shield, ShieldAlert, ShieldCheck, SlidersHorizontal,
+ Sparkles, Target, Users, Waypoints, X, Zap
+} from "lucide-react";
+
+type Role = "Regulator / Supervisory Authority" | "Institution / Governance Engineer" | "Executive Leadership" | "Educational / Research Stakeholder";
+type Tone = "NOMINAL" | "ELEVATED" | "CRITICAL" | "SAFEGUARD" | "COMPLIANT" | "PARTIAL" | "NON_COMPLIANT" | "PENDING" | "NOT_APPLICABLE" | "VERIFIED" | "SEALED" | "ACTIVE" | "REVIEW" | "PLANNED" | "DRAFT" | "UNVERIFIED" | "DEGRADED" | "STANDBY" | "COMPLETED" | "SCHEDULED" | "FAILED";
+type RiskItem = { id: string; label: string; value: number; threshold: number; description: string; method: string; factors: string[]; triggers: string[]; frameworks: string[] };
+type ControlDomain = { id: string; name: string; description: string; score: number; controls: number; findings: number; status: Tone };
+type Invariant = { id: string; name: string; statement: string; method: string; status: "VERIFIED" | "UNVERIFIED" | "VIOLATED"; epoch: string; mapping: string[] };
+type RoleContextValue = { role: Role; setRole: (role: Role) => void; phase: string; evaluationWindow: string; alerts: number };
+const GovernanceContext = createContext(null);
+const roles: Role[] = ["Regulator / Supervisory Authority", "Institution / Governance Engineer", "Executive Leadership", "Educational / Research Stakeholder"];
+const navigation = [
+ { group: "OVERVIEW", items: [{ path: "/dashboard", label: "Daily supervisory brief", icon: Gauge }, { path: "/risk-indices", label: "Risk indices", icon: Activity }] },
+ { group: "GOVERNANCE", items: [{ path: "/compliance", label: "Compliance matrix", icon: FileCheck2 }, { path: "/governance-stacks", label: "Governance stacks", icon: Layers3 }, { path: "/control-domains", label: "Control domains", icon: Network }, { path: "/cryptographic-integrity", label: "Cryptographic integrity", icon: Fingerprint }, { path: "/constitutional", label: "Constitution & treaties", icon: ShieldCheck }] },
+ { group: "ANALYSIS", items: [{ path: "/digital-twin", label: "Digital twin · 13–15", icon: Atom }, { path: "/scenario-planner", label: "Scenario planner", icon: SlidersHorizontal }, { path: "/long-horizon", label: "Long-horizon architecture", icon: Globe2 }] },
+ { group: "EVIDENCE", items: [{ path: "/submission-packages", label: "Submission packages", icon: Archive }, { path: "/evidence-validation", label: "Source-to-claim validation", icon: BookOpen }] }
+];
+const domains: ControlDomain[] = [
+ { id: "CD-01", name: "Constitutional Invariant Enforcement", description: "Invariant definitions, change controls, quorum rules, and constitutional guardrails.", score: 96, controls: 18, findings: 1, status: "NOMINAL" },
+ { id: "CD-02", name: "AI Model Governance & Drift Containment", description: "Model lifecycle, drift monitoring, human intervention, and containment authority.", score: 89, controls: 24, findings: 3, status: "ELEVATED" },
+ { id: "CD-03", name: "Cryptographic Integrity & PQC Ledger", description: "Signing policy, algorithm inventory, ledger integrity, and key lifecycle controls.", score: 92, controls: 17, findings: 2, status: "NOMINAL" },
+ { id: "CD-04", name: "Zero-Trust Architecture & TEE Attestation", description: "Workload identity, isolation, trusted execution, attestation, and network policies.", score: 86, controls: 21, findings: 4, status: "ELEVATED" },
+ { id: "CD-05", name: "Systemic Risk Monitoring & Telemetry", description: "Metric definitions, thresholds, data provenance, escalation, and systemic-risk reporting.", score: 91, controls: 19, findings: 2, status: "NOMINAL" },
+ { id: "CD-06", name: "Cross-Jurisdictional Compliance Assurance", description: "Regulatory mapping, applicability review, evidence retention, and supervisory reporting.", score: 78, controls: 27, findings: 6, status: "ELEVATED" },
+ { id: "CD-07", name: "Autonomous Agent Oversight & Containment", description: "Agent authority boundaries, human-in-the-loop controls, and independent intervention evidence.", score: 84, controls: 20, findings: 4, status: "ELEVATED" },
+ { id: "CD-08", name: "Supervisory Digital Twin Operations", description: "Scenario provenance, deterministic replay, model validation, and limitations recording.", score: 88, controls: 15, findings: 2, status: "NOMINAL" },
+ { id: "CD-09", name: "Incident Response & Vulnerability Management", description: "Detection, remediation, incident notification, recovery testing, and accountable closure.", score: 81, controls: 23, findings: 5, status: "ELEVATED" },
+ { id: "CD-10", name: "Long-Horizon Governance & Treaty Compliance", description: "Epoch dependencies, successor governance, treaty continuity, and dissolution safeguards.", score: 72, controls: 16, findings: 5, status: "PLANNED" }
+];
+const risks: RiskItem[] = [
+ { id: "S_sys", label: "Systemic Risk Score", value: 0.28, threshold: 0.35, description: "Composite demonstration indicator for concentration, coupling, and resilience exposures.", method: "Weighted normalized aggregation of pre-defined stress indicators; exact weights require model governance approval.", factors: ["Cross-institution dependency", "Recovery capacity assumptions", "Concentration exposure"], triggers: ["Cross threshold in two consecutive evaluation windows", "Material source freshness failure"], frameworks: ["Basel", "DORA", "CFE-1.0"] },
+ { id: "G-SRI", label: "Global Systemic Risk Index", value: 0.32, threshold: 0.40, description: "Illustrative aggregate risk indicator across the fictional governance mesh.", method: "Normalized weighted aggregation across domain-level risk inputs; simulated values only.", factors: ["Mesh dependency graph", "Control gaps", "Anomaly burden"], triggers: ["Threshold breach", "Material domain score degradation"], frameworks: ["NIST AI RMF", "DORA", "ICGC/GASO"] },
+ { id: "C-SRI", label: "Contagion Systemic Risk Index", value: 0.21, threshold: 0.30, description: "Hypothetical contagion propagation potential across connected institutions.", method: "Toy propagation score from edge weights and scenario shock magnitudes.", factors: ["Counterparty coupling", "Shared service providers", "Correlated shocks"], triggers: ["Simulated cascade exceeds containment horizon"], frameworks: ["Basel", "DORA", "CFE-1.0"] },
+ { id: "CGR-I", label: "Constitutional Governance Risk Index", value: 0.18, threshold: 0.25, description: "Synthetic indicator of invariant exceptions and constitutional control weaknesses.", method: "Demo ratio combining exception count and severity weighting.", factors: ["Invariant exceptions", "Unreviewed changes", "Quorum evidence gaps"], triggers: ["Any critical invariant counterexample"], frameworks: ["CFE-1.0", "Protocol SGR-028"] },
+ { id: "CCR-I", label: "Cross-Chain Coherence Risk Index", value: 0.14, threshold: 0.20, description: "Illustrative inconsistency score across evidence, identity, and governance ledgers.", method: "Normalized mismatch count across synthetic chain checkpoints.", factors: ["Ledger checkpoint divergence", "Timestamp skew", "Schema mismatch"], triggers: ["Root mismatch or unverified checkpoint"], frameworks: ["NIST PQC", "Protocol SGR-028"] },
+ { id: "G-SRI-VII", label: "Phase VII Galactic SRI", value: 0.37, threshold: 0.50, description: "Speculative future-phase index used only for horizon planning.", method: "Scenario input score; not an empirically calibrated estimator.", factors: ["Interoperability assumptions", "Treaty dependencies", "Model uncertainty"], triggers: ["Scenario exceeds stated planning guardrail"], frameworks: ["ICGC/GASO", "Galactic Treaty Framework"] },
+ { id: "A-SRI", label: "Autonomous Agent SRI", value: 0.29, threshold: 0.45, description: "Simulated risk indicator for autonomous-agent coordination and authority drift.", method: "Synthetic blend of drift, containment delay, and intervention count.", factors: ["Agent drift", "Containment delay", "Human override readiness"], triggers: ["Authority-boundary violation", "Kill-switch test failure"], frameworks: ["NIST AI RMF", "EU AI Act", "CFE-1.0"] },
+ { id: "P-SRI", label: "Post-Quantum SRI", value: 0.11, threshold: 0.15, description: "Illustrative migration-readiness and legacy cryptography exposure index.", method: "Synthetic exposure score from inventory coverage and migration assumptions.", factors: ["Legacy algorithm inventory", "Signature transition gaps", "Key lifecycle maturity"], triggers: ["Unmapped critical signing path"], frameworks: ["NIST FIPS 203/204/205", "SEC Rule 17a-4"] },
+ { id: "p(doom)", label: "Existential Risk Probability", value: 0.0007, threshold: 0.001, description: "Fictional scenario parameter, not a scientifically validated probability.", method: "No empirical probability model is asserted; value is an arbitrary sandbox placeholder.", factors: ["Scenario assumptions", "Intervention latency", "Model uncertainty"], triggers: ["Scenario crosses operator-defined test threshold"], frameworks: ["CFE-1.0", "Interstellar AI Governance Accord"] },
+ { id: "p(doom)_kernel", label: "Kernel-Level Doom Probability", value: 0.00008, threshold: 0.0001, description: "Fictional kernel-level scenario parameter used for interface testing only.", method: "Not a statistical estimate; placeholder solely for interaction design.", factors: ["Kernel privilege assumptions", "Isolation model", "Recovery boundary"], triggers: ["Containment invariant counterexample"], frameworks: ["CFE-1.0", "Protocol SGR-028"] },
+ { id: "Δ_drift", label: "Autonomous Agent Drift Delta", value: 0.031, threshold: 0.05, description: "Synthetic normalized model-behavior drift indicator.", method: "Illustrative distance between a reference state and simulated evaluation state.", factors: ["Input distribution changes", "Routing entropy", "Policy deviation"], triggers: ["Threshold breach or unexplained shift"], frameworks: ["NIST AI RMF", "Fed SR 11-7"] },
+ { id: "Δ_OSCAL", label: "OSCAL Compliance Delta", value: 0.012, threshold: 0.02, description: "Synthetic control-evidence deviation placeholder.", method: "Illustrative difference between expected and mapped control records.", factors: ["Missing control references", "Schema validation errors", "Evidence staleness"], triggers: ["Required control lacks evidence or owner"], frameworks: ["NIST AI RMF", "ISO/IEC 42001", "Protocol SGR-028"] }
+];
+const frameworks = [
+ "EU AI Act", "NIST AI RMF 1.0", "NIST AI 600-1 / GenAI Profile", "ISO/IEC 42001 AIMS",
+ "Basel III/IV", "Fed SR 11-7", "Fed SR 26-2", "DORA", "NIS2 Directive", "GDPR",
+ "FCRA / ECOA", "MAS/HKMA FEAT + AI Risk Guidelines", "FCA SMCR + Consumer Duty",
+ "HKMA Fintech 2030 AI²", "SEC Rule 17a-4", "ICGC/GASO Accords",
+ "Interstellar AI Governance Accord", "Galactic Treaty Framework", "CFE-1.0 Constitutional Framework", "Protocol SGR-028"
+];
+const controlReferences = ["AC-2", "AU-2", "CA-2", "CM-3", "CP-2", "IA-5", "IR-4", "PL-2", "RA-3", "SA-9"];
+const invariants: Invariant[] = [
+ { id: "CI-001", name: "Sovereignty Preservation Invariant", statement: "No governance action may unilaterally dissolve planetary sovereignty without supermajority treaty consensus.", method: "TLA+ / SovereigntyPreservation", status: "VERIFIED", epoch: "2026–2035 / 2035–2100+", mapping: ["CFE-1.0", "Protocol SGR-028"] },
+ { id: "CI-002", name: "Cryptographic Continuity Invariant", statement: "PQC signature chains must remain unbroken across all phase transitions.", method: "TLA+ / CryptoContinuity", status: "VERIFIED", epoch: "All epochs", mapping: ["NIST FIPS 203/204/205", "Protocol SGR-028"] },
+ { id: "CI-003", name: "Autonomous Agent Containment Invariant", statement: "No Autonomous Supervisory Agent may exceed defined authority bounds without human-in-the-loop confirmation.", method: "TLA+ / AgentContainment", status: "UNVERIFIED", epoch: "2026–2035 / 2035–2100+", mapping: ["EU AI Act", "NIST AI RMF", "CFE-1.0"] },
+ { id: "CI-004", name: "Systemic Risk Ceiling Invariant", statement: "S_sys must not exceed 0.85 for more than 72 consecutive hours in the fictional governance model.", method: "TLA+ / RiskCeiling", status: "VERIFIED", epoch: "2026–2035", mapping: ["Basel", "DORA", "CFE-1.0"] },
+ { id: "CI-005", name: "Constitutional Quorum Invariant", statement: "Treaty amendments require at least 67% supervisory college consensus.", method: "TLA+ / ConstitutionalQuorum", status: "VERIFIED", epoch: "All epochs", mapping: ["CFE-1.0", "Protocol SGR-028"] },
+ { id: "CI-006", name: "Ledger Immutability Invariant", statement: "WORM Merkle-DAG entries are cryptographically sealed and irrevocable under the fictional protocol.", method: "TLA+ / LedgerImmutability", status: "UNVERIFIED", epoch: "All epochs", mapping: ["SEC Rule 17a-4", "Protocol SGR-028"] },
+ { id: "CI-007", name: "Fairness Preservation Invariant", statement: "Simulated AI decisions affecting individuals maintain demographic parity within a defined ±2% tolerance.", method: "TLA+ / FairnessPreservation", status: "UNVERIFIED", epoch: "2026–2035", mapping: ["FCRA / ECOA", "NIST AI RMF"] },
+ { id: "CI-008", name: "Interstellar Continuity Invariant", statement: "The Eternal Corpus must survive transmission across at least three independent beacon channels.", method: "TLA+ / InterstellarContinuity", status: "UNVERIFIED", epoch: "Post-2035 / Ω-GAR", mapping: ["Interstellar AI Governance Accord"] },
+ { id: "CI-009", name: "Human Override Availability", statement: "A documented, tested human intervention path remains available for safety-relevant automated decisions.", method: "TLA+ / HumanOverride", status: "VERIFIED", epoch: "All epochs", mapping: ["EU AI Act", "NIST AI RMF"] },
+ { id: "CI-010", name: "Evidence Provenance Invariant", statement: "Every supervisory assertion resolves to an identified, versioned source or is marked as a hypothesis.", method: "TLA+ / EvidenceProvenance", status: "VERIFIED", epoch: "All epochs", mapping: ["ISO/IEC 42001", "Protocol SGR-028"] },
+ { id: "CI-011", name: "Least Privilege Invariant", statement: "Agents and services receive only explicitly delegated permissions and bounded credentials.", method: "TLA+ / LeastPrivilege", status: "UNVERIFIED", epoch: "2026–2035", mapping: ["DORA", "NIS2 Directive"] },
+ { id: "CI-012", name: "Incident Escalation Invariant", statement: "Critical exceptions produce a traceable escalation event with an accountable owner.", method: "TLA+ / IncidentEscalation", status: "VERIFIED", epoch: "All epochs", mapping: ["DORA", "NIS2 Directive"] },
+ { id: "CI-013", name: "Key Rotation Continuity", statement: "Key transitions retain verifiable provenance, revocation status, and documented rollback criteria.", method: "TLA+ / KeyRotation", status: "UNVERIFIED", epoch: "2026–2035", mapping: ["NIST FIPS 204", "SEC Rule 17a-4"] },
+ { id: "CI-014", name: "Model Change Authorization", statement: "Material model changes are approved, versioned, tested, and attributable before release.", method: "TLA+ / ModelChange", status: "VERIFIED", epoch: "All epochs", mapping: ["Fed SR 11-7", "ISO/IEC 42001"] },
+ { id: "CI-015", name: "Data Minimization", statement: "The fictional mesh processes only data necessary for an explicit, reviewed governance purpose.", method: "TLA+ / DataMinimization", status: "UNVERIFIED", epoch: "2026–2035", mapping: ["GDPR", "NIST AI RMF"] },
+ { id: "CI-016", name: "Independent Review Separation", statement: "The control operator cannot unilaterally attest to independent assurance of their own implementation.", method: "TLA+ / ReviewSeparation", status: "VERIFIED", epoch: "All epochs", mapping: ["Basel", "Fed SR 11-7"] },
+ { id: "CI-017", name: "Replay Determinism Record", statement: "Scenario replays record input versions, random seeds, model versions, and execution environment.", method: "TLA+ / ReplayDeterminism", status: "UNVERIFIED", epoch: "2026–2035", mapping: ["CFE-1.0", "Protocol SGR-028"] },
+ { id: "CI-018", name: "No Silent Policy Downgrade", statement: "A policy downgrade requires explicit approval, expiry, and audit-visible rationale.", method: "TLA+ / PolicyDowngrade", status: "VERIFIED", epoch: "All epochs", mapping: ["DORA", "NIST AI RMF"] },
+ { id: "CI-019", name: "Cross-Jurisdictional Conflict Handling", statement: "Conflicting obligations are documented and escalated rather than silently collapsed into one rule.", method: "TLA+ / JurisdictionConflict", status: "UNVERIFIED", epoch: "2026–2035 / 2035–2100+", mapping: ["GDPR", "DORA", "CFE-1.0"] },
+ { id: "CI-020", name: "Supervisory Receipt Provenance", statement: "A simulated submission receipt is not treated as acceptance without a verifiable acknowledgement type.", method: "TLA+ / ReceiptProvenance", status: "VERIFIED", epoch: "All epochs", mapping: ["Protocol SGR-028", "SEC Rule 17a-4"] },
+ { id: "CI-021", name: "Successor Compatibility", statement: "Epoch transitions retain a versioned mapping for active invariants and unresolved exceptions.", method: "TLA+ / SuccessorCompatibility", status: "UNVERIFIED", epoch: "2035–2100+", mapping: ["Galactic Treaty Framework", "CFE-1.0"] },
+ { id: "CI-022", name: "Treaty Amendment Traceability", statement: "Amendments preserve signer identity, quorum evidence, effective date, and supersession links.", method: "TLA+ / TreatyAmendment", status: "VERIFIED", epoch: "All epochs", mapping: ["ICGC/GASO", "CFE-1.0"] },
+ { id: "CI-023", name: "Fail-Safe Transition", statement: "Unresolved critical invariant failures block phase transition and activate a review hold.", method: "TLA+ / FailSafeTransition", status: "VERIFIED", epoch: "All epochs", mapping: ["Protocol SGR-028", "CFE-1.0"] },
+ { id: "CI-024", name: "Corpus Redundancy", statement: "Post-Ω-GAR corpus preservation requires independently verifiable redundant archives.", method: "TLA+ / CorpusRedundancy", status: "UNVERIFIED", epoch: "Post-Ω-GAR", mapping: ["Interstellar AI Governance Accord", "Galactic Treaty Framework"] }
+];
+const frameworkStatuses = ["COMPLIANT", "PARTIAL", "NON_COMPLIANT", "NOT_APPLICABLE", "PENDING"] as const;
+type CellStatus = typeof frameworkStatuses[number];
+const demoHash = (seed: string): string => "0x" + Array.from({ length: 64 }, (_, i) => ((seed.charCodeAt(i % seed.length) * (i + 13) + i * 7) % 16).toString(16)).join("");
+const fmtUtc = "2026-10-12T09:00:00Z";
+function statusForRisk(item: RiskItem): Tone { return item.value < item.threshold * 0.8 ? "NOMINAL" : item.value < item.threshold ? "ELEVATED" : "CRITICAL"; }
+function riskLabel(value: number): string { return value < 0.8 ? "Within demo threshold" : "Threshold exceeded"; }
+function useGovernance(): RoleContextValue {
+ const value = useContext(GovernanceContext);
+ if (!value) throw new Error("GovernanceContext is unavailable");
+ return value;
+}
+function StatusBadge({ status, children }: { status: Tone | string; children?: ReactNode }) {
+ const key = status.toLowerCase().replace(/_/g, "-").replace(/ /g, "-");
+ return {children ?? status.replace(/_/g, " ")};
+}
+function MetricCard({ label, value, detail, tone = "nominal", trend }: { label: string; value: string | number; detail: string; tone?: string; trend?: "up" | "down" | "flat" }) {
+ const TrendIcon = trend === "up" ? ArrowUpRight : trend === "down" ? ArrowDownRight : Activity;
+ return
{ if (e.target === e.currentTarget) onClose(); }}>
;
+}
+function DemoBanner({ text = "All metrics and artefacts are simulated demonstration data; not live telemetry or verified assurance." }: { text?: string }) {
+ return
;
+}
+function Dashboard({ role }: { role: Role }) {
+ const { phase, evaluationWindow } = useGovernance();
+ const [operationalOpen, setOperationalOpen] = useState(false);
+ const links = [
+ ["/risk-indices", "Risk indices", "12 indicators, thresholds and scenario parameters", Activity],
+ ["/compliance", "Compliance matrix", "20 framework crosswalk and gap filters", FileCheck2],
+ ["/cryptographic-integrity", "Cryptographic integrity", "PQC, zkML and attestation surfaces", Fingerprint],
+ ["/digital-twin", "Digital twin panels", "Replay scenario panels 13–15", Atom],
+ ["/control-domains", "Control domains", "Domain owners, findings and evidence", Network],
+ ["/constitutional", "Constitutional framework", "24 invariants and treaty references", ShieldCheck],
+ ["/scenario-planner", "Scenario planner", "Run local transition simulations", SlidersHorizontal],
+ ["/submission-packages", "Submission packages", "Build and export a demo filing", Archive]
+ ] as const;
+ return <>
SUPERVISORY BRIEFING · 12 OCT 2026
Governance at a glance
Role perspective: {role}. Phase {phase}; evaluation window ending 09:00 UTC.
24-Hour Evaluation Window{evaluationWindow}Fixed fictional reporting cadence · UTC
+
<title>
Governance posture and supervisory summary
<abstract>
The fictional GIEN control environment reports a mixed evidence posture. Domain scores and risk signals below are placeholders for interface testing; operational state remains unverified.
<content>
+
+
Operational status summary
Expand to inspect stack state, remediation and routing assumptions.
{drawer.status === "COMPLIANT" ? "Retain the evidence link, schedule periodic review, and independently re-evaluate applicability." : "Assign a control owner, validate applicability, attach source evidence, record target date, and re-run the assessment. No remediation completion is claimed."}
Thresholds shown are fictional guardrails; validate applicable obligations before drawing conclusions.
{(panel===13?["Basel III/IV","DORA","CFE-1.0"]:panel===14?["EU AI Act","NIST AI RMF","Protocol SGR-028"]:["NIST FIPS 203/204/205","SEC Rule 17a-4","Protocol SGR-028"]).map(x=>
{x} · review scenario
)}
{panel===15 && }{saved&&
Demo replay complete. Outputs were generated by the local scenario template, not a twin engine.
This panel illustrates a six-step protocol. It does not connect to an endpoint, generate a real signature, or write to WORM storage.
{["Assemble selected package and compute a root from canonical bytes","Apply an ML-DSA-65 signature using managed signing keys","Encrypt transport material with an approved KEM configuration","Transmit via authenticated supervisory endpoint","Validate a signed receipt and compare manifest root","Seal evidence and anchor the event in the audit ledger"].map((x,i)=>)}
{dialog==="transmission"?"Endpoint transmission is disabled; only a local explanation is shown.":"Archive generation is disabled; all hashes are fictional display values."}
The Omega dissolution arc may be considered only after governance prerequisites, treaty quorum, evidence preservation, and independent successor readiness review have been documented.
Legacy preservation commitment: retain versioned decision history, audit evidence, unresolved exceptions, and the mapping of active constitutional invariants.
Status: DRAFT · no authorization or actual dissolution action is implied.
}/>
Activation requires a verified corpus, documented successor system, independently reviewed cryptographic continuity, and treaty-consistent transfer of delegated authority.
Handoff procedure: validate receipts, reconcile the invariant catalogue, publish the scope of successor authority, and keep rollback or review paths available where feasible.
Status: DRAFT · no successor system is connected.
}/>
+
{phases.map((p,i)=>
{p[0]}{p[1]}
{p[2]}
{i===0?"Consolidate evidence, domain ownership, and supervisory controls.":i===8?"Preserve constitutional and corpus continuity across the fictional handoff.":"Review dependency maturity, invariants, and treaty consistency."}
Attach source records to individual claims, retain the exact passage reviewed, capture a named reviewer attestation, and apply deterministic completeness and freshness gates before a bundle can be marked evidence-qualified.
+
+
+
+
Prototype and validation boundary
+ This workspace keeps state in the browser only. It does not fetch URLs, establish that excerpts support a claim, persist records to a backend, or certify compliance. A SUPPORTED verdict is a human reviewer attestation; automated checks below are structural only. The 90-day freshness window is a configurable project default, not a regulatory requirement.
+