Start from a working example

Your first domain will probably fail, and the hard part is that you won't know why. A corpus too thin to ground, a vocabulary missing the words your claims use, a curriculum whose assessments were never reachable — these all look identical to a broken platform when you have never seen the flow succeed.

An example fixes that reference point. Every bundled example has been driven end to end — corpus to a deployed container answering claims — so when a step fails you know it was something you changed.

Instantiate one

GET  /api/examples                      → what is bundled
GET  /api/examples/payments-routing     → detail, including expected verdicts

POST /api/examples/payments-routing/instantiate
{"foundational_kb_package_id": 1}
→ {"domain_id": 3, "tuning_run_id": 4, "stage": "corpus_ready", ...}

You need an approved foundational KB package first (walkthrough, step 2). The example won't guess one: which grounded vocabulary a domain builds on is your decision, and picking silently would hide it.

Two things the request also accepts, because a shared instance hits both on day one:

"earl_engine_id" — the engine to build on. Omitted, the newest installed engine is used, and the response says which.
"domain_name" — domain names are unique, so a second instantiation of the same example returns 409 A domain with this name already exists. Pass your own name to keep the earlier copy.

The verdicts are measured on a specific engine

Every example records measured_on_engine (GET /api/examples/<slug>): the engine release its expected verdicts were observed on. A newer engine can change verdicts on the same corpus — which relations it asserts, which endpoint pair it picks — so on a different engine the documented verdicts are a claim to be checked, not a promise.

The platform checks it for you. An engine example check instantiates the example on an engine, drives approve → school → train exactly as you would, adjudicates the verification claims, and compares every verdict to the documented one:

POST /api/earl-engines/{engine_id}/example-checks      (super_admin)
{"example_slug": "payments-routing", "foundational_kb_package_id": 1}
→ {"id": 7, "status": "queued", ...}

GET  /api/example-checks/7          → status, per-claim results, log
GET  /api/earl-engines              → each engine carries its latest check per example

Outcomes are deliberately three-valued: passed (every documented verdict reproduced), failed (the pipeline ran and at least one verdict differs — the per-claim rows show expected vs actual, the endpoints used, whether they were the asserted pair, and the demotion reason), and errored (the pipeline itself did not complete, which is an apparatus fault, never a regression). The temporary domain is archived, not deleted, so a divergence stays inspectable. GET /api/examples/<slug> lists the latest outcome per installed engine under engine_checks.

Run the check after every engine install, before building domains on it. An engine that fails it is not broken; the example's documentation is simply not true of that engine until it is re-measured.

What it does, and deliberately does not do

Does: creates the domain, uploads the corpus, opens a tuning run, and fills the vocabulary and curriculum drafts — running the vocabulary through the same validator your own drafts face, so you see the contract being checked rather than trusting that it passed.

Does not: approve anything. The drafts land unapproved, and school, training, freezing and deployment are all still yours to run.

That is the point. Approving, watching school report mastery, and reading a verdict are the skill. Automating them would leave you with a working container and no idea how it got there — and no idea what to do when your own domain behaves differently.

Pick up at step 6 of the API walkthrough and drive the rest yourself. Expect roughly ten minutes to a deployed adjudicator.

`payments-routing`

Routing claims judged against acquirer capability guidance: six documents on acquirer capability, sanctions screening, authentication mandates, cost, and decision precedence.

It demonstrates:

how a corpus, vocabulary and curriculum fit together
declared aliases — the corpus says "American Express", claims say amex, and ALIASES is what makes evidence about one constrain the other
reading a verdict, and what a demotion_reason means
where the limits actually are

Verify it yourself

After deploying, send these claims. Measured on engine v0.65.0 (see measured_on_engine and measurement_history in the example's manifest); an engine example check reproduces this table on any installed engine.

Claim	Expect	Why
`Atlas settles eur currency`	VERIFIED	The corpus states it in a sentence naming both, the vocabulary links `atlas` and `eur` in a capability band, training asserts the belief `atlas settles eur`; the verdict lands on the asserted pair `(atlas, eur)`
`Atlas does not settle eur currency`	CONTESTED	The exact negation. It grounds only through affirmative association → `negated_claim_grounds_only_affirmative_evidence`. A claim and its negation can never both verify
`Northstar supports the amex scheme`	UNCERTAIN — the limit, handled honestly	The corpus says Northstar takes Visa and Mastercard only. That is a closed-world list, not a denial, so nothing contradicts the claim — but no trained belief asserts `(northstar, amex)` either, and VERIFIED requires an asserted pair (engine ≥ v0.64.0). `demotion_reason: relation_unasserted`, on the asserted pair
`Northstar does not support the amex scheme`	CONTESTED	Demoted for polarity, on the asserted pair `(northstar, amex)`. Contested, not verified: the corpus never denies it explicitly
`Northstar supports the visa scheme`	VERIFIED	The positive counterpart of the Amex claim: a supported pair versus a merely unmentioned one
`Meridian supports the amex scheme`	VERIFIED	Same claim shape, different acquirer: the verdict follows the evidence per named entity, not the sentence template

The Northstar/Amex pair is bundled on purpose. The adjudicator will not invent a denial from a closed-world list, and — on current engines — it will not verify a pair the corpus never asserts either. If exhaustiveness matters in your domain ("only these values are permitted"), that belongs in a deterministic rule set beside the adjudicator, not inside it.

History. On engine v0.4.0 the same claim VERIFIED, because nothing read exclusion as negation and no pair assertion was required. That was documented as a limit. From v0.64.0 the pair-assertion check turns it into an honest UNCERTAIN. The example was re-authored on 2026-09-22 so that the claims it does support are asserted (see Authoring a domain, "Assert the pairs your claims are about").

For the other limits, see authoring a domain.

The acquirers and capabilities are invented. The corpus is training material for the proposer, not an authoritative capability matrix.