Reference architecture · the Meaning Operating System
One architecture that carries evidence through identity and meaning to a decision someone can warrant.
Two storage legs, a lakehouse for evidence and a lakebase for action, are joined by metadata-driven master data. A shared semantic layer gives every number one meaning. A sovereign logic engine decides on that meaning, and a ledger records what was decided, on what evidence, and what was given up.
Evidence rises from the lakehouse, gains identity in master data and meaning in the semantic layer, and meets intent at judgement. Action runs on the lakebase, and its outcomes return to accountability.
The Spine is a portable core that carries an organisation from raw evidence, through identity and meaning, through adaptation to the situation at hand, to a solved and explained decision, bounded in execution and returned to strategy as correction.
| Plane | The question it answers | Rate of change |
|---|---|---|
| L0 Strategy Intent | What are we trying to achieve, and what will we not do? | Quarterly to annual |
| L1 Evidence | What arrived, and what did it become? | Continuous append |
| L2 Identity | Who and what is this about? | Continuous, reversible |
| L3 Meaning | What do these things mean, and how are they computed? | Slow, by deliberation only |
| L4 Adaptation | What applies here, now, to this case, and has the world moved? | Fast: the only fast plane |
| L5 Judgement | What is the best feasible decision, and what does it cost? | Per decision, generated |
| L6 Foresight | What might happen, and what if we chose otherwise? | Per query, over the same IR |
| L7 Execution & Feedback | What was done, within what bounds, and what actually happened? | Continuous |
Evidence rises and gains identity, then meaning. Intent descends and gains constraint. They meet at Adaptation, which fits both to the present case and hands a situated program to Judgement. Three planes are slow, one is fast, and the fast one is isolated, so change has somewhere legitimate to live. The storage engines beneath are stubs; the core between them is what Ingqiqo owns.
The lakehouse holds what happened. The lakebase holds what is being done. Master data is the bridge, so both legs agree on who and what every record is about.
DuckLake as catalog and table format, with snapshots and time travel. Organised as a data mesh: each domain, modelled with domain-driven design, owns its slice from Bronze to Gold. A logical data fabric virtualises access across domains without copying data.
Multi-domain mastering of party, employment, location, asset, contract and product. Match rules are generated from the ontology, not hand-coded: Zingg resolves entities and feeds AtroCore. Identity is held as a registry; attributes are read from the source of record.
Postgres as the operational store for applications, the decision ledger and workflow state. Polars works the frames on the application side, and apps follow the open Databricks Apps pattern. Row-level security and point-in-time restore are part of the port, not optional extras.
One rule keeps the legs honest: a live, virtualised read may serve an application, but it may never enter a decision. Anything a decision rests on is first snapshotted and hashed.
Three tiers, each with one job. History is never overwritten, and every interpretation can be argued with and re-derived.
Gold is compiled, never hand-written. The moment a second representation of the same truth is written by hand, many shapes become many truths.
Every tool answers one question. Where two could answer the same one, one is authoritative and the other is a cache.
| Job | Tools |
|---|---|
| Ingestion and reverse ETL | dlt, Airbyte, DuckDB |
| Streaming | Arroyo |
| Documents | Unstructured.io for document ETL |
| Transformation | dbt on DuckDB, with Polars inside Python steps |
| Profiling and quality | YData Profiling, Soda Core |
| Data contracts | Open Data Contract Standard (Bitol) |
| Validation and testing | Pydantic v2, pytest |
| Error tracking | Errbit |
| Master data | Zingg, AtroCore |
| Format interoperability | Apache XTable, so other engines can read the lakehouse metadata |
| Lineage and catalog | DataHub with OpenLineage |
| Business rules and specifications | GoRules, OpenSpec, SpecMaster |
| Code knowledge | GitNexus |
| Policy, privacy and runtime security | OPA, Microsoft Presidio, Cilium, Themis |
| Language models and retrieval | LangChain, LangFlow, RAGFlow, with Langfuse for tracing |
| Reporting | HTML dashboard reports from the semantic layer |
DuckDB and Polars share one semantic layer, so a metric means the same thing in SQL and in code. On it, nineteen models are given life, grouped by the question each family answers.
Terminology · Taxonomy · Ontological · Semantic · Meaning · Context
Data · Process · Application · Business Rule
Cognitive · Memory · Evaluation
Decision · Outcome · Coherence
Motive · Ownership · Institutional Architecture
Meaning changes slowly and by deliberation. Situational variation lives in a separate adaptation step that binds general definitions to this case, this season and this regime, so the ontology never sprouts variants.
Every decision is compiled into one typed, content-addressed program: the Decision IR. Strategy, ontology terms, mastered identities, business rules and evidence all compile into it, and nothing bypasses it.
Tabular in-context-learning models (TabDPT-Turbo and TabICLv2) and Laya, an open-source model, make the platform useful from week one on a client's modest data. They also change what the data, the AI and the decisions owe each other.
In context learning, the client's rows are the prompt. Membership is not inferred; it is read. Entitlement therefore filters the context before it is assembled, never the answer after. Context rows, their order and the decoding policy are pinned in the evidence manifest so results replay.
The neural proposes; the symbolic disposes. No model asserts a constraint, sets a weight or emits a decision. Laya is open source, so it runs inside the client’s own boundary, where its weights can be inspected and its runs pinned, and nothing leaves the jurisdiction. Behavioural parameters are declared, versioned and switchable, never hidden in the interface.
These models are correlational. They estimate what tends to happen, not what happens if we intervene. Every IR variable carries an endogenous flag, and binding a correlational estimate to a decision variable is a compile-time error. Outputs are distributions, and the uncertainty survives into the solver.
For sweeps that would fire thousands of predictions, the ICL model teaches a cheap deterministic surrogate that runs the inner loop, which also restores determinism where the solver needs it. Model versions named here are checked against current published benchmarks before any design is frozen.
A good outcome is not a good decision. Outcomes are assessed against what drove the decision, who owned it, and the institution it was made inside.
Findings climb a fixed ladder (flag, anomaly, investigation, finding, attribution, culpability) and describe machinery, not intent. Three assurance axes, decision integrity, decision validity and attribution integrity, are reported side by side and never collapsed into one score.
The warranty promises process fidelity, not good outcomes: that a decision was made as specified, on the evidence recorded, by the authority named. It is a contractual warranty on the service, not insurance.
The Decision IR, its evidence hash and its relaxation set, checked against the four assurance disciplines: integrity, validity, conscience and optimisation. A companion Agency Warranty covers the actors who carry the decision out.
Every warranted decision is written to a hash-chained ledger and signed. The Intrinsic Coverage Instrument records whether the design covered what motivates the people it affects, and flags an exception where it did not.
Liability caps and a written claims procedure, an ISO 27001-aligned security programme, professional indemnity and cyber cover, and a legal opinion on the structure. Where risk transfer is wanted, a licensed insurer underwrites and the ledger supplies the evidence.
One policy language, one decision point, many enforcement points. Policy is written once in OPA and projected into every engine, because hand-granting access in five places is how the fifth goes wrong.
| Question | Where it is answered |
|---|---|
| How sensitive is this? | Classification and tags per column in the data contract |
| Where is personal information? | Presidio at ingestion, before Silver |
| Who are you, and may you do this? | Single identity provider with MFA; OPA evaluates role and attribute together |
| Who holds which grant, why, until when? | The entitlement register, reviewed quarterly |
| Which rows may you see? | Row-level security in Postgres; per-tenant views in the lakehouse |
| Can identifiers be reversed? | Keyed HMAC-SHA3, never plain hashes; the re-identification crosswalk stays in South Africa |
| Can the network be trusted? | Cilium policy between workloads; an egress allowlist for external services |
| Can data be retired? | Per-client keys: destroying the key retires the data, even inside history |
The boundary filters what enters, never what leaves: the context before the model, the IR before the solver, the join before the query. When an obligation cannot be met, a structured refusal is a permitted answer. Automated decisions about people keep a human review and a route for representations, as POPIA section 71 requires.
Quantum computing threatens today's signatures, not the hash chain. The ledger is built to the NIST post-quantum standards now, and keeps a seam open for quantum solvers later.
Rules that hold regardless of vendor, client or phase. A design that breaks one is wrong even when it works.
It is built to run inside your own boundary, on open tooling you own, with people deciding at every point that matters. I will tell you plainly which planes you need first and which you can leave for later.