What is a need?
A need is a request, as one or more clients actually expressed it, with every sentence that proves it. It carries a title, a description of what is being asked, the accounts that raised it, and each quote with its meeting, date, speaker and timestamp.
A need never says what should be built. That is the central constraint of the system and it is structural, not editorial: the pass that creates needs has no field to write a solution into, and its instructions forbid proposing one. It sorts, and it stops.
BES-042 · 4 quotes · 3 accounts · theme “Security and access”
What are the seven steps?
The pipeline has seven steps, from the calendar to the specification. Every arrow between two steps is a real transformation: no step re-keys the one before it.
| Step | What goes in | What comes out |
|---|
| 01 | Calendar | An event, a Meet link | A meeting and its transcript |
| 02 | Enrichment | The transcript and its attendees | A dated meeting, attached to an account and a project |
| 03 | Extraction | Enriched meeting | Decisions, risks, requests, actions, ideas — each one quoted |
| 04 | Deduplication | Extracted items | One record per thing said |
| 05 | Review | Deduplicated items | Items sealed, corrected or dismissed |
| 06 | Register | Sealed items | Needs grown, attached to a theme |
| 07 | Spec generation | A sealed need | User stories, UX constraints, technical scope, definition of done |
How do four meetings become one line?
At step 06, every sealed item is checked against the needs that already exist in the space, and the instruction is to prefer what exists over creating something new. A request already on file receives one more quote; it does not produce a second record.
That is what separates a register from a set of minutes. Minutes produce four documents nobody joins up. The register produces one line whose fourth quote comes from a person who never spoke to the other three.
Deduplication at step 04 does the same job inside a single meeting: a thing repeated seven times in forty-eight minutes is one record, not seven.
Where does a person have to step in?
At one step only, the fifth. Nothing that was extracted enters the register until a person has sealed, corrected or dismissed it — and nothing dismissed comes back.
Spec generation, at step 07, does not open a second gate: it reads sealed needs only, and what it writes stays a proposal until a person has read it. The move from “what the client asked for” to “what we should therefore do” is never made before a human has first said yes to the need.
What happens if nobody reviews?
Nothing enters the register. Extracted items stay as drafts in the review queue, dashed, and keep being deduplicated against later meetings. The queue does not go stale.
The first seal, even a week later, files everything that has been sealed, not only the item just ticked.
What states does an item or a need have?
Five states, named for what the person controls rather than for what the system is doing.
| State | What it means |
|---|
| AI draft | Extracted, not yet read by a person. Dashed everywhere. |
| In review | In the queue, waiting to be sealed. |
| Sealed | A person said yes. Enters the register and becomes citable. |
| Closed | The subject is settled. Still readable, no longer surfaced as open. |
| Dismissed | A person said no. Does not enter the register, does not come back. |
What can you get out of the register?
Four things, and all four read the same sealed material. The pre-meeting brief, which says what each attendee has already said and what is still open. The register itself, one line per request. The map of themes, which shows what an account actually talks about over six months. And a question asked in plain language, of one meeting, one account or the whole register.
None of those four readings touch drafts. A map of themes drawn from material nobody read back would be a map of what the model thought it heard.
Agents reach the same readings over MCP, within the same perimeter.
And the specification?
That is step 07, from the Organisation plan up. A sealed need becomes a specification: user stories, UX constraints, technical scope and a definition of done. Every block carries the same quotes as the need it came from.
The register stays useful to a team that ships no software at all; the specification is what a team that does gets out of it next, without re-keying anything.
Where are sealed needs written?
In Calliops, and in your Notion if you connect it. Nothing is written into Notion before it is sealed, and everything exports to Markdown, quotes and seals included.
And if a sync fails?
The screen says so with the time and offers to resume. The blocked item is stamped in ink, not in red: it is not lost, it is waiting.
Notion sync interrupted at 09:41. Resume.