0017 Ledger field additions: sealed root per item, disclosure line, move to the store, dictionary correction, bundling sent records

This record answers two hgp issues. A was sent by provenance after decision 0016 (issue #3). B was sent by secretary while aligning its ledger with 03-manifest (issue #2). It replaces the parent field and the salt sentence of 0016.

What

A. Product provenance (issue #3)

1. Sealed root per item

• Each private item (one source original file, or one value) gets its own salt (32 random bytes).
• Item fingerprint = SHA-256(salt ‖ the item written by RFC 8785). Items have two shapes: a file {"type":"file","sha256":"…"}, and a value {"type":"value","name":"…","value":…,"unit":"…"}.
• The item fingerprints are bundled exactly as in 02-Fingerprint section 5 (RFC 6962). The root is the event record’s sealed. Item fingerprints take the place of original fingerprints (leaf = SHA-256(0x00 ‖ item fingerprint)). The order is the order of items written in the private record. The number of items is sealed_count.
• This way one item alone can be opened. Only that item, its salt and the inclusion proof need to be shown. The rest stays closed.
• The number of items is revealed. We consider this acceptable for product provenance.

2. Disclosure line

• Opening one sealed item widens the scope. The ledger records it as an event: "scope_changed" line. On screen and inside provenance, it may be called a “disclosure line” (disclosure).
• Fields: of (the id of that event record), item (the item), salt (the salt), leaf (leaf position number, from 0), proof (inclusion proof), sealed (the root), decided_by (who, in what capacity, when).
• decided_by has the same shape as confirmed_by: {"who","as","at"}. as can only be depositor. For a group, it is the representative’s position (07-Deposit sections 2 and 6). A stand-in depositor cannot open it (decision 0011).
• A disclosure line also goes up as a registry entry. Its refUID is the registry entry of that event.

3. Field names

• parent becomes parents (a list; item 0 is the main parent). This is because of blending two batches (blend). refUID is prev, or parents[0] if there is no prev. Events that are not public are not on the chain, so refUID goes back and points to the nearest public record.
• event_kind: add blend (blending), and change transfer to custody_transfer (the custodian changes).
• tokenized is not added. We do not reserve a name whose meaning and use are not yet settled. Tokens are outside the pilot (provenance design section 10).
• The revocation mark on registry entries is also used for corrections. The old record is the same as “retracted” in 06-Relation network. The screen shows “corrected” if a new record points to it with replaces, and “withdrawn” otherwise.

4. Industry profile

• hgp sets only field names and shapes. The kinds of subject, the event_kind values and the default scope of source originals are set by the industry profile. The product provenance values in table 2 of 0016 and in 06-Relation network section 5 are examples of a “traditional liquor profile”.
• Industry profile files are also published at a public address with a version number. A version once published is never changed (the same rule as 08-Name file section 1). Each record states which profile it followed in profile (the profile file’s address). That way others can read what the values mean.

5. Telegram exception (decision 0010), approved by the head of Nodeone

provenance’s request: a route where the brewery’s representative, the university and Nodeone post photos as “files” in one Telegram group. The originals pass through an outside company’s server without being locked. This is an exception to 0010 (“locked when with outside companies”).

• Only for product provenance photos that will be made public. Photos to be kept private go through Syncthing (a program that sends files directly between devices).
• Send as a “file”. If sent as a photo, Telegram compresses it again and it is no longer the original.
• Photos in which a person can be recognized go this way only after that person’s consent (0016 item 3). Before consent, use Syncthing.
• The original fingerprint is taken from the received file. The fingerprint could not be taken on the sending device, so sha256_device is null. The record states via (route): ["telegram"].
• If the record stops being public, the copy posted on Telegram is deleted. The withdrawal line notes that a copy may remain on the company’s server even after deletion.
• A confirm button can count as a confirmation stamp (decision 0006). Conditions: the person who pressed it has been granted permission on that record (the brewery’s representative position, or an editor the representative named), their Telegram account was linked to their person number in advance, and a bot does not press it for them. The stamp states via: "telegram". Who pressed it relies on the Telegram account, so we state that this is guarded by promise, not by lock (01-Permissions section 1, item 4).

6. Public notes and record gaps

• A public note is the note inside a record (the note of 06-Relation network section 4.1). If the record is public, the note is public too.
• A record gap (“there is no record for this period”) is not an event. It will be settled before provenance Phase 3. The current idea is a claim about the subject (prop: "no_record", with an empty span in when), whose source is a note record by the person who declared the gap (06-Relation network section 1, item 3).

7. Corrections to 0016

• “Merkle by RFC 6962 (sorting, last-leaf duplication removed)” means “remove sorting and last-leaf duplication”. A correction note is added to 0016.
• rights.basis: "agreement" in item 3 of 0016 is "contract", following the value name file of 03-manifest.

B. secretary (issue #2)

1. A line for moving an original to the store uses received once more

No new event name is made. When arkive receives the file and its fingerprint matches, that is “the store received it and the fingerprint matched” (received, PREMIS ingestion). That line’s store is "arkive", and if the file was locked, sha256_stored is present. The received line from the staging store and this line stay in order and form the history of the move. status is not used.

2. Dictionary correction stays trainedAlgorithmicMedia

Even a corrected copy that changes only what a dictionary is sure of has a machine transcription as its base text. IPTC algorithmicMedia means “made from scratch by an algorithm alone, without training”, so it does not fit. Instead, what made the changes is written in other fields: level: "draft", action: "c2pa.edited", made_by: {"type":"machine","name":"dictionary"}, and the number of changes in edits.machine. One line is added to the table in 03-manifest section 6.

3. confirmed_by.at and the line’s at are separate

confirmed_by.at is when the stamp was made. The line’s at is when it was written to the ledger. They are usually the same, and the same value may be used. They differ when the stamp is made offline and uploaded later. This follows the same idea as “time of fact and time of record” in 06-Relation network.

4. Sent records are bundled per pair

• sent_to has only one entry per (provider, purpose, what) pair. at is the first send, last_at the last, and count the number of sends.
• An event: "sent" line is written once, for the first send of that pair on that day. The rule to write it before sending (section 8) stays as it is.
• Training (train) is not bundled. Each send is written separately.

Why

• A1, A2: it must be possible to open just one private photo later. If one salt bundles everything, everything must be shown to check one item. The bundling method is the existing 02-Fingerprint section 5, used as it is.
• A2: opening widens the scope, and only the depositor widens a scope (01-Permissions, 0011). We aligned with the existing scope_changed and confirmed_by shapes.
• A4: each industry has different events. A specification cannot know every industry’s values. Instead, where a value came from must always be readable.
• A5: photos to be made public go outside anyway. But location data and the faces of people who have not yet consented must not go out before publishing. So conditions were attached.
• B: we solved these with existing fields and standard values instead of inventing new names.

Other options

Option	Why not chosen
A1: one salt for everything (0016 as it is)	To open one item, everything must be shown
A2: a new event name disclosed	It widens the scope, so scope_changed is enough
A5: no Telegram exception, Syncthing for everything	The brewery’s representative and the university would have to install a program. The provenance design holds “zero burden on producers” as a principle
B1: a new event name stored or replicated	It does the same work as received. PREMIS replication is closer to adding copies within the same storage
B2: algorithmicMedia	The base text is a transcription by a trained machine
B4: one entry per send (current section 8)	Each time the secretary reads a day’s recordings, entries pile up and the ledger only grows

What it affects

• provenance: sealed per item, sealed_count, disclosure line as scope_changed + decided_by, parents, blend, custody_transfer, remove tokenized, profile, via. The Telegram route under the conditions above.
• secretary: received for the move line, dictionary correction as trainedAlgorithmicMedia + made_by dictionary, bundling sent_to.
• hgp: 03-manifest sections 3, 5, 6 and 8 (v0.7), 05-Glossary, 06-Relation network section 5 (v0.5), correction note on 0016.
• arkive: writes a received line when it receives an original (the same work as the entrance of decision 0004).

Cost

None.