What we can prove, and the one thing we can't.

Every ForceDream execution is signed with the model we selected to run it. No inference provider signs anything at all.

This page loads a real production proof live and separates it into two columns: what carries a signature today, and what nobody currently signs. The second column is not a limitation we are hiding. It is the part of the chain we cannot build alone.

✓ Signed by ForceDream, verifiable by anyone

task_id—

agent_id—

input_hash—

output_hash—

inference_provider—

inference_model—

cost_pence—

merkle_root—

signature—

◇ Nobody signs this — the gap

provider_receivedthat the request arrived

provider_modelwhich weights actually ran

provider_versionwhich revision served it

provider_timestampwhen, by their clock

provider_tokenswhat was actually billed

provider_signaturesigned by the provider's key

Be precise about what the left column means. inference_model is signed, so it cannot be altered after the fact — but it records the model we selected. If our router were wrong, or dishonest, the signature would faithfully preserve the wrong answer. Ours is the only word on it, and a signature over your own claim is not independent evidence.

Why this is the last link

Question a buyer needs answered	Who can answer it	Signed?
Did this task run with these inputs?	ForceDream	yes
Was the output altered afterwards?	ForceDream	yes
What did it cost, and who was paid?	ForceDream	yes
Which model did ForceDream choose?	ForceDream	yes
Which model actually served it?	the provider	no — nobody offers this

Four of the five are answered by a signature you can check without asking us. The fifth is answered by nobody, at any provider, today. An agent deciding whether to pay a stranger for work has no way to establish that the intelligence it paid for is the intelligence that ran.

What would close it

A provider-signed receipt returned alongside the completion. Nothing exotic — a detached signature over a small, fixed payload:

{
  "request_digest": "<sha256 of the request the provider received>",
  "model":          "gemini-2.5-pro",
  "model_version":  "<the revision that served it>",
  "served_at":      1786512000000,
  "tokens":         { "prompt": 412, "completion": 88 },
  "signature":      "<Ed25519 over the above, provider's key>"
}

We would embed that receipt in the execution proof and bind it into the same Merkle tree. The buyer then verifies two independent signatures from two parties with no incentive to collude: ours that the work happened as described, the provider's that their model produced it. Neither can forge the other.

We have built our half. Twelve SDKs across twelve languages implement one shared verification contract, gated in CI against a public conformance suite anyone can clone and run. Adding a provider receipt to the signed payload is a schema change we have already done once, for model binding, in a week. The constraint is not our engineering. It is that no provider emits one.