# Discovery

Source: https://docs.tai.ga/learn/discovery/

Discovery is the discovery phase of a software project.
What you are building, why it is worth building, and how it should work.

It happens in three steps, and you can walk back to an earlier one at any point.
**Context** collects what the product should be built from: reference material and standing rules.
**A conversation** settles what you want, and produces the specification.
**Documents** takes it from there: every other document is written from the specification and from the documents before it, one at a time, with you reviewing each.
An imported product reads its repository in place of the conversation; [Import an existing codebase](https://docs.tai.ga/learn/import-an-existing-codebase/) covers that path.

That work does not change because Taiga does it. What changes is what it costs.
Traditionally this is months of workshops, interviews and write-ups across several people.
Here the conversation is yours and the rest is generated,
and what comes out is a specification agents can act on directly
rather than a document somebody has to translate first.

It is the Learn loop's question in practice: are we building the right thing?
Everything downstream reads what you settle here.

## The conversation

Discovery starts as a conversation. You describe what you want to build, in your own words,
and Taiga assembles a structured specification from what you say.

You do not need to prepare anything or learn the vocabulary first.
The one thing worth doing deliberately is saying when something is undecided,
rather than picking an answer to move things along.
An open question is visible later. A guess is not, and everything generated afterward is built on it.

Your progress is saved as a draft, so you can leave and come back.

## If you already have material, put it in first

You do not need to prepare anything. But if material already exists that this product
should be built from, Discovery can use it while you talk rather than after.

Put reference material and standing rules in before you start: in Discovery's Context step for this product, or at the organization or factory for anything shared.
The product's own Knowledge and Instructions pages open once Discovery is finished.
Discovery searches your knowledge base as the conversation goes, across the organization, factory and product together, and reads the instructions at all three levels.

You do not have to leave the conversation to do it, either.
A file attached in the chat is added to the product's knowledge base,
not just to that message: it stays there after the conversation ends
and is available to everything that comes later.
An image is saved the same way, but for now only Discovery reads it, in the message it was attached to.

Anything true of more than this one product belongs at the organization or factory rather
than here. Put it there once and every future product inherits it,
instead of you remembering to repeat it.

[Policies, Instructions and Knowledge](https://docs.tai.ga/context/policies-instructions-and-knowledge/)
covers which is which.

## The specification

The specification is Discovery's main output.
It is built in seven sections, worked through in order:

| Section                     | What it settles                                                                   |
| --------------------------- | --------------------------------------------------------------------------------- |
| **Vision and purpose**      | The core problem, your vision for the solution, and how you will measure success. |
| **Users and stakeholders**  | Primary users, their roles, and their permissions.                                |
| **Capabilities**            | The core features and workflows.                                                  |
| **Data and information**    | Key data entities and the relationships between them.                             |
| **Technical context**       | Integration requirements and technical constraints.                               |
| **Compliance and security** | Security and regulatory requirements.                                             |
| **Timeline and priorities** | Timeline, milestones, and what comes first.                                       |

The result is structured and machine-readable.

Machine-readable is the point.
It is not a document written for people that agents happen to read.
It is the input every later step is generated from.

Each section carries its own completion status, so you can see what is still thin
rather than discovering it when something downstream comes out vague.
You can export it as a PDF.

## Publishing is what makes it count

Publishing the specification is what moves Discovery on to the rest of the document set.
Nothing downstream reads a draft, so there is no cost to leaving one open
for a day and coming back.

Publishing is a milestone, not a point of no return.
Until Discovery is finished, a published specification can be edited again:
your changes accumulate in a new draft, invisible to everything downstream,
and take effect when you publish the next version.
Every published version is kept.

One thing does not happen by itself: documents already generated from an
earlier version are not rewritten when you publish a new one.
Instead, each document generated from it is marked **Outdated**,
in the document list and on its own page.
Its row in the list names what changed: for example, _Specification changed (v2 → v3)_.
The same happens further down: when the architecture changes,
everything generated from it is marked too.
To bring one up to date, regenerate it while Discovery is open: from its row in the document list, or from the menu on its own page.
Once Discovery is finished, reopen it first.
**Generate remaining** in the document list regenerates outdated documents too, in order with the ones not yet written.
An outdated document does not stop you finishing Discovery.

Before you publish, it is worth one deliberate read.
Not for polish, but for the two things that are expensive later:
anything asserted that you are not actually sure about,
and anything left vague that the rest of the product will have to guess at.

Everything generated afterward is written from this document.
An error here is not one error, it is the same error repeated in every document that follows.

## The rest of the document set

With a specification published, the remaining product documents are generated from it,
one at a time, from Discovery's Documents step.

Do this in the order Taiga offers rather than in bulk.
The documents feed each other, so an assumption you accept early is one you have accepted everywhere.

One document in the list is not prose: [Look & Feel](https://docs.tai.ga/learn/ui-direction/) is a rendered screen of the product's look, navigation and forms, drawn from the specification.

The same list is the product's **Documents** page afterwards.
It carries each document's version and whether anyone has marked it reviewed,
which is what makes it the place to check the set rather than a table of contents.
[Product documents](https://docs.tai.ga/learn/product-documents/) covers the set and the order.

## Finishing Discovery

Discovery ends when you finish it, not when the last document lands.
Finish Discovery is offered once every required document is published.
Finishing locks the document set, opens the rest of the product, and takes you to Initiatives.

Until then the product is in Discovery.
Its sidebar row and breadcrumb take you to the step it has reached, and the pages downstream of the documents stay closed.

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.
The set is editable again, and you finish Discovery again when you are done.

## What Discovery does not decide

Discovery describes the product, not the work.

Turning it into things that can be built is a separate step, and it happens after Discovery is finished.
See [your first product](https://docs.tai.ga/start/first-product/) for that path end to end.