WAI Extension: Deriving Edge

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

Status: Draft. Registers the record wai.edge.derivation: an edge that derives new objects from objects a publisher delivered, publishes each one under receipts of its own, and signs a derivation record that chains it to its source. An edge may evaluate a wai.derive.* operation of derived-tracks over decoded samples, rebuild an object at a lower rung for a sink that lacks the capability it was coded in (decode a wai.video.int_motion clip and write a frame of it as a wai.image.png still), or re-package an object without re-encoding it (explode a WAI2 component into its WAI1 envelope). The record names each input by its content hash and the delivery receipt that carries it, and by the record that derived it where another edge did; the derivation and its parameters; the output by its content hash and receipt; and the energy the derivation took, with its acquisition class. Its check says how a verifier holds the edge to it: replicate, when every step is pinned, so any verifier holding the inputs re-executes the derivation and compares the output byte for byte; or attest, when a step is not (a lossy classical encode, a resampling), so the output rests on the edge’s signature. A sink verifies its object back to its source, hop by hop, and its policy may refuse attested hops. Each record carries forward, by digest, every provenance item its inputs had — the claims about them, the C2PA Manifest Stores bound to or embedded in them, and what their own records carry — in a system or a personal compartment, and an AI-origin label that no hop may lower; a hop that omits an item or lowers a label is refused. Relays still forward every envelope and receipt unaltered (jwp-receipts §4): an edge alters nothing it received; what it derives is a new object of its own. No new transport. The reference implementation is the derive_edge module of wai-rs (feature derive_edge) and its reference edge, wai_edge; the corpus is edge-conformance/, and its second implementation is edge-conformance/edge_verify.py. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

Texts read for this revision: the WAI texts this one cites; RFC 8032 and RFC 8785; California Assembly Bill 853 (Statutes of 2025, Chapter 674), as chaptered, for Business and Professions Code §22757.1 (n), (o) and (p) and §22757.3.1; and the C2PA Technical Specification, version 2.4, §A.3.2 (a manifest store in PNG) and §18.15 (actions). The operations’ names are ISO/IEC 23001-16:2021’s, as derived-tracks registers them; this extension defines its own parameters and arithmetic for them (§4.2), and does not read the parts of that standard derived-tracks did not read.

1. Scope

In scope: what an edge may derive and what it must not do (§3); the derivations this revision registers, how each reads its inputs, what it computes and how it writes its output, and which check each takes (§4); the derivation record, its signature and its identity (§5); how an edge publishes what it derives, carries its inputs’ provenance forward and keeps their AI-origin label (§6); verification of a derived object back to its source (§7); who may sign a record (§8).

Out of scope: a transport, and how a record reaches a sink, which is the carrier’s, as it is for receipts (jwp-receipts §1); how a sink asks an edge for a derivation, and which derivations an edge offers; how an edge measures its energy, which energy-measurement governs; presentation, which stays with the sink (derived-tracks §1); and any derivation this revision does not register.

Relationship to the core spec: wai.edge.derivation is a record (SPEC §5): a signed record a WAI tool emits and verifies. It names no payload format and is not dispatchable. A derived object is an ordinary envelope of its own capability, dispatched by SPEC §4 like any other.

Relationship to jwp-receipts: this extension changes no receipt. A relay forwards what it receives as §4 there requires, byte for byte, and §4.3’s rules stand: a relay re-signs no receipt and rewrites no envelope. An edge that derives is a relay for what it forwards and a publisher for what it derives: each output is a new object with its own content hash, in a group the edge signs with its own key (§6). The derivation record is the separate, parallel statement §4.3 there asks of a relay that attests, and §7.5 there registers its authority (§8).

Relationship to derived-tracks: an operation of §4.2 is that extension’s operation of the same capability string, executed under conditions this profile fixes, so that derived-tracks §3 gives the output’s tier from its inputs’ (§4.5). The record carries the content derived-tracks §4 lists for a receipt over a derived sample, in a layout of its own: the executed operation, its parameters, the frame each input was read at, the inputs by content hash, and, where the check is replicate, the output.

Relationship to SPEC §7.1: an output of one input carries derived_from, naming that input as its motif (§4.3). A sink presents it as what it is, a derived object; it does not reconstruct its motif.

2. Terms

• Edge: a party that derives objects from objects it received and publishes them; named by its Ed25519 key (RFC 8032).
• Derivation: one of §4’s, evaluated once: a set of inputs, its parameters, one output.
• Input, output: the objects a derivation reads and the object it writes, each a whole WAI1 or WAI2 envelope (SPEC §2, §7.1).
• Record: the derivation record of §5. Its hash is its identity (§5.2).
• Source object: an input whose delivery receipt is signed by a key the verifier takes as a source: a publisher it subscribed to (§7.1).
• Hop: a record. The chain of a derived object is its record, and, for each of that record’s inputs that an edge derived, the chain of that input, down to source objects.
• Samples: an image as the canonical RGB8 buffer of reconstruction-binding §2: row-major, three bytes a pixel, no row padding. A pixel is addressed (x, y), x to the right and y down from the top-left. The samples digest is SHA-256 (FIPS 180-4) over the buffer.
• Content hash: jwp-receipts §2.1. A group receipt’s link hash: jwp-receipts §3 step 3.

The record is JSON under the encodings of jwp-receipts §2.4.3: lowercase hexadecimal byte strings, unsigned integers of at most 2^53 − 1 in plain decimal, no other number, no boolean, terms and date-times as defined there, no member named twice. JCS is the canonical form of that section (RFC 8785).

3. What an edge may derive

3.1 Three kinds

1. Evaluate an operation. Read each input as samples (§4.1), evaluate one operation of §4.2 over them, and write the result in an image capability (§4.3).
2. Rebuild at a lower rung. Read an object coded in a capability a sink lacks, and write it in a capability of SPEC §5’s mandatory floor or recommended set: a frame of a wai.video.int_motion clip, as a wai.image.png still or a wai.image.jpeg picture. A rebuild is an evaluation of wai.derive.identity over one frame (§4.2): the read and the write change the capability, and the operation changes no sample. It serves a sink at which the object is inert (SPEC §4 step 6).
3. Re-package. Change the container without decoding: wai-edge:explode writes one component of a WAI2 envelope as its exploded WAI1 envelope (SPEC §7.1, Exploding a component; §4.4). The output’s payload is the component’s bytes.

3.2 What an edge does not do

An edge MUST NOT:

• alter an envelope or a receipt it received, or forward one under its own signature (jwp-receipts §4.3);
• publish an output under any key but its own, or in a group of another key’s track (§6);
• present an output as the object it was derived from: an output has its own content hash and its own receipts, and the source’s receipts never cover it;
• sign a record over a derivation this revision does not register, or over an object it did not derive;
• sign replicate for a derivation whose check is attest (§4.5);
• leave out of its record a provenance item an input had, or label its output lower than an input (§6.1, §6.2).

3.3 What an edge derives from

An edge derives only from objects it has verified: each input’s delivery receipts verify (jwp-receipts §3 steps 1–5), its envelope hashes to its content hash, and, for an input another edge derived, its chain verifies by §7. It names in its record, for each input, the record that derived it, so that a sink can follow the chain (§7.3).

4. The derivations

A derivation is named by the string in its first column. The wai.derive.* strings are derived-tracks’ registered operations; wai-edge:explode is a term of this extension and not a capability string. The other operations derived-tracks registers are not derivations of this revision: wai.derive.srgb_fill reads no input, so an output of it chains to no source, and wai.derive.dissolve has a time structure of its own, which an input read at one frame does not give it.

4.1 Reading an input

An evaluation reads each input at one frame, the input’s frame (§5.1), as samples:

• wai.image.png: frame 0, read by the still reader of packaging §5 (A piece’s ladder, and stills) as 8-bit RGB; the envelope MUST hold no chunk but IHDR, IDAT, IEND and caBX. An ancillary chunk can state a colour representation the samples do not carry (cHRM, gAMA, iCCP, sRGB and others), and this profile’s representation is the samples alone. A caBX chunk holds a C2PA Manifest Store (C2PA 2.4 §A.3.2): it describes the content and changes none of its samples, and the record carries it forward (§6.1).
• wai.video.int_motion: the WIV1 payload with keyframe 0 (integer-payloads.md §3), decoded in full by its pinned decode; frame frame of the clip, which MUST be one of its frames. A clip with keyframe 1 decodes through a parameter set, and is not read here.

An input of either capability holds decode-equivalence (determinism-tiers §2): every conforming reader reads the same samples. An input that does not read as its record states it — another capability, a frame it does not have, a payload its reader refuses, a chunk this section excludes — is refused (input_unreadable).

4.2 The operations

Each operation computes its output samples from its inputs’ samples and its parameters by the rule below, and no other arithmetic. W × H is an input’s width and height; out(i, j) is the output pixel at (i, j) and in(x, y) an input’s, all three bytes of it. An output’s width and height are each at least 1, and its samples at most 2^26 bytes; a parameter the inputs cannot satisfy (a region outside an input, an output past that bound) is refused (params_invalid) when the inputs are evaluated (§7.2 step 5).

• wai.derive.identity, no parameter ({}): out = in.
• wai.derive.crop and wai.derive.roi_selection, { "x", "y", "w", "h" }: w and h at least 1, x + w ≤ W, y + h ≤ H; the output is w × h and out(i, j) = in(x + i, y + j). This profile emits an ROI at its own size, so the two operations compute the same samples; each is named by its own string.
• wai.derive.rotation, { "quarter_turns" }, 1, 2 or 3 quarter turns clockwise. For 1 and 3 the output is H × W, for 2 W × H; out(i, j) is in(j, H − 1 − i) for 1, in(W − 1 − i, H − 1 − j) for 2 and in(W − 1 − j, i) for 3.
• wai.derive.mirror, { "flip" }, left-right or top-bottom: out(i, j) is in(W − 1 − i, j) or in(i, H − 1 − j).
• wai.derive.grid_composition, { "columns", "rows" }, each at least 1, over exactly columns × rows inputs of one size W × H: input k fills the cell at column k mod columns and row ⌊k / columns⌋ of a columns·W × rows·H output. Inputs of different sizes are refused (params_invalid).
• wai.derive.overlay_composition, { "width", "height", "fill", "at" }: a canvas of width × height, each at least 1, every pixel fill (six lowercase hexadecimal digits, the red, green and blue bytes); then each input k, in order, written over it at its own size with its top-left at at[k] ({ "x", "y" }, one entry per input), opaquely: out(x + i, y + j) = in_k(i, j) for every pixel of the input that falls on the canvas. Pixels off the canvas are dropped.
• wai.derive.scaling, { "width", "height" }, each at least 1: the input resampled to width × height. This revision pins no resampling arithmetic, so the samples are the edge’s (§4.5). The reference edge takes the nearest sample, in(⌊i · W / width⌋, ⌊j · H / height⌋); a verifier does not hold an edge to it.

Under these rules every operation but scaling is exact for the instance it executes, in the sense of derived-tracks §2: its inputs and output are 8-bit RGB with no stated colour information, and the canvas fill is a constant the record names (same-representation); it copies samples and computes none (copies-only); each input is one frame, and the parameters have one value (time-invariant); a region or a cell lies on the sample grid, a rotation is a multiple of 90° over one resolution, a reflection maps the grid onto itself, and a composed input is placed at its own size at integer offsets, opaquely. Scaling computes new sample values, and derived-tracks registers it untiered.

4.3 Writing the output

The output of an evaluation is a WAI1 envelope whose manifest is, with no other bytes and no whitespace, members in this order:

{"wai":"1.0","media":"image","intent":"replicate","model_requirement":{"capability":C},
 "conditioning":{"kind":K},"derived_from":{"motif":M,"motif_capability":MC,"renderer":R,
 "settings":S},"target":{"frames":1,"h":HEIGHT,"w":WIDTH}}

(shown here on three lines). C is the output capability and K its last dot-separated segment (png, jpeg); HEIGHT and WIDTH are the output’s. derived_from (SPEC §7.1) is written exactly when the derivation has one input: M and MC are that input’s content hash and capability, R is the derivation followed by @1 when the record names no encoder and the encoder’s id otherwise, and S is BLAKE3("wai:render-settings\x01" ‖ JCS(settings)) with settings the object {"derivation", "encoder", "frame", "params"} of the record’s members of those names and the input’s frame. An output of several inputs carries no derived_from: it presents several motifs, and its record names them all. Strings are written as JSON strings, integers in decimal; nothing in them needs an escape.

The payload:

• wai.image.png, the record naming no encoder: the samples as packaging §5’s still writer writes them, every byte a pure function of the samples;
• otherwise the output of the encoder the record names, run with the settings it states: a PNG of the samples for wai.image.png, a baseline JPEG of them (ITU-T T.81, SPEC §5) for wai.image.jpeg. This revision pins no JPEG writer, so a wai.image.jpeg output always names one.

4.4 Re-packaging

wai-edge:explode, { "component" }, reads one input, a WAI2 envelope, and writes the exploded envelope of its entry number component (from 0), exactly as SPEC §7.1 defines it: the entry’s envelope_manifest where it carries one, and otherwise the manifest that section assembles from the WAI2 manifest’s members, over the entry’s rendition bytes. Nothing is decoded and no sample is read. The output’s capability is the entry’s, and the input’s capability in the record names it too. An entry that cannot be exploded, or a component past the last entry, is refused (input_unreadable). A component and its exploded envelope are the same object for every rule that names an object by content hash (SPEC §7.1), so an exploded output is the object a sink would have taken from the WAI2, now carried on its own, under the edge’s receipts.

4.5 The check

A derivation’s check is replicate exactly when every step of it is pinned: the reading of its inputs (§4.1 pins every reading this revision has), its operation, which is exact (§4.2), and its writer, which is packaging §5’s still writer for a wai.image.png output whose record names no encoder, or SPEC §7.1’s explode. Otherwise its check is attest:

• replicate: a verifier holding every input re-executes the derivation and requires the output envelope, byte for byte (§7.2 step 5). Over inputs at decode-equivalence the output’s samples hold decode-equivalence too (derived-tracks §3 rule 1), and so does the output: PNG is lossless.
• attest: the step that is not pinned rests on the edge’s signature. A verifier still checks every input, and every step before the first that is not pinned: the inputs’ samples, and, where the operation is exact, the samples the edge gave its encoder. For any wai.image.png output, attested or not, it checks that the output’s samples are the ones the record states (§7.2 step 3). It never checks the attested step itself.

A record’s check MUST be its derivation’s (check_mismatch): one derivation has one check, and a sink reads from the record what it is relying on.

5. The derivation record

5.1 Members

A record is a JSON object with exactly these members, under §2’s encodings:

An input:

A provenance item:

The output:

5.2 Signature and identity

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

The signature is verified under jwp-receipts §3.1 step 3’s strict rule. A record SHOULD be sent in canonical form; relays forward it byte for byte.

5.3 Reading and rules

A reader reads a record and refuses at the first of these that holds:

1. It is not one JSON text of the shape §5.1 gives, with every member of the right type and encoding, no member missing and none added, at any level, kind "wai-derivation", and its provenance items in their order, none twice, each naming an input the record has (record_malformed).
2. Its derivation is not one of §4 (derivation_unknown).
3. Its params do not hold exactly the derivation’s members, each in its range (§4.2, §4.4): w, h, width, height, columns and rows at least 1; quarter_turns 1, 2 or 3; flip one of its two values; fill six lowercase hexadecimal digits; at one entry per input, each { "x", "y" }; a size the parameters fix (a region’s, a canvas’s, a scaling’s) within 2^26 sample bytes. Or its encoder is null where §4.3 pins no writer (a wai.image.jpeg output), or not null for wai-edge:explode. Or its output capability is not one the derivation writes (§4), or, for wai-edge:explode, not the input’s (params_invalid).
4. Its inputs are not the derivation’s: another number of them (columns × rows for a grid), an input of a capability §4.1 does not read, a frame, input samples, output width, height or samples that is null for an evaluation or not null for an explode, or a frame other than 0 for a wai.image.png input (inputs_invalid).
5. Its check is not its derivation’s (§4.5) (check_mismatch).
6. Its energy breaks energy-measurement §2: a figure of 0 beside a class, the legacy HwShunt, a class that does not read, a hardware class without its evidence or below the resolution floor (§2.3 there) (energy_invalid).
7. Its synthesis is lower than an input’s (§6.2) (synthesis_dropped).

6. Publishing the output

An edge publishes each output on a track of its own, under its own key, as a publisher does (jwp-receipts §2): a group receipt it signs and an object receipt for the output, whose content_hash is the output’s. The record’s output.receipt and output.object_id name them.

• The group receipt’s signer_pubkey is the record’s (output_receipt_mismatch).
• The object receipt’s joules_micro is the record’s figure, 0 where energy is null. Where the object receipt carries a class label (jwp-receipts §2.4.2), the label is the record’s class and evidence, or the unmetered marker where energy is null (energy_disagrees). An edge SHOULD label its object receipts, and sign its groups over the labelled payload.
• The output is a new object: its receipts bind it to the edge’s key and nothing else. What binds it to its source is the record.

An edge serving a derived object MUST offer its subscriber the record of each hop of the object’s chain, the delivery receipts each record names and the provenance items each carries (§6.1), by the same carriage as the object’s receipts. Without them a sink can verify the object’s delivery from the edge and nothing about where it came from. It forwards the source’s receipts unaltered (jwp-receipts §4.1).

6.1 Provenance carried forward

A derivation makes a new object, and nothing the source carried is in it unless the edge puts it there: a still the pinned writer writes holds no chunk but its picture, and an explode writes a new envelope. So a record carries its inputs’ provenance forward, by reference.

The provenance items of an input are, of what the edge received:

• each claim (jwp-receipts §2.4.3) whose subject_type is object and whose subject is the input’s content hash, named by its link hash;
• each C2PA Manifest Store bound to the input, carried beside it or embedded in it (for wai.image.png, the data of a caBX chunk, C2PA 2.4 §A.3.2), named by its SHA-256;
• for an input another edge derived, every item that edge’s record carries, whatever input of it the item came with.

A record MUST list every provenance item of every input, each with the input it came with and its compartment, and an item that a record below it carries keeps that record’s compartment. Listing an item copies nothing of it: the record names it by digest, the edge offers the item with the chain (§6), and the item’s own signature, where it has one, is what holds it to what it says. An item the record does not list, of any compartment, has been stripped (provenance_stripped).

The compartment is the edge’s reading of an item, in the split California Business and Professions Code §22757.1 makes: personal where the item holds personal information, or unique device, system or service information reasonably capable of being associated with a particular user (§22757.1(n)), and system otherwise: information about the type of device, system or service that made the content, or about its authenticity (§22757.1(p)). Information inside a digital signature is not personal there (§22757.1(n)(2)), so a signature is system provenance. A store embedded in an input the edge reads as system provenance unless it knows otherwise.

This revision carries every item, personal ones included: an edge strips none, and a sink holds the chain’s items from the edge that served it. Redacting a personal item under a stated rule, with a salted commitment that accounts for the removal so that it is never silent, is a later revision’s; until it is registered, a personal item is carried as a system one is. A C2PA manifest an edge emits for its output names each manifest store of its inputs as an ingredient, parentOf for a derivation of one input (C2PA 2.4 §18.15: c2pa.transcoded for a rebuild, c2pa.repackaged for an explode); the reference edge emits none.

6.2 The AI-origin label

A record states, for each input and for its output, an AI-origin label: null where no label is known, or, in rising order, assist (AI altered the content and generated none of it) or generate (AI generated the content, or part of it). A label may rise along a chain and never fall:

• an input another edge derived is labelled at least as that edge’s record labels its output (synthesis_dropped); a source object is labelled as its provenance states, read by the edge;
• the output is labelled at least as every input (§5.3 rule 7, synthesis_dropped), and at least as the derivation’s own step warrants: an edge whose step synthesizes content (a learned upscaler behind an attested scaling, a generated frame) labels its output at least assist, or generate where it generated content.

Every derivation this revision pins copies samples or containers and synthesizes nothing, so it raises no label; an attested step is labelled by its edge, and a verifier checks that no label falls, not what an attested step did. The two labels are the two highest classes of an origin claim’s order of steps, capture, convert, assist and generate, in which every derivation this revision pins is a convert step; a later revision may carry such a claim as a provenance item, name the lower classes, and map them onto the digital source types an export writes.

7. Verification

7.1 What a verifier holds

• records: record texts, the subject’s among them, and the records of its chain that it holds;
• receipts: group and object receipts (jwp-receipts §2.4.1, §2.4.2);
• objects: envelopes it holds, each by the content hash it was given under;
• sources: the publisher keys it subscribed to;
• heads: for each origin it holds one for, the head revision of that origin’s key log (jwp-receipts §7.2);
• provenance: the claims it holds (jwp-receipts §2.4.3), and the C2PA Manifest Stores it holds bound to an object, by the object’s content hash;
• policy, three members:

A record that reads as a JSON text is held under its hash (§5.2), whether or not it then passes §5.3, so that a hop that is held and broken is refused for what it breaks.

7.2 One record

The verifier verifies the subject’s record by these steps, and an input’s record by the same steps when step 4 reaches it. A record verified once is not verified again. At the first step that fails, the verification is refused with that step’s reason, at that record.

1. Reading (§5.3): record_malformed, derivation_unknown, params_invalid, inputs_invalid, check_mismatch, energy_invalid, synthesis_dropped.
2. Signature (§5.2): a key that fails RFC 8032 §5.1.3’s decoding or is of small order is bad_key; a signature that fails, bad_signature.
3. Output. The group receipt whose link hash is output.receipt, and the object receipt of that group at output.object_id, are held (output_receipt_not_held); the group verifies (jwp-receipts §3 steps 1–2), the object receipt is included at its position (§3 step 5 there), and its content_hash is the output’s (output_receipt_invalid); §6’s rules hold (output_receipt_mismatch, energy_disagrees). Where the output envelope is held: it hashes to output.content_hash (output_hash_mismatch); its capability is output.capability, and, for an evaluation, its manifest is the one §4.3 writes from the record (output_manifest_mismatch); and, for a wai.image.png output, the samples it reads as (packaging §5’s still reader) are of the record’s width and height and have its samples digest (samples_mismatch): PNG is lossless, so this holds whoever wrote it.
4. Each input, in order:
   1. its group receipt (by receipt) and its object receipt (at object_id) are held (input_receipt_not_held); the group verifies, the object receipt is included at its position, and its content_hash is the input’s (input_receipt_invalid);
   2. where derivation is null, the group receipt is signed by a source key; otherwise an edge’s output is passed off as a source object, and a hop is missing (chain_skips_hop);
   3. where derivation is not null: the input’s chain is not longer than 8 hops, the subject’s record being the first (chain_too_long); the record of that hash is held (hop_not_held) and reads (§5.3, refused at that record); its output’s content_hash, capability, receipt and object_id are the input’s (hop_mismatch); and it is verified by these steps, whose refusal, at that record, is this verification’s;
   4. where the input envelope is held: it hashes to content_hash (input_hash_mismatch); it reads as §4.1 or §4.4 has it (input_unreadable); and the samples it reads at frame have the digest samples (samples_mismatch);
   5. its provenance (§6.1): each claim the verifier holds about it, each manifest store the verifier holds bound to it, and, where the input envelope is held, each store embedded in it, is an item of the record for this input, of that kind and digest; and, where an edge derived it, every item of that edge’s record is one too, with its compartment (provenance_stripped). Where an edge derived it, its synthesis is no lower than that edge’s record’s (§6.2, synthesis_dropped).
5. Recomputation, where every input is held. For a replicate record: evaluate the derivation (§4.2–§4.4) over the inputs (params_invalid for a parameter they cannot satisfy); the output’s samples digest, size and envelope MUST be the record’s, byte for byte (replicate_mismatch). For an attest record: where the operation is exact, evaluate it, and the output’s samples, width and height MUST be the record’s (samples_mismatch); where it is not, nothing of it is recomputed. Where an input is not held, a replicate record is not-recomputed, and refused under the policy recompute: required (inputs_not_held).
6. Authority (§8): key_log_not_held, edge_not_authorised, edge_revoked.
7. Policy: an attest record under attested: refuse is attested_refused.

A refusal names its place: ["record", r] for steps 1 and 2, ["record", r, "output"] for step 3, ["record", r, "input", i] for step 4, ["record", r, "recompute"] for step 5, ["record", r, "authority", origin] for step 6, an origin of §8 or, where the hop has none, null, and ["record", r, "policy"] for step 7, with r the record’s position among the records given and i the input’s among its inputs.

7.3 The chain

Step 4 follows each derived input to the record that derived it, and that record’s inputs to theirs, until every input is a source object. Each hop is verified on its own, against its own receipts and inputs. A hop that names a record the verifier does not hold is refused, not skipped: a sink that cannot follow a chain to its source knows only that the edge delivered the object (§6). A chain cannot loop, since a record names its inputs’ records by hash and no hash can name a record that names it; the bound of 8 hops is a bound on work.

What a verified chain establishes: the subject’s object was derived, hop by hop, from the source objects the chain reaches, by the derivations its records name with the parameters they state, each signed by the edge that made it; each replicate hop whose inputs were held was re-executed and matched byte for byte; each attest hop rests, at its attested step, on its edge’s signature; and each source object is one its publisher signed for delivery. It does not establish that the publisher meant the object to be derived from; that is §8’s.

7.4 Outcome

A verifier states refuse with a reason and its place, or accept with:

• subject: the subject’s record hash;
• hops: each record verified, in the order first reached, each with its record hash, its signer key, its derivation, its check, checked — recomputed (a replicate record re-executed), not-recomputed (a replicate record with an input not held) or attested — its energy, null or { "joules_micro", "class" }, its authority: confirmed, unconfirmed or none (§8), and its synthesis (§6.2);
• sources: each source object reached, in the order first reached, with its object content hash and the signer key and signer_id of its group receipt;
• energy: for each acquisition class among the hops, in energy-measurement §2’s order, strongest first, the sum of their figures of that class; and unmetered, the number of hops whose energy is null. Figures of different classes are never summed together, and an unmetered hop is never counted as zero. The source objects’ figures are their own receipts’; this total covers the derivations alone;
• provenance: the subject’s record’s items (§6.1), each its input, kind, digest and compartment: every item of the chain, carried to the object the sink received.

8. Authority

A derivation is made under the authority of the origin whose content it derives from. A hop’s origins are the origins its chain reaches: for each source object, the origin its group receipt’s signer_id names where it is origin-bound (jwp-receipts §7.1), taken in ascending order, each once. The authority is edge/derive (jwp-receipts §7.5), and a hop’s edge needs it from each of its hop’s origins, the hops below it included: an origin lists, in its key log, the edges it trusts with its content, as it lists its relays and stores.

For each origin of a hop, where the verifier holds a head for it: the head is a revision the verifier holds for that origin (jwp-receipts §7.2 rules 1–3) (key_log_not_held); it has an entry whose key is the record’s signer_pubkey and whose may_sign holds edge/derive (edge_not_authorised); and that entry’s status is not revoked (edge_revoked).

A hop is confirmed when it has origins and the verifier holds a head for each that passes; unconfirmed when it has origins and lacks a head for one; and none when it has no origin, its sources naming no origin. Under the policy authority: required, a hop that is not confirmed is refused (edge_not_authorised, at the first origin that lacks a head, or at null).

edge/derive is an authority of its own: not delivery, which an edge needs from its own origin to sign its group receipts, and not live/relay, since a relay forwards what it received and an edge publishes something new. Retiring an entry does not withdraw it here; revoking it does. A metered record’s figure needs, beside it, the energy authority of its class (energy/<class>, jwp-receipts §7.5), which that section’s confirmation (§7.4 there) checks under an anchored origin; this section checks edge/derive alone.

9. Reasons

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

10. Conformance

edge-conformance/ holds the corpus, in one file, vectors.json, written from fixed seeds by wai_edge_vectors gen. Each vector is what a verifier holds (§7.1) and the outcome §7.4 gives it. It has:

• Sources: one publisher, whose signer_id is origin-bound, signing an integer clip (wai.video.int_motion), three PNG stills and a WAI2 envelope of two renditions; and the key log of its origin, listing two edges with edge/derive, one edge with delivery alone, and one revoked.
• Replicate hops, recomputed: a frame of the clip rebuilt as a still; each operation of §4.2 but scaling over a still; a grid and an overlay over several stills; a component exploded from the WAI2; and a chain of two hops by two edges, a crop of a rebuilt still, each hop recomputed from its inputs.
• Attested hops: a frame rebuilt as a JPEG picture, whose samples are checked and whose encode is not; a scaling written as a pinned still; and a replicate crop over an attested scaling.
• Provenance and labels: a still whose PNG embeds a manifest store, with a claim about it and a store beside it in the personal compartment, every item carried through two hops; a still whose provenance says it was generated, its label carried through two hops; and a scaling its edge labels assist. The corpus’s manifest stores are byte strings standing for one: a verifier names a store by its SHA-256 and parses none.
• Policies: a chain verified without its inputs’ bytes; one under authority: required whose hops are confirmed; metered hops of two classes, totalled per class.
• Refusals: one vector or more for each reason of §9, each a control of one defect: among them a JPEG output whose record names no encoder, a grid stated over more inputs than its cells, a parameter its inputs cannot satisfy, an attested JPEG whose stated samples are not its frame’s, and a scaling whose stated samples are not its still’s.

A conforming verifier gives every vector the outcome, the reason, the place and the facts the corpus states. wai_edge_vectors verify and the test tests/derive_edge.rs check that the file regenerates byte for byte, that wai-rs gives every vector its outcome, that every reason of §9 appears, and that §9 lists exactly the reference’s codes; the same test runs the reference edge, wai_edge, twice over a source to make a chain of two hops, and verifies it. edge-conformance/edge_verify.py is the second implementation, written from this text: it shares no code with wai-rs; it reads delivery receipts with the JWP corpus’s second implementation (jwp-conformance/jwp_verify.py), decodes WIV1 with the integer payload corpus’s (int-payload-conformance/int_payload_verify.py), explodes WAI2 envelopes with the staged-delivery corpus’s (staged-conformance/staged_verify.py), reads key-log heads with the live-rooms corpus’s (live-conformance/live_rooms_verify.py), verifies every signature with WAI’s strict rule (claim-conformance/_ed25519.py), and writes stills and evaluates every operation itself. It requires every mutated copy of the corpus to fail, and, with each of its own checks dropped in turn, requires the corpus to catch the weakened verifier.

11. Security considerations

• What a record proves. An edge’s signature binds it to the derivation it states. For a replicate hop whose inputs a verifier holds, nothing rests on that signature but who made it: the verifier made the output itself. For an attest hop, the attested step is the edge’s word; an edge that encodes something else and signs it is caught only by a party that compares the output with what it should hold. A sink that cannot accept that refuses attested hops.
• Chains. A hop that names its input as a source object when an edge derived it, or that names a record the sink cannot get, would hide a derivation; both are refused. A chain is verified hop by hop, so a chain is no stronger than its weakest hop, and the facts say which hops were re-executed, which were not, and which are attested.
• Not the source. A derived object is never the object it was derived from. The source’s receipts do not cover it, and its own receipts are the edge’s. jwp-receipts §3.2’s ancestor rule is unchanged: a soft-binding recovery attests the ancestor alone. A verified chain is the accounted transformation that recovery lacks, and it is the record that accounts for it.
• Energy. Each hop’s figure is its edge’s, with its class, and covers that derivation alone. Totals are per class, an unmetered hop is not zero, and the source’s figures stay its own (§7.4).
• Keys. An edge’s key signs its records and its delivery receipts. An origin that stops trusting an edge revokes its entry, and every record under it is refused for that origin’s content from then on.
• Work. A chain has at most 8 hops and a record at most 16 inputs; an output’s samples are bounded. A verifier re-executes only what it holds, and only what §4 pins.
• Provenance. A verifier catches an item stripped from a record only where it holds the item, or the record below that carried it: an edge that drops an item it received, before any party downstream saw it, is caught by a party that holds what the edge received. Once a record lists an item, every hop above it must list it too, so the sink of a chain holds every item’s digest from the subject’s record alone. A compartment is the edge’s reading, and the first edge to read an item fixes it for the rest of the chain.
• Labels. A label can only rise along a chain, so a transcode cannot launder a generated object into an unlabelled one. A source object’s label, and the label an attested step warrants, are the edge’s statements; a verifier checks that no label falls.
• Privacy. A record names objects, keys and provenance items by digest, never a viewer or a session, and copies nothing of an item. Personal provenance is carried by digest in this revision (§6.1); an edge that must not pass a personal item on can only refuse to derive until the redaction rule is registered.