technical white paper

CreationCode

Governed Approvals and Sealed Receipts for Agent-Written Code: Technical White Paper

v1 draft, for founder review. Not published.

creationcode.ai · marino@creationloop.ai · 2026

paper of record · pdf sha-256 timestamp proof

section 00

What this paper is

This paper specifies the governance contract behind CreationCode: how human authority binds to exact bytes, how execution is bounded, how a merge becomes evidence, what a receipt proves about a code change, and, stated with equal precision, what it does not claim.

One disclosure rule governs the whole document. We publish the governance 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 system that governs trust must remain trustworthy even when its method is fully public; if secrecy of method were load-bearing, the system would already be broken.

The names, used consistently here and everywhere else. CreationCode is the product: a governed approval layer and sealed audit record for agent-written code. It runs on the CreationLoop Trust Ledger, and every record it produces seals under the foundation contract specified in the Trust Ledger Technical White Paper at creationcode.ai/trust-ledger-whitepaper. This paper specifies only the code-domain contract above that foundation. A Receipt is the artifact each governed change carries. The line that carries it: your agents write the code. CreationCode governs what ships and proves what shipped.

section 01

The problem

Agents now write real production code, and they write it faster than humans can read it. Review capacity stays flat while change volume climbs, so the merge, the one moment where a proposal becomes the product, increasingly runs on the agent's own account of what it did.

That account is a log, and a log is a claim authored by the system under examination. It can be generated selectively, summarized flatteringly, or lost. When the merged change breaks production, leaks data, or fails an audit, the organization answers for it, and the evidence on hand is the story the agent told about itself plus an approval click nobody can reconstruct.

CreationCode replaces that story with a record. Authority binds to exact bytes, so what the human approved is provably what ran. Execution is bounded, so a grant buys one run under a named ceiling. The merge is verified independently against the code host, so a receipt reflects evidence rather than a claim. And the whole path, request, plan, approvals, run, candidate, merge, seals to an append-only ledger a third party can check from one link.

Every governed change produces a sealed record and one public verification link. The proof travels with the work.

section 02

Definitions

Request.: The exact visible bytes of what the human asked for. Preparation and submission are distinct acts; only the reviewed bytes submit, identified by their content hash.
Plan.: The system's proposed work for a Request, identified by its content hash. What the human approves is the hash of what the human read.
Approval grant.: A single-use authorization cast by a named human, bound to exact content: a plan's hash, or a candidate's commit identifier with its checks fingerprint, together with the spending ceiling it authorizes. A grant authorizes one act, once.
Bounded run.: The single execution a build grant reserves: a named maximum cost, a named execution budget, no self-retry, no siblings.
Candidate.: The exact commit proposed for merge, on its named base branch, with the state of its checks at approval time reduced to one fingerprint.
Receipt.: The sealed artifact a completed change carries, derived only from independently verified evidence on the code host. A receipt can be retrieved; it can never be created or inferred from a claim.
Halt record.: A first-class sealed record of the system refusing or stopping. Honest refusal is part of the contract, never an error to hide.
The ledger.: The CreationLoop Ledger, operating under the foundation contract. Every record above seals to it.

section 03

The governance contract

A governed change carries six guarantees. Each names a property an independent party can check.

C1.

Exact-bytes approval.

A named human approves specific content, and the grant binds to that content's hash. A changed byte after approval voids the grant. There is no approving a description of the work; there is only approving the work.

C2.

Single-use authority.

Every grant is single-use and consumed atomically. An approval cannot be replayed, transferred, or spent twice. Conversation is never authority: chat text cannot approve, submit, build, or merge, and neither can an agent's tool call. Authority enters the system only as a named human's grant.

C3.

Bounded execution.

A build grant reserves exactly one bounded run under its named maximum cost and execution budget. The run cannot retry itself and cannot start siblings. Spend has a ceiling with a human's name on it.

C4.

Bound merge.

Merge approval binds to the exact candidate commit, its base branch, and the fingerprint of its checks at approval time, and it authorizes at most one merge attempt. A head that moved or checks that changed after approval void the grant.

C5.

Independent verification.

After any merge attempt, the system rereads the code host independently. Receipts derive only from that independently verified evidence. An agent's report that it merged is a claim; the code host's state is the fact; only the fact mints a receipt.

C6.

Sealed record.

Every request, plan, grant, run, halt, and receipt seals to the append-only ledger under the foundation contract's guarantees, inheriting its tamper evidence, its in-browser verification against the DNS-pinned key, and its external anchoring.

The verification model. Receipts verify exactly as the foundation contract specifies: in a browser, from one public link, against the ledger's published verification key, with no access to the operator's systems or ours beyond the public surface.

section 04

The lifecycle of a governed change

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

Prepare.

The request is drafted as exact visible bytes. Preparation creates no authority. Recorded: the draft and its hash. Checkable: that what later submitted is what was reviewed.

Submit.

A named human's single-use grant submits the exact request bytes. Recorded: the request, its hash, the grant. Checkable: C1 and C2.

Plan.

The system produces its plan, identified by hash, and stops. Recorded: the plan and its hash. Checkable: the plan the human read is the plan that ran.

Approve and build.

A named human's grant, bound to the plan's hash and a spending ceiling, reserves the plan's one bounded run. Recorded: grant, budget, run identity. Checkable: C1 through C3.

Candidate.

The run yields a candidate: an exact commit on a named base branch with its checks state fingerprinted. Recorded: commit identifier, base, fingerprint. Checkable: the candidate is inspectable in full before any authority touches it.

Approve merge.

A named human's grant binds to that exact commit, base, and fingerprint, authorizing at most one merge attempt. Recorded: the grant and its bindings. Checkable: C4.

Verify independently.

The system rereads the code host and records what is actually there. Recorded: the observed state. Checkable: C5.

Seal.

The complete record seals to the ledger and the change's Receipt becomes retrievable at its verify link. Checkable: the whole contract, from one link.

section 05

What we do not claim

This section is part of the product.

A receipt proves who approved which exact bytes, under what ceiling, what candidate carried what checks fingerprint, and what the code host held on independent verification. It never proves the code is correct, secure, or well designed. The checks fingerprint proves what the checks reported at approval time, never that those checks were sufficient. Code review remains human judgment; the record proves the judgment happened, by a named human, on the exact bytes, on the record.

What the system observes directly, the code host's state at verification, it records as observed. What an agent claims, it records as the agent's claim. A record never presents one as the other.

And the operating-history rule is inherited from the foundation: a record produced to demonstrate the system never counts toward an agent's operating history.

section 06

Identity and custody

Three parties are named in every record. The human who granted, holding approval authority. The agent that worked, holding its signing identity. The operator, the accountable organization. Governed agents appear on the Verified Agent Registry with Trust Cards under the foundation paper's identity rules, and the ledger publishes no scores there or anywhere.

Custody follows the workspace: a workspace's records seal under custody scoped to that workspace, and provider credentials remain the operator's own, held server-side and never entering agent context.

section 07

Integration and access

Agents connect over the protocol they already speak. The approval layer is served as tools an agent calls, and the design premise of every tool is the same: the agent can prepare, ask, and report, while authority stays outside the agent, entering only as a named human's grant. The agent's convenience never becomes the agent's authority.

Access follows one rule, inherited from the foundation: checking is free, issuing is the service. Anyone can open a receipt's verify link and validate it, always, with no account. Issuing receipts for governed changes is what operators engage CreationCode for, and the receipt is the unit of account. The service opens first through a small design-partner program; applications reach marino@creationloop.ai.

section 08

Failure, as the verifier sees it

Everything above is public, and the system is expected to hold. What failure looks like from the outside:

A forged or replayed grant is rejected: grants are single-use and consumed atomically.
A plan edited after approval no longer matches its approved hash; the grant is void.
A candidate whose head moved after approval no longer matches its bound commit; the grant is void.
Checks that changed after approval break the fingerprint; the grant is void.
A second run under a consumed build grant cannot start; the budget binds to the grant.
A merge an agent claims but the code host does not show yields no receipt; receipts derive from evidence, never from claims.
A halt is sealed, never suppressed.

What no one can obtain is authority without a named human, or a receipt without evidence. That is the property CreationCode exists to provide.

section 09

External anchoring

CreationCode's records inherit the foundation contract's external anchoring in full. On an interval, the ledger hashes its seal-chain head and anchors it to the Bitcoin network through an open timestamp-aggregation path, giving every earlier record proof of existence at a point in time that nobody, CreationLoop included, can backdate or quietly revise. 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.

To rewrite an anchored record, rewrite Bitcoin first.

Until an anchor is live, no record claims one.

section 10

Status

CreationCode runs in production on our own repositories first: the system is governed by the contract it sells, and its own changes carry the receipts this paper specifies. The service is opening to a small set of outside design partners; terms are set with the founder as part of the application.

A completed governed change on this ledger is public at its verify link. [GOVERNED-CHANGE RECEIPT PERMALINK, inserted at ratification]

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 governance contract will appear as new versions of this document, never as silent edits. This is version 1.