Requirements and knowledge
The Docs nav item holds a project's requirement chain: what was asked for, what the project does, what work delivered it and what proves that work. A requirement points at the passage that asked for it or at the application that implements it, a task points back at its requirement, and evidence hangs off the task. The same page hosts the generated customer Summary. Knowledge pages and guides live in the same store on the project's engine fork. The platform re-derives every provenance claim rather than believing it.
The four parts
| Tab (UI name) | Also called | What it holds | Where it lives |
|---|---|---|---|
| Requirement sources | materials | Every uploaded file and typed request, versioned as a set | The platform database; the original files in object storage |
| Requirements | features | What the project does, one row per requirement, pinned to a sources version | The project's knowledge store on its engine fork |
| Tasks | tasks | Work created from a requirement and filed to the Board | The requirement ledger plus the Board cards |
| Evidence | evidence | Screenshots, commits, test notes, steps and links attached to an implemented task | The platform database |
A Timeline tab reads all four together, and the Summary view projects them into a customer-facing document.
Requirement sources
A source is a PDF, a word-processing document, an audio recording (transcribed asynchronously), an image (a mockup, a whiteboard photo, a diagram), typed or pasted text, or one of two kinds only the Feed creates: a meeting topic and a Slack digest routed into the project. Every original is uploaded to object storage.
Any mutation (upload, edit, new request, deletion) mints the project's next sources version and snapshots the item set, so a past version renders exactly as it was. A diff between two versions names the items added, changed or removed.
Requirements
A requirement row carries a name, a description, use cases, a status, linked tasks, an origin and a kind.
Kind
Functional (the default), quality, constraint, design, non-goal or noise. The tab groups rows by kind, and kind is pinned once recorded. A non-goal (explicitly out of scope) and noise (text that asks for nothing: headings, boilerplate, background) never take tasks or status. Noise rows exist so that every passage of every source is linked to a row; otherwise text that produced no requirement would look the same as text nobody read.
Origin
From a source: the origin is the source item, a verbatim quote and the character position the platform computed. The platform re-finds the quote in the file and rejects one it cannot find. As-built: the project already implements it, and the origin is the application, read from the live implementation (what its endpoints really do), never from a specification page. A project with applications and no sources still gets a full as-built list.
Status
Derived, weakest to strongest: planned, in progress, implemented, verified. Every filed task done makes a row implemented; evidence on a linked task makes it verified. A manual override always wins and is shown next to the derived value. A row no longer supported by any source is flagged missing, never deleted.
Coverage
A row links any number of passages through citations (a quote, or the first and last words of a long passage). The platform counts origin quotes plus citations per source and returns the uncovered gaps. After a generation, up to three coverage rounds ask only for the passages still unlinked, attaching each to an existing row, a new row or a noise row. A round that makes no progress ends the rounds and never undoes the review. The Requirement sources tab paints uncovered passages with a count, and Cover the rest runs the rounds alone.
Delta reviews
Requirements are never regenerated once a requirements version exists. A review diffs the current sources against the sources version the previous requirements version was pinned to, sends only the changed items and asks for only the affected rows. An empty diff is a recheck of implementation coverage. Versions carry their mode: seed, delta, recheck or selection. Manual overrides, human edits and task links survive a review.
Requirements for this passage
Selecting text in a source offers this action. It books one scoped review whose verdict (covered, partially covered, gap, or not a requirement) is shown inline under the passage, with the rows that cover it. Only missing rows are written.
Compare by sources version
One panel with two axes. By sources version, the platform resolves each sources version to the requirements version pinned to it and shows the sources delta plus the added, changed and removed rows, a changed row showing what it was and which fields changed. By requirements version, the same panel compares two requirement versions directly. The version picker on Requirement sources offers the requirements delta of any version.
The build preview
The first sources version of a project drafts a build preview: one fleet generation designs several variants of the change, each shown as two screen mockups (a widget tree on a twelve-column grid, drawn by one renderer), a plain summary, how it differs, effort S/M/L and a folded technical inventory (data, services, screens, workflows, agents, models, pipeline, what the sources exclude). Variants differ in shape, never in scope. Every text is editable before approval. A comment regenerates with a steer and keeps earlier rounds, and rounds survive a platform restart.
Approval adds the approved design to the requirement sources as a text item plus one image item per rasterised screen, files one build card on the Board ("Build from sources" or "Change from sources") with the pictures attached, and settles the version. "Build without a preview" and "Nothing to build for this version" are the other two exits.
Once a version is settled, or when the project already has a live application, later sources versions skip the preview and book a delta review at once. "Analyse this project" is refused while a preview is open or its build card is still queued, claimed, running or waiting. See Delivery lifecycle.
Tasks
A task is created from a requirement and linked back. The "+ task" button files the kind of work the requirement calls for:
| Work kind | When |
|---|---|
| Change to an application | A change to the application that owns the requirement, else the project's main application |
| Change to the pipeline | Rule, flag or normalisation requirements |
| New model, agent, workflow, guide or report | The text names that platform surface |
| New application | Only when the project has no application |
A picker overrides the kind before filing. Several requirements can be filed as one card, worked as one design pass or as a checklist in order. A task whose card was cancelled can be deleted. The Tasks tab lists builds above the requirement tasks with their stage line (sources, preview, build, analysis).
Evidence
Evidence is attached to a task and shown on the task and under its requirement: a screenshot, a commit (by hash), test notes, steps a person can follow, a link. Browser tests file their screenshots as evidence automatically; see Tests and health.
Timeline
The Timeline is a read over the four stores, newest first. Families: sources (a version minted, items added, changed or removed), build (preview rounds, comments, decision, the build card filed, started and done, the analysis booked), requirements (a review, rows appeared, reworked or flagged missing), tasks (filed and done through the Board card), evidence.
The Docs Assistant
Every fork carries a stamped Docs Assistant agent. Its tool reads a snapshot of the chain the platform re-stamps after each review, because requirements live in the fork's knowledge store while sources, tasks and evidence live in the platform database, and a fork-local tool can reach neither live. Every answer carries the time of its snapshot. Noise rows are excluded. See Agents and MCP.
The project Summary
Docs, Requirements, Summary is the customer-facing account of the project, generated from the chain: the sources, the requirement rows with live status and evidence, the tests, the applications and app services with their URLs, workflows, agents, guides and governance. Statuses read Demonstrated, Verified and Open. Non-goals are their own section; noise rows never appear. The only hand-written part is the notes (audience, decisions the customer must make, caveats). The Summary can be downloaded as Markdown, opened as a print-ready page for the browser's Save as PDF, and saved as a copy to Knowledge as a dated handover page that travels with the project.
Knowledge pages
The project's Knowledge pages are the knowledge store on its engine fork: Markdown bodies whose wiki-style links become a link graph, read and written through typed tools (list, get, search, upsert, neighbours, links) on the project's MCP endpoint and through the Docs page (the Knowledge and Specification tabs, reachable by URL). Entry types: specification pages, requirement documents, requirement rows, guide tours, handover pages, digests and meeting items from the Feed, and concept notes. A delivery exports the Knowledge pages and indexes them in the runbook; see Deployments and environments.
Guides
A guide is a knowledge-store entry the Guides page (Build group) launches as a spotlight tour over the running application, listed by the application it explains with a preview of the step outline. "Build a guide" files a new-guide or change-guide request on the Board. Each saved guide can carry one PDF (cover, contents, every step's title and body with a screenshot captured when the guide was built, rendered by a headless browser walking the real tour); "Download PDF" shows pages and capture time and flags a capture older than the guide's last save. Inside an app service a guide needs the embed bridge; see Applications.