V.E.R.A. Episode 9: Governing the Truth Engine
Series: V.E.R.A. SaturdayTarget publication date: 28 March 2026Word count (body): ~2,200 / 1,800-2,500 dev log targetCitation count: 5 / 3+ minimumFeed card title check: primary keyword "V.E.R.A." in first 7 chars: Y / subtitle under 90 chars: YNZ integration: none / appropriate for technical architecture articlePSC disclaimer: verbatimElection phase at publish: Phase 1 (pre-period)Readability (Flesch-Kincaid): ~11 / 10-13 targetAvg sentence length: ~17 words / 15-22 targetPassive voice ratio: ~10% / below 15% targetNTP claim scan: 12 e-type sourced / 18 n-type / 0 flagged
Series Navigation: Episode 8: From Blueprint to First Light | GitHub: github.com/andreas-linux/vera
"Governance is not about control. It is about creating conditions where the right things happen without needing to be mandated."Adapted from the OECD Principles of Corporate Governance.
Forty-two tests. All passing.
Phase F gave V.E.R.A. a working system. The code is on GitHub. The first end-to-end verified query runs. Every gate in the test suite is green.
Now comes the harder question: how do we ensure it stays true?
Eight episodes. Eight weeks. Eight phases of the TOGAF Architecture Development Method. Each phase has built on the last: from architecture vision to business requirements, from information systems design to technology stack, from opportunities assessment to migration planning. Phase F was the sprint to first working code. Phase G is something different. It is the infrastructure that protects everything that was built.
Phase G of the TOGAF ADM is Implementation Governance: the structures, gates, and agreements that ensure the delivered system matches what was designed. For most software projects, governance arrives as an afterthought, retrofitted after the first production incident. For V.E.R.A., it is built into the architecture from first principles, because the system's entire value proposition depends on it. An AI reasoning engine that claims to verify existence must be able to demonstrate that its own verification logic has not drifted from its specification.
This week, we document the governance regime, the CI/CD compliance pipeline, and the quantified alignment between V.E.R.A. and the OECD Due Diligence Guidance for Responsible AI (January 2026) [1].
Nine Episodes: The Journey So Far
| Episode | Title | Phase | Status |
|---|---|---|---|
| 1 | The Project Charter | Preliminary | Published |
| 2 | The 98 Rules That Make AI Stop Lying | Business Requirements | Published |
| 3 | The Architecture of Truth | Phase A: Architecture Vision | Published |
| 4 | The Blueprint for Verified Intelligence | Phase B: Business Architecture | Published |
| 5 | Where Logic Meets Data | Phase C: Information Systems | Published |
| 6 | The Engine Room | Phase D: Technology Architecture | Published |
| 7 | The Verification Gap | Phase E: Opportunities and Solutions | Published |
| 8 | From Blueprint to First Light | Phase F: Migration Planning | Published |
| 9 | Governing the Truth Engine | Phase G: Implementation Governance | This week |
What Phase G Actually Means
Many projects treat governance as paperwork imposed on engineers after the work is done. That misunderstands what TOGAF Phase G is for.
Phase G is the handover from the architecture team to the delivery team, with the architecture team retaining oversight authority. It answers four questions that Phase F does not. Who has authority to approve deviations from the architecture? How are deviations detected before they compound? What constitutes evidence of compliance at each release gate? And what happens when the evidence is missing?
For V.E.R.A., these are not administrative questions. The existence-predication firewall is the system's central claim. If a developer bypasses it for performance reasons, or softens a refusal for usability reasons, the architecture is no longer V.E.R.A. Something else is running under the name. The governance regime exists to prevent that drift without requiring human review of every commit.
Phase G produced four formal deliverables:
| Deliverable | Content | V.E.R.A. Output |
|---|---|---|
| Architecture Compliance Plan | Rules for ensuring the built system matches the architecture | NTP rule enforcement checklist; CI/CD gate definitions |
| Architecture Contract | Agreement between architecture team and delivery team | Signed-off V.E.R.A. architecture baseline; deviation procedure |
| Compliance Assessment | Ongoing measurement against architecture requirements | 42/42 passing test suite as compliance evidence |
| Architecture Governance Framework | How decisions are made and escalated | REF-001 as hard gate; NTP deviation requires architecture board sign-off |
The Architecture Contract is the key instrument. It defines the baseline: six architecture principles, the Krampitz R1-R9 rule set [2], and the three-layer verification pipeline. Any change to these requires a formal deviation request with NTP justification. A performance optimisation that short-circuits the E! Verification Service is not a technical decision. It is an architecture decision, and it requires architecture board sign-off.
This is not bureaucracy. It is the structural expression of the system's promise.
NTP Compliance in the CI/CD Pipeline
The Architecture Compliance Plan defines four gate levels. Each gate maps directly to an NTP principle derived from Wessel (1992) [2].
| Gate | Check | NTP Rule Enforced | Failure Mode |
|---|---|---|---|
| Pre-commit | Formula parser validation | Krampitz R1-R9 applied to changed formulas | Fail: commit blocked |
| Pull request | E! Corpus schema integrity | Entity/Property/Alias schema constraints enforced | Fail: PR rejected |
| Merge | Full test suite | 42/42 tests: Krampitz (12), Parser (15), E! Service (10), Pipeline (5) | Fail: merge blocked |
| Release | End-to-end demo | demo_first_query.py: all five decision paths pass | Fail: release tag blocked |
Three points about this design are worth stating explicitly.
First, the gates are fail-closed. A test failure blocks the next stage. It does not generate a warning. This mirrors REF-001: the system refuses rather than proceeding under uncertainty. The fail-closed design follows the same principle Zero Trust Architecture applies to network access: when the verification evidence is absent, deny. Not warn. Deny.
Second, the gates enforce NTP rules, not software quality in general. A commit can achieve full test coverage and still fail the pre-commit gate if it introduces an e-type formula that bypasses Krampitz classification. The pipeline tests logical correctness, not only functional correctness. These are different things, and conflating them is how governance collapses while the test suite stays green.
Third, the release gate uses the end-to-end demo as its evidence. Five decision paths, all passing: VERIFIED, NOT_EXISTS, NO_CHECK_REQUIRED, REFUSAL, and alias resolution. The demo is not a showcase. It is the release criterion. If the demo fails, the release does not tag.
OECD Due Diligence Guidance: The Quantified Case
The OECD Due Diligence Guidance for Responsible AI (January 2026) [1] defines a six-step framework for responsible AI development and deployment. V.E.R.A. was not designed to comply with it. It was designed to solve a logical problem: how to separate existence claims from predication claims using NTP's formal framework.
The alignment is structural, not incidental.
| OECD Step | Requirement | V.E.R.A. Implementation | Status | Version |
|---|---|---|---|---|
| Step 1 | Embed responsible business conduct into policies and management systems | V.E.R.A.'s six architecture principles (Wall of Separation, Fail-Safe Refusal, Consequence Transparency, Context-Sensitive Identity, Reasoning Transparency, Evidence-Based Existence) are implemented as code constraints, not policy documents. | Full | All versions |
| Step 2 | Identify and assess actual and potential adverse impacts | Krampitz Load Analyzer classifies every formula as e-type (existence claim, risk-bearing) or n-type (logical necessity, risk-free) before any LLM generation occurs. Risk is identified at the formula level, before output is produced. | Full | v0.1+ |
| Step 3 | Cease, prevent, and mitigate adverse impacts | REF-001 (Fail-Safe Refusal) is a hard architectural block, not a configurable flag. The existence-predication firewall cannot be bypassed at runtime. The system refuses rather than hallucinating. | Full | v0.1+ |
| Step 4 | Track implementation and results | Every query generates a full audit record: KLA decision (e/n), E! verification result (EXISTS/NOT_EXISTS/UNKNOWN), D-Service resolution, timestamp, and source provenance. The audit trail is append-only. | Full | v0.1+ |
| Step 5 | Communicate actions to address impacts | GPL-3.0 open-source release. Full architecture documentation published. GitHub repository public. Every design decision is traceable to NTP source material (Wessel, 1992) [2]. | Full | v0.1+ |
| Step 6 | Provide for or cooperate in remediation | E! Corpus provenance model supports targeted correction (source, date, confidence per entry). Corpus versioning enables rollback. Remediation API is a v0.2 deliverable. | Partial | v0.2 |
Five of six steps are fully satisfied by design at v0.1. Step 6 (remediation) is partially satisfied: the provenance model is in place, but the remediation API that allows corpus corrections via a structured workflow is a v0.2 deliverable.
The argument this makes to enterprise procurement and governance teams is precise. When you deploy V.E.R.A., you are not acquiring a system and then retrofitting due diligence compliance. The compliance is in the architecture. The audit trail is structural. The refusal mechanism is non-negotiable. The OECD framework was published in January 2026; V.E.R.A.'s architecture principles predate it and satisfy it because both are grounded in the same underlying requirement: AI systems must be able to account for what they claim to know.
That is a provable architectural property. It is not a marketing claim.
What Comes Next
In Episode 10, the series moves to Phase H: Architecture Change Management. Phase H closes the TOGAF ADM cycle, asking how the architecture evolves in response to lessons learned, new requirements, and external change, including regulatory change [3]. For V.E.R.A., Phase H defines the process for adding new E! Corpora domains, updating the NTP rule set as Wessel (1989) and Wessel (1996) validation completes, and managing the transition from the GPL-3.0 open-source core to commercially licensed domain corpora.
Episode 11 marks the real milestone: the v0.1 release article. The architecture is complete. The governance regime is in place. The code runs. The next arc begins.
Arc 2 (Episodes 12-16) builds the system that proves the commercial case: D-Service identity resolution, the Pharma 500 corpus (500 drugs, approximately 7,100 E! Corpus entries), a FastAPI wrapper, and the LLM integration with side-by-side hallucination comparison. Episode 15 is the one to watch.
All architecture documents, governance artefacts, working code, and the full V.E.R.A. GitHub repository are available at: https://github.com/andreas-linux/vera/ [4]
Join the Movement
V.E.R.A. is an open-source initiative under Te Pono Limited [5]. We are looking for contributors across five disciplines:
Logicians: to validate the hexadecagon structure and strict/lax consequence definitions against Wessel (1989) and Wessel (1996). This is the highest-priority academic need in the project.
Python developers: to contribute to the D-Service implementation, FastAPI wrapper, and Pharma 500 corpus build.
Data engineers: to extend the Wikidata ETL pipeline and build domain-specific corpus loaders.
Enterprise architects: who understand the governance and compliance implications of verified AI, particularly the OECD alignment documented above.
Pharma domain experts: who can validate the Pharma 500 entity and property definitions against the WHO Essential Medicines List.
Governance separates an architecture from a system. The truth engine now has both.
Ita est momentum veritatis. So it is, the moment of truth.
Have you worked on a project where the test suite stayed green while the architecture quietly drifted from its specification? What was the governance gap that let it happen, and how did you find it?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. V.E.R.A. (Verified Existence & Reason Architecture) is an open-source logic engine available on GitHub.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
[1] OECD. "Due Diligence Guidance for Responsible AI." January 2026. https://www.oecd.org/en/about/programmes/responsible-business-conduct.html
[2] Wessel, H. (1992). Logik. Berlin: VEB Deutscher Verlag der Wissenschaften.
[3] The Open Group. "TOGAF Standard, Version 9.2 — Phase H: Architecture Change Management." 2018. https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html
[4] Hamberger, A. "V.E.R.A. (Verified Existence and Reason Architecture)." GitHub. 2026. https://github.com/andreas-linux/vera/
[5] Te Pono Limited. New Zealand Companies Register. https://www.companiesoffice.govt.nz/