EARL Developer Platform — documentation

EARL is a developer platform that exposes its own cognitive capabilities through an SDK: evidence-grounded reasoning, persistent memory, planning, self-observation, governed actions and verifiable records. Your application gains the capabilities it integrates, on the data you connect. These guides ship with the platform build and describe the version that is running. This build is an intermediate build: the cognitive capabilities are measured as the register states; the developmental capabilities (governed self-modification, which the correction of 2026-09-23 reads as replacement of one bounded expression by random search under a lab grammar; EARL repairing its own mechanism, which is not demonstrated; and inherited development) have no developer interface yet, and the release gate for them is stated in the register's roadmap section. Repair of your designated Rust code is a different, narrower capability and is available as a developer preview: you supply the requirement and start the repair, EARL proposes and tests a patch, and nothing is applied without your approval (Code repair).

The path: create an application → connect domain information → compose SDK operations → test and deploy. Read the register (last group) before you rely on any capability.

Start here

From a fresh machine to your first application: the platform, the SDK and the application lifecycle.

• Developer quickstart — from a fresh machine to your first applicationInstall the developer environment, create an application, connect a domain, bind the runtime, call every capability with the application key, and deploy. Twenty minutes.
• Build a vertical application — your logic, data, memory, reasoning and actions on EARLBuild a vertical of your own on EARL: application-owned logic, data, memory, reasoning and actions. Start with a working reference application, then adapt its data and workflow to your domain.
• SDK reference — `earl_sdk` (Python 3.11+)Every SDK operation, its typed outcomes (Result, SemanticUncertainty, OperationalError) and error contracts; how the SDK is generated from the API.

Connect your data

How the engine reads a corpus, what a vocabulary and a curriculum are, and how the validators keep authoring compatible by construction.

• Authoring a domain — corpus, vocabulary, curriculumThe corpus, vocabulary and curriculum contracts; what the engine reads from a sentence; which verbs it knows; the validators that refuse an ungroundable authoring before the school starts; the authoring record.
• Start from a working exampleA worked domain (payments routing): corpus, vocabulary, curriculum and the claims it answers, with the verdict each one gets and why.

Reason, remember, act

The cognitive operations composed in one application loop, what the persistent runtime keeps, and how a policy turns verdicts into dispositions and signed evidence.

• Natural-language questions — let your users ask the domainLet your users ask the domain in plain English: what they can ask, the SDK call and its outcomes, how to show an answer with its evidence, and how to write a corpus that answers well.
• Reasoning, memory and planning — composing the cognitive operationssubmit, beliefs, query, prove, evaluate, plan, observe and check composed in one loop, with the outcome each can return and a table of what each operation can and cannot do.
• Persistent workflows — what a workflow keeps, and what it does notWhat the workflow's runtime image keeps between calls and across restarts, what prove closes over, concurrency and idempotency, isolation, engine adoption.
• Evidence packages and policy — the referenceWhat a signed evidence package proves (integrity and attribution, never truth), the policy document format and every rule type, and offline verification.

Deploy and operate

What runs where, how to operate an application against the platform, and the specific case of a frozen adjudicator container.

• Deploying and operating an applicationThe primary deployment guide: your service holds the application key; the platform hosts the persistent runtime; handle every outcome; operate from records, replay and offline verification; change the engine with the contained successor interface.
• Deploying an adjudicator (the frozen verifier container)Freeze a trained domain and deploy the read-only verifier container: identity, adjudication, evidence packages verified offline, operation. What it does not do.
• The mission vertical: deploy, propose, authorize, verifyThe mission vertical (developmental, SYNTHETIC reference world): deploy your application's own gateway, designate your authorizers, propose in Cursor-on-Target or QGroundControl, authorize as yourself, read and verify every record.
• API walkthrough — from an empty platform to a deployed adjudicatorEvery HTTP call in order: authenticate, KB, domain, documents, tuning run, vocabulary, curriculum, school, train, freeze, deploy, adjudicate, policy, evidence, organisations.

What is available now

The register: SDK availability, integration qualification, semantic qualification, the exactly named research statuses, the developmental release gate, execution paths, known limitations, and every finding with its status.

• Capability limitations — the registerRead before you rely on any capability. States that this build is an intermediate build and what the release gate for the developmental capabilities is.

More

• Building a POC vertical — from your claims to a deployed adjudicatorWhat an engineering team needs to take one domain of their own from source
• Code repair — fixing supported defects in your own Rust codeEARL diagnoses, constructs and verifies **supported** repairs in the Rust code you designate, and applies
• Qualifying the four gated learning paths

API reference

Endpoint schemas and an interactive console are generated from the running API: Swagger UI · ReDoc · openapi.json. Those describe individual endpoints; the guides above describe how to put them together. The application API (/api/v1) and the Python SDK (earl_sdk) are versioned together; the SDK reference lists every operation and outcome.

Self-modification and inherited development

Central to EARL, stated at the status it has (corrected 2026-09-23: what is called governed self-modification is replacement of one bounded expression by random search under a lab grammar, accepted by a frozen gate; nothing in it learned from its attempts; self-repair is not demonstrated): governed self-modification, the self-model and the research language-realisation faculty (G-COG-0) are qualified research results with no developer interface in this release; they are listed in the manifest as qualified-but-not-exposed. What applications can invoke today is the contained successor interface — evaluate an installed engine release over a copy of a workflow image, adopt it as an explicit authority action with preservation checks, roll back byte-identically. That is installed-release adoption under your control, not EARL producing its own successors. Two things this section is not about are exposed: plain-English questions over a domain (language.ask, guide) and the code-repair developer preview for your own Rust code (guide). The exactly qualified portions (G-COG-0 language realisation, G-COG-1B.1 admit-to-grounding learning, G-COG-2A/2B self-model, G-COG-3 governed self-modification, L3 ethical learning) and the release gate are in the register, sections D and E.