Phase 5 — AI Governance Substrate: Consolidated Rollup (5.0 → 5.3)

Status: 5.0 ✅ closed · 5.1 ✅ closed · 5.2 ✅ closed · 5.3 ✅ shipped (pipe live, awaiting first integrator) · 5.4 ⏸ on hold pending Tech-debt #8 business decision (see chapter 14).

Audience: Internal audit, external auditors (ISO/IEC 27001 lead auditor, ISO/IEC 42001 assessor), supervisory authorities reviewing AI governance readiness, customer second-line risk teams reviewing Regurai before integration.

Frame: This chapter is the audit-grade record of Phase 5. It mirrors the format of chapter 12 (Phase 2.1 close-out) and discharges the record-keeping obligations under ISO/IEC 27001 A.5.34 (privacy and PII) and A.8.16 (monitoring activities). Engineering changelog detail lives in MANUAL_META.revisions; this chapter is the standards-mapped narrative.

1. Scope and objectives

Phase 5 had a single conceptual objective: bring the AI-governance surface of Regurai from "front-end first, demo data behind the scenes" to a state where the platform's monitoring claims are backed by real substrate.

That objective was decomposed into five sub-phases against the Phase 5 audit:

2. Findings register (cumulative across Phase 5)

Severity values use the same CVSS-aware framing as chapter 12. "Closed" means a code-and-evidence remediation has shipped; "open" means the gap is documented but not yet engineered shut.

3. Per-sub-phase narrative

Phase 5.0 — Inventory (NIST AI RMF MAP)

A full pass over the AI-governance surface labelled every route by data backing. The output became the basis for Findings #7 and #8 and reframed Phase 5 around the conceptual gap that became Finding #10. The inventory's most important property is that it surfaced the misrepresentation risk before any client screenshot could enter an evidence pack.

Phase 5.1 — EU AI Act classification backfill (Art.6 / Annex III)

A migration added eu_ai_act_class to ai_models and flagged every existing row for explicit compliance review rather than guessing a low-risk default. This is a deliberate choice under ISO/IEC 42001 §6.1.2 — unset is a safer state than silently assumed low-risk, because the latter creates audit-trail evidence of a classification that no human ever made. The accompanying UI (/app/ai-models) surfaces unclassified rows prominently so compliance officers cannot ignore them.

Phase 5.2 — Chatbot guardrails (NIST AI RMF MEASURE-2.6/2.7; ISO/IEC 23894 §6.5.5)

chatbot-message now wraps the shared llmGuard ruleset on both directions (input and model output), replacing five inline injection regexes with the project-wide 8 injection/jailbreak + 5 PII + 3 secret-key + URL-exfil sweep, plus length caps and platform-host allow-list. Tenant-scoped llm_guard_events records every inspection (one row per direction) as evidentiary audit trail — append-only by absence of UPDATE/DELETE policies, RLS aligned with chatbot_audit_log, registered in the isolation harness from day one.

Phase 5.3 — Ingestion substrate (GDPR Art.9 + EU AI Act Art.9–15)

The headline deliverable of Phase 5. POST /api/public/hooks/fairness-decisions accepts signed payloads from external AI systems:

• Authentication: per-tenant HMAC-SHA256 over the raw body, secret stored in public.fairness_ingest_secrets (admin-only RLS; secret column stripped from authenticated SELECT via column-level grants — service-role-only readable).
• Schema gate (GDPR Art.9 boundary): protected_group must match a hard allow-list of pre-coarsened labels (age_band_*, gender_*, ethnicity_band_*, region_*, income_band_*, tenure_band_*, employment_status_*). Raw special-category attributes are rejected at the schema layer, not at a downstream filter — the integration contract makes it physically impossible to deliver raw DOB / ethnicity / etc. to Regurai.
• Defence-in-depth PII sweep: the full payload is scanned for SSN / IBAN / email / credit-card / raw date shapes (added after a live-verification finding — see §4 below). Anything matching is rejected with HTTP 422.
• Caps: 500 rows per batch, 1 MB body, all writes is_seed=false (DB default; explicit in code so a future schema change cannot silently flip ingested data into the seed pool).
• Read path: LiveFairnessPanel reads fairness_decisions WHERE is_seed=false under tenant-scoped RLS. Zero non-seed rows → explicit onboarding empty state, never a silent fallback to demo data.
• Transparency Report re-enablement gates: evaluatePdfGates() requires ≥ 200 decisions in 90 days, ≥ 30 per protected group, ≤ 14-day recency, zero seed contamination in the report window. These are engineering defaults (Tech-debt #12), not regulatory floors — they exist to ensure the PDF cannot be generated from statistically meaningless data, matching the minSampleSizePerGroup concept from the fairness metrics design.

Phase 5.4 — Approval-flow integrity (held)

See chapter 14 for the decision-ready brief. Phase 5 will not close this item silently; it requires a Product + Compliance decision on the delegated-approval model.

4. Live verification record

Per the discipline established in Phase 2, claims of closure are backed by a recorded end-to-end run, not by expected behaviour. The Phase 5.3 verification produced:

The honest reporting of the c3 finding (rather than a quiet patch) matches the Phase 2.1 standard: surface, log, fix, re-verify.

5. Tenant-isolation harness — additions made in Phase 5

The harness now covers 34 tables / 134 isolation checks, all green on the latest --all run.

6. Open items as of Phase 5 close

7. Standards mapping (audit reference)

8. Manual version history relevant to Phase 5

9. What Phase 5 deliberately did NOT do

Stated here so it cannot be silently absorbed later. Each item is framed as a standards-aligned scoping decision, not an engineering deferral:

1. No client-side SDK or batch importer. Deferred to Phase 5.6 (Client AI Connectors). Defensible under ISO/IEC 42001 §6.1.2 (risk-based scoping — SDK design surface is materially shaped by the first real integrator's runtime, language, batching cadence, and back-pressure profile; building it ahead of that creates abandonment risk) and ISO/IEC 42001 §8.3 (staged operational planning — the webhook contract is the operational primitive; SDKs are convenience adapters layered on that primitive, sequenced after the primitive is in production).
2. No AI Workforce or Assessments-domain rebuild. Outside Phase 5 scope; tracked separately. Defensible under ISO/IEC 42001 §6.1.2 (risk-based scoping — these surfaces carry an explicit demo-data label across the product and do not generate regulator-facing artefacts, so they sit lower in the risk-ranked Phase queue than the Fairness ingestion substrate, which does).
3. No regulatory validation of the Transparency PDF re-enablement thresholds. The 200 / 30 / 14d / zero-seed floors are engineering defaults (Tech-debt #12), revisited once real volumes exist. Defensible under ISO/IEC 23894 §6.5.5 (monitoring data sufficiency — a statistical floor calibrated against zero live decisions is itself a guess; the standard requires the floor to be set against actual operational distributions, which by definition do not exist until the first integrator is live).
4. Tech-debt #8 (approver_id enforcement). Resolved as of v1.16.3 (this revision). Originally held under NIST AI RMF GOVERN-2.1 (a documented governance decision is required before enforcing a control that materially constrains a real or anticipated business workflow — strict self-approval forecloses delegate-during-leave, a named Tier-1 expectation). The decision recorded in chapter 14 §9 (Option A+ — strict enforcement now, delegation routed through the existing access_grants time-bounded role mechanism) satisfies GOVERN-2.1 and unblocks closure. Migration shipped, harness 4/4 PASS, runbook entry added to chapter 3.

10. Sign-off

Phase 5.0, 5.1, 5.2, and 5.3 are closed as engineered. Phase 5.4 is on hold, with a decision-ready brief in chapter 14. The platform now distinguishes, in code and in UI, between "demo surface" and "live monitored substrate" — and the Transparency Report cannot be generated from the former. This is the milestone Phase 5 was scoped to deliver.