Domain Axioms: Why We Start From Your Field, Not Our Tool

Before we write a line of code, we write down how you think. The document we produce is not a requirements list — it is a model of your domain's reasoning structure. This is what the system is built against.

The problem with building for the average

General-purpose AI is built to work reasonably well across the widest possible range of tasks. That is its design goal — and it achieves it. A general-purpose system can draft an email, summarise a document, or answer a factual question with competence.

What it cannot do is reason about your specific domain. It does not know that a Korean court distinguishes between uijang and gamuijangin precedent interpretation. It does not know that your lab protocol for tissue preparation has a specific exception when working with samples under 48 hours post-mortem. It does not know that your institution's evaluation rubrics treat “policy relevance” differently from “academic rigour.”

These distinctions are not edge cases. They are the substance of professional expertise. An AI system that does not understand them cannot be trusted with professional work.

What axioms are — and what they are not

We use the word “axioms” deliberately. In geometry, an axiom is a statement taken as self-evidently true — from which everything else follows. Domain axioms are the same kind of thing: the foundational rules of your field that practitioners apply without thinking, because they are so fundamental they are rarely written down.

They are not user stories. Not feature requests. Not a list of what the system should be able to do. They are the reasoning structure that sits beneath those requests — the logic that makes one output acceptable and another one wrong in ways that only a domain expert would notice.

A senior attorney, asked to review a first-draft case memo, evaluates it against a set of implicit standards: issue framing, precedent mapping, logical sequencing of argument, appropriate hedging on contested statutory interpretation. These standards are not in any manual. They live in the practitioner. Domain axioms are our attempt to make them explicit.

How we build the document

The axiom document is co-authored. We do not arrive with a questionnaire. We arrive with open-ended questions and we listen. The first session is diagnostic — we are trying to understand the work, not the wishlist. We ask senior practitioners to walk us through a typical case, project, or evaluation cycle. We ask what a good output looks like, and — more usefully — what makes an output wrong in ways that might not be immediately obvious to a non-expert.

The document that results has a specific structure:

• Domain scope. What the system is and is not for. Explicit exclusions matter as much as inclusions.
• Reasoning structure. The logical steps a practitioner takes through the core workflows. Written in the practitioner's language.
• Evaluation standards. What distinguishes a good output from a barely acceptable one. Specific enough to use as a test.
• Explicit constraints. The things the system must never do, and why. Particularly important for legal and medical domains.

The document is then reviewed and signed — by us, and by the senior practitioner who co-authored it. It becomes the contract the system is built against.

Why the document matters more than the model

Most AI deployments fail not because the underlying model is weak, but because the model was never told what the domain requires. The result is a system that produces outputs that are technically coherent and domain-ignorant — plausible-sounding, but wrong in ways that an expert immediately recognises and a non-expert cannot detect.

The axiom document solves this by giving the system a stable reference. When a JurisCorpus agent drafts a case memo, it is not simply prompting a general-purpose model — it is querying a knowledge base structured around the axiom document, then generating output constrained by those axioms. The document does not change when the underlying model is updated. The domain knowledge persists.

This is why we call it domain-first design. The domain specification comes before the technical architecture. The tool serves the field — not the other way around.