Blog
遠方世界
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.
Figure 01
D0/D1/D2 carry the entire product specification from positioning down to deploy. The glossary fixes shared vocabulary; D9 logs every selection decision so the chain stays auditable.
D0
Product positioning
Why the product exists. Who it serves. What is in vs out of MVP.
containssystem map · core flow · non-functional targets · success metrics
D1
Product design
How the product actually behaves from a user-visible point of view.
containsfeature specs · user stories · UI · TIN/DIN/TOUT/DOUT/STATE nodes · data definitions
D2
Technical design
Which modules implement which D1 node. Nothing in D2 is allowed without a D1 caller.
containstech stack · node modules · API · DB · EXT-external · deploy topology
Glossary
Every project-specific word is registered here once. All of D0/D1/D2 reads from the same vocabulary.
D9 · selection log
Every non-trivial selection (library, vendor, model, algorithm) is logged with the alternatives that were rejected and why.
completenessCompleteness standard: any engineer holding the blueprint can ship without making new product or architecture decisions — only implementation choices remain.
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.
Figure 02
Earlier blueprint drafts ran from D0 through D9. As the framework matured, six of those layers were absorbed into sibling subsystems that already owned the same job. The blueprint stack itself shrank to D0/D1/D2 + D9.
D3
Task schedule sheet
→ Task subsystem (5.3-tasks)
A real task system already tracks state, owners, and dependencies. Keeping a parallel sheet only invited drift.
D4
Change log
→ Change tasks in the task subsystem
Every change is already a task. Type=change captures it where it actually happens.
D5
Test case table
→ Derived from D0/D1/D2 directly
A complete blueprint already defines every node, contract, and KPI. Tests should read from it, not from a parallel document.
D6
Release checklist
→ Deploy Skill completion criteria
Whoever performs the deploy already runs the deploy Skill. The skill's completion criteria are the checklist.
D7
Experience document
→ Memory subsystem (M1/M2/M3 + skills)
Experience is structured: project memory (M2), reusable skill (M1), and platform chat (M3). One bin per shelf life.
D8
Memory archive
→ Platform auto-save (agent-*.jsonl)
Every modern agent runtime already persists its own session log. Manually maintaining D8 was redundant.
What survived
D0 / D1 / D2 (the blueprint proper) + D9 (selection log). Everything else lives in a subsystem that already does the job.
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.
Figure 03
The same Core/Side/Auxiliary triage applies whether you are classifying systems or classifying features inside a system. Every flow then resolves to five node kinds. Two ideas, no exceptions.
System level
Feature level
TIN
Terminal IN — user directly produced
DIN
Data IN — produced by another system, passed via user
TOUT
Terminal OUT — feedback the user perceives
DOUT
Data OUT — structured asset returned to user
STATE
State write — bypasses user, writes to intermediate store
two-axiom systemTwo principles, end of story. Anyone who knows them can read any blueprint in the framework without further onboarding.
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.
