suede-ops-architecture

# Suede Ops Architecture ```text Ordering law: data, then workflows, then intelligence. ``` An agent reading fragmented data does not report that it holds a third of the picture. It returns a fluent, confident answer built on a third of the picture. Fragmented input produces polished mistakes at scale, and polished mistakes survive review that visible chaos would not. Architecture is what stops the model from being asked a question its inputs cannot answer. This skill ends with a written architecture, not a build. Every step below produces a line in the Output Contract, and every gate names what an agent does when it fails. ## Before Starting Collect these. Work with what exists and name what is missing in the Output Contract rather than blocking on it. 1. **Entities** — the nouns the operation runs on (client, project, order, job, track, release, patient). 2. **Work units** — the recurring things people do, one line each, in the words the person doing them uses. 3. **Tool list** — every system holding operational data, including spreadsheets, shared drives, and any inbox used as a database. 4. **Cycle length** — median days for one unit of work to go from open to done. 5. **Blast radius per work unit** — what a wrong output costs, and whether it can be undone. Read `references/triage-examples.md` for worked classifications before running Step 3 on unfamiliar work. ## Step 1 — Schema before surfaces Name the entities, their fields, and their relationships...