The Cohort Policy

"A wall with no door isn't a trust boundary. It's a promise you haven't been asked to keep yet."

What Happens When the Archive Finally Clears the Bar

The quarantine two lessons ago had an easy life. Nothing was approved, nothing was pressing, and the product worked perfectly without a single transcript crossing the wall. That is genuinely the right way to start. But a gate is only tested on the day someone has thousands of transcripts they actually want on the other side — and then the question stops being "should the default be denied?" and becomes the much harder "what does a human decision even look like at this scale?"

The honest problem: per-release review does not scale to thousands of videos, and pretending it does produces the worst outcome of all — a gate that everyone agrees is important and nobody actually operates, until someone quietly widens it to get work done. Meanwhile the thing you're approving isn't really each individual transcript. It's a pipeline: this provider, this model, this configuration, this audio preparation, producing output of this structural quality. You looked at a sample, you formed a judgment about the pipeline, and you'd happily stand behind every release that came out of it.

Approve the Identity, Not the Instance

So Recall built the door as a cohort policy. An operator creates a policy that pins, as exact values, everything that defines the pipeline whose output the judgment covers:

the provider and the model;
the configuration hash and the audio proxy configuration hash — the same content-addressed fingerprints the paid ledger uses;
the release status and the structural quality class it covers;
the approver, and the evidence behind the decision.

Only releases that match that exact identity can be selected under the policy, and selecting one writes a durable per-release approval row that names the policy it came from. The judgment is made once, by a person, about a precisely-described population — and then applied mechanically to the members of it. The promotion is automated. The judgment never is.

Notice what the config hashes buy here, because it's the whole reason this is safe. If anything about the pipeline drifts — a new model, a changed setting, different audio preparation — the fingerprint changes, and the drifted releases simply do not match the policy. They aren't quietly swept in on the strength of a judgment that was made about something else. A policy can't silently grow to cover output its approver never saw, because the thing it pins is an identity, not a description.

The Manual Gate Didn't Go Anywhere

The original path is untouched and still valid: a release that a human individually reviewed and approved is eligible, exactly as before. The cohort path sits beside it rather than replacing it, and it's deliberately narrower — the older legacy transcripts, produced by a different model entirely, fall outside every Scribe cohort policy and stay quarantined. Two doors, both requiring a person, one of them able to carry a decision across a population.

The cohort path also refuses a shortcut it could easily have taken: approving a release under a policy does not rewrite that release's own review status. A candidate release stays a candidate; the policy approval is recorded as a separate durable fact next to it. It would have been so convenient to stamp "reviewed" on everything the policy touched — and it would have been a lie, because nobody reviewed them. The system keeps two true statements instead of one convenient false one. That honesty costs something, and it is worth seeing where the bill arrives: the export guard from lesson 1 refuses a candidate release outright, so keeping the status truthful means the guard can no longer be a single chain of checks. It became a disjunction — export if the release walked the manual path, or if it holds a live approval row under a live policy — with both branches still requiring eligibility explicitly set to approved, the release still current, and the video not retired. Build the door and the doorway in the same change. A promotion path whose consuming boundary has no branch for it is a door opening onto a wall, and it fails closed and silently, which is the hardest kind to notice.

Publishing Is a Job, Not a Button

Pressing Publish to Lantern in Operations doesn't perform the publication inside the request — Track 2 forbade that, and this is a good place to watch the rule hold under pressure. It creates one durable job with three recorded phases: approve every remaining release matching the policy's kind, ask the corpus engine for a complete reindex, then reconcile its semantic vectors. The job and each phase's response survive a closed page and a control-plane restart; an interrupted job returns to the queue on startup and repeats its idempotent phases; a failure records the exact phase and the remote error for a deliberate retry. A database index allows exactly one publish job in flight at a time.

The detail that says the design is finished: a run that approves nothing is still worth running. Corrections and retirements since the last publication need to propagate too — a corrected release drops the old version from the feed, and a retired missing video disappears from the next reconciliation. Publication isn't a one-way push of new material; it's a reconciliation of what the corpus should currently contain. A gate that only knows how to let things in eventually fills the corpus with things you've since stopped standing behind.

Code

A policy pins an identity; an approval names the policy it came from·sql

-- The judgment, recorded once, about a precisely-described pipeline.
CREATE TABLE corpus_approval_policies (
  policy_id                    TEXT PRIMARY KEY,
  provider                     TEXT NOT NULL,
  model                        TEXT NOT NULL,
  configuration_sha256         TEXT NOT NULL,   -- exact ASR config
  proxy_configuration_sha256   TEXT NOT NULL,   -- exact audio prep
  release_status               TEXT NOT NULL,
  quality_class                TEXT NOT NULL,
  status                       TEXT NOT NULL,   -- active | revoked
  approved_by                  TEXT NOT NULL,   -- WHO decided
  evidence_json                TEXT NOT NULL,   -- on WHAT basis
  created_at                   TEXT NOT NULL
);

-- Applying it: one durable row per release, naming its policy.
CREATE TABLE release_corpus_approvals (
  approval_id TEXT PRIMARY KEY,
  release_id  TEXT NOT NULL REFERENCES transcript_releases(release_id),
  policy_id   TEXT NOT NULL REFERENCES corpus_approval_policies(policy_id),
  status      TEXT NOT NULL,
  approved_at TEXT NOT NULL,
  UNIQUE (release_id, policy_id)    -- re-approving is a no-op
);

-- Config drift changes the fingerprint -> no match -> not approved.
-- A policy cannot grow to cover output its approver never saw.

-- And the consuming boundary needs a branch that recognizes it:
--   export if  (manual path walked)  OR  (live approval row
--               under a live policy) -- both still require
--   corpus_eligibility='approved', is_current, and not retired.

Publication is a durable, phased, idempotent job·python

# The request does NOT publish. It creates one job. (Track 2.)
# At most one publish job may be in flight -- enforced by a partial
# unique index, not by hoping the operator doesn't double-click.

PHASES = ('approving', 'reindexing', 'vectorizing')

#  approving   -> approve every remaining release matching the policy
#  reindexing  -> ask the corpus engine for a complete reindex
#  vectorizing -> reconcile its semantic vectors

# Each phase records its own response. On a control-plane restart an
# interrupted job returns to the queue and repeats -- every phase
# is idempotent, so repeating is free.
# A failure stores the exact phase + remote error for a DELIBERATE
# retry. Nothing auto-retries into a remote system.

# And the part that looks pointless but isn't:
#   approved_now == 0  is still a useful run.
#   Corrections drop the old release from the feed; retired videos
#   disappear. Publication RECONCILES; it doesn't only push.

Exercise

Find an approval step in your own work that a human performs one item at a time — reviewing entries, whitelisting sources, signing off on records. Ask what the reviewer is actually judging: this specific item, or the process that produced it? If it's the process, design the cohort policy: write down every input that defines that process, decide which of them you could pin as an exact fingerprint, and name what would have to change for a new item to fall outside the judgment. Then design the other direction — how does a withdrawal or correction leave the approved set?

Hint

The failure this prevents is a scaling gate that gets quietly widened. Watch for two specific holes. (1) A policy described in words ('the good model') rather than pinned to identities — descriptions stretch to cover new things, fingerprints don't. (2) An approved set with no exit: if you can add but never reconcile, the set drifts away from what you'd actually stand behind, one superseded version at a time.