We Shipped: V.E.R.A. v0.1 Is in the World
PRE-FLIGHT METRICS CARD:- Hook type: Data lead (Vectara HHEM-2.3 external framing)- Strategic intent: v0.1 release announcement + TOGAF arc completion + coding arc transition- NTP claim scan: All e-type claims sourced. No preliminary NTP content presented as validated. No hexadecagon structure, strict/lax consequence formal definitions, or definite descriptions referenced. No unimplemented capability claims.- Overexposure compliance: 98 NTP requirements referenced by concept only (count 3); test suite referenced without count (count 2 threshold); 170ms referenced as design decision (count 2); OECD alignment referenced without framework detail restatement (count 3).- Cross-series callbacks: 4 planned and executed (Cyber Sunday, EA Thursday, Gen AI Tuesday, Linux Wednesday)
Return to Episode 10: How a Verified Reasoning System Manages Its Own Evolution
Frontier reasoning models hallucinate more than one query in ten. In March 2026, Vectara released HHEM-2.3, its latest hallucination evaluation model covering current frontier AI systems, and that is what it found [1]. Not a 2022 problem. A right-now problem, measured against the most capable systems available today.
In that same month, OpenAI acquired Promptfoo, an AI output testing platform already deployed at more than 127 Fortune 500 companies [2]. The market is investing seriously in AI verification. Which means the market has arrived at a conclusion V.E.R.A. reached ten episodes ago: unverified AI output is an enterprise liability.
This is Episode 11. The TOGAF Architecture Development Method arc is complete. V.E.R.A. v0.1 is released under GPL-3.0. This is the announcement, the arc summary, and the bridge to what comes next.
Ten Episodes and One Architecture
V.E.R.A. started with a single claim: AI hallucination is not a training problem and not a scale problem. It is a logical architecture problem.
Standard predicate logic, the foundation on which every modern language model is built, conflates existence with predication. A model can generate grammatically correct, semantically coherent statements about entities that do not exist, because nothing in the logic requires an entity to exist before properties are attributed to it. This is not a flaw in any specific model. It is a structural property of the underlying formalism.
Non-Traditional Predication Theory, developed by Professor Horst Wessel at Humboldt University Berlin, and formalised in the Krampitz rules published in 1990, solves this by mathematically separating existence (E!) from predication (ℳ). The E!x operator requires that an entity exist before any property is predicated of it. The separation is deterministic. It is verifiable. It is not probabilistic.
Episodes 1 through 3 established this theoretical foundation. Episode 1 was the project charter: the vision, the commercial vehicle (Te Pono Limited), and the operating principle. Episode 2 documented the requirements catalogue drawn from Wessel and Krampitz. Episode 3 laid out the Architecture Vision: what a system that implements NTP at scale would look like, and what it would need to do.
Episodes 4 through 10 followed the TOGAF Architecture Development Method in sequence. Each episode mapped to one ADM phase.
Episode 4 (Phase B, Business Architecture) established the twelve formal business architecture artefacts: the capability model, the service catalogue, the value stream, the information concept model. Episode 5 (Phase C, Information Systems Architecture) defined the ten-step deterministic verification pipeline and the five interconnected data schemas. Episode 6 (Phase D, Technology Architecture) specified the six-layer system and set the latency design target: verification processing fast enough to sit inside existing query response time, invisible to the user. Episode 7 (Phase E, Opportunities and Solutions) documented the Verification Gap, the space between what current AI verification products offer and what formal-logic-based reasoning verification provides. Episode 8 (Phase F, Migration Planning) delivered the five-milestone roadmap from architecture to first verified query. Episode 9 (Phase G, Implementation Governance) documented the CI/CD governance regime and confirmed Milestone 4: the first NTP-verified query with a complete provenance chain. Episode 10 (Phase H, Architecture Change Management) completed the arc by defining how V.E.R.A.'s architecture evolves without compromising its core logical properties.
Ten episodes. Ten ADM phases. One architecture. The design work is done.
What v0.1 Is
V.E.R.A. v0.1 is five working modules, a seed E! Corpus, and a passing test suite.
krampitz_analyzer.py implements the R1 through R9 Krampitz rules. These are the validated subset of NTP requirements that can be applied deterministically to verify logical predications. Each rule governs a specific class of claim: rules about existence, about identity, about negation, about how properties are attributed. When a claim reaches the analysis layer, it is processed against every applicable rule in sequence.
formula_parser.py converts natural-language assertions into the formal logical structure the Krampitz Analyzer processes. This is the translation boundary between prose and logic. The parser handles the fundamental unit of NTP claim analysis: a subject, an existence predicate, and a property predication.
e_verification_service.py is the existence verification layer. For any entity appearing in a query, the service checks the E! Corpus: is there a verified existence record for this entity? If the record is absent, the claim fails existence verification and the pipeline flags it before predication is attempted. No existence, no predication. That is the rule.
vera_pipeline.py orchestrates the three layers in sequence. A query enters, passes through formula parsing, existence verification, and Krampitz analysis, and exits with a structured provenance chain: what the query claimed, what existence records were found, which logical rules were applied, and what the analysis concluded.
demo_first_query.py is the demonstration script. A working, end-to-end example of V.E.R.A. processing a real query through the complete pipeline. This is what "we shipped" means: not a whitepaper, not a proof of concept, not a roadmap. A working demonstration.
The test suite covers all modules. Every test passes. The count is not the point; the coverage is.
The E! Corpus seed covers a verified entity set sufficient for demonstration and initial testing. Entities from Wikipedia confirmed via Wikidata; pharmaceutical entities from WHO data. This is a starting corpus. The Pharma 500 build, which will establish verified pharmaceutical entity coverage at scale, is the first major deliverable of Arc 2.
The codebase is GPL-3.0. It is available on GitHub. Te Pono Limited is the commercial vehicle. The revenue model is an open-source verification architecture plus proprietary domain-specific E! Corpora for enterprise clients requiring verified entity coverage in specialist domains: pharmaceutical, legal, financial, government.
The Landscape This Enters
Four developments from early 2026 clarify where V.E.R.A. sits. They are consistent with the problem V.E.R.A. addresses. They are not proof that V.E.R.A. works; proof comes from the test suite and from Arc 2's demonstrations. But they confirm that the problem is real, active, and attracting serious investment.
Promptfoo and the output testing layer. OpenAI's acquisition of Promptfoo on 9 March 2026 is the clearest market signal yet [2]. Promptfoo has more than 127 Fortune 500 companies testing AI outputs against defined criteria. The acquisition means output verification is now considered infrastructure-grade by one of the largest AI organisations in the world. The Cyber Sunday series made a related observation in the context of AI deployment governance [3]: organisations are investing in AI output monitoring at the same time as they are deploying AI at scale. The question is not whether to verify but what to verify.
Here is the answer to that question: Promptfoo asks whether an AI output is correct. V.E.R.A. asks whether the reasoning that produced it was logically valid. These are different questions. A model can produce a correct output through flawed reasoning; it can also produce a correct output that its next query will contradict, because the underlying reasoning was not constrained by existence or logical consistency requirements. Output testing catches wrong answers. Reasoning verification catches wrong logic. They are not competitors. They are layers.
HHEM-2.3 and the persistence of the problem. Vectara's HHEM-2.3 data covers frontier reasoning models in operation in March 2026. More than 10% hallucination rate at current frontier capability levels [1]. OpenAI's own analysis frames hallucination as a structural property of how language models are trained and incentivised, not a problem that training alone will eliminate [4]. The implication for enterprise AI governance is direct: reasoning models require external verification. Not as a stopgap pending improvement. As a permanent architectural layer.
arXiv 2603.21149 and formal verification. A paper published on arXiv in March 2026 demonstrated Z3 formal verification achieving 100% accuracy across 135 test cases on structured problem sets [5]. Z3 is a satisfiability modulo theories solver. It is a different formal methods approach from NTP, but it operates in the same intellectual space: deterministic, proof-based verification rather than probabilistic output checking. The Linux Wednesday series noted the open-source verification movement in the context of V.E.R.A.'s GPL-3.0 release [6]: the formal verification research community is producing working results, and V.E.R.A.'s NTP-based approach is a sibling methodology, not an isolated experiment.
NIST AI Agent Standards and the trust architecture. The NIST AI Agent Standards Initiative is developing guidance for agent identity and authorisation [7]. The EA Thursday series has covered Zero Trust Architecture's role in agent governance directly: ZTA verifies who an agent is and what it is authorised to do [8]. V.E.R.A. addresses the adjacent layer: what an agent reasons, and whether that reasoning is logically valid. Identity verification and reasoning verification are complementary layers of the same trust architecture. One answers "who is this agent?" The other answers "is this agent's reasoning sound?"
What V.E.R.A. Does Differently
The market terminology is loose, and the distinction matters.
Most AI verification products are output classifiers. They take a model's response and assess it: is this harmful, is this factually consistent with prior responses, does this align with defined criteria? These are valuable functions. They operate at the output layer.
V.E.R.A. operates at the reasoning layer, below the output, using NTP's E!/ℳ separation. Before any predication is generated, existence verification is required. The query "Is Aspirin effective for managing fever?" requires, under V.E.R.A.'s architecture, that "Aspirin" resolve to a verified entity in the E! Corpus. Only then can properties (effectiveness, application, dosage range) be predicated. The Krampitz rules then govern the logical structure of the predication itself.
This architecture catches a class of errors that output testing cannot: logically coherent claims about entities that either do not exist or cannot be confirmed to exist from verified sources. A language model generating a plausible drug interaction for a compound that has no verified existence record is not making a grammatical error or a semantic error. It is making an existence error. Standard output testing is not designed to detect this.
The Gen AI Tuesday series reported BCG's cognitive governance findings from March 2026: human oversight of AI systems hits a practical ceiling at around four or more concurrent AI tools, as cognitive load produces what the research calls a "brain fry" condition [9]. The design implication is that human-in-the-loop verification of AI reasoning at enterprise scale is not viable as a primary control. This is why the 170ms latency target, set as a design decision in Episode 6, remains the architecture's governing constraint: verification must sit inside existing response latency, invisible to the user and imperceptible to the workflow. An architecture that requires a separate human review step is not an architecture; it is a hope.
What the TOGAF Arc Established
The ten episodes produced more than working code and an architecture diagram. They produced a governance trail.
A TOGAF Architecture Description does not just define what a system does. It defines why each architectural decision was made, what alternatives were considered, what the tradeoffs were, and what the implications of each decision are for system evolution. The V.E.R.A. architecture is documented at that level across all ADM phases. Every component has a rationale. Every interface has a formal contract. Every risk is logged.
This matters for the Arc 2 implementation. No architectural decisions need to be relitigated. The codebase has a design, and the design has a documented basis. When Arc 2 extends the architecture with D-Service (the Indiscernibility Relations that handle identity resolution), the extension fits into a defined architecture rather than accreting on top of an undocumented system.
The OECD Due Diligence Guidance for Responsible AI provides the regulatory frame that makes V.E.R.A. legible to enterprise and government audiences. V.E.R.A.'s provenance chain aligns with the guidance's tracking requirements. This alignment has been documented since Episode 7. The point here is not to restate the framework; the point is that the governance case for V.E.R.A. in regulated environments rests on a documented architecture that can be audited, not on a product claim that cannot.
What Comes Next: Arc 2
Episode 12 begins the coding arc. The working title is "The Identity Problem."
The technical focus is D-Service v0.1: implementing D1 through D4, the four Indiscernibility Relations specified in the V.E.R.A. architecture. These relations govern when two differently-named entities are in fact the same entity. D4, the most practically significant, handles cases where two entities are indiscernible across all relevant properties.
The concrete demonstration will be pharmaceutical: is Panadol the same entity as Paracetamol? Without D-Service, a verification system that encounters a query about Panadol cannot use its Paracetamol verification records and vice versa. With D4 resolution, the system correctly identifies them as indiscernible and applies the relevant existence and predication records to both names.
This is not a contrived example. It is the central identity problem in pharmaceutical AI verification. It is also why Pharma 500 was selected as the first production domain: the stakes are clear (these are medications), the entities are well-defined (WHO data exists), and the identity resolution problem is genuinely hard (brand names, generic names, chemical names, and trade names refer to the same underlying entities through different surfaces).
Episodes 12 through 16 complete Arc 2 and deliver V.E.R.A. v0.2: D-Service, a 500-drug corpus, a FastAPI wrapper making V.E.R.A. accessible as an endpoint, a Claude integration layer, and a side-by-side demonstration of what V.E.R.A. catches that an unverified language model misses. That last deliverable is the highest-value content moment in the series. Everything up to Episode 15 builds toward it.
A Note on Open Source
V.E.R.A. is GPL-3.0. The code is available. This is a deliberate choice with a deliberate rationale.
The Linux Wednesday series covered the bazaar model: open-source projects survive not because of their licensing terms but because they produce working code on a defined timeline, and working code attracts contributors [10]. V.E.R.A. has working code. It has a timeline. It has an unsolved problem, claim extraction (how to isolate atomic claims from prose for NTP verification), that is genuinely hard and academically interesting. Researchers working on formal logic, natural language processing, and AI verification will find a working codebase to build on, not a concept paper to respond to.
The proprietary element is not the architecture. The architecture is open. The proprietary element is the E! Corpora: the verified entity coverage in specialist domains. A pharmaceutical firm, a legal organisation, or a government agency that needs verified entity coverage for their specific domain will need a corpus built to their requirements. That is where Te Pono's commercial model sits. The engine is shared. The domain-specific fuel is not.
This is the same structure as many successful open-source commercial projects. The intellectual property that matters commercially is not the algorithm; it is the curated, quality-controlled, domain-specific data that makes the algorithm useful in production.
The Question for This Stage
The architecture is done. The first release is in the world. Arc 2 begins next week.
Given that frontier reasoning models still hallucinate more than one query in ten, and that human oversight of AI reasoning at enterprise scale is not a viable primary control, what is the minimum viable verification layer you would demand before trusting an AI agent to act on your behalf?
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] Vectara. "HHEM-2.3: Hallucination Evaluation for Reasoning Models." March 2026. https://vectara.com/
[2] PromptFoo. "OpenAI Acquires Promptfoo." 9 March 2026. https://promptfoo.dev/
[3] Hamberger, A. "The Hour-Zero Protocol: Navigating the Fog of War." The Hamberger Report: Cyber Sunday, Part 6. 22 March 2026. [LinkedIn]
[4] OpenAI. "Why Language Models Hallucinate." 2026. https://openai.com/research/
[5] arXiv:2603.21149. "Formal Verification of AI Reasoning Systems Using Z3." March 2026. https://arxiv.org/abs/2603.21149
[6] Hamberger, A. "Forty-Seven Seconds of National Darkness." The Hamberger Report: Linux Wednesday, Episode 6. 4 March 2026. [LinkedIn]
[7] NIST. "AI Agent Standards Initiative: Identity and Authorisation Guidance." 2026. https://nist.gov/artificial-intelligence
[8] Hamberger, A. "AI Agents Versus Agentic AI: The Distinction That Changes Everything." The Hamberger Report: EA Thursday, Chapter 4. 5 March 2026. [LinkedIn]
[9] Boston Consulting Group. "Brain Fry: The Cognitive Governance Ceiling at Four or More AI Tools." March 2026. https://bcg.com/
[10] Hamberger, A. "Forty-Seven Seconds of National Darkness." The Hamberger Report: Linux Wednesday, Episode 6. 4 March 2026. [LinkedIn]