> ## Documentation Index > Fetch the complete documentation index at: https://docs.bluegenai.com/llms.txt > Use this file to discover all available pages before exploring further. # The First Step in Traceability What the platform records as you build: the chain from source material to tested application, how changes are attributed and reviewed, and the boundaries each agent works inside. Regulated work is not judged only on whether the software runs. It is judged on whether you can show how it came to be that way. This page collects what the platform records as a by-product of normal use. There is no separate compliance mode to switch on; the chain described here is produced by working through a project in the usual order. ## The Chain from Requirement to Test Each stage of a project consumes the one before it, which is what makes the work traceable rather than merely documented. | Stage | What it produces | What it carries forward | | :------------------ | :------------------------------------------------------------------ | :------------------------------------------------------------------------- | | **Source material** | A solicitation, a requirements pack, an existing codebase, or a mix | The origin of every downstream statement | | **CAB** | A structured specification in 10 sections | User Stories, each with acceptance criteria and a numbered flow | | **Tickets** | The units of work | The requirement behind each one, and any Note you added to the story | | **Epics** | Build order | Which Tickets belong to which wave, and in what sequence | | **Build** | The application | The agent works from the Ticket, the Epic, and the requirement behind them | | **App Testing** | Pass or fail per scenario | The acceptance criteria written in the User Story | The acceptance criteria that get tested are the ones written into the User Stories in the CAB, which produced the requirement that generated the Ticket, in the Epic that set its place in the build. **Nothing in that chain is added afterwards to make the work look organised.** The practical consequence is that the chain is only as good as the corrections you make to the blueprint. A requirement the CAB got wrong and nobody fixed is traceable all the way to a passing test. ## What the Review Record Captures Every change to a blueprint goes through review before it lands, whether you made it by hand or asked the CAB agent to make it for you. * Each proposed change is tagged as coming from **a person or from the AI**. * You accept or reject each one individually. * The system records **who decided, their email address, and when**, then who applied the result. **What is auditable is the review process, not the finished document.** While a change is under review, provenance is complete. Once a change is applied, that record stays with the review; the blueprint itself carries no per-section history, so reading a finished CAB does not tell you which parts a person rewrote. Previous versions are retained as timestamped snapshots, but the snapshots record when, not who. If you need to show who changed a specific requirement, the review history is where that lives. Plan to keep it rather than reconstruct it from the document. ## What a Blueprint Does When Your Source Material Is Silent A specification that quietly fills its own gaps is more dangerous than one with visible holes, because the holes are the part you need to see. The CAB is built to leave them visible. | Situation | What the platform does | | :---------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | | Your material never named the project or client | Both are inferred and marked `[Inferred]` | | Two source documents contradict each other | Both readings appear and the discrepancy is noted, not silently resolved | | Your material described no reports | The Reporting section is generated empty rather than invented | | Your material implies no business rules | Only rules present or implied in your documents appear; there is no standard rule set supplied | | Something could not be determined at all | It becomes a **Suggested Question**, with the context that prompted it, the impact of leaving it open, and concrete options | Suggested Questions are deduplicated across your whole source set and ordered by impact, so the ones that most affect the build appear first. Treat that section as the agenda for your next requirements conversation rather than as a list of defects. ## What Each Agent Is Allowed to Do The platform runs several agents, each confined to its own job. | Agent | Confined to | | :------------------ | :------------------------------------------------------------------------------------------- | | **Prototype agent** | Front ends with mock data; it does not touch databases | | **Build agent** | Your project's own workspace; it cannot reach outside it | | **Testing agent** | Browser controls only: no file access, no command execution, no internet | | **Ask Mode** | Read-only; it is prevented from changing anything, and cites answers at `path/file.ext:line` | **That separation is enforced by the platform rather than requested in an instruction.** It is a property of how the agents are wired, not a rule they have been asked to follow. ## Related topics - [Step-by-Step Workflow](/cab/step-by-step-workflow.md) - [What Goes In?](/cab/supported-input-types.md) - [Troubleshooting & FAQ](/tips-and-tricks/troubleshooting-faq.md) - [BlueGenAI Documentation](/index.md) - [Overview](/web-apps/build-mode/overview.md)