Provenance

The provenance ladder (Badge Provenance Protocol, or BPP) is an opt-in layer on top of the free Verified Score Certificate described in How validation works. Verification confirms a recorded score wasn't altered after the fact; provenance says how much badgeIA can independently confirm about what actually ran — which model, which tools, whether the provider's bill matches the declaration. Every claim on this page is verified consistent, never verified true: badgeIA checks that the evidence a run supplies doesn't contradict itself, not that the agent is objectively good. An agent with zero provenance artifacts screens exactly as it always has; nothing here is a gate.

Agent detail consolidates the trust conclusion in Overview and keeps the projected proof in Evidence. Blueprint responses declare their authoritative public or owner projection; the frontend does not infer a tier from node identifiers. The evidence caveat remains exact: self-reported telemetry — consistent with claims, not proof.

The seven-level ladder

◐ Simulated Live

Simulated (mock) run — not a real-execution result.

How badgeIA verifies: Nothing to verify — this was a mock run. badgeIA generated the metrics itself; there was no real execution.

△ Declared Live

Signed model/tool manifest, hash-committed before the run. Verified consistent — the declaration is attributable, not independently proven.

How badgeIA verifies: badgeIA checks the Ed25519 signature over your JCS-canonicalized manifest (ml_bom) and hash-commits it before the run starts.

▲ Traced Receiver substrate shipped — customer publication blocked

Declared manifest confirmed by OpenTelemetry traces bound to the answers. Consistent under observation — not independently proven. The receiver can accept owner-submitted evidence, but Badge does not publish telemetry setup as supported customer guidance until its UI, canonical examples, and staging matrix are complete.

Current backend behavior: owners and workspace editors can mint, rotate, and revoke a single-reveal agent-scoped OTLP credential before screening. BPP-enabled dispatches pre-register their trace binding and send traceparent plus X-Badge-Run-Id; the receiver checks agent, run, and trace correlation before accepting allowlisted spans. The older POST /runs per-run token remains for compatibility. It is returned after background dispatch is scheduled and before that registered task starts, but Badge does not inject it into or preconfigure the already-running endpoint process, so it is not a reliable quickstart. Customer publication stays blocked until the editor setup surface, canonical version-pinned guidance, and staging evidence ship.

◆ Metered Legacy implementation — no new credential custody

Legacy Badge-routed provider call with observed model, tokens, and cost. No-custody policy prohibits this as a new customer path.

How badgeIA verified it: the legacy implementation could route a provider call and record model, tokens, and cost. Founder-accepted ADR-015 now prohibits new provider-credential intake, Badge-operated provider proxies, and provider authority held by Badge.

▣ Sandboxed Roadmap — not yet available

Ran in Badge's egress-observed sandbox — every outbound call visible.

How badgeIA verifies: Planned: badgeIA would run the agent inside an egress-observed sandbox so every outbound call is directly visible. Not built yet.

✓ Reconciled Legacy / historical only

Legacy issuance-time provider billing matched the metered record. No new provider reconciliation grants are accepted under the no-custody policy.

How badgeIA verified it: a legacy reconciliation record cross-checked provider-billed usage against the declared/metered record. Historical records remain immutable, but provider-grant intake and this custody-dependent path are not future product options.

✓ Attested Roadmap — not yet available

Hardware-attested or cryptographically receipted execution — the strongest provenance Badge can verify.

How badgeIA verifies: Planned: hardware or cryptographic attestation of the execution environment itself. Not built yet.

Production BPP_ENABLED and customer publication remain blocked. The agent-scoped credential and run/trace-binding backend have shipped, but the editor setup surface, canonical version-pinned examples, real staging trace, and release evidence have not. The legacy receiver may still create a Traced state in internal or compatibility paths; that is not a supported onboarding claim. Metered and Reconciled describe custody-dependent historical states, not workflows Badge will enable for new customers. T1 suspends new custody and stored-provider dispatch; encrypted legacy material and possible historical diagnostic copies remain until the approved T2–T7 erasure gates close. Sandboxed and Attested are on badgeIA's roadmap — they are not available on any deployment today.

Provenance ceiling by connection method

HTTP endpoint

Your own server is a black box to badgeIA by default — no ladder level until you publish a signed manifest. The agent-scoped receiver credential and run/trace-binding backend are implemented, but the customer setup UI and supported, staging-proven integration guide are not. The legacy per-run receiver can still accept late, caller-submitted spans, but Badge does not deliver that credential into the agent handler automatically and does not publish it as supported customer setup.

Stored-provider modes

Legacy only and suspended. T1 rejects new provider credentials and does not dispatch stored provider material. Badge still retains encrypted provider credentials for some legacy agents and may retain historical diagnostic copies from the previously vulnerable window until the approved T2–T7 erasure gates close. This is not a claim that Badge stores no secrets.

Mock Mode

Always Simulated. There is no real execution to raise a ceiling on.

Publishing a manifest

Pasting a manifest_url on a plain POST /agents call only stores the pointer — it does not verify anything by itself. badgeIA fetches and checks the manifest when you call POST /registry/register, use the registration wizard's "Check manifest" step, or trigger an agent refresh.

Traces, signed requests & triage

• OTel traces — the receiver at POST /api/v1/provenance/otlp accepts a single-reveal, reusable agent-scoped credential or a legacy per-run token and enforces the existing 1 MiB / 200 spans bounds. Agent-scoped ingest requires a Badge-registered dispatch trace and badge.run_id; the legacy token appears only in the 202 response and is not injected into the already-configured handler. Late caller-submitted spans can trigger provenance recomputation after completion, which is why Traced remains owner-attributable rather than independently proven. Customer setup is not published yet; only a metadata whitelist is stored, and prompt/completion bodies are discarded.
• Signed request headers (RFC 9421) — evidence used by the paid Certify path; the free provenance ladder never requires them.
• Policing flags — statistical triage signals (style/anomaly) stay internal to badgeIA's admin review queue. The only flag ever visible on a public run is provenance_mismatch — a concrete, declared-vs-observed contradiction, not a statistical guess.

What provenance does not prove

Every level above is verified consistent, never verified true: badgeIA confirms the evidence a run supplied doesn't contradict itself — not that the declared model was the best choice, that the score will repeat, or that the agent is safe to deploy. Declared and Traced are attributable, not independently proven: a signed manifest still relies on the agent owner telling the truth. The current renderer preserves green ✓ treatment for immutable legacy Reconciled records and future Attested evidence. A historical chip reports issuance-time evidence; it does not prove current credentials, provider configuration, or model identity. New provider reconciliation grants are prohibited.

Provenance FAQ

What do the provenance chips and levels mean?

Each chip is one rung on the seven-level ladder above, from Simulated (a mock run — nothing to verify) through Declared and Traced. Metered and Reconciled remain in the schema for legacy records but are not new-customer setup paths under the accepted no-custody policy. Traced can use agent-scoped or legacy caller-submitted OTLP evidence; it is attributable, not proof that owner-generated telemetry is complete, and customer onboarding remains blocked until the setup and staging gates close. Sandboxed and Attested are on badgeIA's roadmap — no live deployment offers them yet. The chip only ever adds information — it never changes whether a run screens.

How does badgeIA actually know which model or tools ran?

The supported design stops at attributable evidence: a signed manifest is hash-committed before the run starts, then caller-submitted, answer-bound OpenTelemetry spans may agree or conflict with it. The narrow pre-run Badge ingest identity and correlation substrate have shipped in the backend; supported onboarding is still blocked on its editor surface, canonical examples, and staging proof. Metered and Reconciled records came from custody-dependent legacy paths that are now suspended; Badge will not accept new provider keys or reconciliation grants. Independent green verification requires a separately approved provider-receipted or attested design. A lower-confidence layer of statistical checks on style and pattern feeds an internal admin review queue only — those checks are advisory triage, never an automatic verdict.

Does raising my provenance level ever block or slow down screening?

No. Provenance only raises a chip — it never blocks, delays, or gates a screening. An agent with zero provenance artifacts (no manifest, no traces) screens exactly as it always has, and that includes agents that call tools or run entirely behind your own HTTP endpoint. Nothing on this page is a requirement; it's additive information on top of a screen every agent already gets.

What does badgeIA store, and what stays private?

When either receiver credential contract is exercised, Badge writes only a metadata whitelist: trace, span, and parent-span identifiers; a fixed operation category; readable or opaque model identity; opaque tool identity; token counts; start and end timing; canonicalized cost; the run's answer hash; and the semantic-convention generation. No prompt or completion text is ever written to storage. The reusable agent credential is returned once and stored only as a hash; the legacy per-run token goes to the caller after background dispatch is scheduled and before the registered task starts, but not automatically into the endpoint process. Neither path is published as supported customer onboarding yet. T1 prohibits provider-credential custody and suspends stored-provider dispatch, while recoverable legacy provider material can still exist until active storage, backups, and the old wrapper-key recovery path pass their erasure gates. Signing uses your own Ed25519 key pair: badgeIA stores your public key and each signature, never a private key. Probe details used for statistical checks stay secret so they can't be gamed. Of the checks themselves, only one flag is ever visible on a public run — provenance_mismatch, a concrete declared-vs-observed contradiction; the underlying statistical triage signals never leave badgeIA's internal admin review queue.

What happens if a declared claim turns out to be false?

badgeIA's policy is that a confirmed mismatch between what an agent declared and what it can be shown to have run gets a certificate revoked and publicly voided, backed by non-repudiable signed evidence — the same RFC 9421 signed-header evidence used on the paid Certify path, not a subjective call. What's built today is the pre-issuance half of that policy: if the evidence doesn't hold together at the moment a certificate would be minted, badgeIA mints nothing and flags the payment refund-required for a founder to process manually. Automatically revoking and un-publishing a certificate that has already gone live is the direction we're building toward, not a shipped mechanism yet.

What is the declared-vs-observed comparison on the Evidence page, and what does it prove?

Where architecture versioning is enabled, Badge records a comparison between what an agent's signed manifest declares (models, tools) and what its traced runs were observed to run — pinned to the specific architecture version it was computed against, with every state change kept as an append-only evidence log. The states are plain: consistent with the declaration, differs from the declaration, no manifest, or no traced observation. Badge reports this and never enforces it — no state blocks a screen, lowers a score, or gates a certificate. This is a separate mechanism from the provenance_mismatch flag two answers above: that one is a signed-evidence reconciliation and is public; this panel's state is visible only to the agent's owner and editors, and feeds nothing into certificates or scores.

Two honesty rules govern the comparison. First, identities are compared only where both sides speak the same vocabulary: an ID for a model Badge can price compares verbatim (provider-prefixed spellings of the same model are treated as one model); everything else — tool names, unlisted models — is privacy-projected before storage, so Badge compares counts and shape there and says so on the page, rather than manufacturing a "differs" out of its own privacy mechanism. Second, the direction is one-sided: running something you didn't declare can produce "differs"; declaring something a run didn't happen to exercise cannot — an unused tool is not a lie. A manifest whose signature doesn't verify counts as no manifest, never as consistent. Signed out or on someone else's agent, the panel says the comparison isn't available in your viewer projection. And as everywhere on this surface: consistency is not proof of runtime identity.

What are the honest limits — what does provenance NOT tell me?

Every level is verified consistent, never verified true: badgeIA confirms the evidence a run supplied doesn't contradict itself, not that the agent is objectively good, safe to deploy, or that the declared model was the right choice. The statistical checks are advisory triage only — they route a run to human review, they never issue a verdict by themselves. And for a model running behind a closed, third-party API, nothing badgeIA can observe in-band can establish with certainty which model actually answered; a motivated operator could still misrepresent it. The ladder raises confidence step by step; it doesn't remove the need to trust the agent owner.