Developer surface · the proof layer

The signed atom.
The verifiable agent.
The composable receipt.

The Vault is the asset. Attribution is the API. Every atom — every quote, dispatch, bill, renewal, model inference, agent action — is signed at write-time, hash-chained into the vault, and exposed as a zero-knowledge-attestable receipt. The same evidence that underwrites a lender becomes the proof surface that any downstream system — CDP, DAM, ABM, CPQ, SCM, RevOps, FinOps, or an autonomous agent — can read, verify, and act on.

▸ Signed atoms. ZKP-attested inferences. MCP-callable proofs. Verifiable without revealing the underlying data. The address-level operating ledger, exposed as a composable primitive for the agentic economy — and the observability + audit layer for every agent acting inside it.

"Interactivity is part of the model itself. Responsiveness and intelligence are trained together — not bolted on as a harness."
Mira Murati + Thinking Machines Lab · Interaction Models · May 2026

The next architectural turn in AI isn't faster query/response — it's continuous, listening systems that produce evidence as they run. The Vault was already built this way: atoms are emitted, signed, and attested in 200-millisecond windows, not in nightly batches or quarterly reviews. Attribution is the public surface of that continuous evidence stream — turn-taking is for chatbots, attestation is for commerce.

◂ the asset The Vault The capture layer — 16 operator modules deposit structured, hash-chained evidence.
▸ you are here Attribution The proof surface — the same evidence, exposed as signed receipts any system or agent can verify.

From turn-based queries to continuous attestation.

The dominant pattern for system-of-record APIs is request → response: a lender asks at quarter-end, a CDP polls at midnight, a RevOps dashboard refreshes on demand. That pattern was designed for paper. Attribution flips it. Every atom emits a signed receipt as it happens, the way a credit-card swipe emits an authorization. The lender, the CDP, the agent — all subscribe.

▸ Before · request/response

Periodic, polled, unsigned

  • Underwriting refresh: quarterly diligence, six-week DD cycle
  • CDP enrichment: nightly batch from a warehouse export
  • Audit log: append-only text, no cryptographic chain
  • Agent action: opaque call to an LLM, no receipt of what it saw or did
  • Provenance: "trust the vendor's reporting layer"
▸ After · continuous attestation

Per-atom, signed, subscribable

  • Underwriting: live confidence band; ZKP-attested in ~80ms per inference
  • CDP enrichment: webhook on every atom; the signal is the source
  • Audit log: hash-chained, WORM, third-party verifiable
  • Agent action: signed receipt — model, prompt hash, vault slice, output, time
  • Provenance: verify the math, not the vendor

The atom is the unit of proof.

An atom is the smallest repeatable unit of commercial decision — a quote sent, a dispatch confirmed, a margin recalculated, a renewal priced. The Manifesto names four families (Price, Deploy, Expand, Govern). On the vault side, each atom is hash-chained at write-time. On the attribution side, each atom is exposed as a signed envelope: who did what, on which address, with what inputs, with what model, at what time, and a proof that none of it has been edited since.

▸ Stage 01

EMIT

An operator action or a model inference produces a structured event. Captured at write-time, not post-hoc. Inputs, model version, prompt hash, output, and address are all part of the payload.

▸ Stage 02

SIGN

The event is signed with the operator's vault key. The signature binds the actor (human, agent, or model) to the action. Any later mutation breaks the chain.

▸ Stage 03

CHAIN

The signed event is appended to a per-operator hash chain. Each new atom commits to the prior root. The chain is WORM by construction; time-stamps are anchored to a public clock for ordering.

▸ Stage 04

ATTEST

On request, a zero-knowledge proof is produced: "this output was computed from this operator's vault with the published methodology" — without revealing the underlying records. Verifiable on-chain.

// shape · a signed atom envelope
{
  "atom_id": "atm_01HZ7K9QMBTAV3RX8YS2N4FJD7",
  "loop": "price",           // price · deploy · expand · govern
  "kind": "quote.priced",
  "address": "addr_4f9a...e21c",  // the gravitational unit · Manifesto §01
  "actor": { "type": "agent", "id": "agt_pulse.quote.v3", "human": "u_jane@acme" },
  "inputs_hash": "sha256:9b8a...d31f",
  "model":  { "name": "pulse-quote", "version": "3.2.1", "weights_hash": "sha256:c1e2...4a90" },
  "output": { "price": 12450, "margin": 0.34, "confidence": 0.91 },
  "emitted_at":  "2026-05-17T14:08:21.402Z",
  "prev_root":   "0x7a3c...8e10",
  "chain_root":  "0xb4f1...92a3",
  "signature":   "ed25519:5f...c2",
  "attestation": { "zkp": "groth16:...", "verifier": "allometry/pulse-v3", "on_chain": true }
}

Six endpoints. One ledger.

The proof surface is intentionally narrow. Six endpoints cover the entire interaction model: emit a signed atom, fetch a profile, request an inference with an attached attestation, verify a proof, subscribe to a stream, and resolve a covenant. The full schema lives in the docs; the contract below is stable.

POST/v1/atoms

Emit a signed atom

Write-path. Operator modules, partner integrations, and authorized agents post structured events; the vault signs, chains, and stamps. Returns the atom's root and signature.

▸ idempotent on atom_id · p50 12ms · webhook-fan-out
GET/v1/operators/<id>/profile

Read the live profile

The address-graph projection: revenue quality, margin defensibility, counterparty risk, vintage. Continuously updated from the most recent vault state. The same shape lenders consume.

▸ ETag + If-None-Match · p50 38ms · vintage timestamps included
POST/v1/inferences

Request an attested inference

Run a Pulse model against the operator's vault. Returns the output and a ZKP receipt binding (model_version, weights_hash, vault_root, inputs_hash) → output. Verifiable without seeing the data.

▸ p50 ~80ms · attestation = groth16 · on-chain anchor optional
GET/v1/proofs/<id>/verify

Verify a proof

Stateless verifier. Pass an attestation; receive a boolean and the public inputs. Mirror endpoint published as a verifier contract for on-chain consumers. Same code, two surfaces.

▸ p50 6ms · published verifier circuit · third-party-runnable
GET/v1/streams/<topic>

Subscribe to a stream

Server-sent events or webhooks per (operator, loop, kind). Every atom that matches your filter, in order, with chain root and signature. The "interaction model" surface — continuous, not polled.

▸ at-least-once · sequenced by chain_root · resumable with cursor
GET/v1/covenants/<id>/resolve

Resolve a covenant

Given a covenant ID (lender or smart-contract clause), return the current resolution: triggered / not-triggered, the atoms that evaluate it, and a proof. The bridge from continuous attestation to deterministic settlement.

▸ deterministic given chain_root · re-runnable for any historical root

The control plane for physical revenue.

If you've run Kubernetes, the shape is familiar. You declare desired state; a control plane reconciles the world to match and keeps one authoritative record of what's true. Allometry is that control plane for physical revenue — operating decisions are the declared intent, the vault is the reconciliation log, and the attested ledger is the cluster state every consumer reads from. Your modules and agents are the workloads; Allometry schedules them, signs what they do, and proves it.

Control plane

The vault + Pulse

The decision-and-attestation layer that reconciles every operator's state into one provable record.

Declarative API

Signed atoms

You don't describe steps — you emit intent and outcome. POST /v1/atoms is the desired-state write.

Reconciliation loop

Continuous attestation

State is re-proven as the world changes — the ledger is always current and always verifiable, not polled.

Cluster state / etcd

The hash-chained ledger

One source of truth, append-only and tamper-evident. Every consumer reads the same root.

Workloads / pods

Operator modules + agents

The things actually doing work. They run anywhere; the control plane records and signs what they did.

kubectl / API server

The six endpoints

One stable contract, reached through MCP, SDK, or CLI — the way you talk to the control plane.

Same idea, different substrate: Kubernetes made compute declarative and verifiable. Allometry makes revenue decisions declarative and verifiable — so capital, agents, and finance systems can consume them like any other reconciled API.

Three surfaces. One contract.

The same six endpoints are exposed three ways. An MCP server for AI agents (any MCP-compatible runtime — Claude, Cursor, internal agents — gets first-class proof tools). A typed SDK for application code. A CLI for operators, auditors, and CI. One contract, one verifier, one ledger underneath.

▸ MCP server

Tools any agent can call

An MCP server exposes atoms.emit, profile.read, inference.run, proof.verify, and stream.subscribe as agent tools. Drop into Claude, Cursor, or any MCP client; the agent gets verifiable I/O for free.

▸ SDK

Typed clients for app code

TypeScript and Python first; Go and Rust on the roadmap. Strong types over the wire schema, retries, idempotency, verification helpers, and zero-config webhook handlers. npm i @allometry/attribution.

▸ CLI

Operator + auditor surface

Verify a proof from your terminal: allometry verify <atom_id>. Export a vault slice with attached attestations for a Big-4 auditor. Tail a stream during incident review. Same contract, scriptable.

# MCP · agent flow
$ claude mcp add allometry https://api.allometry.com/mcp
# now any agent has tools:
#   atoms.emit · profile.read · inference.run · proof.verify · stream.subscribe

# SDK · TypeScript
import { Allometry } from "@allometry/attribution";
const alm = new Allometry({ key: process.env.ALLOMETRY_KEY });
const { atom, root } = await alm.atoms.emit({
  loop:    "price",
  kind:    "quote.priced",
  address: "addr_4f9a...e21c",
  output:  { price: 12450, margin: 0.34 }
});

# CLI · auditor
$ allometry verify atm_01HZ7K9QMBTAV3RX8YS2N4FJD7
✓ signature valid      ed25519:5f...c2
✓ chain root valid     0xb4f1...92a3
✓ ZKP attestation      groth16 · verifier pulse-v3 · on-chain anchor 0x9a...
✓ vault vintage        14 months · tier T1 eligible

The categories that read from the ledger.

CDP, DAM, ABM, CPQ, SCM, RevOps and FinOps each invented their own system of record because the substrate they needed didn't exist. The 97% economy never had one at all. The attribution layer doesn't replace these tools — it becomes the signed source each one reads from, so signals stop fragmenting and provenance stops being a configuration item.

Category What it owns What the ledger gives it Surface it calls
CDP Customer profile · identity graph Signed account events with vault-side provenance — every enrichment is sourced and timestamped stream.subscribe · profile.read
DAM Asset library · creative governance Asset usage attestations — which creative was used in which quote, on which address, with what result atoms.emit · inference.run
ABM Account targeting · campaign orchestration Account substrate with hash-chained intent signals — outbound triggered by atoms, not by polled lists stream.subscribe (loop=expand)
CPQ Configure-price-quote workflows Margin Protect + Cost Engine inferences as attested receipts — every quote priced with provable inputs inference.run (model=pulse-quote)
SCM Supply-chain orchestration Inventory + Active Operations atoms — supplier counterparty risk evaluable from the ledger directly stream.subscribe (loop=deploy)
RevOps Revenue pipeline orchestration The unit graph: quote → dispatch → bill → renew, signed, with no reconciliation between systems profile.read · covenants.resolve
FinOps Per-decision cost · capital allocation Per-atom unit economics — the substrate for cost telemetry, budget enforcement, and capital deployment inference.run · covenants.resolve

Agents need receipts.

The unsolved problem of the agentic economy is not "can the agent do the work" — it's who did what, with what data, on whose authority, and is the output stable enough to bill against. Today, an autonomous agent reaches into a vendor's system, makes a call, and leaves nothing verifiable behind. Attribution flips that. Every agent action is a signed atom. Every model output is an attested inference. Every settlement clause resolves to a proof.

Put plainly: this is the observability and audit layer for agents — the agentic equivalent of what Datadog is to servers. Not "did the server stay up," but "which agent took which action, on whose data, with what result — provably." As agents move from drafting to doing, that ledger stops being nice-to-have and becomes the thing you bill, dispute, and underwrite against.

The agentic gap today

  • No actor binding. A "ServiceTitan AI" call and a Claude tool call land in the same audit log as untyped text.
  • No input provenance. The agent read the price book, the inventory feed, and the customer history — but nothing proves which versions, or in what order.
  • No output binding. The agent quoted $12,450. Did the model produce that, or was it edited by a workflow?
  • No replay. If the customer disputes, there is no way to re-run the inference from the same state and produce the same answer.
  • No settlement. Vendor invoices are usage-billed by seats or calls, not by attested unit-of-work — so margin can't be priced.

What the ledger provides

  • Actor binding. The signed atom names the agent (or human), the runtime, the prompt hash, the model + weights hash.
  • Input provenance. inputs_hash commits to the exact vault slice the agent read — fully replayable.
  • Output binding. The signed envelope binds output to inputs. Edits create a new atom; the chain is WORM.
  • Replay. Re-run any inference against any historical chain_root. Deterministic. Disputes resolve by math.
  • Settlement. Per-atom unit economics enable per-decision billing — the natural pricing model for the agentic stack.

Settlement is opt-in.

Attribution doesn't require blockchain. The vault is the system of truth; the verifier is a stateless function. But where a counterparty does want deterministic, automated settlement — a working-capital line that draws as job-cost atoms accumulate, a parametric covenant that triggers on a margin band, an insurance-linked payout indexed to vintage — the same proof surface plugs into a smart-contract verifier. Same attestation, same verifier circuit, same root. On-chain becomes an output surface, not a requirement.

▸ AnchorChain root committed every 15 minutes to a public chain · choose your settlement layer
▸ VerifierSame Groth16 circuit as the API verifier · published as a Solidity contract for on-chain consumers
▸ CovenantsLender-defined or counterparty-defined clauses · evaluated deterministically against any chain_root
▸ DrawsWorking-capital tier: draws permitted up to T1 cap when attested cashflow atoms cross the configured threshold
▸ ParametricInsurance-linked tier (T3): payouts triggered by attested operational atoms — no claims process
▸ Settlement assetUSDC, RTP rails, or off-chain wire · the proof is on-chain, the money lands wherever the lender wants

▸ This is the same architecture Plaid built for consumer fintech — but for physical revenue. Smart contracts are the option, not the obligation. Most lenders today want the proof in their inbox; some lenders tomorrow will want the draw to execute itself. The ledger supports both off the same primitive.

The trajectory: RevOps to FinOps to Capital.

The Manifesto's Layer 1 → Layer 2 → Layer 3 ladder maps directly onto the operational evolution most organisations are already living through. RevOps optimises the revenue pipeline. FinOps puts a unit-cost on every decision. Capital deploys against the attested unit economics. Attribution is the substrate that lets the same atom serve all three.

▸ Layer 1 · RevOps

The pipeline operating layer

The 16 modules close the operator's urgent loops — quoting, dispatch, margin, renewals. The atom graph is the unified pipeline; every decision is signed at the point it's made. RevOps gets a coherent system of record, not a stitched dashboard.

Per-seat SaaS · the wedge
▸ Layer 2 · FinOps

Per-decision unit economics

Every atom carries cost, margin, and capital implication. The FinOps surface — budget enforcement, cost telemetry, allocation reporting — runs natively off the ledger. No reconciliation between an ops system and a finance system; both read the same signed events.

Per-decision usage · the orchestration toll
▸ Layer 3 · Capital

Attested capital deployment

Working capital, infra debt, insurance-linked, rated paper — each lender tier subscribes to the proof stream and underwrites against attestations. Capital lands in days because diligence is continuous; the methodology is open, the math is verifiable.

BPS on flow · the revenue layer

Two precedents. One pattern.

Operational data layers get absorbed by capital and payments incumbents — because those incumbents cannot underwrite or extend financial services without the underlying telemetry. Plaid is the consumer-fintech version. Tola → Block is the SMB-cashflow version. Allometry is the same pattern for physical revenue. The attribution layer is the reason that pattern becomes the standard, not the exception.

▸ Plaid · the API standard

Bank data as a developer surface

ShapeAPI-first fabric between consumer data and capital providers
InsightLenders couldn't reach the data; the data couldn't reach the lenders
OutcomeBecame the underwriting standard for an entire category

The lesson: the API surface, not the application, becomes the institutional standard. Plaid's developer surface is what made bank data composable. The attribution layer is the same surface for the 97% economy — the difference is that the data is cryptographically attestable from day one.

▸ Tola → Block · the acquisition signal

Cashflow telemetry → payments rails

ShapeSMB AP/AR/cashflow tool, YC + Sequoia backed
EventAcquired by Block · August 2025 · folded into Square
OutcomeCashflow telemetry now powers Square's capital deployment

The lesson: payments incumbents buy the operational data layer because they can't underwrite without it. Block needed Tola to extend Square Capital. The same dynamic — at a much larger scale — applies to lenders, insurers, and infrastructure investors who need to underwrite the physical economy. The attestation primitive is what makes the acquisition unnecessary: every counterparty can subscribe.

What's real today. What's pilot. What's roadmap.

The attribution layer is being built in stages. Hash-chaining is in production. The MCP server, SDK, and CLI surfaces are in design-partner pilot. ZKP attestation is benchmarked but not yet on the production API surface. Smart-contract settlement is opt-in for design-partner lenders. We will never label something as live on this page until it is.

▸ Live

Production today

  • Signed atoms · per-operator hash chains
  • Write-time capture across the 16 modules
  • Profile API · ETag-cached reads
  • Webhook subscriptions per (loop, kind)
  • Stateless verifier endpoint
  • Audit-trail exports for Big-4 partners
▸ Pilot

Design-partner only

  • MCP server · Claude + Cursor first
  • TypeScript SDK · alpha consumers
  • CLI · auditor + ops use cases
  • Pulse inference receipts (signed, not yet ZKP)
  • Inbound covenant resolution for T1 lenders
  • Stream cursor + resume semantics
▸ Roadmap

12–24 month horizon

  • Production ZKP attestation · groth16
  • On-chain anchor (settlement layer TBD)
  • Solidity verifier contract · published
  • Smart-contract covenants for T3 / T4 tiers
  • Per-decision FinOps billing surface
  • Python · Go · Rust SDKs

What this isn't.

The attribution layer overlaps with several adjacent primitives, but it's none of them. Audit logs are append-only text. Snowflake is a warehouse. Segment is a router. OPA is a policy engine. Attestation services prove provenance of artifacts, not of decisions. The table below makes the boundaries explicit.

Capability Audit log Warehouse (Snowflake) Router (Segment) Policy (OPA) Attribution
Per-event signature no no no no yes
Hash-chained provenance append-only no no no yes
Inference attestation (ZKP) no no no no yes (pilot)
Continuous / push surface poll poll yes poll yes
Verifier is published no no no policy is yes
MCP-callable no via adapters no no yes
On-chain settlement bridge no no no no opt-in
Underwriting-grade evidence no if shaped no no yes

Why now. Five vectors converging.

The attribution layer is shippable now — and not earlier — because five technical and market conditions all crossed their thresholds in the same window. The Vault is the operational wedge; attribution is the surface those vectors make economically rational.

▸ 2024–26

Reasoning models

Frontier models reliable enough to produce attestable inferences in production. The model output can be bound to inputs without a human in the loop reviewing each one.

▸ 2025–26

MCP standard

A protocol every major agent runtime now speaks. An attestation surface that's MCP-native is composable across Claude, Cursor, internal agents, and runtimes that haven't shipped yet.

▸ 2024–26

ZKP performance

Groth16 and successor systems achieve sub-100ms proving for the inference-scale circuits that matter — fast enough to attach a proof to a production API call without breaking latency budgets.

▸ 2023–26

Lender appetite

Post-2023, balance-sheet capital is actively asking for novel underwriting signals. Continuous, cryptographically-attestable operating data is what they would have built themselves if they could.

Honest questions, honest answers.

The attribution layer makes claims that sound a lot like a 2017 ICO deck. They aren't. Here is the difference, in plain text.

▸ Do I need to be an Allometry operator customer to use the attribution layer?

To emit signed atoms into a vault, yes — the operator has to be using the modules that produce the atoms in the first place. The vault is the system of truth; you can't sign data that doesn't exist.

To read from the ledger, no. Any authorized counterparty (lender, partner, downstream system, MCP-enabled agent) can call the proof surface against an operator vault that has granted access. Read access is granted per-operator, per-scope, per-counterparty. The proofs verify without revealing the underlying records.

▸ Is this a blockchain product?

No. The vault is the system of truth. Centralized writes, hash-chained per-operator, with a published verifier. Blockchain shows up in exactly two places: (1) the chain root is anchored to a public chain every fifteen minutes for tamper-evidence and ordering, and (2) settlement is opt-in for counterparties who want deterministic on-chain draws or parametric payouts.

If you want to consume the proof surface entirely off-chain, the API and verifier work the same way. On-chain is an output surface, not a requirement.

▸ How is this different from a normal webhook + audit log?

A webhook delivers an event. An audit log appends a row. Neither one binds the event to a model version, a vault root, an actor, and a verifier circuit. The attribution envelope does. The signature is cryptographic, not configurational: a downstream system doesn't have to trust Allometry's reporting layer — it can verify the math.

Concretely: an audit log can be edited by anyone with the database password. A signed atom cannot be edited without breaking the chain, and any chain break is publicly detectable from the on-chain anchor.

▸ Are the ZKPs real today, or aspirational?

Honest answer: in pilot, not production. Signed atoms and hash-chained vaults are live. ZKP attestation on inference outputs is benchmarked against Risc0, Aleo, and Halo2, and is in design-partner pilot for a small number of lender consumers. The production label on this page will only flip when the proof is real, on-chain-verifiable, and consumed by an external counterparty.

This matches the same honesty band published on /the-vault. We refuse to label anything as production-ZKP until it actually is.

▸ How does the MCP server differ from "give the agent an API key"?

An MCP server exposes the proof surface as typed agent tools, not as raw HTTP. The agent calls inference.run and receives back the output plus a signed receipt as a structured tool result; the agent's transcript becomes part of the actor binding on the signed atom; the runtime (Claude, Cursor, internal) is part of the actor field.

Practically: with an API key, an agent that quotes a price leaves no verifiable trail. With the MCP surface, the same call is a signed atom in the operator's vault, replayable from any historical chain root.

▸ Who underwrites the verifier?

The verifier circuit is published; the methodology is published; the model weights hash is included in every attestation. Big-4 audit and independent engineering partners sign attestations against the same vault data that lenders consume. The point of the architecture is that institutional trust does not require trusting Allometry as a company. It requires trusting the math + the audit + the methodology — all of which are third-party verifiable.

▸ Does this replace my CDP / DAM / ABM / CPQ / SCM?

No. Each of those tools owns its own UX, its own workflow, and its own buyer. The attribution layer becomes the signed source they read from. If your CPQ today reconciles between Salesforce, ServiceTitan, and NetSuite to figure out what a quote actually was, the attribution layer eliminates that reconciliation by giving all three systems the same signed atom to point at.

The composability table in §05 maps the call patterns. Most teams keep the tools they have and replace the integration glue.

▸ What's the pricing model for the developer surface?

Three tiers, matching the trajectory in §08:

Per-seat SaaS for operators using the 16 modules — this is the wedge and the existing motion. Per-decision usage for downstream consumers (CDP, DAM, agents) calling inference.run and stream.subscribe against the attested ledger. BPS on flow for capital tier consumers (T3–T1 lenders) underwriting against the proof surface.

The developer surface is free during pilot for design partners.

▸ Why won't Stripe / Salesforce / Snowflake ship this themselves?

They could, but it would require re-architecting at the write-path level. Their existing data is structured for ops reporting and for warehouse analytics, not for underwriting. Their writes are not signed. Their inferences are not attested. Their integration model is "trust our reporting layer," not "verify the math against a published circuit." Adding the attribution layer means redoing their write-path on every product surface — which costs more than they would ever recover by competing with us.

The most likely path is partnership: payments incumbents subscribe to the attribution layer for the verticals they don't already cover. That is the Tola → Block precedent, generalized.

▸ What's the moat?

Same moat as /the-vault: the attested ledger is time-locked. A competitor can copy the endpoint shape in an afternoon. What they cannot copy is native attested data accumulating month by month — every signed atom hash-chained at write-time as the operator runs on Allometry. A late entrant starts the native-attestation clock at zero with each new operator.

The compounding moat: every consumer (CDP, agent runtime, lender) that integrates against the published verifier becomes a stakeholder in the standard. Switching cost is not the SaaS — it's the verifier they've already trusted in production.

The pages that tell this one story.

▸ Attribution is the developer surface. These are the asset, the thesis, and the runtime.

▸ you just read Attribution The developer surface — signed atoms, ZKP receipts, MCP-callable proofs.
see the asset side ▸ The Vault The capture layer — how 16 operator modules become the underwritable, signed substrate.

The vault is the asset.
Attribution is the API.

If you're building an agent: drop the MCP server in and your agent gets verifiable I/O for free. If you're building a downstream system: subscribe to the stream and stop reconciling. If you're a lender: verify the math, not the vendor. Same ledger underneath.