Seventeen Systems

01Where they operate

Each of the seventeen answers the same five questions — where state lives, what is retrieved, who approves, what starts it, what happens when it breaks — and each one wrote its answers down before this page existed. Plotting the answers against the layers a system can have puts every project in one of four shapes, and the shape turns out to predict more about a system than what it is for.

02The decision matrix

The same five decisions, side by side. Read down a column rather than across a row: a row tells you about one system, a column tells you whether there is a person behind them or seventeen coincidences.

The five columns are not the six architecture layers repeated. They are the decisions that differ between systems: storage covers corpus and index together, selection is the layer of that name, and the human gate is where grounding stops being a schema and becomes a person.

Shipped — the system has run and the cell describes what it does. Designed — no pipeline has ever run, so the cell describes what was specified. Every cell is the answer recorded for that system; none of them is a summary of several.

03The vector store

Seventeen systems, and the answer was no seventeen times. That is not a position I set out with, and it is not a position about the technique. It is what the column says after the fact, and the two most useful entries in it are the two where I built the thing first and then watched it sit there.

Eventist Intelligence carried vector columns on three tables in its first schema; nothing ever populated them and a later migration dropped all three. Fat Sai LifeOS created an embeddings table with a cosine index on the assumption that recalling past work would need semantic search; nothing ever wrote to it and nothing ever read it. In both cases what people actually typed was a client, a venue, a year, a piece of equipment, a project key, a date — structured attributes, answerable by an index that can point at the row that matched.

The other fifteen reasons fall into three shapes. Some systems have no corpus at all, so the model sees only what the request carries: one meeting that fits a prompt whole, one CV read outward, three reference clips. Some have a corpus small and concrete enough that an exact filter beats a score: fifty-four catalogue items reached by a category tab, a 503-item question bank filtered by part and topic, one table of contact rows, thirty-eight rows frozen into an explicit bridge column, one person’s ledger that loads whole, a few thousand files described in short concrete nouns. And some have a corpus that is not documents at all: a room, differenced as a distance threshold in three-dimensional space; sixteen deterministic protocol checks; a whitelist of facts a writer is permitted to state, which is a permission rather than a recall.

The sentence that keeps recurring across the reasons is that a similarity score always returns something. For an archive whose stated rule is that ambiguous evidence returns nothing, always-something is the wrong answer, and it is wrong in the direction nobody notices.

A vector store earns its place when three things are true together: the corpus is too large or too varied to enumerate, the query is a paraphrase rather than an attribute, and the caller would rather have an approximate answer than none. None of these seventeen had all three. The largest corpus here is over 140,000 photographs, and it is retrieved by project code and a closed vocabulary of tags — because that is what people type. The day those three conditions arrive together I will reach for one. They have not yet, and pretending otherwise would have cost two of these systems a table each. It cost them a table each anyway.

04What the columns show

Postgres is the default, and every exception has one reader

Seven of the seventeen keep state in Postgres, an eighth keeps a JSONB plan row, and a ninth specifies Postgres for an engine that never shipped. The exceptions are not a different taste in databases. Two keep state in the browser because the only reader is the person who wrote it. Two keep it as plain files on disk — local clips in one, a config directory and dated result files in the other. One keeps a single Google Sheet and calls it the sole source of truth — the only system here whose database is a document. And one stores nothing at all: its output is a mesh in a repository. The pattern is not that Postgres is good, it is that the moment a second reader appears the answer stops being interesting.

The gate sits on the way out, and the one system without it paid for it

Seven systems have a human approval step, and every one of them sits on an outbound path: a database trigger on publish that cannot be skipped, a pending row a human flips before anything is sent, a dry run that needs a write flag before it touches a file, an action item that opens as a commitment awaiting approval, a sound-and-edit pass before a clip goes out, a contact sheet before crops are accepted, a category left blank rather than guessed. Ten say none, and nine of those ten never send anything outward unattended — the person pressing the button is the gate. The tenth is the one to stare at: the agent team publishes to a live site on a Monday-morning schedule with no human on the publish path, and pays for it in the failure column with deterministic gates outside the writing agent, a read-back that confirms the write, rollback to draft, an alert mail, and skipping the week rather than shipping.

Five run without being asked; twelve wait

Three run on launchd — roughly thirteen jobs from weekly to nightly, a calendar from every thirty minutes to daily, and one weekly run at Monday 08:00. A fourth is an hourly watcher over a folder. A fifth polls every five seconds, and the record says explicitly that this is a poll and not a push. Everything else is on demand, by hand, or paused, including three where the schedule exists only on paper. Running unattended is the most expensive property in the table, and it was bought five times out of seventeen.

“None” in the failure column means three different things

Where a person starts the run, failure means stop and write nothing: a script that raises and stops, a shell that halts on the first error, a wrong-database guard that aborts, a clip script that exits with no retry. The operator is the retry. Where nothing runs unattended, none means there is nothing that can fail while nobody is watching. And where no pipeline has ever run, none means the system does not exist yet — three rows say that, which is the honest reading of a chapter that also contains three finished products. Only the five systems on a clock have a failure path that recovers instead of stopping, and each recovers in its own idiom: a checks producer feeding a banner, an alert mail and an auto-fix job; a run row that logs the failure and counts the slot it missed; a rollback to draft with an alert and a skipped week; an hourly retry deduplicated by filename; a badge that keeps its last face and asks again in five seconds. Two of those rows show the same trick from different directions: the hourly watcher retries and deduplicates by filename, and the steward re-gathers its whole domain every cycle and deduplicates by source key. What makes a repeat safe in both is the key sitting in the selection column immediately to the left — which is why None in that column is so often the answer of a system that already knows what a thing is.

05The limit

The honest limit is in the same columns. Three of the seventeen have never run, and most of the rest serve one person or one team on machines I control; none has had to survive a corpus, a headcount or a load I did not choose myself. What the table does show is that I made the same call seventeen times with nobody enforcing it — reach for the boring store, buy a schedule only where the work arrives whether or not anyone asks, and stand the human at the point where being wrong is expensive. That is a smaller claim than architecture at scale, and it is the claim the evidence actually supports.