Where Logic Meets Data
PRE-FLIGHT METRICS CARD
REAL INTELLIGENT AI
EPISODE 5
Return to Episode 1: V.E.R.A. Project CharterPrevious Episode: Episode 4, The Blueprint for Verified Intelligence
Where Logic Meets Data
TOGAF ADM Phase C: Information Systems Architecture
By Andreas Hamberger, M.A. Phil in Logic (Humboldt University), Wellington, New Zealand.
"The value of an idea lies in the using of it."Thomas Edison
In Episode 1, we published the V.E.R.A. Project Charter. In Episode 2, we laid down the 98 requirements. In Episode 3, we presented the Architecture Vision. In Episode 4, we delivered the complete Business Architecture: twelve artifacts describing what V.E.R.A. does, how it delivers value, and who does what.
Today we cross the line from what to how. Phase C of the TOGAF Architecture Development Method is the Information Systems Architecture. It answers two questions that every CTO, every lead developer, every data architect asks when they see a business architecture: what does the data look like, and what do the applications do with it?
For V.E.R.A., Phase C is where the E! Corpus schema meets real data. Where seven interface specifications become concrete API contracts. Where the Krampitz Analyzer, which already passes all its tests in Python, gets wired into a verification pipeline that touches every claim an LLM produces.
This is the episode where architecture stops being a diagram and starts becoming software.
Two Architectures, One Truth
TOGAF Phase C has two halves. The Data Architecture defines what information the system stores, where it comes from, and how it flows. The Application Architecture defines what software components exist, what each one does, and how they interact.
Most enterprise systems treat these as separate concerns. V.E.R.A. cannot afford to. The entire point of the system is that data integrity drives application behaviour. If the E! Corpus says an entity does not exist, the application layer must refuse to predicate about it. Data and application are not peers in V.E.R.A. Data is the authority. Applications obey.
This is the Existence-Predication Independence principle, implemented as information systems architecture.
The Data Architecture: Where Verified Reality Lives
The E! Corpus is V.E.R.A.'s foundational truth layer. It is not a knowledge graph in the conventional sense. It is an existence registry with full provenance tracking, designed so that every claim about what is real can be traced to a cited source.
The data model consists of five interconnected schemas:
| Schema | Key Fields | Purpose |
|---|---|---|
| Entity | canonical_name, existence_status, entity_type, confidence | The core registry. Every entity has one of three statuses: EXISTS, NOT_EXISTS, or UNKNOWN. |
| Property | property_name, property_value, provenance_id, valid_from/to | Predicative information (ℳ) about entities. Per NTP Rule R1, properties are only meaningful when attached to entities with verified existence. |
| Provenance | source_type, source_url, reliability_score, verification_method | Every existence claim must be traceable to its source. No provenance, no existence status. Non-negotiable. |
| Alias | alias_name, alias_type, language | Supports the D-Service identity resolution. "Albert Einstein", "A. Einstein", and "Альберт Эйнштейн" must all resolve to the same entity. |
| Identity Relation | entity_a_id, entity_b_id, relation_type, ntp_relation | Stores the results of D-Service evaluations using all four NTP indiscernibility relations (D1-D4). |
The schema enforces a rule that most AI systems ignore entirely: you cannot store a property without proving the entity exists first. The Property table has a foreign key to the Entity table, and the Entity table requires a foreign key to at least one Provenance record before an EXISTS status can be assigned.
This is not a design choice. It is Principle 2 (Evidence-Based Existence) expressed as a database constraint.
Eight Entity Types: The Ontological Taxonomy
Every entity in the E! Corpus is classified into one of eight types. The classification matters because it determines how the system handles existence verification and property queries:
| Type | Examples | Default E! Status | Predication Allowed? |
|---|---|---|---|
| PERSON | Albert Einstein, Marie Curie | EXISTS | Yes, with provenance |
| PLACE | Paris, Mount Everest | EXISTS | Yes, with provenance |
| ORGANISATION | Google, United Nations | EXISTS | Yes, with provenance |
| EVENT | World War II, Moon Landing | EXISTS | Yes, with provenance |
| THING | Eiffel Tower, iPhone | EXISTS | Yes, with provenance |
| CONCEPT | Democracy, Gravity | EXISTS | Yes, with provenance |
| FICTIONAL | Unicorn, Sherlock Holmes | NOT_EXISTS | Yes (n-type only; no reality claims) |
| MYTHOLOGICAL | Zeus, Thor | NOT_EXISTS | Yes (n-type only; no reality claims) |
The last two rows are where NTP's elegance becomes visible.
Standard AI systems either refuse to discuss fictional entities or happily hallucinate about them as if they were real. V.E.R.A. does neither. It retains FICTIONAL and MYTHOLOGICAL entities with a NOT_EXISTS status, allowing predication ("Sherlock Holmes is a detective" is a valid n-type statement) while blocking existence claims ("Sherlock Holmes published a paper in 2024" triggers an immediate refusal). The maths handles both cases cleanly because NTP was designed for exactly this distinction.
The Wikidata Pipeline: Seeding the Corpus
A data model without data is a filing cabinet without files. For the MVP, the E! Corpus will be seeded from Wikidata, the structured knowledge base behind Wikipedia. Wikidata provides exactly what V.E.R.A. needs: entities with unique identifiers (Q-codes), structured property claims, and cited sources.
The ETL (Extract, Transform, Load) pipeline maps Wikidata fields to V.E.R.A.'s schema:
| E! Corpus Field | Wikidata Source | Example |
|---|---|---|
| canonical_name | rdfs:label (English) | "Albert Einstein" |
| entity_type | P31 (instance of) mapped to taxonomy | Q5 → PERSON |
| existence_status | Derived: real entities → EXISTS; fictional → NOT_EXISTS | Q937 → EXISTS |
| wikidata_qid | Q identifier | Q42 (Douglas Adams) |
| provenance | Source citations + retrieval timestamp | wikidata.org/wiki/Q937, retrieved 2026-02-28 |
The pipeline also maps Wikidata's P31 ("instance of") property to our eight entity types. A Wikidata item classified as Q5 (human) becomes PERSON. Q515 (city) becomes PLACE. Q1190554 (fictional character) becomes FICTIONAL. The mapping is deterministic: no machine learning, no probabilistic classification. An entity's type is derived from its structured metadata, not guessed from context.
For the MVP, we are targeting an initial corpus of approximately one million entities. That is enough to demonstrate the verification pipeline on general knowledge queries while keeping the database small enough to run on a single machine.
The Application Architecture: Seven APIs, One Pipeline
In Phase B, we specified seven interfaces (IF-001 through IF-007). Phase C turns those specifications into concrete application components with defined API contracts, request/response schemas, and failure modes.
Here is the complete interface catalogue with its Phase C implementation:
| ID | Interface | Technology | Contract Summary |
|---|---|---|---|
| IF-001 | User Query Interface | FastAPI REST | POST /api/v1/query → verified answer + reasoning chain + provenance. SLA: < 5 seconds. |
| IF-002 | E! Corpus API | FastAPI REST | GET /api/v1/exists/{entity} → ExistenceResult (status, confidence, provenance). SLA: < 200ms. |
| IF-003 | Krampitz Analyzer API | FastAPI REST | POST /api/v1/krampitz/analyze → KrampitzResult (e/n characteristic, rule chain). SLA: < 100ms. |
| IF-004 | D-Service API | FastAPI REST | POST /api/v1/identity/resolve → IdentityResult (D1-D4 relation, confidence). SLA: < 1 second. |
| IF-005 | Claude API Integration | Anthropic SDK | NTP-constrained prompting with pre/post verification. Pause-and-verify on every claim. |
| IF-006 | Wikidata API | SPARQL + REST | ETL pipeline: extract entities, map to E! schema, load with provenance. Batch and incremental. |
| IF-007 | Audit Log Interface | Structured JSON | Complete reasoning chain for every transaction. Immutable append-only store. |
Every interface uses the same error handling pattern. If a call fails, the pipeline does not guess, retry with weaker constraints, or fall back to unverified output. It returns a structured error with a specific failure code. Fail-safe refusal is not just a principle; it is the default behaviour of every API in the system.
The Ten-Step Pipeline: From Question to Verified Answer
The heart of V.E.R.A.'s application architecture is the query processing pipeline. Every natural language question follows the same deterministic path through ten steps. There are no shortcuts, no fast paths, no optimistic assumptions.
| Step | Component | Action | If It Fails |
|---|---|---|---|
| 1 | API Gateway | Validate request structure | Reject malformed request with HTTP 400 |
| 2 | Safety Interceptor | Scan for crisis indicators and PII | Route to human-in-the-loop or anonymise |
| 3 | Query Parser | Convert natural language to NTP formula | Return parsing error to user |
| 4 | Krampitz Analyzer | Determine existential loading (e or n) | Flag ambiguous formulas for review |
| 5 | E! Verification | Check entity existence in corpus | Block predication if ~E! (does not exist) |
| 6 | D-Service | Resolve identity using D1-D4 | Return UNKNOWN if unresolvable |
| 7 | LLM Wrapper | Generate response with NTP constraints | Timeout or quality failure → retry once |
| 8 | Response Validator | Re-check all claims against E! Corpus | Strip unverified assertions from output |
| 9 | Audit Logger | Record complete reasoning chain | Alert on logging failure; never suppress |
| 10 | Response Formatter | Structure response with provenance links | Return verified response to user |
Notice the fourth column. Every step has a defined failure mode, and every failure mode defaults to caution. Step 5 does not return "probably exists". It returns EXISTS, NOT_EXISTS, or UNKNOWN. Step 8 does not flag unverified claims for the user to sort out. It strips them. The pipeline assumes the worst and proves the best.
This is the architectural expression of what Wessel's NTP gives us: a system where the absence of evidence is treated as evidence of absence from the corpus, triggering qualification or refusal rather than invention.
The Safety Interceptor: Before Logic, Humanity
Step 2 in the pipeline deserves its own section. The Safety Interceptor sits between the API Gateway and the NTP engine. It performs three functions that have nothing to do with logic and everything to do with responsibility.
Crisis Detection identifies prompts that require immediate human escalation. If a user's query triggers crisis indicators (self-harm language, financial distress patterns, phrases suggesting immediate danger), the system routes to a human-in-the-loop queue before any NTP processing occurs. False positives mean a human reviews a benign query. False negatives could mean real harm. The system is calibrated accordingly.
PII Anonymisation strips personally identifiable information before any data reaches the LLM. Names, addresses, identification numbers, financial details: all are tokenised with session-scoped replacements. The LLM never sees real PII. The response is de-tokenised on the way out, so the user sees their original context, but the language model never does.
Content Classification routes queries to appropriate verification paths. A medical query gets different handling from a historical query. An identity question ("who is this person?") routes through the D-Service with extra care. Classification is rule-based and auditable, not probabilistic.
V.E.R.A. was designed to stop hallucinations. But a system that stops hallucinations while ignoring human welfare has missed the point entirely. The Safety Interceptor ensures that before V.E.R.A. applies formal logic, it first checks whether formal logic is what the moment requires.
What We Have Already Built
Phase C is not purely theoretical. Two of V.E.R.A.'s core components already exist as working Python code, tested and passing:
| Component | Test Status | What It Does |
|---|---|---|
| Krampitz Load Analyzer | All tests passing | Implements Rules R1-R9 from Wessel (1992). Accepts an NTP formula, returns its existential characteristic (e or n) with the complete rule chain that produced the result. |
| Formula Parser | 15 tests passing | Converts natural language statements into NTP formula notation. Handles negation (inner and outer), conjunction, disjunction, implication, and existential quantification. |
These are not prototypes. They are the implementations of IF-003 (Krampitz Analyzer API) and the front end of the query processing pipeline. When we wrap them in FastAPI endpoints, they become the live services described in this Phase C architecture.
The next components to build are the E! Corpus database (SQLite for MVP, PostgreSQL for production), the Wikidata ETL pipeline, and the E! Verification Service (IF-002). These three together form the existence layer: the part of the system that knows what is real.
The LLM Integration Pattern: Constrained Generation
V.E.R.A. does not replace the language model. It wraps it. The Claude API integration (IF-005) follows a five-step pattern that is fundamentally different from how most AI applications use LLMs:
Step 1: Pre-process. Run the user's query through Layers 1 to 3 (Krampitz, E! Verification, D-Service). Determine which entities exist, which do not, and which are unknown.
Step 2: Inject. Add the verification results to the system prompt. The LLM receives explicit instructions: these entities are verified; these are not; never assert existence for unverified entities.
Step 3: Call. Send the constrained prompt to the Claude API.
Step 4: Post-verify. Parse the LLM's response. Extract every entity reference. Re-check each one against the E! Corpus. If the LLM introduced an entity that was not in the verified set, flag it.
Step 5: Deliver. Return the validated response with provenance links, or return a qualified response with unverified claims stripped.
The critical insight is Steps 4 and 5. Most AI wrappers trust the LLM to follow instructions. V.E.R.A. does not. It verifies that the LLM followed instructions by running a second existence check on the output. Trust but verify is not just a slogan. It is Step 8 in the pipeline.
The Audit Trail: Every Reasoning Step, Every Time
The Audit Log Interface (IF-007) records every step of every transaction in an immutable, append-only store. For a single query, the audit trail captures: the original query, the parsed NTP formula, the Krampitz analysis result with the full rule chain, every E! Corpus lookup with the existence result, every D-Service evaluation, the LLM prompt (with NTP constraints), the raw LLM response, the post-verification results, and the final delivered response.
This is not optional. In regulated industries (finance, healthcare, government), you cannot deploy an AI system without being able to explain why it said what it said. V.E.R.A.'s audit trail does not summarise. It records. When a regulator asks "why did your system assert that this drug interaction exists?", V.E.R.A. can produce the complete chain: the entity was verified in the E! Corpus (source: Wikidata Q-code, retrieved on this date), the Krampitz Analyzer classified the statement as e-type (Rule R1), the E! Verification Service confirmed existence (confidence 0.97), and the post-verification check confirmed the LLM's claim matched the corpus.
That is not a log. That is a proof.
The Six-Layer Architecture, Made Concrete
In Episode 4, we previewed a five-layer technical architecture. Phase C refines this to six layers with specific technology choices for the MVP:
| Layer | Component | MVP Technology | Safety Function |
|---|---|---|---|
| L1: Edge | API Gateway | FastAPI + rate limiter | Input validation, attack prevention |
| L2: Safety | Safety Interceptor | Python + rule engine | Crisis detection, PII anonymisation |
| L3: Logic | NTP Engine | Krampitz Analyzer + E! Service + D-Service (Python) | Existential verification, identity resolution |
| L4: LLM | LLM Wrapper | Anthropic Claude API | Constrained generation with NTP rules |
| L5: Data | E! Corpus + Audit | SQLite (MVP) → PostgreSQL | Verified existence, complete audit trail |
| L6: Infra | Deployment | Local (GeForce 4080 Super) | Data sovereignty, network isolation |
The technology choices are deliberate. SQLite for the MVP because it requires zero infrastructure and runs on a single machine. FastAPI because it generates OpenAPI documentation automatically (satisfying requirement DOC-004). Python throughout because our working code is already in Python and our "vibe coding" approach with Claude works best in Python.
Nothing in this architecture is exotic. That is the point. V.E.R.A.'s innovation is not in the technology stack. It is in the logic layer. The NTP rules are the differentiator. Everything else is proven, boring, reliable engineering. Boring is a feature when you are building trust infrastructure.
What Comes Next
In Episode 6, we will enter Phase D: the Technology Architecture. This is where deployment topology, infrastructure provisioning, and performance engineering take centre stage. How does V.E.R.A. scale? How does it handle concurrent verification requests? What does the monitoring and alerting stack look like?
We are also approaching the point where architecture meets implementation. The Krampitz Analyzer and Formula Parser already work. The E! Corpus schema is defined. The API contracts are specified. The next step is wiring them together and running the first end-to-end verified query.
We are building in the open. All Phase B artifacts, plus the Phase C/D Architecture Definition Document, 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:
- Python developers to help build the E! Verification Service, D-Service, and Wikidata ETL pipeline
- Data architects to refine the E! Corpus schema and design the production migration from SQLite to PostgreSQL
- Logicians to validate our NTP implementation against the hexadecagon structure
- API engineers experienced with FastAPI to help design the production API layer
- 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.
What part of V.E.R.A.'s architecture would you build first? If you had the E! Corpus, the Krampitz Analyzer, and the API contracts in front of you, which piece would you wire up on day one, and why?
Next week in Episode 6: Phase D takes V.E.R.A. from architecture to infrastructure. Deployment topology, performance engineering, and the monitoring stack that keeps verified reasoning honest.
Ita est momentum veritatis. So it is, the importance of truth.
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.
Published: 28 February 2026© Andreas Hamberger 2026. All rights reserved.
References
[1] Wessel, H. (1992). "Existenz, Ununterscheidbarkeit, Identität." Humboldt University, Berlin. Primary source for NTP Rules R1-R9, Indiscernibility Relations D1-D4, and Metatheorems MT1-MT3.
[2] V.E.R.A. Architecture Documentation Suite (2026). Phase B artifacts: Requirements Catalogue (98 requirements), Capability Model, Service Catalog, Interface Specifications (IF-001 through IF-007). Available: https://github.com/andreas-linux/vera/
[3] Wikidata. Structured knowledge base. Seed source for E! Corpus MVP. https://www.wikidata.org/
[4] FastAPI documentation. https://fastapi.tiangolo.com/
[5] Anthropic Claude API documentation. https://docs.anthropic.com/