prim.process

A prim is a file that stands for a thing — a lot, a contract, a menu — that processes act on. This is the argument for the process profile in prims. Spec below.

People were writing processes down long before there was software to run them on. The Venetian Arsenal fitted out roughly a galley a day in the 1500s because the sequence was fixed and the workshops sat along the canal in the order the ship needed them. A machine shop still runs a traveler, a card that rides along with the part and picks up a signature at every station. Neither of those is a system. Both are a process someone wrote down clearly enough that the next person could run it without being trained by the last one.

The written ones that work are boring in the same specific way. They name the steps and their order, the tool each step uses, and the person who gets to say a thing is finished, who is almost never the person who did the work. Judgment doesn’t disqualify a process from being written down. It just has to be located. Somebody decides whether the sauce is broken. The process says who, and if you’re diligent it says what they’re deciding against.

That matters more than it used to. A process that’s written down, understood by the people running it, and repeatable even where it needs a call is a process an agent can carry most of the way by itself. The industry reflex is to build software around the process first: a form, a workflow tool, an integration layer, and then some AI bolted onto the side of it. That reflex made sense when the thing running the process was a computer that couldn’t read. Now you can write the process in English, name the tools, name who publishes, and you’re most of the way to the thing you were going to spend two quarters building.

The processes most companies run were shaped around what one person could hold in their head and get through in a day. That constraint moved. The processes mostly haven’t.

A lot leaving the floor

flowchart TB
  r[Receive] --> i{Incoming OK?}
  i -->|no| x[Reject]
  i -->|yes| m[Make]
  m --> q{Final QC}
  q -->|rework| m
  q -->|pass| p[Pack]
  p --> s[Release]
  classDef stop fill:#e8c547,stroke:#0c0c0e,color:#0c0c0e
  class s stop

A truck backs into the dock and a pallet comes off it. Before anyone touches a machine, incoming inspection can reject the whole lot and send it back to the supplier. If it passes, the floor builds against the spec. Final QC either accepts the lot or routes it to rework, and rework goes around the loop again. Then packing, which feels like the end and isn’t. The boxes sit on the outbound rack until the person the walk names signs the release. Plenty of finished lots have spent a week on that rack.

Files: One file per lot. The spec is its own file; the lot cites it by revision, so bumping the spec doesn’t rewrite what shipped in March.
Tools: Receive dock, incoming inspect, make, final QC, pack, release.
Who publishes: Whoever the walk names as releaser, usually somebody in quality. The operator who taped the box shut doesn’t have that signature.

Each walk compiles to a process file. Here’s the lot’s:

process.json

{
  "id": "lot-release-v1",
  "version": "1",
  "cites_type": "lot",
  "steps": [
    { "tool": "receive-dock", "as": "receive" },
    { "tool": "incoming-inspect", "as": "inspect" },
    { "tool": "make", "as": "make" },
    { "tool": "final-qc", "as": "qc" },
    { "tool": "pack", "as": "pack" },
    { "tool": "release", "as": "release" }
  ],
  "stop": { "publish": "human" }
}

Buying a house in Texas

flowchart TB
  o[Executed contract] --> e[Earnest money at title]
  e --> n[Option period]
  n -->|cheap exit| d[Dead]
  n --> ins[Inspections]
  ins -->|dies| d
  ins --> ti[Title and survey]
  ti -->|dies| d
  ti --> l[Loan and appraisal]
  l -->|dies| d
  l --> c[Sign at title company]
  c --> f[Fund and record]
  f --> k[Keys]
  classDef stop fill:#e8c547,stroke:#0c0c0e,color:#0c0c0e
          class k stop

The option period is the cheap exit. Inspections, title, and the loan can kill the deal too; they just cost more.

Residential deals here run on TREC forms, which is worth knowing if you’ve bought a house somewhere else. There’s no closing at a lawyer’s office. You write the offer on the form, and your earnest money goes to a title company rather than to the seller. Then the option period starts: a window you paid a few hundred dollars for, during which you can terminate for any reason or none. Inspection happens inside it if you’re smart. Meanwhile the title company works up a commitment, a surveyor shoots the lot, and the lender does what the lender does. Everybody signs at a table. The house isn’t yours when you sign, though. It’s yours when the title company funds and the county records the deed, which might be that afternoon and might be the next morning.

Files: One file per closing, anchored on the executed contract. Title commitment, survey, and loan conditions stay their own files — nobody retypes a survey into a contract.
Tools: Offer desk, escrow at the title company, inspection report, lender, closer.
Who publishes: The closer, at funding. Buyer and seller both signed, and neither signature moved the house.

process.json

{
  "id": "tx-residential-close-v1",
  "version": "1",
  "cites_type": "closing",
  "steps": [
    { "tool": "offer-desk", "as": "contract" },
    { "tool": "title-escrow", "as": "earnest" },
    { "tool": "option-clock", "as": "option" },
    { "tool": "inspect-report", "as": "inspect" },
    { "tool": "title-survey", "as": "title" },
    { "tool": "lender", "as": "loan" },
    { "tool": "closer", "as": "close" }
  ],
  "stop": { "publish": "human" }
}

Seven courses, one pass

flowchart TB
  u[Menu locked] --> z[Mise]
  z --> fire[Fire a course]
  fire --> pass{Chef pass}
  pass -->|back| fire
  pass --> table[Table]
  table -->|more courses| fire
  table -->|seventh plated| done[Service over]
  classDef stop fill:#e8c547,stroke:#0c0c0e,color:#0c0c0e
  class pass stop

The menu locks days before service, and once it’s locked the cooks stop arguing about it. Mise happens once, in the afternoon: everything portioned, sauces down, garnish trays set. Then the same loop seven times. Hors d’oeuvre, soup, fish, sorbet, roast, salad, dessert. Every plate goes up on the pass and the chef looks at it. A plate that gets sent back never reaches the table, so for the diner it was never cooked. Same pass, same eyes, seven times. Service ends when the last dessert is down.

Files: One file for the menu; one per ticket. Each ticket cites the menu, which is how forty covers run off one menu instead of forty copies.
Tools: Menu lock, mise, the pass, expo to the table.
Who publishes: The chef at the pass. Cooks plate. Plating isn’t releasing.

process.json

{
  "id": "tasting-seven-v1",
  "version": "1",
  "cites_type": "service",
  "steps": [
    { "tool": "menu-lock", "as": "menu" },
    { "tool": "mise", "as": "prep" },
    { "tool": "pass", "as": "pass" },
    { "tool": "expo", "as": "table" }
  ],
  "stop": { "publish": "human" }
}

An edition goes out

flowchart TB
  d[Draft] --> lock{Lock gate}
  lock -->|fail| d
  lock --> v[Verify cited]
  v -->|fail| d
  v --> desk[Draft Desk]
  desk -->|publish| live[Published]
  desk -->|kill| dead[Discarded]
  classDef stop fill:#e8c547,stroke:#0c0c0e,color:#0c0c0e
  class desk stop

A runner drafts an edition off the house shell. Lock gate checks the tokens: right volume and numbering, nothing still sitting there as a placeholder. Verify opens every URL the draft cited and confirms the page at the other end says what the draft claims it says. Either gate can bounce it back to the runner, and both regularly do. What survives sits at Draft Desk until a person publishes it or kills it. The credential that wrote the HTML has no publish rights, which is deliberate and occasionally annoying.

Files: One file per edition. Everything it cites stays in its own pack, so the edition stays thin and the sources stay reusable across editions.
Tools: volume-shell, lock-gate, verify-cited, Draft Desk.
Who publishes: The editor at the desk. The job that generated the page has no button for it.

process.json

{
  "id": "ledger-edition-v1",
  "version": "1",
  "cites_type": "edition",
  "steps": [
    { "tool": "volume-shell", "as": "draft" },
    { "tool": "lock-gate", "as": "lock" },
    { "tool": "verify-cited", "as": "verify" },
    { "tool": "draft-desk", "as": "desk" }
  ],
  "stop": { "publish": "human" }
}

Four walks, and the file underneath doesn’t change shape between them. A lot, a house, the seventh plate, an edition. Any walk described well enough that someone else could run it is a process prim. The process carries the order and the tools. The prims are the things being made and the things being cited. Between them, raw material goes in one end and the finished thing comes out the other, which is all a process has ever been for.

Judgment is taste that hasn’t become data yet.

Some of these walks have a person at the end. Taste is available where the data is. What isn’t available is your preference on the thing nobody wrote down. When a walk is making something for you and hits that gap, it stops and waits. The stop is right. The gap it stopped on is the failure, and the failure is upstream. Either the step was cut too coarse to show where the choice actually lives, or somebody held an opinion and never put it in the file.

This page is one. What you’re reading is the view. The file is a web-page prim, and that prim composes an interview prim, because prims compose. A process prim is what turned the web page into this HTML. If that sounds circular, it is, and that’s how you know the shape holds.