suede-ops-architecture

Suede Ops Architecture

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 before designing a screen, an automation, or an agent.

For each entity record: the fields it carries, the entity it belongs to, and the lifecycle states it moves through.

Gate. Every work unit from Before Starting reads or writes at least one named entity. A work unit touching no entity means the schema is incomplete.

Halt format. Stop. Name the unmapped work unit in one line. Offer: add the missing entity, fold the work unit into an existing entity, or mark it out of scope in writing. Wait for the choice.