Scope — what is agreed

How to read this document. This is the contract-bearing view of the platform: everything here is a confirmed item, embedded live from the record — the text below each bold heading IS the item, at its current version, with its review state in italics. Sections follow the delivery loop, not a database order: material comes in, gets reviewed, reaches the client, becomes agreement, feeds agents, and reports itself. Each section opens with two or three sentences telling you what you are about to read and how its items relate. Assumptions and deliberately parked topics close the document.

Intake — how raw material becomes proposals

Everything starts with unstructured reality: meeting notes, transcripts, old documents, mails. This section covers how that material enters an engagement and becomes typed, sourced proposals — with agents forbidden from assuming their way past a gap. The scenario shows the flow; the requirement makes continuous upload from both sides concrete.

SCN-1 — Provider scopes a new engagement from intake material (confirmed)

A new engagement starts with a dump of whatever exists — notes, transcripts, slide decks, mail threads. Agents draft typed, sourced items from it, gap analysis shows what the methodology still expects, and the clarification queue forms. When readiness turns green, the scope is ready to meet the client. REQ-27 — Clients and consultants upload source material into the engagement (confirmed)

Meeting notes, documents and mails can be uploaded (or mailed) into the engagement by either side; agents cross-reference uploads against existing items — enriching, contradicting or gap-filling — and file the results as proposals.

Review workspace — where drafts become agreed scope

The consultant's daily home. Agent drafts arrive here, and the consultant turns them into agreed scope without leaving the document context. The scenario sets the loop; the requirements then pin its parts in reading order — first seeing everything (detail), then acting on it (confirm/edit/reject, bulk), then the surfaces that keep review humane at volume (the document view itself, redlines, comments, the digest, taxonomy) and the propagation of consequences when one answer changes many things.

SCN-5 — Consultant reviews an agent-drafted scope section (confirmed)

The daily discovery loop. An agent has drafted items from intake material; the consultant needs to turn drafts into agreed scope without leaving the document context. REQ-9 — Every item's full detail is visible in the review surface (confirmed)

Expanding an item shows its complete body, provenance (source document and location), confidence, revision history, and what it links to — without leaving the page. REQ-10 — In-place review actions: confirm, edit-then-confirm, reject with reason (confirmed)

Each proposed item carries its review controls where it stands in the document. Editing creates a revision then confirms; rejecting requires a reason. REQ-11 — Section-level bulk confirm (confirmed)

A consultant who has read a whole section can confirm all its proposed items in one action. REQ-15 — The narrative product document is the primary reading view (confirmed)

The engagement renders as ONE document: vision on top, each capability a chapter, scenarios nested under their capability, requirements nested under the scenarios they serve - the serves-link graph rendered as narrative hierarchy, with authored connective prose between sections. Type-grouped item lists remain as audit views only. REQ-22 — Track-changes review: revisions render as redlines business users recognize (confirmed)

Item and document changes present in the Word idiom business users already know: old text struck through, new text marked, per change, inline where it applies. Accepting a redline confirms the revision; rejecting reverts it with a reason. REQ-23 — Comment threads on every item, driving versions (confirmed)

Anyone with access can comment on an item; comments thread; a comment can be promoted into a change (new version) or a new clarification. Clarifications specifically show their version timeline with the comment track that caused each version — the business owner's 'yes, but...' becomes clarification v3, visibly. REQ-24 — Condensed review digest with visible impact (confirmed)

One pane listing everything awaiting a decision — proposed items, open comments, pending redlines — each with a one-line summary and its blast radius: which scenarios, capabilities and documents are affected via the link graph if this change lands. REQ-25 — Requirement taxonomy: category, functional domain, and emergent grouping (confirmed)

Every requirement carries a category (functional / technical / formal) and, where applicable, a functional domain. The document view groups and orders requirements by domain with display numbering per group, while immutable keys stay stable underneath. Domains emerge as scope emerges — they are not fixed upfront. REQ-28 — Answered clarifications trigger impact analysis and grouped consequence-changes (confirmed)

When a clarification is answered (or a review comment lands), the agent computes the blast radius through the link graph and proposes ONE grouped changeset touching every affected item — reviewed and accepted as a unit, with per-item opt-out.

Client workspace — the shared side

The client sees the engagement through the same views the consultant uses — transparency is the default, editing is what's gated. These scenarios show the two ways a client participates (answering what is asked, and correcting what they read); the requirements pin the access model and the page itself.

SCN-2 — Client answers clarifications via magic link (confirmed)

The client follows their link, sees the questions waiting for them with enough context to answer well, and answers in place. Each answer immediately updates what it touches — the client watches their input change the scope, which is what keeps them answering. SCN-9 — The client corrects the record in dialogue (confirmed)

A client reads something that is subtly wrong and says so in plain language — first as comments, over time as a conversation with an agent that proposes the consequence-corrections across all affected items ('that changes REQ-7 and closes CLA-2 - confirm?'). The full agentic client experience grows out of this scenario. REQ-4 — Clarifications are routed items with measured answer latency (confirmed)

Every unknown becomes a clarification item routed to whoever can answer it, with age and answer latency measured. The queue is worked, not admired: an unanswered clarification visibly blocks the items it gates. REQ-5 — Clients access engagements via tokenized magic links, no accounts (confirmed)

A client reaches their engagement through a tokenized link — no account, no password, scoped to that engagement, expiring and renewable. The barrier to answering is one click. REQ-26 — Client review page: shared views with accept and comment (confirmed)

Behind the tokenized link the client gets the consultant's views read-only — document, status, logs, keys and states included — plus accept/comment per released item and answer threads on clarifications. No editing.

Agreement — where "agreed" becomes enforceable

The heart of the methodology: deliberate acts that turn a living draft into something both sides can rely on. Read these as one mechanism seen from four angles — a review round carries a document version to the client, a baseline freezes the agreement, diffs make every later change visible, and increments let one version be maintained while the next is scoped.

SCN-6 — Consultant releases a scope draft to the client (confirmed)

The internal/external boundary. Nothing is client-visible until the consultant deliberately releases; releasing defines exactly what the client sees and which clarifications they are asked to answer. SCN-3 — Provider and client sign a scope baseline (confirmed)

When gaps are closed and clarifications answered, the consultant renders the scope as a signable baseline. Both sides sign the same rendered snapshot; from that moment, every change is a visible diff against it. SCN-7 — Consultant compares the current draft to the last release (confirmed)

Scope drift made visible. Before a client meeting or a new release, the consultant answers 'what changed since the client last saw this?' in one view. SCN-8 — Two streams run in parallel: v1 is maintained while v2 is scoped (confirmed)

The normal shape of a real engagement after first go-live: production v1 runs under a signed baseline with incidents and small change requests, while v2 discovery evolves the scope in its own stream. REQ-12 — Visibility always; client review happens in invited, document-scoped review rounds (confirmed)

Clients can see the engagement at any time, including draft documents, with document state (draft / in review / approved) unmistakable. The controlled act is sending a document version to review: it opens a review round in which the client accepts/comments per item; closing the round feeds a new version or approval. REQ-6 — Baselines are immutable rendered snapshots; scope change = item-level diff (confirmed)

A baseline is a rendered, signable snapshot of the agreed scope at a moment in time. Scope change after signing is an item-level diff against it — visible, attributable, machine-checkable. REQ-16 — Item-level diff between the current draft and any release (confirmed)

Added, changed (old vs new), removed, and state-changed items since a chosen release, grouped by section.

Briefing — how agents meet the engagement

Agents never read the whole record; they receive compiled, minimal, directive context for the task at hand, and must write their results back. One scenario carries this section; its technical requirements live in the Solution document.

SCN-4 — Agent session is briefed and writes back (confirmed)

An agent session starts from a compiled briefing — the minimal context for its task — and may not end without writing back what it decided, where it deviated, and what it discovered. The record briefs the next session; no memory lives in anyone's head.

The record beneath it all

Everything above stands on one property: every fact has exactly one home. This requirement is the tailoring rule — an engagement only ever owes the documentation its profile activates.

REQ-2 — Engagement profile activates slots; gap analysis counts only activated slots (confirmed)

Tailored, not biblical — minimum sufficient documentation.

Methodology as content

The rules that govern how documents are written are themselves platform content — versioned, reviewable, and compiled into agent briefings.

REQ-31 — Section content specs: 'how to write' guidelines become machine-enforced drafting contracts (confirmed)

Every catalog section carries a content spec: required attributes per item type in that section (e.g. an integration section requires purpose, direction, pattern, contract format, volumes, error handling, environments), writing guidance, and an example. Specs are compiled into agent drafting briefings as directive instructions, measured by field-level gap analysis, and shown to reviewers as checklists.

Assumptions — what we believe but have not proven

Three beliefs the platform is built on. The first is the largest untested product bet; the second is why the platform wins where generic AI fails; the third is deliberately unproven until we sell one.

ASM-1 — Clients will engage through a shared review workspace (tokenized access) (confirmed)

Original assumption was a thin magic-link page for answering clarifications. Jesper's review (2026-07-06) revised it: the link is just the access mechanism — behind it the client needs a full review experience: the same views the consultant has, with accept and comment on every released item, the ability to upload meeting notes and documents, and over time a conversational way to correct the record. ASM-2 — Agents know general tech, not the client's business — writing client specifics down is where we win (confirmed)

AI models are strong on general technology and weak on any specific client's business rules, because those rules are not in their training data. In a test, four leading models all missed a domain-specific billing rule 20 out of 20 times when it was undocumented — but a written test scenario caught it every time. So the platform's biggest value is capturing exactly the knowledge that only exists at the client. ASM-3 — We can sell discovery as a fixed-price product — unproven until we sell one (confirmed)

The bet: a client will pay a fixed price for the discovery phase alone, because its output — a signed scope baseline with readiness and open questions — is valuable even if they build with someone else. There is no market evidence for or against this yet; the research found zero verified claims on pricing.

Out of scope — deliberately parked

Pricing (parked until the discovery product is proven on a real engagement) · multi-reviewer workflows (designed for, not built) · operations documents (until a go-live approaches) · selling the platform to other providers (after it has proven itself on ours).