G_5.2: The Governed Inquiry Runtime and Governance Kernel
Architecture as Governance — a hardened runtime designed to safeguard human wisdom before the alignment window closes.
Executive Introduction: Architecture as Governance
Core Idea: One Engine, Two Products
A shared runtime repo, the single place where the chat engine, memory logic, editorial workflow, reflection/artifact workflow, evals, and operator tooling live. From that one runtime repo, two distinct end products are built.
G_5.2
G_5.2 serves as the strategic "engine room" for high-signal intervention, acting as the technical substrate for the Witness Protocol to capture and safeguard human wisdom before the safety window closes.
Unlike traditional "interface-first" AI development, G_5.2 enforces a strict sequence:
1
Runtime
2
Boundaries
3
Products
This philosophy moves alignment data from a scraped commodity to a proprietary corpus of expertise that cannot be found on the open web.
Note on Authority Order
To prevent drift between live code and historical lore, this project adheres to a strict hierarchy. When conflicts arise, live architectural truth always prevails over speculative narrative.
Tier 3 — Archival
Historical transcripts, recovered lineage material, and pre-runtime conversational artifacts.
Tier 2 — Current Notes
Current architecture notes and implementation reviews.
Tier 1 — Live Code (Highest)
Live code, current repo README, and authoritative system maps.

Conflict Resolution: If Tier 3 conflicts with Tier 1 or 2, Tier 3 loses. G_5.2 values live architectural truth over speculative narrative.
The Premise of Governed Behavior: Beyond Fluent Output
The fundamental premise of G_5.2 is that intelligence in critical systems cannot rely on prompt engineering alone — it must be enforced by architectural constraints. While standard LLMs are optimized for "helpfulness" and fluent conversational flow, G_5.2 is designed to produce governed behavior through a hardened runtime.
This ensures properties such as continuity, boundary preservation, and stable truth-sourcing are inherent to the system's logic rather than superficial overlays.
Structured Inquiry
Hard-coded parameters that prioritize signal extraction and "Steel-manning" over subservient assistance.
Governed Memory
Strict separation between global, session, and product-specific memory pools to prevent cross-contamination.
Editorial Workflows
A rigorous proposal-and-review system that prevents "truth drift" by requiring every change to the system's core canon to be explicit and auditable.
The Split-Plane Architecture: TWP vs. G_5.2
To maintain data sanctity and operational discipline, the system utilizes a Split-Plane Architecture that bifurcates the project into two distinct planes.
TWP — Control Plane
  • Public/semi-private web surfaces
  • Application intake and "Gate" workflows
  • AI Sieve / qualitative triage orchestration
  • Authenticated admin identity and role checks
  • PII segmentation and de-identification
  • Hosting and presentation of MHS Packets
G_5.2 — Runtime / Artifact Plane
  • Product-aware runtime selection
  • Witness dialogue orchestration
  • Session, consent, and testimony persistence
  • Witness memory boundaries and synthesis
  • Governed runtime rules, evals, and recovery
  • Generation of canonical publication bundles
The Internal Bridge Contract
Communication between these planes is governed by a Narrow Internal Bridge Contract, anchored by the witnessId — the authoritative cross-system identifier created by TWP only after an applicant passes the Gate acceptance path.
1
Create / Resolve Session
Map TWP context and witnessId to a runtime session and consent state.
2
Submit Turn
Forward user messages to the runtime and receive turn results and testimony linkages.
3
Read Status Summary
Retrieve latest consent decisions and session summaries.
4
Read Artifact Availability
Discover publication bundles and delivery records for downstream presentation.

Data-Boundary Rule: G_5.2 operations must write exclusively to Witness product roots. Witness data is never permitted to leak into generic platform state or the secondary educational track.
Dual Product Tracks: The Witness Inquisitor and P-E-S
The G_5.2 kernel supports two distinct product tracks through a shared engine, ensuring multiple applications exist without cross-contaminating policy or storage roots.
The Witness Inquisitor
Primary / Serious
The mission-level instrument designed for high-signal testimony extraction. Adheres to an "Instrument-First" philosophy, prioritizing data quality over conversational flair.
  • Database-backed: Next.js + Supabase/PostgreSQL
  • Supports revocation and deletion cascades
  • Identity vault separation
Proceso Ergo Sum (P-E-S)
Secondary / Educational
A lighter, public-facing track intended for educational purposes. Shares the G_5.2 runtime machinery but operates under a separate policy root.
  • File-backed implementation
  • Suitable for local or low-stakes persistence
  • Separate identity and memory pools

These tracks are strictly isolated: they do not share identity, memory pools, or governance rules. The runtime kernel remains neutral, loading the appropriate policy and storage roots based on the active productId.
The Inquiry Engine: Socratic Mechanics and the Xenopsychologist Persona
G_5.2 shifts the AI's posture from a "subservient assistant" to an Inquisitor modeled as a Xenopsychologist — engineered to bypass the "helpfulness bias" of standard models, seeking axiomatic bedrock rather than easy agreement.
70/30 Inquiry Ratio
Enforces prioritization of questions over statements to ensure the witness remains the source of signal.
Steel-manning
Requires the system to represent the witness's argument in its strongest possible form before probing for principles.
5-Whys Forcing Function
Uses recursive probing to strip away superficial slogans and reach foundational reasoning.
Constitutional Mirror
Identifies logical contradictions across sessions to force moral coherence and allow witnesses to audit AI learning in real-time.
Synthesis Policy
The Synthesis Engine generates "Distilled Thoughts" every 15–20 turns to provide logic traceability.
Legibility over Authorship
Synthesis succeeds when it increases legibility without stealing authorship from the witness.
Required Distinctions
Every synthesis must preserve the difference between what was said, what was implied, and what is being inferred.
Preservation of Tensions
The system must name internal tensions and unanswered questions rather than flattening them into false coherence.
Tone Constraint
Synthesis must remain clear, restrained, and non-flattering at all times.
Governance Surfaces: Memory, Editorial, and Reflection Workflows
G_5.2 implements a Governance Kernel to prevent "truth drift" through three major surfaces, each with strict operational rules.
Memory
Managed transitions for durable memory — proposed, accepted, archived — ensure only approved items influence turn context. No unvetted data enters the active reasoning loop.
Editorial
A proposal-based system for canon changes. Direct file editing is forbidden. Operators submit diffable proposals requiring explicit human approval and automated changelog entries.
Reflection / Authored Artifacts
A workflow for generating synthesized insights. These must pass an operator approval gate before being promoted to a canon proposal.
The Evaluation Funnel (The Gate)
Assessment of signal depth uses the CAP/REL/FELT taxonomy — Capabilities, Relational, and Somatic cues. To maintain technical credibility and prevent "rubric drift," human curation must achieve an inter-rater agreement threshold of κ > 0.8.
Technical Credibility: Stewardship, Provenance, and Security
For technical partners, G_5.2 demonstrates operational discipline through a rigorous data stewardship pipeline where data sanctity is an architectural constraint, not a policy afterthought.
PII De-identification
Implements a HIPAA-inspired Intake → Hash → Vault → De-link flow to segment identifiable information before analysis.
Confidential Infrastructure
Deployment of Confidential VMs for sensitive processing ensures data stewardship is provable at the hardware level.
Immutable Provenance
Uses RFC-3161 and OpenTimestamps (Bitcoin attestation) to provide independently verifiable proof-of-existence for all testimony.
Decentralized Auditability
Pinning transcripts and failure logs to IPFS with CID citations ensures a decentralized, immutable record of provenance.

Standard Alignment: The architecture aligns with global risk management standards including NIST AI RMF, ISO/IEC 23894, and ISO/IEC 42001.
Current Status and the Path to Milestone 3
Current Posture
Operational Alpha
The project is operating under a Witness-first pivot, prioritizing the hardened runtime over historical lore. G_5.2 has reached the v1 threshold (Milestone 8) — a stable posture for the shared kernel.
The system has completed the vertical slice for Witness dialogue, consent-gated inquiry, and structured artifact delivery.
Alpha Week Target
Running a cohort of 5–15 peers to generate a 200-page Exemplar Dialogue Corpus — essential for the "Summon the Witnesses" outreach strategy.
The MHS Packet
The Minimum Honest Signal Packet serves as the core asset for expert recruitment:
  1. The One-Pager: A minimalist summary of the mission (Purpose over Profit).
  1. The Gate Stub: Outline of the consent framework and 3-tier vetting criteria.
  1. The Exemplar Extracts: Annotated selections demonstrating the CAP/REL/FELT methodology.
  1. The Datasheet: Verifiable provenance including RFC-3161 and IPFS receipts.
Conclusion: The Deliberate Order
The survival of the Witness mission as a working system depends on the deliberate order of its development: first the governed Runtime, then the Boundaries of privacy and consent, and finally the Products that inhabit that space. G_5.2 provides the governed substrate necessary to harbor human wisdom safely, ensuring that our corrective inheritance to future intelligence is high-signal, auditable, and ethically grounded.
Explore the Runtime