Skip to content

Platform

The Earp AI Operating System

Six planes between a request and an outcome. Each one has a single job, a guarantee it makes to the planes around it, and fields it writes to a hash-chained ledger — so every model-assisted decision can be replayed, audited and defended.

Explore the planesFollow one request

Architecture

Six planes, one ledger

Hover or focus the stack to separate the planes; select one to see its capabilities and the mechanism behind each. The stack reads top to bottom: what the model sees, how it reasons, what it may say, what gets recorded, how it ships, and how it is watched.

Showing 6 Decision Plane capabilities.

Plane 04 / 06Selected

Decision Plane

Turns every model-assisted outcome into a hash-chained ledger entry that can be replayed, audited and defended.

  • Hash-chained ledger

    Each entry's hash is SHA-256 over the previous entry's hash and the canonical JSON of its body, so altering any historical field breaks every hash after it and verification fails at that height.

  • Idempotency keys

    A SHA-256 of (actor, intent, canonical inputs) is checked against the ledger before execution; a hit returns the recorded outcome instead of re-running the model.

  • Lineage capture

    Decisions that consume another decision's output record its id as parent_id, forming a DAG you can walk from any outcome back to the original request and every intermediate step.

  • Deterministic replay

    Replay re-resolves the pinned context manifest, model version, params and policy bundle from the entry, re-executes in a sandbox and diffs the new output and hash against the recorded ones.

  • Human-in-the-loop checkpoints

    Routes declare escalation predicates (confidence below floor, flagged guardrail, value above limit); a match parks the decision in a review queue and the reviewer's identity and verdict are appended as a child entry.

  • Write-once storage

    Entries are appended to object storage with object lock in compliance mode, and the chain head is periodically anchored to a separate account so neither operator nor vendor can rewrite history.

Ledger fields and guarantees for this plane

Request lifecycle

One request, eight ledger writes

A single request crosses every plane — the Decision and Guardrail planes twice. Each step appends fields to the same ledger entry, so the finished record is a complete account of what happened and why.

  1. 01
    Deployment Plane

    Ingress and release pin

    The router hashes the tenant id into a canary ring and resolves the one release hash that ring is serving. Model, prompts, policy bundle and index snapshot are now fixed for the life of the request.

    Writes to ledger

    • trace_id
    • release_hash
    • deployment_ring
  2. 02
    Decision Plane

    Idempotency check

    SHA-256 over (actor, intent, canonical inputs) is looked up in the ledger. A hit returns the recorded outcome and stops here; a miss reserves the key with status pending so a concurrent retry waits instead of executing twice.

    Writes to ledger

    • idempotency_key
    • status: pending
  3. 03
    Guardrail Plane

    Input screening

    PII and PHI spans are replaced with typed placeholders, the injection classifier scores the prompt, and the NLU pass resolves intent so later policy runs on typed fields rather than free text.

    Writes to ledger

    • redaction_map_hash
    • input_verdicts[]
    • intent
  4. 04
    Context Plane

    Entitled retrieval and window assembly

    Hybrid retrieval runs with the caller's ACL filter inside the query. Segments are packed against per-segment token ceilings; overflow is evicted by relevance. The ordered chunk list is hashed into a manifest.

    Writes to ledger

    • context_manifest_hash
    • source_ids[]
    • window_tokens
  5. 05
    Reasoning Plane

    Routing and inference

    The router picks the cheapest allow-listed model whose measured pass rate clears this task's bar, compiles the versioned template with pinned parameters, and validates the response against its JSON Schema.

    Writes to ledger

    • model_id
    • model_version
    • prompt_template_hash
    • params_hash
    • route_reason
  6. 06
    Guardrail Plane

    Output verdicts

    Every guardrail bound to the route returns pass, flag or block: grounding entailment against cited chunks, policy-as-code checks, output PII scan. A block issues a coded refusal from the policy engine.

    Writes to ledger

    • guardrail_verdicts[]
    • policy_bundle_hash
    • refusal_code
  7. 07
    Decision Plane

    Commit or escalate

    If an escalation predicate matches, the decision parks in a review queue and the reviewer's verdict is appended as a child entry. Otherwise the outcome is committed and chained to the previous entry's hash.

    Writes to ledger

    • decision_id
    • outcome
    • parent_id
    • prev_hash
    • ledger_hash
  8. 08
    Observability Plane

    Trace close, sampling and export

    The trace closes under the same id stored on the entry. A stratified sampler may enrol the decision in tonight's eval run, control charts update, and the entry streams to your SIEM as an OCSF-shaped event.

    Writes to ledger

    • eval_sample_flag
    • control_chart_id
    • export_batch_id

Plane specifications

What each plane guarantees

The contract for each plane: its guarantee, the failure it contains, the ledger fields it owns, and every capability with the mechanism that implements it.

Plane 01 / 06

Context Plane

Assembles exactly what the model is allowed to see, inside a fixed token budget, and records where every token came from.

Guarantee
Every prompt is built from a manifest of addressed, access-checked sources — nothing enters the window that cannot be traced back to a document version and the caller's entitlement.
Contains
Hallucinated grounding, cross-tenant leakage and silent prompt bloat.
Ledger fields
  • context_manifest_hash
  • source_ids[]
  • entitlement_scope
  • window_tokens

  • Hybrid retrieval

    BM25 and dense vectors are queried in parallel, merged with reciprocal-rank fusion, then re-scored by a cross-encoder so exact identifiers (policy numbers, CPT codes) are never lost to semantic similarity.

  • Entitlement-aware filtering

    Document ACLs are denormalised into the index as filter attributes and applied inside the vector query, so a chunk the caller cannot open is never scored, let alone returned.

  • Window budgeting

    Each prompt segment (system, policy, evidence, history, tool output) has a token ceiling; overflow is resolved by relevance-ranked eviction and extractive compression, never by truncating the tail.

  • Tiered memory

    Session memory lives in a TTL-bound store, durable memory requires an explicit write with a retention class, and both are retrieved through the same entitlement filter as documents.

  • Provenance chains

    Every chunk carries (source URI, document version hash, byte offsets, ingest job id); the ordered list is hashed into a context manifest that the ledger entry references.

  • Freshness contracts

    Sources declare a maximum staleness; the ingest scheduler raises an alert and the retriever down-ranks any chunk whose document version is older than its contract allows.

Plane 02 / 06

Reasoning Plane

Chooses the cheapest model that clears the task's quality bar, builds the inference call deterministically and parses the result into typed structures.

Guarantee
Identical inputs produce an identical inference request: model id, version, parameters and prompt template hash are pinned and recorded before the call is made.
Contains
Uncontrolled model sprawl, unpinned versions and free-text outputs flowing into systems of record.
Ledger fields
  • model_id
  • model_version
  • prompt_template_hash
  • params_hash
  • route_reason

  • Policy-based model routing

    A router scores each request on task class, data sensitivity and latency budget, then selects from an allow-list of models with measured pass rates on that task's eval set; the chosen rule is logged as route_reason.

  • Deterministic inference building

    Prompts are compiled from versioned templates with typed slots; temperature, seed, stop sequences and tool schemas are resolved from configuration and hashed into params_hash.

  • Structured output enforcement

    Responses are constrained to a JSON Schema via grammar-guided decoding where the provider supports it, and validated with a strict parser elsewhere; a parse failure triggers one repair pass, then escalation.

  • Intent and entity NLU

    A small fine-tuned classifier resolves intent and extracts entities before any large-model call, so routing and guardrails operate on typed fields instead of raw text.

  • Fallback cascades

    Each route declares an ordered fallback list with its own timeout; a provider error or latency breach moves to the next model and records the hop, so degraded answers are always attributable.

  • Cost and latency envelopes

    Per-tenant token and spend budgets are enforced at call time by a token-bucket limiter; requests that would exceed the envelope are queued or down-routed, never silently dropped.

Plane 03 / 06

Guardrail Plane

Evaluates inputs and outputs against policy-as-code before anything leaves the model boundary, and records which rule fired and why.

Guarantee
No output reaches a user or a downstream system without a recorded verdict from every guardrail bound to that route — pass, flag or block.
Contains
Prompt injection, data exfiltration, out-of-policy advice and unexplainable refusals.
Ledger fields
  • guardrail_verdicts[]
  • policy_bundle_hash
  • redaction_map_hash
  • refusal_code

  • Policy-as-code

    Rules are written as versioned, unit-tested policies (OPA/Rego or typed predicates) bundled per route; the bundle's hash is pinned in configuration so a policy change is a reviewed deploy, not a prompt edit.

  • PII and PHI redaction

    Detectors (pattern, checksum and NER) replace sensitive spans with typed placeholders before inference; the reversible mapping is encrypted, stored separately and re-hydrated only for entitled callers.

  • Jailbreak and injection defense

    Retrieved content is wrapped in delimited, non-instruction channels, a classifier scores inputs for injection patterns, and tool calls are checked against a per-route allow-list regardless of what the model asks for.

  • Deterministic refusal logic

    Refusals are issued by the policy engine, not improvised by the model: each carries a refusal code, the rule id that triggered it and a user-facing template, so identical requests are refused identically.

  • Grounding checks

    Claims in the output are aligned to cited chunks with an entailment model; an unsupported claim above the route's threshold flags the response for review or forces a cited rewrite.

  • Continuous red-teaming

    An adversarial suite of injection, exfiltration and policy-evasion prompts runs on every policy or model change in CI; any regression in block rate fails the pipeline.

Plane 04 / 06

Decision Plane

Turns every model-assisted outcome into a hash-chained ledger entry that can be replayed, audited and defended.

Guarantee
Any decision can be reconstructed byte-for-byte from its ledger entry: same context manifest, same model version, same parameters, same policy bundle.
Contains
Undefendable outcomes, duplicate side effects and audit trails that can be quietly edited.
Ledger fields
  • decision_id
  • idempotency_key
  • parent_id
  • outcome
  • prev_hash
  • ledger_hash

  • Hash-chained ledger

    Each entry's hash is SHA-256 over the previous entry's hash and the canonical JSON of its body, so altering any historical field breaks every hash after it and verification fails at that height.

  • Idempotency keys

    A SHA-256 of (actor, intent, canonical inputs) is checked against the ledger before execution; a hit returns the recorded outcome instead of re-running the model.

  • Lineage capture

    Decisions that consume another decision's output record its id as parent_id, forming a DAG you can walk from any outcome back to the original request and every intermediate step.

  • Deterministic replay

    Replay re-resolves the pinned context manifest, model version, params and policy bundle from the entry, re-executes in a sandbox and diffs the new output and hash against the recorded ones.

  • Human-in-the-loop checkpoints

    Routes declare escalation predicates (confidence below floor, flagged guardrail, value above limit); a match parks the decision in a review queue and the reviewer's identity and verdict are appended as a child entry.

  • Write-once storage

    Entries are appended to object storage with object lock in compliance mode, and the chain head is periodically anchored to a separate account so neither operator nor vendor can rewrite history.

Plane 05 / 06

Deployment Plane

Ships models, prompts and policies into your environment through the same controls as the rest of your software, with a rollback path measured in minutes.

Guarantee
Every running configuration — model version, prompt templates, policy bundle, retrieval index — is a single immutable release hash that was evaluated before it took traffic.
Contains
Unreviewed prompt edits in production, all-at-once rollouts and irreversible model swaps.
Ledger fields
  • release_hash
  • deployment_ring
  • canary_cohort
  • infra_commit

  • Forward-deployed engineering

    Our engineers work inside your cloud accounts under your IdP with scoped roles, ship through your CI/CD and leave behind infrastructure-as-code, runbooks and eval suites your team already operates.

  • Release bundles

    Model id, prompt templates, policy bundle, index snapshot and tool schemas are packaged into one content-addressed release; production can only reference a release hash, never loose parts.

  • Eval-gated promotion

    A release advances from staging to canary only when its golden-set and adversarial eval scores clear per-route thresholds; the gate result is attached to the release as a signed attestation.

  • Canary rings

    Traffic shifts through 1% → 10% → 50% → 100% rings keyed on a stable tenant hash, with automated comparison of guardrail flag rate, latency and override rate against the incumbent release.

  • One-step rollback

    The previous release hash stays warm; rollback is a pointer swap in the router, and in-flight idempotency keys guarantee retried requests do not execute side effects twice.

  • Infrastructure-as-code landing zones

    Networking, private model endpoints, KMS keys and log sinks are declared in Terraform modules with policy checks in the plan stage, so every environment is reproducible and drift is visible in a diff.

Plane 06 / 06

Observability Plane

Treats model behaviour as a process under statistical control and turns the ledger into evidence your auditors and regulators can consume.

Guarantee
Every quality signal has a control limit, every limit breach has an owner, and every audit request can be answered from the ledger without engineering involvement.
Contains
Silent quality decay, alert fatigue and audits answered with screenshots.
Ledger fields
  • trace_id
  • eval_sample_flag
  • control_chart_id
  • export_batch_id

  • Statistical process control

    Override rate, guardrail flag rate and grounding score are plotted on control charts with 3σ limits; Western Electric rules page the route owner on sustained shifts, not single spikes.

  • Drift detection

    Population stability index on input embeddings and feature distributions is computed per window against the release's baseline; crossing the threshold opens a ticket with the offending slices.

  • Continuous eval harness

    A stratified sample of production decisions is re-scored nightly against rubric graders and human labels, so eval results describe live traffic instead of a frozen test set.

  • End-to-end tracing

    OpenTelemetry spans cover retrieval, routing, inference, guardrails and ledger write under one trace id, which is also stored on the ledger entry to join operational and audit data.

  • Audit export

    Ledger ranges are exported as signed, chain-verifiable bundles with a manifest mapped to control objectives, and streamed to your SIEM in OCSF-shaped events.

  • Chain verification

    A scheduled verifier recomputes every hash from the last anchored checkpoint to the head and alerts on the first height where the chain fails, pinpointing tampering or corruption.

Map your stack onto the six planes

In a two-week Systems Assessment we place every model, prompt, retrieval path and policy you run today onto these planes, mark which guarantees are missing, and rank the remediation by audit exposure.

Contact UsSee the Architecture

Interfaces

What plugs in

The platform runs inside your cloud accounts and attaches to the systems you already operate. Each integration binds to one plane through a narrow, typed interface — swapping a vendor never changes what the ledger records.

  • Reasoning Plane

    Model providers

    Azure OpenAI, Amazon Bedrock, Google Vertex AI, Anthropic API, open-weight models on vLLM or TGI

    A provider adapter normalises request and response shapes, maps provider errors onto the fallback cascade and records the provider-reported model version on every call.

  • Context Plane

    Vector stores and search

    pgvector, OpenSearch, Azure AI Search, Pinecone, Weaviate

    A retriever interface requires filter push-down for ACL attributes and returns chunk ids with document version hashes, so provenance survives a change of store.

  • Guardrail Plane

    Identity providers

    Okta, Microsoft Entra ID, Ping Identity, any OIDC or SAML 2.0 IdP

    Caller group claims drive retrieval entitlements and policy scope; reviewer identities on escalated decisions come from the same token, never from a free-text field.

  • Observability Plane

    SIEM and log pipelines

    Splunk, Microsoft Sentinel, Elastic, Google SecOps

    Ledger entries and guardrail verdicts stream as OCSF-shaped JSON over HTTP event collectors or your log shipper, carrying the trace id for correlation.

  • Deployment Plane

    CI/CD and infrastructure-as-code

    GitHub Actions, GitLab CI, Azure DevOps, Terraform, Argo CD

    Eval gates and red-team suites run as pipeline stages; release bundles are built and signed in your pipeline and promoted by your deployment tooling.

  • Context Plane

    Data platforms

    Snowflake, Databricks, BigQuery, S3 and ADLS object stores

    Ingest jobs read through masked views or governed shares, stamp each chunk with the job id, and honour source freshness contracts.

  • Decision Plane

    Review and ticketing

    ServiceNow, Jira Service Management

    Escalated decisions open a ticket carrying the decision id; the reviewer's verdict is written back to the ledger as a child entry when the ticket resolves.

  • Decision Plane

    Keys and secrets

    AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault

    Customer-managed keys encrypt ledger storage and redaction maps; key ids are recorded per entry so a revoked key is traceable to the exact records it protected.

Book a Systems Assessment

Two weeks, fixed scope. We map every model, prompt, data flow and decision path you run today, score them against your compliance regime, and hand you a ranked remediation plan with named mechanisms — not a slide deck.

Contact UsSee the Architecture