The SOP is data — get the process out of Vera's head without letting the model invent it (step 2/8) · ops studio

The SOP as data

Run the code. That's Vera's Monday sweep as a dict — and the loop at the bottom just caught the model red-handed.

Walk the fields:

owner, version, date — the header that makes it an SOP instead of a note. One name, not "the team." A version string that will bump when anything changes. A date someone can hold against reality ("this was written before we switched carriers — re-verify it").
source on every step — the field most SOP tools don't have and this whole workflow depends on. "transcript" means Vera said it on the recording. "model-filled" means the model wrote it to bridge a gap. The distinction is provenance: transcript steps start life presumed real; model-filled steps start life presumed invented until the performer says otherwise.
verified — did the person who does the task confirm this exact step? Not "did it read well in review." Did Vera look at step 3 and say "yes, that menu exists and that's what I click."

Now look at what the lint flagged. Step 3 — Admin > Batch Tools > Requeue All — is model-filled and unverified. And in this story it's worse than unverified: Vera's actual method is one order at a time, because bulk requeue drops the hazmat flags. The model bridged a transcript gap with the opposite of the truth, formatted to match the surrounding steps perfectly. Nothing about the sentence looks wrong. Only the provenance field knows.

Why a dict and not a doc

Because a doc can only be read, and reading is exactly the review that fails — a plausible invented step survives reading. Data can be linted:

model-filled + unverified → blocked, mechanically, every time, including at 5pm on the Friday someone tries to rush v1 out before Vera's last day.
No owner → blocked. No version → blocked.
Later: safety-touching step without a safety review → blocked. Same lint, one more rule.

The one thing the lint can't do is the verification itself. verified: True gets set by a human who performed the task, and by nobody else — the same division of labor you'll see all chapter: the machine enforces that the check happened; the human is the check.

Next: you play Vera, reading a draft against what she actually said.

The SOP as data

Run the code. That's Vera's Monday sweep as a dict — and the loop at the bottom just caught the model red-handed.

Walk the fields:

owner, version, date — the header that makes it an SOP instead of a note. One name, not "the team." A version string that will bump when anything changes. A date someone can hold against reality ("this was written before we switched carriers — re-verify it").
source on every step — the field most SOP tools don't have and this whole workflow depends on. "transcript" means Vera said it on the recording. "model-filled" means the model wrote it to bridge a gap. The distinction is provenance: transcript steps start life presumed real; model-filled steps start life presumed invented until the performer says otherwise.
verified — did the person who does the task confirm this exact step? Not "did it read well in review." Did Vera look at step 3 and say "yes, that menu exists and that's what I click."

Why a dict and not a doc

Because a doc can only be read, and reading is exactly the review that fails — a plausible invented step survives reading. Data can be linted:

model-filled + unverified → blocked, mechanically, every time, including at 5pm on the Friday someone tries to rush v1 out before Vera's last day.
No owner → blocked. No version → blocked.
Later: safety-touching step without a safety review → blocked. Same lint, one more rule.

Next: you play Vera, reading a draft against what she actually said.

The SOP is data — get the process out of Vera's head without letting the model invent it — step 2 of 8

The SOP as data

Why a dict and not a doc

The SOP as data

Why a dict and not a doc