The Blueprint for Verified Intelligence
Return to Episode 1: V.E.R.A. Project CharterPrevious Article: Episode 3, "The Architecture of Truth"
REAL INTELLIGENT AI
Episode 4
The Blueprint for Verified Intelligence
TOGAF ADM Phase B: Business Architecture
By Andreas Hamberger, M.A. Phil in Logic (Humboldt University), Wellington, New Zealand.
**
"A vision without a plan is a hallucination." -- Widely attributed
Twelve formal architecture artifacts.
That is what it took to turn V.E.R.A.'s triple-layer verification vision into something you can actually build, test, and deploy. Not a pitch deck. Not a whitepaper. Twelve interlocking documents produced under TOGAF's Architecture Development Method, covering every dimension from capability modelling to risk assessment to a twelve-week implementation roadmap.
In Episode 1, we published the V.E.R.A. Project Charter. In Episode 2, we laid down the 98 requirements that make AI stop lying. In Episode 3, we presented the Architecture Vision: the triple-layer verification system that mathematically separates predication from existence.
Today, we answer the question every enterprise architect asks after a vision is presented: How does it actually work as a business?
Phase B of the TOGAF Architecture Development Method is the Business Architecture. It is where vision becomes operating model. Where principles become capabilities, capabilities become services, and services become processes that you can test, measure, and deploy.
This is the most thorough business architecture I have delivered in thirty years of enterprise architecture practice. Let me show you why it needed to be.
**
Twelve Artifacts: The Complete Operating Model
A TOGAF Business Architecture is not a single document. It is an interlocking set of artifacts that, taken together, describe how an organisation delivers value. For V.E.R.A., these artifacts describe how a logic engine delivers truth.
| Artifact | Key Content | Why It Matters |
|---|---|---|
| Requirements Catalogue | 98 requirements across 12 categories | The law V.E.R.A. must obey |
| Capability Model | 6 Level-1, 26 Level-2 capabilities | What V.E.R.A. must be able to do |
| Service Catalog | 8 business services with SLAs | What V.E.R.A. delivers |
| Process Architecture | Triple-layer verification pipeline | How V.E.R.A. verifies truth |
| E! Corpus Data Model | Entity, Property, Provenance schemas | Where verified reality lives |
| Interface Specifications | 7 interfaces with API contracts | How components talk to each other |
| Organisation Model | 8 actors, RACI matrix | Who does what |
| Test Strategy | Unit, integration, system, acceptance | How we prove it works |
| Gap Analysis | 15 gaps with 12-week roadmap | What we need to build |
| Risk Register | 16 risks with mitigations | What could go wrong |
| Phase C/D Architecture | 5-layer technical architecture | How we build it |
| Business Architecture Overview | Consolidated reference document | The master index |
Every artifact is available on the V.E.R.A. GitHub repository.[1] This is open-source architecture for an open-source logic engine.
Six Capabilities: What V.E.R.A. Must Do
A capability model answers a deceptively simple question: what does this system need to be able to do? Not how it does it, not what technology it uses, but what fundamental abilities it must possess.
V.E.R.A. requires six Level-1 capabilities to fulfil its mission of verified, ontologically-sound AI reasoning:
**
| ID | Capability | Description |
|---|---|---|
| CAP-L1-01 | NTP Logic Processing | Apply Non-Traditional Predication Theory rules to analyse and validate statements |
| CAP-L1-02 | Existence Verification | Verify entity existence against curated evidence corpus |
| CAP-L1-03 | Identity Resolution | Determine entity identity using indiscernibility relations (D1-D4) |
| CAP-L1-04 | LLM Integration | Interface with Large Language Models for natural language processing |
| CAP-L1-05 | Reasoning Transparency | Provide auditable, traceable reasoning chains for every output |
| CAP-L1-06 | Fail-Safe Governance | Refuse invalid inferences and maintain logical integrity |
These six capabilities decompose into twenty-six Level-2 sub-capabilities. NTP Logic Processing alone breaks into five: Formula Parsing, Existential Loading Analysis, Consequence Type Classification, Negation Handling, and Rule Validation. Each one maps directly to validated rules from Wessel (1992).[2]
This is the critical difference between V.E.R.A. and every other AI safety wrapper on the market. Our capabilities are not heuristics. They are not machine-learned patterns. They are formal mathematical operations derived from a peer-reviewed logical theory. You cannot convince V.E.R.A. to skip a capability. The maths does not negotiate.
Eight Services: What V.E.R.A. Delivers
Capabilities describe what V.E.R.A. can do. Services describe what V.E.R.A. delivers to its consumers. The distinction matters because services have contracts: defined inputs, defined outputs, measurable service levels.
The V.E.R.A. Service Catalog defines eight business services. The flagship is the Query Verification Service (SVC-001), which is the external-facing API that accepts natural language queries and returns NTP-validated responses. It realises all six Level-1 capabilities in a single transaction.
Behind it sit seven internal services: Existence Lookup, Identity Resolution, Krampitz Analysis, LLM Wrapper, Audit Logging, Refusal Handling, and Corpus Synchronisation. Each has defined SLAs. The Krampitz Analysis Service, for example, must classify any formula in under 100 milliseconds. The Existence Lookup Service targets sub-200ms response times per entity check.
These are not aspirational. They are contractual. When V.E.R.A. goes into production, these SLAs become the basis for monitoring, alerting, and incident response.
**
The Verification Pipeline: How Truth Is Manufactured
The Process Architecture is where V.E.R.A. comes alive. It defines the exact sequence of operations that transform a natural language query into a verified, ontologically-sound response.
The pipeline operates in ten deterministic steps:
| Step | Component | Action | Decision Point |
|---|---|---|---|
| 1 | User Query | Natural language input received | -- |
| 2 | Query Parser | Convert to NTP formula | Parse failure: Refusal |
| 3 | Layer 1: Krampitz | Determine existential loading (e/n) | n-type: Skip Layer 2 |
| 4 | Layer 2: E! Verify | Check existence in E! Corpus | NOT_EXISTS: Refusal |
| 5 | Layer 3: D-Service | Resolve identity (D1-D4) | Ambiguous: Qualify |
| 6-10 | LLM + Post-Verify | Generate, intercept, validate, format | Claim unverified: Flag/Reject |
Notice the decision points. At every stage, there is a gate. If the gate fails, the pipeline does not push through regardless. It either refuses, qualifies, or escalates. This is the fail-safe refusal principle from our requirements, implemented as process architecture. Integrity over answers. Always.
**
Mind the Gap: Fifteen Gaps and a Twelve-Week Plan
Every honest architecture includes a gap analysis. If you cannot describe what you do not have, you do not understand what you need.
V.E.R.A. has fifteen identified gaps across three categories: eight capability gaps (things we need to build), three knowledge gaps (things we need to validate from source materials), and four infrastructure gaps (platforms we need to provision).
The eight capability gaps are the implementation roadmap in disguise. They tell us exactly what to build and in what order:
| Sprint | Gaps Addressed | Deliverables |
|---|---|---|
| Weeks 1-2 | Krampitz Analyser + Database | R1-R9 implementation, SQLite schema |
| Weeks 3-4 | Formula Parser + E! Corpus seeding | NL-to-NTP conversion, Wikidata ETL |
| Weeks 5-6 | Existence API + Refusal Handler | exists() endpoint, intelligent refusals |
| Weeks 7-8 | D-Service (D1-D4) | Identity resolution with four relations |
| Weeks 9-10 | Claude API Integration | LLM wrapper with pause-and-verify |
| Weeks 11-12 | Audit Logger + CI/CD | Compliance trail, GitHub Actions |
The three knowledge gaps are worth calling out separately. They represent areas where our source materials are incomplete: the hexadecagon structure (the full mapping of 16 binary connectives to consequence zones), the formal definitions of strict versus lax consequence, and the detailed treatment of definite descriptions. All three require access to Wessel (1989) or Wessel (1996), which we are actively seeking.[2] We have marked these gaps clearly because intellectual honesty is not optional in a project about truth.
Sixteen Risks: What Keeps Us Honest
The Risk Register identifies sixteen risks scored by likelihood and impact. Three are rated High, nine Medium, and four Low. Let me highlight the three High risks because they reveal something important about V.E.R.A.'s design philosophy.
Risk 1: E! Corpus Completeness. No knowledge base is ever complete. V.E.R.A. mitigates this with the UNKNOWN response. When an entity is not found in the corpus, the system does not assume non-existence. It returns UNKNOWN and qualifies the output. This is not a weakness. It is a feature. An honest "I do not know" is infinitely more valuable than a confident hallucination.
Risk 2: LLM Prompt Injection. Adversarial users will try to bypass V.E.R.A.'s verification layers through prompt injection. Our defence is architectural, not heuristic. The NTP rules are not part of the prompt that users can manipulate. They are enforced by the Krampitz Analyser and the E! Verification Service as deterministic code. You cannot talk your way past a mathematical proof.
Risk 3: Source Material Gaps. Our three knowledge gaps (hexadecagon, strict/lax consequence, definite descriptions) could delay full implementation. Mitigation: the MVP focuses on validated rules (R1-R9, MT1-MT3, D1-D4) from Wessel (1992).[2] Everything in the MVP has been verified against primary sources. We build on what we have proven, not on what we hope to prove.
**
A Preview: The Five-Layer Technical Architecture
As a bonus, we have also produced a forward-looking Phase C/D Architecture document that maps the business architecture onto a concrete technical implementation. The architecture consists of five layers:
| Layer | Function |
|---|---|
| L1: Edge / API Gateway | Request routing, rate limiting, input validation |
| L2: Safety Interceptor | PII scanning, crisis detection, prompt injection defence |
| L3: NTP Engine | Krampitz Analyser, E! Verification, D-Service |
| L4: LLM Wrapper | Claude API integration with pause-and-verify |
| L5: Data + Observability | E! Corpus, audit logs, drift monitoring dashboards |
This architecture follows a "Secure by Design" and "Safe by Default" philosophy. Every layer has controls. Every control maps to a risk. Every risk maps to a requirement. Traceability is not a nice-to-have; it is the entire point.
**
What Comes Next
In Episode 5, we will move into Phase C: the Information Systems Architecture. This is where the E! Corpus schema meets real data, where the Krampitz Analyser meets real code, and where the interface specifications become working APIs.
We are building in the open. All twelve Phase B artifacts, plus the Phase C/D Architecture, are available on GitHub:
https://github.com/andreas-linux/vera/
Join the Movement
V.E.R.A. is an open-source initiative. We are looking for logicians to validate our NTP implementation against the hexadecagon structure, Python developers to help build the E! Verification Service and D-Service, data architects to design the Wikipedia/Wikidata ETL pipeline, enterprise architects who understand the compliance implications, and researchers with access to Wessel (1989) or Wessel (1996) source materials.
The age of the Stochastic Parrot is ending. The age of Verified Reason is beginning.
Ita est momentum veritatis. So it is, the importance of truth.
What does your organisation's gap analysis look like when it comes to AI verification? Have you tried to map the distance between what your AI systems claim and what they can actually prove? I would love to hear your experience.
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 acknowledge the role of AI tools, such as Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, which assisted in drafting, editing and reviewing. They accelerated the process, but the first draft, revisions, vision, voice and final decisions were mine alone.
Publication Date: 21 February 2026Copyright 2026 Andreas Hamberger. All rights reserved.
Next week in Episode 5: Phase C takes V.E.R.A. from blueprint to code. The E! Corpus schema meets real Wikidata, and the Krampitz Analyser meets its first real formulas.
References
[1] V.E.R.A. GitHub Repository. https://github.com/andreas-linux/vera/
[2] Wessel, H. (1992). "Existenz, Ununterscheidbarkeit, Identitat." Wissenschaftliche Zeitschrift der Humboldt-Universitat zu Berlin, Reihe Geistes- und Sozialwiss. 41, pp. 30-39.
[3] V.E.R.A. Architecture Documentation Suite (2026). TOGAF ADM Phase B Artifacts v1.0. Available at https://github.com/andreas-linux/vera/