The reference shelf.

Technical brief: the architectural choices that are hard to change later

Who it is for: An evaluating architect with a specific system estate in mind.

The brief begins with the foundational decisions in the data platform: ontology-grounded retrieval, open columnar storage, standard Kubernetes instead of a provider-specific service, inference on local models, integrated cataloguing and quality, and the patented method for querying a program as though it were a table. It then gives a reference architecture from sources to consumers, an integration approach for each class of system, and ingestion patterns chosen object by object, with the operating cost of each. Change data capture, for example, carries the highest overhead and is used only where currency changes a decision. It continues into governed agents, controls, deployment and patterns by solution family. It answers how this would connect to your estate and what you would have to operate.

Data and AI capability reference: the grounding question, with its limits stated

Who it is for: Architects, data leaders and security reviewers working to an evaluation checklist.

A longer reference in parts, covering the data layer, the AI layer, governed agents, and deployment and security. Its centre is one question to put to any vendor: is the system answering from a copy of your data, or from your data? It compares chunk-and-embed retrieval with an ontology over live records. It is careful about its own claim. Some sources are landed for performance with lineage attached, the source always remains the authority, and vector retrieval keeps its place over unstructured text. It lists stated boundaries, including that no agent grants or denies an entitlement and that screen automation is a bridge and not a permanent design. It ends with what we would need from you to assess your environment.

What's inside:

• The argument in one page: most enterprise AI stalls on readiness, not model quality — and the two halves that have to be worked together.
• The grounding question to put to any vendor — is the system answering from a copy of your data, or from your data? — with chunk-and-embed retrieval compared honestly against an ontology over live records.
• The data layer, the AI layer, governed agents, and deployment and security, each in its own part.
• The stated boundaries: sources landed for performance keep lineage and the source remains the authority; vector retrieval keeps its place over unstructured text; no agent grants or denies an entitlement; screen automation is a bridge, not a design.
• What we would need from you to assess your environment, listed concretely.

Get a copy: Ask us for EF-06 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

The Mnemos platform: governance built once, inherited by everything we make

Who it is for: An architect who wants to know what our own products will stand on, and why it is not sold on its own.

Mnemos is the layer that makes a product governed by construction rather than by policy document. It holds what the organisation knows, decides whether an answer may be given at all, registers agents as principals alongside people, gates execution, keeps a record that can be added to but not quietly altered, and routes work to the smallest model that will do it. Every product we build inherits all of that the day it is created. The document is plain about status: Mnemos is in development and is not sold on its own, and everything we deliver commercially today runs on the two production platforms. Read it to see where we are going, not to buy it today.

What's inside:

• What the layer holds and does: what the organisation knows, whether an answer may be given at all, agents registered as principals alongside people, execution gating, a record that can be added to but not quietly altered, and routing to the smallest model that will do the job.
• Why every product we build inherits all of that the day it is created — governance by construction rather than by policy document.
• The product family that stands on it, and the status stated plainly: in development, not sold on its own, with everything we deliver commercially today running on the two production platforms.

Get a copy: Ask us for EF-07 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

Agent-native, not agent-added: what must exist before an agent can be held responsible

Who it is for: A platform lead or architect designing for agents from more than one vendor.

A design note on why identity, authority, boundary and record must exist in the substrate before an agent can own a task, and why they cannot be bolted onto software built for people. It explains autonomy by action class, using Auto, Approve and Advise, agreed before anything is built and enforced on the decision path and not at the front door, since scheduled jobs and background processes never use the front door. It describes the lifecycle of a governed agent, from configuration through evaluation, running, record and review, and the problem of governing agents you did not build. It includes a diagnostic you can apply to any proposal: count how many use cases sit in each gate.

Sovereign AI: what changes when nothing can leave

Who it is for: Architects and risk owners whose residency or classification rules remove the default shortlist.

The document explains why sovereign deployments so often disappoint: the diminished edition, intelligence that is still hosted somewhere else, dependence on a managed service, governance held in the vendor's control plane, and an air gap that is not disconnected. It shows how one codebase serves on premises, private cloud, public cloud, air-gapped and federated deployments. It sets out how a model is chosen, as the smallest one that passes your own evaluation on a licence your lawyers have read, and how federation gives a group view without gathering data in one place. It closes with questions to put to any vendor, which we will answer on the record.

What's inside:

• The position most organisations are actually in — the default shortlist is already unavailable, and that is usually discovered late and expensively.
• The five failure patterns: the diminished edition, intelligence still hosted elsewhere, the managed-service dependency, governance in the vendor's control plane, and the air gap that is not disconnected.
• One codebase across five topologies: on premises, private cloud, public cloud, air-gapped and federated.
• How a model is chosen — the smallest one that passes your own evaluation, on a licence your lawyers have read — and how federation gives a group view without gathering data in one place.
• The questions to put to any vendor, which we will answer on the record ourselves.

Get a copy: Ask us for EF-09 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

Migration assurance: proving the target equals the source on live data

Who it is for: Architects and programme leads on an ERP, core banking, CRM or cloud migration.

A design note on a narrow use. Reconciliation and parallel running are among the most resource-intensive and least automated parts of a migration, and risk concentrates at cutover. The pattern reads legacy and target estates where they sit, unchanged, and runs one query across both, so balances, documents, master data and volumes are reconciled side by side on live data and not on sampled extracts. The note covers what happens during the programme and what you keep afterwards, including access to legacy history without running the legacy system. It states what it requires: read-only access to both estates, reconciliation rules for each wave and a mapping between structures. Neither system is changed.

Token optimisation without the marketing: the levers on inference cost, and where each does nothing

Who it is for: Platform leads and finance partners who own an inference bill.

A note on the levers that reduce inference cost. Send less, choose a smaller model where it will do, reuse repeated work, and refuse work with a budget that can decline. For each lever it says which workloads it helps and which it does nothing for. A single large retrieval request, for instance, gains nothing from compressing history, and the boundary for choosing a smaller model is currently set by hand from experience and not learned. It explains why all of them need one controlled path for AI traffic, and it ends with questions to put to anyone's cost claim, ours included. It offers no savings percentages, and it says why.

Service offerings: what each way of working includes, what we need and what you keep

Who it is for: Sponsors and procurement leads comparing ways to start.

The reference for how we engage. For each offering it states the shape, who it suits, what is included, what we need from you and what you receive. The offerings are discovery and assessment, professional services, proof of concept, Innovation as a Service and AI as a Service. It explains the cycle of frame, build, realise and scale, and when each engagement model fits, including why outcome-linked pricing needs a reliable baseline and when we will tell you it is the wrong model. It carries short answers on where to start, how long it takes, what it costs and who owns what is built. It answers what exactly you are buying, and what you owe in return.

What's inside:

• Five offerings, one fabric — proof of concept, discovery and assessment, professional services, innovation as a service, and AI as a service. They are not a sales funnel with stages; they are shapes of help that combine freely, and the combination is yours to choose.
• What you are buying — in every case, a business question answered, not a platform. The document states it in one line each: what the offering is for, what it includes, what it needs from you, and what you receive at the end.
• The cycle behind them — every engagement moves through the same frame, build, realise, scale cycle, so a discovery that finds a live question can become a proof, and a proven answer can become a platform, without re-explaining the problem at each step.
• The economics of the second question — once a governed foundation exists, the next question costs a fraction of the first. The document makes this explicit, because it is the entire commercial argument for doing the work in this order.

Get a copy: Ask us for EF-03 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

Start a conversation: how a proof of concept is agreed, run and judged

Who it is for: A sponsor who wants to test an idea against real data before committing budget.

It begins with why most proofs of concept fail: no agreed success criterion, and no sponsor able to accept the result. It then sets out the steps. Agree the question precisely enough that two people would recognise the same answer. Agree success in writing, including what counts as a partial result and who decides. Agree the boundary. Build against real data, not a tidied sample. Receive a written verdict. For regulated readers the boundary is the important part: read-only access, nothing leaving your environment, nothing written back, in the topology you need, including air-gapped. It states that a verdict to stop is a legitimate outcome.

What's inside:

• Why proofs of concept fail — two causes, named without varnish: no agreed criterion for success, and no sponsor who can act on the answer. The document exists to fix both before anything is built.
• The five steps — agree the question; agree what success looks like, in writing, including what a partial result means and who decides; agree the boundary; build against real data; deliver a written verdict. Each step is a page, and none can be skipped.
• The boundary for regulated data — what we will and will not do inside your estate: read-only access, nothing leaves, air-gapped acceptable, and the test data belongs to you.
• The verdict — the proof ends with a written answer to the question it started with, including when the answer is no. A clear no, early and in writing, is a success this document claims credit for.

Get a copy: Ask us for EF-05 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

Professional services: named specialists who build, with a handover written before the work starts

Who it is for: Delivery leads and heads of function with a stalled initiative, or a question they cannot yet specify.

This document describes the roles we place inside your team: forward deployed engineer, AI specialist, data specialist, solution architect and, for a pod, a delivery lead. It states what each owns, such as identifier continuity and entity resolution for the data specialist, or action-gate mapping and refusal behaviour for the AI specialist. It explains the method. The first week goes on the business and not on software, a written transfer plan exists from day one, and the engagement closes with a recommendation that may be to stop. It lists when to use the service and what you must provide, including access to the people who do the work and not only to their managers.

What's inside:

• The five roles — forward-deployed engineer, AI specialist, data specialist, solution architect, and delivery lead. Each is described by what they are accountable for, not by a job title: the forward-deployed engineer owns the working outcome end to end, and the others own grounding, reachability, topology, and cadence respectively.
• Practitioners, not consultants — the people who scope the work are the people who build it. The document is blunt about what that means: no handover between a sales team and a delivery team, and no advice that its author does not stay to implement.
• The first week — the document commits to it in writing: the first week is spent on the business, not the infrastructure — who decides, who is affected, what the work is judged against. Architecture follows the answer, never the other way round.
• The transfer plan — the engagement is designed to end. A written transfer plan exists from day one, and the closing recommendation may be that you should stop — the document says so, and means it.

Get a copy: Ask us for EF-04 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

Innovation as a Service: how value is tied to one question at a time

Who it is for: Finance and strategy leads who must justify an investment in terms their board already uses.

The brief sets out a repeating cycle in which each investment is tied to a defined question, an accountable sponsor and a reference measure. It describes the service lines, from framing a question to sustaining what was built, and says which engagement model fits which situation. Its treatment of value is unusual. It lists the levers, such as recovery and scrap, claim evidence, inventory and receivables, spend consolidation and report assembly effort, and says where each lands in the accounts. It publishes no percentages, and it names the sources of value we cannot quantify. It also lists what makes an opportunity progress: a defined question, an owner, a reference point and accessible data.

Our product line: which products exist, at what stage, and what you can rely on today

Who it is for: Anyone reading a proposal that mentions our own products.

The document lists our own products by name with their real status, and states plainly that none is generally available. Everything we deliver commercially today runs on ZigmaData and on Kyros, powered by Kaman, both in production. The products stand on Mnemos, our governance layer, which is in development and is not sold on its own. The document defines each status term, so a reader can tell in development from on the roadmap, and it keeps the production platforms and our own products apart inside proposals. Use it as a check. When a proposal names a product, find it here and see what stage it has reached before you rely on it.

What's inside:

• Nine products, one platform — the full line, each by name: what it does, the problem it exists for, and how it relates to Mnemos. The catalogue covers grounding and provenance, agents and orchestration, evaluation, and regulated deployment patterns.
• Status, stated plainly — each product carries one of three labels with definitions that mean what they say: private beta, in development, on roadmap. A beta is running with design partners; a roadmap entry is a direction, not a date.
• Why we publish this — a client evaluating a proposal is entitled to know which part of it is proven and which part is planned. This document exists so that distinction is never a surprise discovered after signature.
• Production platforms versus our own products — production platforms we are accountable for are kept strictly separate from the EigenForge product line, including inside proposals. The document explains the separation and how to verify it.

Get a copy: Ask us for EF-08 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

Partner pack: for integrators, advisory firms and technology partners

Who it is for: A systems integrator, advisory firm, technology partner or reseller weighing up working alongside us.

The pack states the partnering position plainly. We do not compete for the programme — we take a specific, bounded problem inside it, do that well, and hand the relationship back. Reconciliation, parallel running and cutover evidence are where programme risk concentrates and effort is least automated, and that is our most natural point of entry alongside an integrator. What we leave behind — a governed layer over the client's estate — is the foundation for follow-on analytics, reporting and AI work that the partner can deliver. One deployment story covers the whole client base, from air-gapped to cloud-first, and there is no lock-in argument to defend because systems of record are read-only and storage formats are open.

What's inside:

• Who it is for — systems integrators, advisory firms, technology partners, and resellers. Each gets a section on what the partnership looks like from their side of the table, not from ours.
• The division of the room — we do not compete with partners for the programme. The document states our entry points plainly: reconciliation, parallel running, cutover evidence — the bounded problems where governed AI pays for itself, inside transformations the partner leads.
• What we leave behind — every engagement leaves artefacts the partner owns: the evaluation harness, the provenance chain, the control configuration. Follow-on work goes to the partner by design, not by accident.
• One story, every client — the partner learns the deployment story once and it holds across their whole client base, because the same five topologies cover every estate from one codebase.
• No lock-in to defend — systems of record are read-only and storage formats are open, so a partner never has to argue around our contract to serve their client. The document puts this in writing.

Get a copy: Ask us for EF-10 — documents go out personally, case by case, and we will say so if a different one fits your situation better.

Cost per answered question: the unit that makes any two quotes comparable

Who it is for: Procurement and finance leads comparing AI quotes priced in different units.

The module shows why price per token, per seat and per query cannot be compared directly. It proposes one measure: the total cost of running the system for a period, divided by the number of questions that received a correct answer someone used. It lists the components that budgets omit, including retrieval and indexing, the data platform, hosting for local models, evaluation and human review, and refusals and retries. It explains why agents change the arithmetic, and why a local model carries a largely fixed cost that favours high utilisation. You can apply the measure to any vendor's quote, ours included. Its exercise is to divide last month's spend on one use case by a reviewed sample of correct, used answers.