Blueprint as the single source of truth — the D0/D1/D2 stack inside TEAM OS

Most "documentation" inside an active project is a layered fossil — half-finished design notes from three sprints ago, a wiki page no one trusts, a spec that was last accurate before the rewrite, a Notion that diverges from the code, a tribal-knowledge layer in someone's head. None of it is *the* truth. All of it is *some* truth. New people coming in cannot tell which is which, so they ask, and the answers further fork. This is the default state of a software project, and AI agents make it worse, not better, because they will happily extrapolate from whichever fossil they find first.

TEAM OS replaces this with one thing: a blueprint. Not a document, not a wiki — a project artifact called the blueprint, which is by construction the single source of truth. Any feature change, any new functionality, any implementation tweak updates the blueprint first. When code disagrees with the blueprint, the blueprint wins until someone decides otherwise. The framework treats the blueprint the way a building site treats the architectural drawing: code is the construction, the blueprint is the drawing, and you do not pour concrete in places the drawing does not show.

The completeness standard is physical. A blueprint is complete when an engineer holding it can ship without making new product or architecture decisions — only implementation choices remain. That is the test we run on a blueprint before we declare it done. If a question of the form "how should this behave?" or "which subsystem owns this?" arises during implementation, the blueprint is incomplete and the answer goes back into the blueprint before the work continues. This sounds like a slogan, but it is actually a checkable property: at any point in development we can ask, what new decision did we just have to make that was not in the blueprint? If the answer is non-trivial, the blueprint failed.

The stack is three layers wide. D0 is product positioning — what the product is, who it serves, where MVP draws its line, what non-functional targets it has to meet, how success is measured, how its systems are partitioned. D1 is product design — feature specs, user stories, UI, the five-kind node definitions, and the data model that runs through them. D2 is technical design — tech stack, node modules, APIs, database tables, EXT-external dependencies, deployment topology. Two sidecars sit alongside: a glossary that fixes project-specific vocabulary once and for all, and D9, the selection log, which captures every non-trivial pick (library, vendor, model, algorithm) along with the alternatives that were rejected and why.

Earlier versions of the framework had nine layers — D0 through D9. We deleted six of them, not because the work they tracked was unnecessary, but because each of those layers duplicated a sibling subsystem that already owned the same job. D3 (task schedule) collapsed into the task subsystem. D4 (change log) became change-typed tasks. D5 (test case sheets) was dissolved entirely — a complete blueprint already defines every node, every contract, every KPI; tests should read from the blueprint, not from a parallel document. D6 (release checklist) became the completion criteria of the deploy skill. D7 (experience document) was structured into a memory subsystem with three shelf-lives. D8 (memory archive) became the platform-level auto-save that every modern agent runtime already does. What survived was D0/D1/D2 + D9. Removing the extra layers made the stack smaller *and* more accurate, because every remaining piece now has exactly one home.

The classifier is isomorphic. The same Core / Side / Auxiliary triage applies at both the system level and the feature level. At the system level: remove a core system and the product loses meaning; a side system outputs into or gates the core system; an auxiliary system has no effect on it. At the feature level: a core feature sits on the core flow itself; a side feature is a branch that joins the core flow as input or gate; an auxiliary feature does not touch it. One sentence, two levels — that is enough to triage any new piece of work into one of three bins without arguing about category boundaries.

Every flow resolves to five node kinds. TIN is a terminal input: the user produced it directly. DIN is a data input: another system produced it, and the user passes it along. TOUT is a terminal output: feedback the user perceives. DOUT is a data output: a structured asset the user can use elsewhere. STATE is a state write: the system bypasses the user and writes to an intermediate store. That is the full alphabet. A user story is a path through these nodes. A feature is the set of paths that pass through a particular subsystem. A blueprint is the union of all those paths, plus the modules that implement them.

Data is classified by where it enters the node graph. Information is what flows through nodes (sub-classified into transient, accumulating, recording, and session-temporary). Rules are the logic inside nodes (sub-classified into designer-set rules and user-set settings). Resources are what nodes reference (sub-classified into designer-created definitions, media assets, and user-created content). This is not three categories someone invented on a whiteboard — it is what falls out of the node model when you ask "what is this datum doing in the graph?" The blueprint forces every concept that appears in the product (mood, gift, affinity, conversation) to be filled into a three-column row before it is allowed to become a real data file, which catches missing definitions before they become missing fields in the database.

D2 is forced to point back to D1. Every node module declared in D2 must list which D1 features it supports. If the module cannot point to any D1 caller, it should not exist. This single rule kills more architectural drift than any other check we have. It also makes the blueprint navigable in both directions: D1 → D2 to find the implementation, D2 → D1 to find the justification. There is no module floating freely with no business it supports, and there is no D1 feature claiming behavior that no module actually implements.

The blueprint is a single git artifact. It lives in the project repo, versioned, diffable, reviewable. No external service, no managed wiki, no model that has to "remember" something. An AI agent assigned to a task reads the blueprint as plain files, writes back changes that are themselves plain files, and commits them next to the code. A human reviewer reads the same files. There is no privileged channel. This is the property that lets an agent join a project halfway through and become useful in a small number of turns — it just reads the blueprint the same way any other engineer would, and the blueprint tells it where everything is.

We do not claim the blueprint solves project management. Disagreements still happen, decisions still age out, hard choices still have to be made by humans. What the blueprint solves is the question "where is the truth?" — and that one question, answered concretely, removes a surprising amount of friction from everything else.