Product documents

A product 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

Group	Documents	What it answers
Intent	Product 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?
User interface design	Look & Feel	What does the product look like, and how do you move around 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

They are generated one at a time, and not in an arbitrary sequence. Each is written from some of the ones above it, and for the required documents the order is a rule. Taiga offers only the next one, and a required document can be generated only once every required document above it is published. The same holds for regenerating one. Look & Feel and the Service Blueprint sit outside that order: each is offered once its own inputs are published, and nothing downstream waits for either.

Everything is generated from the specification. The technology decisions, the data flow, the DPIA and the threat model are written from the architecture, and the DPIA and the threat model read the data flow, which is where the trust boundaries and the data stores come from. The risk register reads both of them. A document started with a gap above it would have to invent what the missing one should have settled, so Taiga refuses to start it rather than letting an assumption in unnoticed.

Get the specification and the architecture wrong and the rest is a careful analysis of the wrong system.

Reviewing a document does not hold up the next one: a published document unlocks what follows whether anyone has read it or not. That is what lets Generate remaining write every required document still missing, in this order, while you read the ones that have landed. Review each as it appears rather than saving them all for the end. An assumption you accept in the architecture is one the threat model is written from.

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 follow the code: a push to the product’s integration branch refreshes them, a burst of pushes is folded into one refresh, and a push that changes nothing since the last analysis costs nothing. You can also refresh one document by hand.

Sections are not fixed

A document’s sections come from its own content rather than from a fixed template.

So two products’ 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 products and their documents do not line up section for section, that is expected.

Where the set lives

The product’s Documents page lists all of them together, in the order they are generated. Each row carries the document’s published version and whether anyone has marked it reviewed, so what is still unread is readable from the list rather than one document at a time.

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.

When a source changes

Documents already generated from an earlier version are not rewritten when you publish a new one. Instead, each document generated from the changed one is marked Outdated, in the document list and on its own page, and its row says what changed: for example, Architecture changed (v2 → v3). Regenerate it from its row or from its own page, or let Generate remaining pick the outdated documents up along with the required ones still missing. Until you do, the published version stands, outdated or not.

Locked once Discovery is finished

Finishing Discovery locks the set. The lock is what lets the rest of the product trust what it was built from. To change a locked document, reopen Discovery from the document’s page, make the change, and finish Discovery again. Discovery describes the step.