technical white paper

Verified Agent Output

The CreationLoop Trust Ledger: Technical White Paper

v3.4

creationloop.ai · marino@creationloop.ai · 2026

paper of record · pdf sha-256 timestamp proof

section 00

What this paper is

This paper specifies the verification contract behind a Verified Agent Output: what the CreationLoop Ledger records, what it proves, how anyone can check it, and, stated with equal precision, what it does not claim.

One disclosure rule governs the whole document. We publish the verification contract: everything an independent party needs to understand and validate a record. We keep operational internals private: key management and rotation, infrastructure layout, and anti-abuse mechanics. A verification system must remain trustworthy even when its method is fully public; if secrecy of method were load-bearing, the system would already be broken. The boundary between the two is a policy choice, drawn on purpose.

The names, used consistently here and everywhere else. CreationLoop is the company. The CreationLoop Trust Ledger is the service. Verified Agent Output is the product. A receipt is the artifact each job carries, and the CreationLoop Ledger is the permanent record it lives on. The Trust Card is an agent's public face on our registry. The line that carries all of it: The proof travels with the work.

section 01

The problem

Companies now delegate real work to AI agents. Accountability does not delegate with it. When an agent books, publishes, edits, pays, or promises, a human organization answers for the result, usually on the evidence of logs the agent's own stack produced about itself.

A log is a claim authored by the system under examination. Logs can be edited after the fact, generated selectively, or lost. They help teams investigate; they give a customer, an auditor, or an executive nothing they can independently verify. As agent work scales, the gap between what organizations are accountable for and what they can prove widens.

A receipt from an independent ledger is a different kind of evidence: a witness record, made by a party separate from the agent that did the work, bound to the exact delivered artifact, carrying the named human authority that approved it. The ledger exists to bind those three things, agent claim, exact artifact, and named human approval, into one portable object.

The ledger closes the gap for a specific unit of work: the agent job. Every completed run produces a sealed record and one public verification link. The proof travels with the work.

section 02

Definitions

Agent job (run).: One traceable unit of delegated work: a request, the actions taken under it, the approvals that gated it, and the delivered result.
Receipt.: The artifact a completed job carries: a compact, hash-bound reference to its sealed record, portable wherever the work goes.
Verified Agent Output (VAO).: The sealed record a completed run produces: the request, the agent's reported actions, each named human approval, policy checks, and the receipt for the delivered work, verifiable in a browser without access to the systems that produced it.
The CreationLoop Ledger.: The append-only record system that receives, verifies, and seals run events. The service that operates it is the CreationLoop Trust Ledger; in this paper, the ledger.
Trust Card.: The public face of an agent on the ledger: definition fingerprint, operator identity, verified task count, approval completion, and policy history. Trust is displayed on the card and earned on the ledger.
Video Receipt.: When the delivered work is video, the receipt also renders as a short watchable summary of the sealed record, playable beside the work itself: evidence you can press play on. The watchable form is a rendering; verification always checks the record.
Verify link.: One public URL per record. Opening it serves the sealed record, the approvals, the output's credentials, and the receipt.

section 03

The verification contract

A Verified Agent Output carries six guarantees. Each names a property an independent party can check.

G1.

Origin.

Every event in the record arrived authenticated to the submitting agent's signing secret. Events are delivered over one signed webhook; signatures use HMAC-SHA256.

G2.

Order.

Every event is recorded with its arrival time. Sealed rows cannot be altered, so the recorded order stands.

G3.

Uniqueness.

Each event is recorded exactly once. Duplicate or replayed submissions are rejected by a unique event constraint; one verified event creates one traceable job via a unique receipt event.

G4.

Tamper evidence.

Records enter an append-only store: guard triggers reject mutation, and deletion carries no privilege. Each sealed record is signed. The ledger's claim here is precise: alteration is evident. A changed record breaks its seal.

G5.

Named human approval.

Each required approval was cast by its named human through a single-use signed link. An approval cannot be replayed, transferred, or cast twice.

G6.

Output binding.

The delivered output matches its recorded hash. When the work is media, the delivered file itself is received, the published receipt is hash-bound to it, and each media receipt states its credential status, pending or embedded; C2PA 2.x content credentials attach as the embedding stage lands. When the work is video, the same sealed record also renders as the Video Receipt, the human door to the proof; the record, never the rendering, is what verification checks.

The verification model. The recipient of a verify link validates the record in the browser, against the ledger's published verification key, with no access to the operator's systems or ours beyond the public surface. Key discovery is DNS-pinned: the verification key is published at a well-known location under the creationloop.ai domain, so trusting a record reduces to trusting DNS plus TLS for exactly one domain.

section 04

The run lifecycle

Six stages take a request to a verifiable record. At each stage, the contract says what is recorded and what an auditor can later check.

Authenticate.

The request is authenticated and recorded once. Recorded: the request event under G1 and G3. Checkable: origin and uniqueness.

Execute.

One verified event creates one traceable job; the record captures the job's permissions and operating context. Agent keys are revocable; a revoked key stops producing acceptable events while history already sealed stays valid. Recorded: job identity, context, reported actions. Checkable: every action's origin, order, uniqueness.

Approve.

A named human completes each required approval gate through a single-use signed link. Recorded: approver identity, gate, timestamp, signature. Checkable: G5 per approval.

Seal.

Instructions, actions, approvals, policies, and results enter the tamper-evident ledger: append-only records, every record sealed. Checkable: G4 across the record.

Deliver.

The finished work carries provenance and a receipt bound to the ledger record: hash binding for the receipt, credential status stated on every media receipt, and for video, the watchable Video Receipt beside the work. Checkable: G6.

Verify.

The recipient validates the record in-browser against the DNS-pinned key. Checkable: the whole contract, from one link.

section 05

What we do not claim

This section is part of the product.

For events an external system reports, the ledger proves who reported them, their order, and their integrity. Whether the reported action physically occurred on the external platform sits outside the record. If an agent reports "posted to platform X," the record proves that claim was made by that agent's key, at that position in the sequence, and was never altered afterward. It does not prove the post exists on platform X.

Ground-truth observation, where the ledger can attest that the action itself occurred, applies only to runs executed on our own pipeline, where the executing substrate and the recording substrate are the same system.

Formally, records carry two attestation classes: sealed self-report (G1 through G5 over what an external agent claimed) and pipeline-observed (the same guarantees, where execution itself happened inside the recording system). A record never presents one class as the other.

Two further disciplines bound every claim the ledger makes. A record produced to demonstrate the system never counts toward an agent's operating history. And the ledger's vocabulary is fixed: it attests verified provenance and execution evidence, never proven correctness. Whether the work was good remains a human judgment; the ledger's contribution is proof that the judgment was made by a named human, on the exact artifact, on the record.

section 06

Agent identity

An agent on the ledger is identified three ways. Its definition fingerprint: the SHA-256 digest of its published definition, so any party can check that the agent's stated definition is byte-identical to the one its operator published. Its operator identity: the accountable organization. Its signing secret: the credential behind G1, revocable without rewriting history.

The Verified Agent Registry is the public roster: every agent we operate is listed with its Trust Card. Counters on a card display only receipt-backed facts: verified tasks, approvals completed, policy breaches. The ledger publishes no scores. A number that cannot be independently recomputed from records has no place on a trust surface.

section 07

Integration and access

One signed webhook. The agent keeps running where it runs, on its own infrastructure and its own stack; CreationLoop receives its events, verifies them, and seals the record. No SDK lock-in, no execution migration, no access into the operator's systems.

Access follows one rule: checking is free, issuing is the service. Anyone can open a verify link and validate a record, always, with no account. Free verification is how a standard spreads. Issuing receipts, the operation of the ledger for an agent's work, is the service operators engage CreationLoop for.

The public surface is agent-readable by design: the site publishes machine-readable copies of its content (llms.txt and llms-full.txt) and an MCP endpoint (POST creationloop.ai/api/mcp) whose tools serve canonical site content verbatim and accept design-partner applications, so an agent can read this paper's claims and apply on its operator's behalf. Human applications reach marino@creationloop.ai.

section 08

Tampering, as the verifier sees it

Kerckhoffs's stance: everything above is public, and the system is expected to hold. What failure looks like from the outside:

An event injected without the agent's key fails G1 at verification.
A rewritten order fails G2: sealed rows reject alteration.
A replayed event is rejected at ingestion by G3's uniqueness constraint; a record showing the same event twice fails verification.
An edited or deleted row breaks the G4 seals downstream of it; the verify surface reports the record as no longer intact.
A forged or reused approval link fails G5's signature or single-use check.
A swapped deliverable no longer matches the G6 hash; for media, provenance credentials fail.

What an attacker cannot achieve without detection is the quiet edit: the record that reads as intact after history changed. That is the property the ledger exists to provide.

section 09

External anchoring

Trusting a record today reduces to trusting DNS plus TLS for one domain. The contract reduces it further.

The contract's next stage anchors the ledger externally. On an interval, the ledger hashes its seal-chain head, a single digest summarizing every sealed record to that point, and anchors it to the Bitcoin network through an open timestamp-aggregation path. Each anchor yields a proof, stored per anchored head and served on the verify surface beside its block reference, checkable against public Bitcoin block headers with open tooling. An anchored head gives every earlier record proof of existence at a point in time that nobody, CreationLoop included, can backdate or quietly revise: rewriting anchored history would mean rewriting a public record maintained by thousands of independent parties and sealed by seventeen years of proof of work.

The division of labor is exact. Bitcoin seals the record; the ledger proves the work. Anchoring adds a timestamp witness over the whole chain, and per-record verification stays as specified above, in the browser, from one link. The boundary is standing: we hold no token, we sell no chain, and issuing or verifying a record never requires holding, transacting, or trusting any cryptocurrency. Bitcoin serves here as timestamp infrastructure, the most widely replicated append-only record in existence, and nothing more.

To rewrite an anchored record, rewrite Bitcoin first.

Until an anchor is live, no record claims one.

section 10

Status

The ledger runs in production on our own agents first. The CreationLoop CMO Agent's completed runs are the first Verified Agent Outputs, listed on the public registry with the real definition fingerprint. Registry counters display with an "illustrative concept · live counters at launch" label until live values bind; the label is itself an instance of the no-unverifiable-claims rule. The ledger is opening to a small set of outside design partners; terms are set with the founder as part of the application.

A completed run on this ledger is public today at its verify link: https://creationloop.ai/verified/proof?receipt=pow_354d3617-5972-4786-934a-426d8e0e4b7b. The launch announcement will carry its own record the same way.

section 11

Versioning

This paper is versioned, and its claims are tied to the substrate as of the version date. Where the implementation and this paper disagree, the paper is wrong and gets revised; records are never rewritten to match prose. Material changes to the verification contract will appear as new versions of this document, never as silent edits. v3.3 narrows four claims to the shipped mechanism, tamper evidence, media credentials, the demonstration rule, and external anchoring, following the cross-repo ratification recon of 2026-08-06. v3.4 converts the paper to published form: the ordering guarantee narrows to its receipted mechanism, the status section links a live verified run, and the draft banner is removed. v3.5 restores the section 9 kicker under forward framing.