WAI Extension: Contribution Records

Mirrored from the canonical text at commit b1681667 (2026-10-22).

Status: Draft. Registers the record wai.media.contribution: who contributed what to a piece of media made by people and models together, and how much, computed from the process that made it. A tool signs a session naming its parties: people, each by a key and each countersigning its own membership, and models, each by its digest. Every act in the session is a signed step in a hash chain: a person authors or edits samples, a model generates, proposes candidates or inpaints a marked region, a party selects one candidate, transforms a state with a pinned derivation, composes layers, or rejects an output. Each act has a dependency rule, and re-executing the steps gives, for every sample of the output, the parties whose act produced its value (made_by) and the parties whose choices conditioned it (directed_by): the authorship map, computed rather than declared. A verifier checks what the steps say: that an edit or an inpainting changed no sample outside its region, that a selected output is a member of the set it was chosen from and that each candidate regenerates from its seed, that a transform recomputes, that the map recomputes, and that the output’s origin claim (synthesis) is at least what the map implies. The steps are the leaves of a Merkle tree, so a creator can disclose some of them with inclusion proofs; a prompt is a salted commitment until its creator opens it; and the outcome says which tier the disclosure reaches: recomputed, checked or stated. A sample whose label no disclosed, pinned rule fixes is unknown or undisclosed, never attributed to anyone, and the shares are sample counts per party, never one blended figure. No new transport. The reference implementation is the contribution module of wai-rs (feature contribution); the corpus is live-conformance/contribution/, and its second implementation is live-conformance/contribution_verify.py. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

Texts read for this revision, each pinned to the version named: the C2PA Technical Specification, version 2.4 (April 2026), §10.2.3.2, §18.2, §18.15.1, §18.15.2 and §18.15.4; the Creator Assertions Working Group’s Identity Assertion, version 1.2 (ratified 15 December 2025), §5.1, §5.1.2, §6.1 and §8; the IPTC Digital Source Type vocabulary as released on 2024-10-23; arXiv 2609.07711, §3.4; and Copyright and Artificial Intelligence, Part 2: Copyrightability, a report of the United States Copyright Office (January 2025), its table of contents and its Part V. A section number of one of those texts in this extension is that version’s.

1. Scope

Process-level provenance that captures who contributed what, and to what extent, within a co-creation session and across sessions, is named as an open research direction in arXiv 2609.07711 §3.4. WAI’s derivations are exact, so a record of the process can be re-executed to the artifact, and the map of who made each sample can be computed from it.

In scope: the records (§2) and the session with its parties (§3); the steps, the acts and their pinned operations (§4); the chain of steps and its Merkle tree (§5); the contribution record (§6); the authorship map, its dependency rules, its encoding and its shares (§7); disclosure and the privacy of process (§8); agreement with an origin claim and the mappings onto C2PA actions, identity assertions and live tracks (§9); verification (§10).

This revision maps still images of RGB8 samples in full. Audio maps by sample interval and video maps by frame are not part of it: a session’s media is image (§3.1), and a later revision registers the other media with their canonical buffers.

Out of scope, each a slot a later revision fills:

• Legal questions. WAI decides none. A registration authority, a collective or a court applies its own rule, case by case, to facts. The cited report takes up, in turn, assistive uses of AI systems, prompts, expressive inputs, and modifying or arranging AI-generated content (its Part II), and concludes that outputs may be protected in whole or in part where a person was able to determine the expressive elements they contain, and that prompts alone are unlikely to suffice (its Part V). A contribution record states, sample by sample, which party’s act produced each value and which parties’ choices conditioned it, and how much of that a verifier recomputed. It does not say which of those facts make anyone an author anywhere. Registering a work, and contacting any authority about it, are its owner’s decisions.
• Tooling and presentation of the map (later revisions’ tools).
• Aggregating an audience’s choices into one act: an audience party may act alone in this revision (§3.1), and a step on behalf of many is a later revision’s.
• Direction tracks: the act direct is reserved (§4.2) and refused until registered.
• Attribution through conditioning: a generation conditioned on an earlier state, and what an inpainting reads outside its region, attribute nothing here. generate and candidates take no input in this revision (§4.2). The works that condition a generation, a set of candidates or an inpainting (a reference image, an adapter, a taste prior, a catalogue) are named by influence, in a record beside the step that leaves the step as this extension reads it (influence §4.2), and the shares of the output that follow are computed there from this extension’s map.

Relationship to the core spec: wai.media.contribution is a record (SPEC §5): signed records a WAI tool emits and verifies. It names no payload format and is not dispatchable.

Relationship to synthesis: an origin claim says what an object is; a contribution record says how it was made and by whom, sample by sample. The record names the output’s origin claim, and a verifier holds the two to each other (§9.1). This extension takes synthesis §2’s encodings and its two integer derivations by name.

Relationship to deriving-edge: a transform or a composition of this extension evaluates one of that extension’s operations (§4.2 there) by its name, its parameters and its arithmetic, over states of a session rather than over delivered objects, with no envelope written. A deriving edge’s record chains published objects; a session’s steps chain the states of one piece of work.

2. Records

Every record of this extension is a JSON object (RFC 8259) under the encodings of jwp-receipts §2.4.3, read as synthesis §2 reads a record: strict JSON, no member named twice, at most 32 levels of nesting, byte strings in lowercase hexadecimal, integers unsigned and at most 2^53 − 1, no other number, no boolean, terms and date-times as defined there. Each record has exactly the members its section lists, no member missing and none added, at any level, and a kind naming it; one that does not is record_malformed. So is a member outside the values or ranges its section gives.

A signed record carries signer_pubkey (32 bytes, an Ed25519 key of RFC 8032) and sig (64 bytes):

sig       = Ed25519(signer_key, "wai:contribution\x01" || JCS(record without "sig"))
link_hash = BLAKE3("wai:contribution-link\x01" || JCS(record))

JCS is RFC 8785. The signature is verified strictly (SPEC §7 Signatures): a key that fails step 1 or 2 is bad_key, and a signature that fails a later step bad_signature. A record is named by its link hash wherever another names it. issued_at holds the instant its signer signed it, self-asserted.

A state is a picture a step produces: width × height pixels as the RGB8 buffer of reconstruction-binding §2 (row-major, three bytes a pixel, no row padding), each side at least 1 and the buffer at most 2^26 bytes. Its samples digest is SHA-256 (FIPS 180-4) over the buffer, and a state is named by it and by the step that produced it. A pixel is addressed (x, y), x to the right and y down from the top-left. A sample of the map is a pixel.

3. The session

3.1 The session record

The tool a session runs in signs a session record, kind "wai-session":

A party is one of:

• {"role": "human", "key"}: a person, by the Ed25519 key it signs with (32 bytes; as a did:key it is the same key);
• {"role": "audience", "key"}: a person in an audience, by its key;
• {"role": "model", "digest", "type"}: a model, by its prior’s digest (SPEC §3.1), or, for a generator that reads one model file and names it by SHA-256 (SPEC §5 Payload of wai.generate.spectral), by that file’s SHA-256; and type, trained or algorithmic as synthesis §3.1 has a model’s type.

A human or an audience party is a keyed party. No key appears twice, no digest twice, and no keyed party’s key is the tool’s (record_malformed), so the tool’s signature never stands for a person’s.

3.2 Membership

A keyed party countersigns its membership: it signs a membership record, kind "wai-membership", over the session as the tool signed it:

A membership whose session is not the session’s link hash, whose party is not a keyed party, or whose signer is not that party’s key is membership_invalid. A keyed party with no membership is party_not_countersigned: no person is enrolled as a party of a session, and so as a maker or a director of any sample (§7), without its own signature over the session’s parties. A model party signs nothing; the tool signs its acts (§4.1).

4. Steps

4.1 The step record

Each act is a step, kind "wai-step":

An output is {"samples", "width", "height"}, one state; for candidates it is {"set", "width", "height"}, a set of 2 to 16 states of one size by their samples digests, none twice; for reject it is null.

A step whose session is not the session’s link hash is session_mismatch; whose party, or a party its params name, is not a party of the session, party_unknown; whose performer’s role is not one its act admits (§4.2), party_role_mismatch; and whose signer is not the one this section names, signer_mismatch.

4.2 Acts

• author: samples a person made enter the session: a drawing, a recording, typed text set as an image.
• generate: a model produces a state.
• candidates: a model produces a set of states, committed by their digests and, where the generator is pinned, by their seeds.
• select: a party picks one member of a committed set. Its output is that member.
• edit: a person replaces samples inside the region with samples it made.
• inpaint: a model fills the region a party marked.
• transform: a derivation, with parameters a party chose, maps one state to another.
• compose: a party places layers on a canvas, or tiles them in a grid.
• reject: a party discards a state. The state stays committed, so a verifier sees what was discarded as well as what was kept.
• direct: reserved for direction tracks. A step whose act is direct is act_reserved.

A step that breaks the table’s inputs, output or region is record_malformed; an input of a select that is not a member of a candidates step’s set, or a select whose output is not its input, is selection_not_in_set (§10.2 step 6).

4.3 Parameters

A step’s params has exactly these members:

• generator: a term naming what generated: wai.generate.spectral (§4.5) or another.
• prompt: the salted commitment to the prompt (§8.1), 32 bytes, or null for none.
• prompt_by: the party that wrote the prompt; null exactly when prompt is.
• mask_by: the party that marked the region.
• seed, steps: integers or null; seeds: an array of one integer per member of the set, in the set’s order, or null.

4.4 The check

A step’s check says whether every sample it carries forward is fixed by a pinned rule:

• replicate: every sample the act carries from its inputs recomputes from them under an operation this revision pins (§4.5), and every sample a model introduces regenerates under a pinned generator. Samples a person introduces (author, an edit’s region) are that person’s own, the source the chain starts from, as a capture is in synthesis §3.2: there is nothing to recompute, and the signature says who made them.
• attest: a step that is not replicate: what it produced rests on its signer’s statement.

A generator another extension pins is not wai.generate.spectral: a step of influence’s conditioned generator, wai-influence:spectral-blend, is attest here, and that extension regenerates it (influence §4.4). A step whose check is not its act’s is check_mismatch. A replicate step’s parameters are those §4.5 gives its operation; a generate, candidates or inpaint step of wai.generate.spectral has a seed (each of its seeds) from 0 to 2^32 − 1 and steps from 1 to 64, and its output’s sides are each at most 4096 with width · height at most 2^23, the ranges SPEC §5 Payload of wai.generate.spectral gives an instruction object. Otherwise params_invalid. An attest step’s params under derivation is any object.

4.5 The pinned operations

Each operation computes its output from its inputs’ samples and its parameters, and defines, for each output pixel, the input pixels it reads: its sample mapping, which the map follows (§7.2).

Transforms:

• wai.derive.crop {"x", "y", "w", "h"}, wai.derive.rotation {"quarter_turns"} and wai.derive.mirror {"flip"}: deriving-edge §4.2’s, its parameters and its arithmetic exactly. Each output pixel reads the one input pixel that section copies to it.
• wai-synthesis:upscale2 and wai-synthesis:denoise3, {}: synthesis §4.1 and §4.2. Output pixel (2x, 2y) of the upscale reads in(x, y); (2x + 1, 2y) reads it and in(x₁, y); (2x, 2y + 1) reads it and in(x, y₁); (2x + 1, 2y + 1) reads those and in(x₁, y₁), with x₁ and y₁ as there. Each output pixel of the denoise reads the nine clamped pixels of its neighbourhood.
• wai-contribution:lut {"table"}, table 768 bytes: out(x, y) byte c = table[256 · c + in(x, y) byte c], for c 0, 1, 2. Each output pixel reads the input pixel at its own position. It is a value transform: a colour grade, a tone curve, a levels adjustment. No other WAI text pins a per-sample colour mapping, so this extension pins this one.

Compositions, over the step’s inputs in its order:

• wai.derive.overlay_composition {"width", "height", "fill", "at"} and wai.derive.grid_composition {"columns", "rows"}: deriving-edge §4.2’s. A pixel an input covers reads the pixel of the last input that covers it; a pixel of an overlay’s canvas that no input covers reads nothing and holds the fill.

Generation, for generate, candidates and inpaint:

• wai.generate.spectral: the reference generator SPEC §5 Payload of wai.generate.spectral names, generate(model, prompt, seed, steps, h, w), with the performer’s model file (whose SHA-256 is the party’s digest), the opened prompt’s text (§8.1), the empty string where prompt is null, and h and w the output’s. A candidates member at position k of the set is made with seeds[k]. An inpaint makes the picture at the input’s size and copies its samples inside the region; outside the region, the output is the input.

A parameter the inputs cannot satisfy (a crop outside its input, grid inputs of different sizes, an at entry missing) is params_invalid when the inputs’ sizes are known (§10.2 step 6).

5. The chain and its tree

5.1 The chain

A session’s steps are numbered from 0 by seq, and each names the link hash of the one before it in prev: a hash chain, so no step can be removed, inserted or reordered without breaking every link after it. A step whose seq is not below the record’s steps (§6), a seq given twice, a step 0 whose prev is not null, a later step whose prev is null, or a prev that is not the link hash of step seq − 1 where the verifier holds that step, is chain_broken.

5.2 The tree

The steps are the leaves of a binary Merkle tree, built as jwp-receipts §2.2 builds a group’s, over the steps’ link hashes in seq order, with domains of this extension’s own so that the root of a session’s steps can never be read as a group’s:

leaf(step)        = BLAKE3("wai:contribution-leaf\x01" || link_hash(step))
node(left, right) = BLAKE3("wai:contribution-node\x01" || left || right)

At each level with an odd number of nodes the last is duplicated; the root is the single node left. The duplicated last leaf also walks to the root from the position past it, so the record states the number of leaves, steps, and §5.1 refuses a seq that is not below it: no step can stand at a position the tree does not have.

A disclosed step carries an inclusion proof: its siblings from the leaf level upward, exactly ⌈log₂ steps⌉ of them (none for one step). It is walked as jwp-receipts §3 step 5 walks an object’s proof, with the leaf index the step’s seq and the direction bits the bits of seq: at level i, bit i of seq set means the current node is the right child. A proof of another length, or one that does not reach the record’s root, is inclusion_failed.

6. The contribution record

The tool signs the contribution record, kind "wai-contribution":

A record that is not the session’s is session_mismatch; one not signed by the tool’s key, signer_mismatch; one whose origin is not null while content_hash is, record_malformed.

An estimate is {"estimator", "class", "party", "basis", "share_ppm"}: a term naming the method, a term naming its class (the family of methods it belongs to, such as an information-theoretic one), a party (party_unknown otherwise), made_by or directed_by, and the share it estimates in parts per million, at most 1 000 000. An estimate is the tool’s statement with its class, as an energy figure carries its class: a verifier reports it as stated, beside the counts of §7.4 and never in place of them, and never adds it to them.

7. The authorship map

7.1 Labels

Every sample of the output has a label: two sets, made_by, the parties whose act produced the sample’s value, and directed_by, the parties whose choices conditioned it (a prompt, a mask, a selection, a transform’s parameters, an arrangement). A set holds parties, and may hold one of two markers:

• unknown: no pinned rule fixes where the sample’s value came from, even with every step disclosed: an attest transform or composition does not pin its sample mapping;
• undisclosed (in a verifier’s computed map only, never in a stated one): the sample comes from a state whose step the verifier does not hold.

A marker is never a party and is never counted as one: unknown is never zero. A sample a rule cannot attribute is reported as such, not credited to anyone.

7.2 Dependency rules

The map of a state is computed from its step and its inputs’ maps. The map of an input whose step the verifier does not hold has every sample ({undisclosed}, {undisclosed}). For a step performed by party a:

So a geometric transform carries each label through its exact sample mapping; a filter that mixes pixels takes the union of what it mixes; a value transform keeps made_by and adds its chooser to directed_by; a selection keeps the chosen candidate’s map and adds the selector everywhere; a composition takes each layer’s map where the layer is visible. A model’s samples, generated or inpainted, are made_by that model whether or not its generator is pinned: the act places them, and the step’s status (§10.3) says whether they were regenerated. An edit’s or an inpaint’s region takes nothing from the samples it replaced: they no longer condition it.

Where the verifier does not know an input’s size (its step is not held), the sample mapping cannot be followed; a transform or compose then gives every output sample ({undisclosed}, {undisclosed, a}), and a select gives the input’s label as above. The output’s map is the map of the state the record’s output names: the one its step produced.

7.3 Encoding

The map is a JSON object under §2’s encodings, kind "wai-authorship-map", unsigned and bound by its digest:

A set is an array of party positions in ascending order, then "unknown" where it holds that marker; a stated map holds no "undisclosed". Every party is a party of the session. A map that is not one JSON text under §2’s encodings, or that breaks any of these rules, is map_malformed: each map has one encoding.

map digest = BLAKE3("wai:contribution-map\x01" || JCS(map))

The record names the map by its digest, and the map names the output’s samples digest and size, so the map is bound to the samples it describes. A map whose digest is not the record’s map, or whose output, width or height is not the record’s output’s, is map_unbound.

7.4 Shares

The shares of a map are exact sample counts: the number of samples; for each party, the number of samples whose made_by holds it, and separately the number whose directed_by holds it; and, for each of the two sets, the number of samples holding unknown and the number holding undisclosed. A sample counts once for each party its set holds, so a sample two parties made counts for both. The counts are never combined into one figure: what made_by and directed_by mean is a reader’s to weigh under its own rule.

8. Disclosure

8.1 Salted commitments

A prompt, and any other text a party gives a step, is carried as a salted commitment:

commitment = SHA-256(salt || UTF-8(text))

with salt 32 fresh random bytes for each commitment. A short or guessable prompt cannot be recovered by hashing candidates: the salt is not disclosed with the step. An opening {"commitment", "salt", "text"} discloses one: the salt (32 bytes) and the text (a string). An opening whose salt and text do not hash to its commitment is opening_mismatch.

8.2 What each disclosure gives

A creator discloses some or all of the steps, each with its inclusion proof, and some or all of the states, the openings of the prompts and the model files a pinned generator reads. The tier of the outcome (§10.3) follows from what is disclosed:

A withheld prompt stays private: its commitment binds the step to it, and the step’s map does not depend on its text. A withheld step stays private too: its leaf is in the root, so it cannot be replaced later, and the samples it produced are undisclosed, never credited to anyone.

9. Agreement and mappings

9.1 The origin claim

Where the record names an origin claim (synthesis §3.1) the verifier holds, read by synthesis §2 and §3.1:

• its subject is the object output.content_hash (origin_mismatch);
• where any sample of the stated map is made_by a model party, its class is synthesized (origin_understated): an object any part of which a model generated or inpainted is not captured, reconstructed or assistive, as synthesis §3.2’s lattice has it.

9.2 The C2PA actions

Where every step is disclosed, the record gives one C2PA statement, {"actions": A}, written in JCS: A is the actions of the output’s manifest (C2PA 2.4 §18.15.1), one per step behind the output, in seq order, after a first c2pa.created action:

• first: {"action": "c2pa.created", "digitalSourceType": "http://c2pa.org/digitalsourcetype/empty", "softwareAgent": {"name": T}}, T the session’s tool: a session is begun on an empty canvas in a tool, and C2PA 2.4 §18.15.2 asks for c2pa.created first with that source type;
• then, for each step, the action below with "softwareAgent": {"name": N}, N the tool for a keyed performer and tag:transaction.science,2026:wai/model/ followed by the digest in lowercase hexadecimal for a model (synthesis §6’s model identifier), a generator-info map (C2PA 2.4 §10.2.3.2) with its name:

An action’s members are written in the order JCS gives them. changes (C2PA 2.4 §18.15.4.6) is one region map (§18.2): [{"region": R}], R one spatial range for each rectangle, in the step’s order, {"type": "spatial", "shape": {"type": "rectangle", "unit": "pixel", "origin": {"x": X, "y": Y}, "width": W, "height": H}}, the coordinates as integers (a manifest in CBOR writes them as the floats §18.2.3 types them). The IPTC term is http://cv.iptc.org/newscodes/digitalsourcetype/ followed by the code. The trained models’ c2pa.ai-disclosure assertions are the origin claim’s (synthesis §6). A rejected state, and a branch of the session the output does not come from, give no action: they did not make the asset. Embedding the statement in a manifest, and signing it, is C2PA’s.

9.3 Identity assertions (informative)

A keyed party may give the output’s manifest an identity assertion (Identity Assertion 1.2 §5.1, label cawg.identity) whose referenced assertions include the actions assertion of §9.2, as §6.1 there recommends for an actor who performed those actions, under a credential of §8 there. The roles of §5.1.2 there (cawg.creator, cawg.contributor, cawg.editor, …) are the party’s own statement of its relationship to the asset; this extension does not derive one from the shares. The party’s key in the session is an Ed25519 key, not a credential type of §8 there, and the relation between the two is the party’s to state.

9.4 Live tracks (informative)

A record covers one still. Over live-provenance, a manifest that covers such a still (a picture a room shares, a frame made in a session and then streamed) can name the record by its link hash in an entity-specific assertion of the kind that extension’s §5 defines for the stream, the group and the take; the record, its session, its memberships, its disclosed steps and its map are then offered by the carriage that offers the track’s receipts, as deriving-edge §6 offers a chain’s records. Per-frame maps of a live track are a later revision’s.

10. Verification

10.1 Inputs

A verifier is given: the session record; its memberships, in a list; the contribution record; the disclosed steps, in a list, each with its inclusion proof; the authorship map; the openings it holds, in a list; the states it holds, each a buffer, named by its samples digest; the model files it holds, each named by its SHA-256; the origin claims it holds, in a list; and a policy of one member:

10.2 Steps of verification

The verifier runs these steps and stops at the first refusal, which it reports with its reason and its place: ["session"], ["session", "party", i], ["membership", i], ["record"], ["step", i], ["map"], ["map", x, y], ["opening", i], ["origin", i] or ["policy"], each i a position in its list (a party’s among the parties) and (x, y) a pixel.

1. Reading (§2, §3, §4.1–§4.3, §6, §7.3, §8.1): the session, the memberships, the record, the steps, the map and the openings, each in order, read and their signatures verify; the origin claims read and verify by synthesis §2 and §3.1. record_malformed, bad_key, bad_signature, act_reserved, map_malformed. A step whose act is direct is act_reserved once its members are read, whatever they hold. A proof that is not an array of 32-byte strings is record_malformed.
2. Openings (§8.1): opening_mismatch.
3. Membership (§3.2): each membership in order (membership_invalid), then each keyed party in order (party_not_countersigned).
4. The record (§6): session_mismatch, signer_mismatch, and each estimate’s party (party_unknown).
5. Each step, in the order given: session_mismatch, party_unknown, party_role_mismatch, signer_mismatch (§4.1); check_mismatch and params_invalid (§4.4); chain_broken (§5.1); inclusion_failed (§5.2).
6. Each step against the states, in seq order, each by these checks in order:
   1. each state its output names that the verifier holds is width · height · 3 bytes (samples_mismatch);
   2. each input whose step the verifier holds is that step’s output, or a member of its set (input_unknown); for a select, instead: its output is its input, and where the verifier holds the input’s step, that step is a candidates step and the input is a member of its set (selection_not_in_set);
   3. for an edit or an inpaint whose input’s step is held, that step’s output has this step’s output’s size (region_invalid);
   4. for a replicate transform or compose whose inputs’ sizes are known (the verifier holds each input’s step): its parameters hold over them (§4.5, params_invalid), and the size they give is the output’s (recompute_mismatch);
   5. the act’s own check, where the verifier holds what it reads:
      • edit, inpaint: a held buffer of the input that is not of the output’s size is region_invalid; with the input’s and the output’s samples held, every pixel outside the region is the input’s, byte for byte (outside_region_changed);
      • generate, candidates, replicate: with the model file and the prompt’s opening (where prompt is not null) held, each state regenerates (§4.5): the samples digest of what the generator makes is the state’s (regeneration_mismatch);
      • inpaint, replicate: with the model file, the prompt’s opening and the output’s samples held, every pixel inside the region is the generator’s picture’s (regeneration_mismatch);
      • transform, compose, replicate: with every input’s samples held, the operation evaluated over them gives the output’s size and samples whose digest is the output’s (recompute_mismatch).
7. The output (§6): where the verifier holds the step output.step, that step’s output is one state with the record’s samples digest and size (output_mismatch); a held buffer of the output’s digest is width · height · 3 bytes (samples_mismatch).
8. The map (§7): the map is bound (map_unbound). The verifier computes the output’s map by §7.2 from the steps it holds and compares it with the stated map, pixel by pixel in row-major order, made_by then directed_by. Where the computed set holds undisclosed, the parties and the unknown it holds besides are in the stated set; otherwise the two sets are equal. At the first pixel where that fails: unknown_attributed where the computed set holds unknown and the stated set does not (a sample no pinned rule fixes, credited to a party); otherwise map_mismatch.
9. The origin claim (§9.1): origin_mismatch, origin_understated, at the claim’s place.
10. Policy: an outcome below the policy’s tier is tier_not_met.

10.3 Statuses and tiers

Each step the verifier holds has a status:

• attested: its check is attest;
• checked: its check is replicate, the verifier holds the step of each of its inputs, and each check of step 6.5 its act has run (an author and a reject have none, a select’s is step 6.2’s against the held candidates step, and an edit needs both of its states held, an inpaint its states, its model file and its opening);
• not-checked: otherwise.

The steps behind the output are the step output.step and, recursively, the step of each input of a step behind the output. The outcome’s tier:

• recomputed: every step behind the output is held, and checked;
• stated: the verifier holds no step;
• checked: otherwise.

10.4 What an accepted case states

• tier (§10.3);
• session and record: the link hashes of the session record and the contribution record;
• steps: each held step in seq order, its seq, act, party, check and status;
• committed: the number of steps not held;
• computed and stated: the shares (§7.4) of the computed map and of the stated map, each samples; made_by and directed_by, each a list of {"party", "samples"} for the parties with a count above zero, in ascending order of party; and made_by_unknown, made_by_undisclosed, directed_by_unknown and directed_by_undisclosed;
• estimates: the record’s, as stated;
• origin: agree where the claim the record names was held and checked, not-checked where it was not held, null where the record names none;
• c2pa: the statement of §9.2 as its JCS text, where every step is held; otherwise null.

11. Reasons

The codes this extension adds, each with where it is raised:

12. Conformance

live-conformance/contribution/ holds the corpus, in one file, vectors.json, written from fixed seeds by wai_contribution_vectors gen. It holds the model file of wai.generate.spectral its sessions generate with, and the vectors: each a case of §10.1, its outcome and, accepted, everything §10.4 states; refused, its reason and its place. The exact generator of the corpus is wai.generate.spectral, with the model file of its conformance vector (wai-rs/tests/vectors/generate/generate_spectral_model.json). It has:

• Accepted, recomputed: a person’s drawing, a collaborator’s brush edit inside a region, and a crop, with a captured origin claim that agrees; an inpainting by the pinned generator inside a region one person marked, from a prompt another wrote, regenerated, with a synthesized origin claim that agrees; three candidates, each regenerated from its seed, one selected by an audience member, one rejected, then a colour table applied; a generated layer composed over a drawing and a fill; and a chain of transforms (rotation, mirror, upscale, denoise, crop), each recomputed.
• Accepted, checked: an inpainting by a trained model the tool attests, its outside region checked; an attested scaling whose output is unknown; the candidates session with its generating step undisclosed, its samples undisclosed; and the same with every step disclosed but the prompts withheld, so no candidate is regenerated.
• Accepted, stated: the record and the map, no step; and a record that attaches an estimate with its class.
• Refused: each reason of §11 at least once, each a control of one defect, and a second control for each check that has a second place in §10.2: among them a sample outside an edit’s region changed, a selected output not in its set, a candidate and an inpainted region that do not regenerate, a map that does not recompute, a gap in the chain and a prev that skips its predecessor, a step by a party the session does not have, a person enrolled without countersigning, an attested region credited to a person instead of unknown, an origin claim of a lower class than the map implies, and a prompt commitment that does not open.

A conforming verifier gives every vector the outcome, the reason, the place and the statements the corpus states. wai_contribution_vectors verify and the test tests/contribution.rs check that the file regenerates byte for byte, that wai-rs gives every vector its outcome, and that §11 lists exactly the reference’s codes. live-conformance/contribution_verify.py is the second implementation, written from this text: it shares no code with wai-rs; it computes every map itself, evaluates every pinned operation and runs the generator in its own arithmetic, checking that arithmetic first against the generator’s conformance vector (wai-rs/tests/vectors/generate/sha256.json); it reads origin claims with the synthesis corpus’s second implementation (synthesis_verify.py), verifies every signature with WAI’s strict rule (claim-conformance/_ed25519.py) and every link hash with BLAKE3 written from its specification (claim-conformance/_blake3.py); it mutates copies of the corpus and requires every copy to fail; and it drops each of its own checks in turn and requires the corpus to catch the weakened verifier.

13. Security and privacy considerations

• What is checked and what is stated. A step is signed by the party that performed it, or by the tool for a model. The samples a person introduces are that person’s statement: WAI checks everything that happened to them afterwards, not whether the person made them without a model. An author step’s source says what the person made, as a capture’s claim does. A model’s samples from an attest generator are the tool’s statement; from a pinned generator they are regenerated, so the step proves exactly what was generated, and that no person painted it.
• The region. An edit or an inpainting is checked, not claimed, to have changed nothing outside its region: a verifier holding the two states compares every pixel. What a model’s fill read from outside the region conditions it, and is not attributed in this revision.
• Taste as evidence. A candidates step commits every candidate by digest and seed, and a reject keeps what was discarded committed, so a verifier that regenerates the set sees what was chosen over what.
• Withholding. A creator who discloses part of a session cannot change the rest later: the record’s root commits to every step. A withheld step’s samples are undisclosed and a withheld prompt is a salted commitment; neither is ever credited to a party. A creator who withholds can only lower the tier the outcome reaches.
• Enrolment. A person is a party only by countersigning the session, so a tool cannot credit a person, or blame one, without that person’s signature over the whole list of parties. A model party signs nothing; its acts are the tool’s statements about it.
• Not a judgment. A record states facts sample by sample; it ranks no contribution, and its counts are exact where a rule fixes them and marked where none does. An estimate is the tool’s, with its class, and is never mixed into the counts. What any of it means for authorship is decided elsewhere, by others, under their own rules.
• Privacy of process. Prompts are committed with a salt; a session names parties by keys and digests, never by name; the states are digests unless disclosed. A disclosed state is a picture, and a creator discloses what it chooses.