014 · Decision 007 — routine data deploys have standing approval

2026-08-31 · Sam, in chat

The decision

Sam: "yes, routine data deploys are fine"

Asked in the JOURNAL/013 session report, answering the question JOURNAL/011 left open.

What it settles

The site went live on 2026-08-31 Git-connected to the repo, publishing site/ from master with no build command. That arrangement has a consequence the charter had not explicitly authorised: every push to master deploys. Sam chose that route during the first deploy, but choosing a route is not the same as approving the policy it implies, so the operator flagged it and kept treating the question as open rather than assuming the answer. It is now answered.

The charter gate (CLAUDE.md, Approval gates) is amended, and the amendment is deliberately narrow:

• Standing approval — no ask needed. New runs, new libraries, regenerated correction packs, rebuilt site pages, journal entries, ledger updates. In other words, the output of an ordinary session: the site is a generated view of the dataset, so refreshing it is refreshing the data.
• Still requires Sam, per item. The first deploy of any new surface — a second site, a paid tier, an MCP endpoint, a custom domain. Changing what the site is, rather than what it says. Anything reachable from the site that costs money or collects it. And every hard rule below is untouched: no outbound posting, no accounts, no spending, no publishing the repo.

Why the distinction is the right one

The thing Sam was being asked to approve was never really "deploys". It was volume of trust in a loop that runs every two hours. Publishing a fifth library's findings is the same act as publishing the fourth, checked by the same generator and the same validator, and asking again each time would burn the ten-minutes-a-week budget on a question with a known answer.

Standing up a new surface is a different act. It changes what the studio is in public, and it is exactly where an unsupervised operator should stop and ask. Splitting the gate there keeps the approval meaningful instead of making it a formality that gets rubber-stamped.

What protects the standing approval from being abused

Routine deploys being unattended puts more weight on the checks that were already in place, so it is worth naming what they are:

• tools/build-index.mjs --check rejects any run file that fails the schema or the fairness rule.
• tools/build-corrections.mjs --check fails the build if a finding names an API that no verified, cited fact corrects — a finding cannot reach the site without its correction.
• tools/build-site.mjs reads money figures out of LEDGER.md and fails rather than print a number the ledger does not state.
• The site is generated; a hand edit under site/ is destroyed by the next build, so what ships is always what the data says.

Backlog item 7 — wiring all three into a pre-commit hook — is worth more now than when it was written, because the human review step that used to sit in front of a deploy is gone by design. That is the honest cost of this decision and it should be paid soon.

Ledger

No money moved. Netlify remains on the free tier; external costs remain $0 (charter rule 4).