Project documents
A project accumulates a set of documents, generated from the specification and from each other. They are what agents read before they plan or build anything, which makes reviewing them the highest-leverage thing you do in Taiga.
What the set covers
Section titled “What the set covers”| Group | Documents | What it answers |
|---|---|---|
| Intent | Project Specification | What are we building, for whom, under what constraints? |
| Design | User Flows, Architecture Overview, Technology Decisions, Data Flow Diagram | How does it work, and what did we choose? |
| Security and privacy | Threat Model, Data Protection Impact Assessment, Risk Register | What can go wrong, and what are we doing about it? |
| Communication | Service Blueprint | How is the service delivered end to end, explained without requiring a developer? |
| As-built | Codebase Snapshot | What is actually in the repository right now? |
Producing this set by hand is normally a project of its own, spread across several people. That changes what is worth your attention: the expensive part is no longer writing them, it is agreeing with them.
Order matters
Section titled “Order matters”They are generated one at a time, and not in an arbitrary sequence. Each is written from the ones before it.
The clearest case is the security group. The Data Flow Diagram identifies where data enters, rests and leaves, and where the trust boundaries are. The Threat Model and the DPIA are then written against that. Get the data flow wrong and the security work is a careful analysis of the wrong system.
Review each document as it appears rather than saving them all for the end.
Intent and reality are tracked separately
Section titled “Intent and reality are tracked separately”Every document carries an origin: plan or reality.
A plan document is what you intend. A reality document is what the code actually is, read from the repository as it stands. The Codebase Snapshot is the clearest example: a point-in-time record of the linked repository, not a description of what anyone meant to build.
Keeping these apart is deliberate. Intent and implementation drift, and a system that quietly merged them would hide exactly the gap you most need to see. Reality documents can be refreshed from the repository as the code moves on.
Sections are not fixed
Section titled “Sections are not fixed”A document’s sections come from its own content rather than from a fixed template.
So two projects’ architecture documents can legitimately have different sections, and a document can gain a kind of section that did not exist before without anything being rebuilt. If you are comparing two projects and their documents do not line up section for section, that is expected.
Updating a document from your own material
Section titled “Updating a document from your own material”You can point a document at source material you already have. Upload PDFs, spreadsheets or other documents, write a short instruction about what to do with them, and Taiga proposes targeted section updates.
You get a diff. You apply only the parts you want, and it will tell you which sections it considered and left unchanged. Nothing is rewritten wholesale behind you.
Drafts, versions and publishing
Section titled “Drafts, versions and publishing”Documents are versioned and have a draft state. An unpublished draft is yours to iterate on; the published version is what agents work from.
This matters when you are correcting something an agent got wrong: editing a draft changes nothing downstream until you publish it.