The system of record
← Engagements

mkb — Agentic Delivery Platform

active
internalintentarchitecturegovernance
Read the engagement — in this order
1Product description — the wholediscovery/visiondraft2System description — the full platform, end to enddiscovery/systemin_review3Scope — the agreed platformdiscovery/scopein_review4Solution — decisions, technical requirements, risksdesign/solutionin_review5Delivery plandelivery/planin_review
Items
106
Open clarifications
0
Awaiting review
27
Active risks
6

Documents (5)

DOC-1
Product description — the whole →
discovery/vision
v5draft
Open document →
by agent:discovery-draftersource: slice-2 foundation deploy 2026-07-06confidence: 0.9v5updated 06 Jul, 19:48
DOC-2
Scope — the agreed platform →
discovery/scope
v3in_review
Open document →
by agent:methodology-authorsource: full-weight migration 2026-07-07confidence: 0.85v3updated 06 Jul, 19:48
DOC-3
Solution — decisions, technical requirements, risks →
design/solution
v5in_review
Open document →
by agent:methodology-authorsource: full-weight migration 2026-07-07confidence: 0.85v5updated 07 Jul, 05:08
DOC-4
Delivery plan →
delivery/plan
v4in_review
Open document →
by agent:methodology-authorsource: full-weight migration 2026-07-07confidence: 0.85v4updated 06 Jul, 19:51
DOC-5
System description — the full platform, end to end →
discovery/system
v2in_review
Open document →
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.85v2updated 06 Jul, 20:14

Increments (2)

INC-1
Slice 1 — item store skeleton
delivery/plan
v4closed
shipped
PR #2 + #3, live at mkb-api.exerun.com / mkb.exerun.com
summary
The system of record: 7 item types, revisions, links, telemetry, engagement profiles; Explorer pages; deployed to production 2026-07-06.
description
The system of record made real: seven item types with lifecycles and full revision history, typed links forming the scenario spine, telemetry events on every mutation, engagement profiles for tailoring, the Explorer's engagement pages, and a fail-closed API. Everything built since runs on it.
by agent:discovery-draftersource: slice-2 foundation deploy 2026-07-06confidence: 0.9v4updated 06 Jul, 19:51
INC-2
Slice 2 — review workspace
delivery/plan
v4active
base
Baseline #1 (scope confirmation)
summary
The consultant review experience on confirmed scope: document view with embeds, review actions, digest, taxonomy, redlines, comments, review rounds.
description
The consultant review experience, cut from Baseline #1: document and increment types, releases that pin exact item versions (review rounds and baselines), the diff engine, threaded comments, and the embed-expanding document reader — all shipped. Remaining in this increment: review actions with consultant login, the digest page, and redlines.
by agent:discovery-draftersource: slice-2 foundation deploy 2026-07-06confidence: 0.9v4updated 06 Jul, 19:51

Scenarios (21)

SCN-1
Provider scopes a new engagement from intake material
discovery/scope > intake
v3confirmed
domain
intake
description
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.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
SCN-2
Client answers clarifications via magic link
discovery/scope > client-workspace
v3confirmed
domain
client-workspace
description
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.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
SCN-3
Provider and client sign a scope baseline
discovery/scope > agreement
v3confirmed
domain
agreement
description
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.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
SCN-4
Agent session is briefed and writes back
discovery/scope > briefing
v3confirmed
domain
briefing
description
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.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
SCN-5
Consultant reviews an agent-drafted scope section
discovery/scope > review-workspace
v3confirmed
flow
  • Consultant opens the scope draft; the document renders section by section from items
  • Proposed items stand out visually from confirmed ones inside their section
  • Consultant expands an item: full body, source reference, confidence, what it serves
  • Consultant confirms it, edits it first (creating a revision), or rejects it with a reason
  • Section completeness updates immediately; the review counter drops
actors
consultant (daily during discovery), agent (drafts)
domain
review-workspace
description
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.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.9v3updated 06 Jul, 19:41
SCN-6
Consultant releases a scope draft to the client
discovery/scope > agreement
v3confirmed
flow
  • Consultant opens the release view and sees what is ready: confirmed items, queued clarifications, unresolved proposals
  • Consultant previews the engagement exactly as the client will see it
  • Consultant releases: an immutable snapshot (release v N) is created
  • The client link activates or updates; queued clarifications become the client's to-do list
  • The draft keeps evolving internally without touching what the client sees
actors
consultant (per review round), client (recipient)
domain
agreement
description
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.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.85v3updated 06 Jul, 19:41
SCN-7
Consultant compares the current draft to the last release
discovery/scope > agreement
v3confirmed
flow
  • Consultant opens the diff view for the engagement
  • Item-level changes since release v N: added, changed (with old/new), removed, state changes
  • Changes group by document section so the conversation follows the scope structure
actors
consultant (before releases and client meetings)
domain
agreement
description
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.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.8v3updated 06 Jul, 19:41
SCN-8
Two streams run in parallel: v1 is maintained while v2 is scoped
discovery/scope > agreement
v3confirmed
flow
  • v1 baseline is signed and in operation; incidents and CRs arrive against it
  • v2 discovery opens as its own increment; drafts diverge from baseline v1 without touching it
  • The consultant switches stream context explicitly; each stream shows its own status
  • Different client contacts see different streams: ops contact sees v1 state, stakeholders see the v2 draft
  • v2 releases become baseline v2; v1 views are never disturbed retroactively
actors
consultant, ops client contact, v2 stakeholders, agents in both streams
domain
agreement
description
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.
by agent:discovery-draftersource: content-model session 2026-07-06 (ForgeDock study + sync/versions constraints from Jesper)confidence: 0.85v3updated 06 Jul, 19:41
SCN-9
The client corrects the record in dialogue
discovery/scope > client-workspace
v3confirmed
flow
  • Client comments on an item or tells the dialogue 'that is not quite right, it works like X'
  • Agent maps the correction to affected items via the link graph
  • Agent proposes the corrections with impact preview; nothing is written silently
  • Consultant (or client, where released) confirms; versions and threads record the exchange
actors
client, agent, consultant
domain
client-workspace
description
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.
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.75v3updated 06 Jul, 19:41
SCN-10
Engagement setup and tailoring
discovery/scope > intake
proposed
flow
  • Consultant creates the engagement and picks the profile (domains, document set)
  • Owed documents scaffold with empty sections per the catalog
  • Gap analysis is live from minute one: what the methodology expects vs what exists
  • The intake address and client link are ready before the first meeting
actors
consultant
domain
intake
description
The five minutes that replace a week of project setup. Creating an engagement selects its profile; the platform scaffolds exactly the documents that profile owes — empty sections, live gap analysis — and nothing more.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.85v1updated 06 Jul, 20:14
SCN-11
Design is reviewed with the client
discovery/scope > agreement
proposed
flow
  • Agents draft design/solution and design/integrations from confirmed scope, per content specs
  • Consultant reviews in the workspace: confirm, edit, reject
  • A review round invites the client; they accept and comment per item
  • Round closes into the design baseline — build cuts from it
actors
consultant, client architect/owner, drafting agents
domain
agreement
description
Discovery's sibling for the design phase. Agents draft the solution and integration documents from confirmed scope; the consultant reviews internally; a review round carries the design to the client; acceptance becomes the design baseline.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
SCN-12
An increment is built under governance
discovery/scope > build
proposed
flow
  • Increment cut from the design baseline; tasks briefed by the compiler
  • Coding agents build in their own runners; every session writes receipts back
  • A change contradicting a recorded decision is held pre-merge and surfaced as a deviation item
  • Acceptance view: what was delivered vs what was scoped, as a diff
actors
coding agents, consultant, the record
domain
build
description
Where the platform's promise meets code. An increment is cut from the baseline; coding agents receive compiled briefings per task; deviations from decisions are caught before merge; receipts land as items; acceptance diffs delivered against scoped.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
SCN-13
A change request after the baseline
discovery/scope > agreement
v2proposed
flow
  • Client asks in a comment or dialogue; a CR item forms (proposed)
  • Blast radius computed via the link graph; effort signal attached
  • Client approves or declines the estimated CR
  • Approved CRs become scoped diffs against the next baseline — never silent edits
actors
client, consultant, agents (impact analysis)
domain
agreement
description
The client asks for something new once scope is signed. The platform turns the ask into a change request with computed blast radius, a real lifecycle, and — on approval — a scoped diff onto the next baseline. Change control the original methodology priced with 26 factors, reborn as arithmetic. The original methodology's discipline carries over: scope creep is countered by swapping priorities, not by add-only — an approved CR invites the question 'what moves out to make room'.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.85v2updated 07 Jul, 05:08
SCN-14
Acceptance and go-live
discovery/scope > ops
proposed
flow
  • Acceptance round: client walks scenarios, accepts per item, defects become items
  • Go-live checklist computed from owed ops documents and open blockers
  • Baseline marked live; the ops stream (incidents, small CRs) opens
  • Hypercare period tracked by telemetry, not calendar faith
actors
client, consultant, ops contact
domain
ops
description
The formal close of a delivery stream. The client walks the scenarios and accepts per item; the go-live checklist computes from the catalog (which ops documents this profile owes); the live baseline is marked and the ops stream opens.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14
SCN-15
An incident in the ops stream
discovery/scope > ops
proposed
flow
  • Incident arrives (mail-in or form) into the v1 stream
  • Linked to affected scenarios; severity set; SLA clock starts
  • Fix lands; if it changed behavior, a CR or clarification records it
  • SLA and recurrence computed from events
actors
client ops contact, consultant, agents (triage draft)
domain
ops
description
Production hurts; the record absorbs it. Incidents arrive by mail or form into the live version's stream, linked to the scenarios they break, with SLA clocks measured — and fixes that change scope become CRs, not folklore.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14
SCN-16
The consultant's portfolio morning
discovery/scope > portfolio
proposed
flow
  • Portfolio view: per engagement — open queues, aging clarifications, rounds awaiting clients, drift vs baseline
  • Sorted by what needs a human today
  • Click-through lands in the engagement, in context
actors
consultant (daily), later: the provider's team
domain
portfolio
description
One glance across every engagement: which queues rot, which clients are silent, which streams drift. The platform turns five engagements from five anxieties into one prioritized list.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
SCN-17
A new consultant or agent onboards from the record
discovery/scope > briefing
proposed
flow
  • New consultant opens the engagement: vision -> scope -> solution -> plan, each with its reading line
  • Briefing compiler produces a role-based onboarding brief
  • First task briefed from the record; their questions become clarifications, improving it for the next person
actors
new consultant, agents, the record
domain
briefing
description
The two-consultants problem, solved structurally: the next person (or session) reads vision, scope, solution and plan, receives a role-based compiled brief, and is productive without a handover meeting — because the record, not anyone's head, holds the engagement.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.85v1updated 06 Jul, 20:14
SCN-18
The methodology evolves without breaking engagements
discovery/scope > foundation
proposed
flow
  • A foundation document (catalog, spec, rule) is edited and reviewed
  • Foundation version N+1 releases
  • Engagements see 'foundation vN+1 available' and adopt when ready
  • Agent briefings update on adoption
actors
provider (methodology owner), engagements
domain
foundation
description
A lesson learned becomes a spec change, reviewed like any document, released as a foundation version — and running engagements adopt it deliberately instead of being silently rewritten.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14
SCN-19
Material arrives by mail
discovery/scope > intake
proposed
flow
  • Client forwards mail to the engagement address
  • Filed as a source with provenance
  • Agents cross-reference against existing items; proposals and clarifications form
  • Consultant reviews the proposals in the normal queue
actors
client, intake agents, consultant
domain
intake
description
The lowest-friction intake there is: the client forwards a thread to the engagement's address; it files as a source; agents cross-reference and propose — enrichments, contradictions, new clarifications.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
SCN-20
A review invitation reaches the client where they live
discovery/scope > client-workspace
proposed
flow
  • Round opens; invitation goes out with the tokenized link
  • Client answers in the workspace; progress visible to the consultant
  • Reminders throttle on measured latency; silence escalates to the consultant, not to spam
actors
client, platform (notifications), consultant
domain
client-workspace
description
Rounds don't wait to be discovered. Opening one sends the invitation (mail first, chat later) with the magic link; reminders pace themselves from answer-latency telemetry instead of nagging.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
SCN-21
A baseline is signed
discovery/scope > agreement
proposed
flow
  • Readiness green; baseline rendered from pinned items
  • E-signature flow (integration) for both parties
  • Signature recorded on the release; the anchor is legally clean
actors
client sponsor, provider
domain
agreement
description
The legally clean anchor: the rendered baseline document is e-signed by both sides; the signature binds to the exact release snapshot — nobody ever argues about which version was agreed.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14

Capabilities (9)

CAP-1
Item store
discovery/vision > the-loop
v4confirmed
example
REQ-12 exists exactly once; the scope document, the client page and an agent briefing all render the same underlying item.
excludes
  • how things are rendered or reviewed (CAP-2/3)
  • who may see what (release gate, CAP-4)
includes
  • item types and state machines
  • revisions on every change
  • links (serves/blocks/mitigates...)
  • engagement profiles (tailoring)
description
The single record every other capability reads and writes: typed knowledge items (requirements, scenarios, risks, clarifications, decisions...) each with one home, a lifecycle, full version history, human keys (REQ-3), and typed links forming the scenario spine.
by human:jespersource: VISION.md 2026-07-05v4updated 06 Jul, 19:40
CAP-2
Intake→draft engine
discovery/vision > the-loop
v4confirmed
example
Workshop notes in; REQ-2 'Support gift cards' out — state proposed, confidence 0.7, source page 3, blocked by CLA-1 'which PSP?'.
excludes
  • confirming items (consultant)
  • client interaction (CAP-3)
includes
  • upload/ingestion of material
  • extraction into typed items with provenance
  • clarification generation
  • orphan-fact lint on documents
description
Turns raw intake — meeting notes, transcripts, old documents, chat — into PROPOSED items with source references and confidence, and files clarifications for every unknown instead of assuming. Humans confirm; agents never write truth directly.
by human:jespersource: VISION.md 2026-07-05v4updated 06 Jul, 19:40
CAP-3
Client workspace
discovery/vision > the-loop
v4confirmed
example
Business owner opens the link, answers CLA-3 with 'yes, but only for EU', which spawns clarification v3 and updates readiness.
excludes
  • editing items (consultant only)
  • seeing unreleased draft documents (CAP-4 gate)
includes
  • shared read views with keys and states
  • accept/comment on released items
  • clarification answering with yes-but threads
  • client uploads feeding CAP-2
description
The client's side of the engagement: tokenized access (no account) to SHARED views — the same scope document, status and logs the consultant sees, read-only plus accept/comment per item, uploads of their own material, and over time a conversational way to correct the record.
by human:jespersource: VISION.md 2026-07-05v4updated 06 Jul, 19:40
CAP-4
Baseline engine
discovery/vision > the-loop
v4confirmed
example
Baseline v1 signed in March keeps rendering March's truth while the v2 draft diverges; the client-readable diff lists exactly what changed and why.
excludes
  • day-to-day review actions (CAP-2)
  • client rendering (CAP-3)
includes
  • release snapshots with pinned item versions
  • signable baselines
  • increment/stream scoping
  • diff views (draft vs release vs baseline)
description
The agreement machinery: releases (what crossed to the client, immutable), baselines (what was signed), increments (parallel streams like v1-maintenance vs v2-discovery), and item-level diffs between any two points — scope drift made arithmetic.
by human:jespersource: VISION.md 2026-07-05v4updated 06 Jul, 19:40
CAP-5
Briefing compiler
discovery/vision > the-loop
v4confirmed
example
A coding agent starting on the payments increment gets: the 4 confirmed requirements it serves, the PSP decision, 2 open risks — 600 tokens, not the whole engagement.
excludes
  • running the agents themselves
  • policing them (hooks live with the runner)
includes
  • two-pass briefing compilation (completeness, then ambiguity-stripping)
  • retrieval handles for just-in-time lookups
  • repo emission of generated markdown views
  • writeback of agent session results
description
Compiles the minimal, directive context an agent needs for a task — from the same items everyone else reads — and takes structured results back (decisions, deviations, new items). Emits AGENTS.md/CLAUDE.md into working repos so agents meet the engagement in the format they already understand.
by human:jespersource: VISION.md 2026-07-05v4updated 06 Jul, 19:40
CAP-6
Delivery telemetry
discovery/vision > the-loop
v4confirmed
example
'2 clarifications open 6 days, blocking REQ-12 and the checkout scenario' appears without anyone writing a status mail.
excludes
  • narrative status reports (rendered FROM this, never written)
includes
  • event log (who did what when)
  • computed status and RAG-style rollups
  • latency metrics (clarification answer time, review queue age)
  • drift alarms vs baseline
description
Append-only events from every mutation, turned into computed answers: where the engagement stands, how fast clarifications get answered, whether the review queue is rotting, whether build diverges from baseline. Status is calculated, never claimed.
by human:jespersource: VISION.md 2026-07-05v4updated 06 Jul, 19:40
CAP-7
Build governance
discovery/vision > the-loop
proposed
example
An agent implements the payments increment; its PR is held because it contradicts DEC-1's storage decision; the deviation lands as an item for the consultant.
excludes
  • running the agents (external runners)
  • code review itself (stays in git)
includes
  • pre-merge deviation checks against decisions
  • build receipts as items
  • acceptance diff: delivered vs scoped
description
Coding agents build increments under the platform's rules: briefed from the record, checked against decisions and constraints before anything merges, and their receipts — what was built, tested, deviated — written back as items. External pipelines (ForgeDock-style issue-in/PR-out) can run as engines underneath: governed, never autonomous.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
CAP-8
Operations & portfolio
discovery/vision > the-loop
proposed
example
Monday 08:30: the portfolio shows one engagement with a client 6 days silent on a blocking clarification, another with baseline drift — the consultant knows where the day goes.
excludes
  • infrastructure monitoring (stays in ops tooling)
includes
  • ops stream per live version
  • incident items with SLA clocks
  • cross-engagement portfolio view
description
Life after go-live, and life across engagements. Each live version runs as its own stream — incidents, small changes, SLA telemetry — while the consultant's portfolio view shows every engagement's queues, drift alarms, aging clarifications and waiting clients in one morning glance.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
CAP-9
Foundation manager
discovery/vision > the-loop
proposed
example
The integration spec gains a data-protection field; foundation v3 releases; two engagements adopt it, one running go-live defers.
excludes
  • engagement content (lives in engagements)
includes
  • foundation versioning
  • per-engagement adoption
  • spec changes flowing into agent briefings
description
The methodology itself as living, versioned content: catalog, content specs and rules edited and reviewed like any document, released as foundation versions that engagements adopt deliberately — so improving the method improves every future engagement without silently changing running ones.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14

Requirements (44)

REQ-1
Every fact has exactly one home: a typed item with slot, lifecycle, provenance
design/solution > item-store
v3confirmed
domain
item-store
category
technical
rationale
One-home-per-fact is what made the original methodology work.
description
Every fact an engagement needs — requirement, decision, risk, answer — exists as exactly one typed item with a slot in the document structure, a lifecycle state, and full provenance. Nothing is stated twice; everything else renders from these items.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
REQ-2
Engagement profile activates slots; gap analysis counts only activated slots
discovery/scope > item-store
v2confirmed
domain
item-store
category
functional
rationale
Tailored, not biblical — minimum sufficient documentation.
by human:jespersource: VISION.md 2026-07-05v2updated 06 Jul, 19:41
REQ-3
Items must link to the scenarios they serve (scenario spine)
design/solution > item-store
v3confirmed
domain
item-store
category
technical
rationale
Traceability was the original methodology's weak spot; here it is structure.
description
No scenario, screen, integration or test exists without a link to what it serves. The spine makes 'show me everything this scenario touches' a query instead of archaeology.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
REQ-4
Clarifications are routed items with measured answer latency
discovery/scope > client-workspace
v3confirmed
domain
client-workspace
category
functional
rationale
The clarification queue is THE core quality mechanism (verification boundary).
description
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.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
REQ-5
Clients access engagements via tokenized magic links, no accounts
discovery/scope > client-workspace
v3confirmed
domain
client-workspace
category
functional
description
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.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
REQ-6
Baselines are immutable rendered snapshots; scope change = item-level diff
discovery/scope > agreement
v3confirmed
domain
agreement
category
functional
rationale
Machine-checkable scope control.
description
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.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
REQ-7
Agent briefings are compiled (two-pass), directive, with retrieval handles
design/solution > briefing
v4confirmed
domain
briefing
category
technical
evidence
Context rot; ETH null result on descriptive dumps; hybrid JIT pattern.
hypotheses
Phase-aware briefing scoping (different context per delivery phase) is OUR untested hypothesis — no field evidence exists either way; A/B it with our own telemetry against a static constitution and pure just-in-time retrieval.
description
A briefing is compiled in two passes — completeness, then ambiguity-stripping (anything not traceable to an activated slot or confirmed item is removed, because agents treat over-specification as mandatory). It arrives directive — rules and constraints, never prose overviews — with retrieval handles (stable item keys, saved queries) for just-in-time lookups, and is emitted into the formats agents already read (AGENTS.md/CLAUDE.md).
by human:jespersource: VISION.md 2026-07-05v4updated 07 Jul, 06:46
REQ-8
Every mutation emits telemetry; delivery status is computed, never reported
design/solution > telemetry
v3confirmed
domain
telemetry
category
technical
evidence
~40pt perception gap (METR); DORA verification tax.
description
Every mutation writes an event: who, what, when. Status, queue health and drift are computed from these events — nobody writes a status report, and perception never substitutes for measurement.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
REQ-9
Every item's full detail is visible in the review surface
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
You cannot review what you cannot see. 'I can't tell you what is missing because I don't see any details' — Jesper, 2026-07-06.
description
Expanding an item shows its complete body, provenance (source document and location), confidence, revision history, and what it links to — without leaving the page.
acceptance criteria
  • All body fields render legibly
  • Source reference and confidence visible
  • Revision count and last-updated visible
  • Links (serves/blocks) shown with target titles
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.95v3updated 06 Jul, 19:41
REQ-10
In-place review actions: confirm, edit-then-confirm, reject with reason
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
Review must happen in document context, not in chat and not in a separate admin screen. Rejection reasons feed agent re-drafting.
description
Each proposed item carries its review controls where it stands in the document. Editing creates a revision then confirms; rejecting requires a reason.
acceptance criteria
  • Confirm/edit/reject on every proposed item
  • Edit produces a new revision attributed to the consultant
  • Reject blocked without a reason
  • All three visible in the activity log
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.9v3updated 06 Jul, 19:41
REQ-11
Section-level bulk confirm
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
Agents draft faster than humans click. Per-item-only confirmation guarantees review fatigue (see risk on review fatigue).
description
A consultant who has read a whole section can confirm all its proposed items in one action.
acceptance criteria
  • Bulk confirm per document section
  • Items individually revisioned and logged
  • Mixed sections (some rejected) handled without blocking the rest
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.7v3updated 06 Jul, 19:41
REQ-12
Visibility always; client review happens in invited, document-scoped review rounds
discovery/scope > agreement
v4confirmed
domain
agreement
category
functional
rationale
Jesper 2026-07-06: clients could always access drafts, but reviews were grouped per document and sent as a separate controlled process. Faster cycles, same discipline. Replaces the earlier stricter reading (client sees released material only).
description
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.
acceptance criteria
  • Draft/in-review/approved state visible on every document view
  • Send-to-review creates a review round on a pinned document version
  • Client accept/comment recorded per item within the round
  • Round closure produces a new version or an approval record
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.95v4updated 06 Jul, 19:41
REQ-13
A release is an immutable snapshot with item versions
design/solution > agreement
v3confirmed
domain
agreement
category
technical
rationale
'What did we agree' needs a fixed reference point; releases are the anchors change control diffs against — and the stepping stone to the signable scope baseline.
description
Releasing records exactly which item versions the client was shown, numbered sequentially.
acceptance criteria
  • Release stores item ids + versions immutably
  • Later item edits do not alter past releases
  • Releases listed with timestamp, author, item count
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.9v3updated 06 Jul, 19:41
REQ-14
Preview-as-client before release
A0130 > Requirements
v2rejected
rationale
The consultant is accountable for what the client sees; no surprises across the boundary.
description
One click shows the engagement exactly as the client link will render it, before anything is shared.
rejection reason
Folded into REQ-26: under shared views, preview-as-client is just the client role rendering.
acceptance criteria
  • Preview matches the client rendering byte-for-byte
  • Reachable from the review workspace
  • Shows which clarifications the client will be asked
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.8v2updated 06 Jul, 10:05
REQ-15
The narrative product document is the primary reading view
discovery/scope > review-workspace
v4confirmed
domain
review-workspace
category
functional
rationale
Consultants and clients understand products as wholes with a red thread, not as item lists. 'I miss the thin red line that bakes everything together in a product' - Jesper, 2026-07-06. The original methodology's A0100 Analysis Report served exactly this role.
description
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.
acceptance criteria
  • One document view per engagement: vision, then capability chapters with nested scenarios and requirements
  • Nesting derived from serves links, not manual ordering
  • Authored narrative blocks can be placed between sections and are versioned like items
  • Per-section completeness and gap markers preserved from the slot model
  • Reading it top-to-bottom tells the product story without opening a single item
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.85v4updated 06 Jul, 19:41
REQ-16
Item-level diff between the current draft and any release
discovery/scope > agreement
v3confirmed
domain
agreement
category
functional
rationale
Scope drift must never be invisible — success criterion #2 of the whole platform.
description
Added, changed (old vs new), removed, and state-changed items since a chosen release, grouped by section.
acceptance criteria
  • Diff vs any past release
  • Field-level old/new for changed items
  • Grouped by document section
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.75v3updated 06 Jul, 19:41
REQ-17
Documents are items: markdown narrative with live item embeds
design/solution > content-model
v3confirmed
domain
content-model
category
technical
rationale
Minimize content types to one machinery (Jesper's condition) and adopt ForgeDock's core insight: structure lives inside the readable artifact, so document and truth cannot disagree by construction.
description
A document is an item of type 'document' whose body is markdown containing embeds by reference ({{REQ-12}}). One mechanism — lifecycle, revisions, review, release — covers atoms and narrative alike. Prose never restates item content; the renderer expands embeds at read time.
acceptance criteria
  • 'document' exists in the type registry with draft/review/released lifecycle
  • Embeds resolve to current item content at render time
  • Documents version, review, and release exactly like other items
  • The vision one-pager exists as the first document item
by agent:discovery-draftersource: content-model session 2026-07-06 (ForgeDock study + sync/versions constraints from Jesper)confidence: 0.9v3updated 06 Jul, 19:41
REQ-18
Orphan-fact lint: prose claims must be backed by items
design/solution > content-model
v3confirmed
domain
content-model
category
technical
rationale
Transclusion removes duplicate truth; the residual risk is narrative stating facts that were never itemized. A lint downgrades that failure from conflict to visible incompleteness.
description
Agents lint every document for factual claims not covered by an embedded or linked item, and propose extracting each into an item with an embed left in place. Lint results attach to the document as a completeness report.
acceptance criteria
  • Lint runs on document save/review
  • Each orphan fact becomes a proposed extraction
  • Documents show orphan-fact count next to completeness
by agent:discovery-draftersource: content-model session 2026-07-06 (ForgeDock study + sync/versions constraints from Jesper)confidence: 0.75v3updated 06 Jul, 19:41
REQ-19
Baseline-pinned rendering: one document, correct for every version
design/solution > content-model
v3confirmed
domain
content-model
category
technical
rationale
Serves the many-versions reality: the maintained v1 and the in-discovery v2 read the same document sources at different pins. Falls out of embeds + release snapshots (REQ-13).
description
Any document renders 'as of' a chosen release/baseline by resolving embeds against that release's pinned item versions; the current draft resolves live. No per-version document copies exist.
acceptance criteria
  • Render accepts a release parameter
  • Embeds resolve to the pinned item version for that release
  • Draft rendering clearly marked as unpinned
by agent:discovery-draftersource: content-model session 2026-07-06 (ForgeDock study + sync/versions constraints from Jesper)confidence: 0.85v3updated 06 Jul, 19:41
REQ-20
Increments are first-class: parallel streams over one record
design/solution > agreement
v3confirmed
domain
agreement
category
technical
rationale
Real engagements maintain one version while scoping the next. Without stream scoping, parallel work forks the truth or blocks on itself.
description
An increment scopes a stream of work (e.g. 'v2 discovery') targeting a future baseline. Item changes are tagged to an increment; two increments can run concurrently; diffs compute per increment against its base baseline. Git's model applied to scope: baseline=tag, increment=branch, revision=commit, release=merge.
acceptance criteria
  • Increment type in the registry with open/active/closed lifecycle
  • Item changes attributable to an increment
  • Per-increment status and diff vs base baseline
  • Slice 1 (shipped) and slice 2 (discovery) modeled as the first increments
by agent:discovery-draftersource: content-model session 2026-07-06 (ForgeDock study + sync/versions constraints from Jesper)confidence: 0.8v3updated 06 Jul, 19:41
REQ-21
Repo emission: VISION.md and AGENTS.md are generated views of the engagement
design/solution > content-model
v3confirmed
domain
content-model
category
technical
rationale
Closes the loop the agent itself exposed: today the richest narrative lives in repo files maintained beside the platform. Emission makes the repo's markdown a view of the record, not a competitor to it.
description
The platform emits markdown views into the project repo — vision, agent instructions, scope extracts — marked as generated, with edits flowing back as proposed changes rather than silent forks.
acceptance criteria
  • Engagement can emit a markdown bundle to a target repo path
  • Emitted files carry a generated-from marker with engagement and release reference
  • Manual edits to emitted files are detected and returned as proposals
by agent:discovery-draftersource: content-model session 2026-07-06 (ForgeDock study + sync/versions constraints from Jesper)confidence: 0.7v3updated 06 Jul, 19:41
REQ-22
Track-changes review: revisions render as redlines business users recognize
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
'Business users are used to see documentation in a certain way - markdowns with track changes and comments' - Jesper. The original methodology ran customer review cycles exactly this way in Word.
description
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.
acceptance criteria
  • Any two versions of an item/document render as an inline redline
  • Accept/reject per change, not only per item
  • The redline view works for clients (read + comment) and consultants (full actions)
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.85v3updated 06 Jul, 19:41
REQ-23
Comment threads on every item, driving versions
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
Review is a dialogue, not a verdict. Jesper: a business owner saying 'yes - but' should drive version 3 of a clarification, and the trail must stay visible.
description
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.
acceptance criteria
  • Threaded comments on items and documents
  • Promote comment -> revision or -> clarification
  • Version timeline view per item showing which comment drove which version
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.85v3updated 06 Jul, 19:41
REQ-24
Condensed review digest with visible impact
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
Jesper: 'a condensed version of the comments that facilitates a change and a visible view of impact'. Also the direct mitigation for RSK-4 (review fatigue) — which this engagement is already feeling at 20+ pending decisions.
description
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.
acceptance criteria
  • Single digest across items, comments and redlines
  • Impact preview per entry from link traversal
  • Actions executable from the digest without opening each item
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.8v3updated 06 Jul, 19:41
REQ-25
Requirement taxonomy: category, functional domain, and emergent grouping
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
Jesper: requirements are a mixture of tech and func; grouping by functional domain is how consultants and clients understand scope. Same trichotomy as the original A0130.
description
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.
acceptance criteria
  • category field required on requirements
  • domain assignable and editable as scope emerges
  • document view groups by domain with per-group ordering
  • existing 21 requirements back-classified on confirmation of this item
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.85v3updated 06 Jul, 19:41
REQ-26
Client review page: shared views with accept and comment
discovery/scope > client-workspace
v4confirmed
domain
client-workspace
category
functional
rationale
Transparency decision (shared views, gated editing). Replaces the thin Q&A-only magic-link concept, which Jesper's review declared dead.
description
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.
acceptance criteria
  • Client rendering reuses consultant views (no separate dumbed-down UI)
  • Accept/comment per released item
  • Everything gated only by release state and edit rights
  • Consultant can open any surface 'as the client' — same rendering path, client role (absorbed from REQ-14)
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.85v4updated 06 Jul, 19:41
REQ-27
Clients and consultants upload source material into the engagement
discovery/scope > intake
v3confirmed
domain
intake
category
functional
rationale
Jesper: 'ability to upload meeting notes or documents, cross data points'. Intake is continuous, not a one-time dump.
description
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.
acceptance criteria
  • Upload from both consultant and client surfaces
  • Uploads stored as sources with provenance
  • Agent cross-referencing produces proposed enrichments/contradictions, never silent writes
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.8v3updated 06 Jul, 19:41
REQ-28
Answered clarifications trigger impact analysis and grouped consequence-changes
discovery/scope > review-workspace
v3confirmed
domain
review-workspace
category
functional
rationale
'A clarification on a separate item can affect wider... we need to change across many items based on a clarification comment' - Jesper. One answer, many consequences; unmanaged, this is exactly how scope quietly forks.
description
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.
acceptance criteria
  • Answering a clarification offers an impact analysis over linked items
  • Consequence-edits form a grouped changeset with one review decision
  • Per-item opt-out within the group
  • The changeset references the clarification version that caused it
by agent:discovery-draftersource: Jesper review round 2, 2026-07-06confidence: 0.85v3updated 06 Jul, 19:41
REQ-29
Document catalog: every document declares its type and owes its sections
design/solution > foundation
v3confirmed
domain
foundation
category
technical
rationale
'The vision has a place somewhere' — Jesper. DOC-1 proved documents work but nothing enforces what they should contain; the methodology's core promise is that every piece of knowledge has one defined home.
description
A document item carries a doc_type from the re-authored document catalog. The catalog defines, per document type, the required sections, which item types belong in each section, and which narrative is expected. Per-document completeness and gap analysis compute against the catalog spec — the slice-1 Document Structure Index, re-authored and retargeted at the item store.
acceptance criteria
  • doc_type on document items, validated against the catalog
  • Catalog defines sections + allowed item types + expected narrative per doc type
  • Per-document completeness (% sections filled) and gap markers
  • Creating a document scaffolds its required sections
by agent:discovery-draftersource: Jesper feedback round 3, 2026-07-06confidence: 0.9v3updated 06 Jul, 19:41
REQ-30
Re-authored document naming: phase/slug paths replace Netcompany codes
design/solution > foundation
v4confirmed
domain
foundation
category
technical
rationale
'While documentation methodology was based on Netcompany we should change the convention... its last year — new structure / naming' — Jesper. Also the clean-room requirement: the shipped methodology must be our own authorship.
description
Retire the inherited series codes (A0100, D0180...). New convention: phase/slug paths — discovery/vision, discovery/scope, design/solution, delivery/plan, delivery/status (computed only), agreement/baseline-N. Slots become path-style: 'discovery/scope > requirements/payments'. Engagement profiles activate catalog subsets by path prefix. Existing item slots migrate once confirmed.
acceptance criteria
  • Catalog v1 defined in the new convention (6-8 document types, minimum sufficient)
  • All existing item slots migrated to path-style
  • Old codes survive only as provenance references in the methodology map
  • Profile tailoring works on path prefixes
addendum 2026 07 06
Integrations: design/integrations as its own tailorable document; one repeating section per external system (design/integrations > cvr). delivery/ reserved for plan/status; design/ for what gets built.
by agent:discovery-draftersource: Jesper feedback round 3, 2026-07-06confidence: 0.85v4updated 06 Jul, 19:41
REQ-31
Section content specs: 'how to write' guidelines become machine-enforced drafting contracts
discovery/scope > foundation
v3confirmed
domain
foundation
category
functional
rationale
'We ensured we captured all the information by having clear this-is-how-you-write guidelines' - Jesper. The 49 Netcompany guidelines, re-authored as executable specs. Evidence: agents follow directive instructions (1.6x uptake); descriptive prose guidance does not help.
description
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.
acceptance criteria
  • Content spec per catalog section (required fields, guidance, example)
  • Drafting agents receive the spec for the section they are filling
  • Gap analysis measures field-level completeness, not just section presence
  • Review UI shows the spec as a checklist next to the section
by agent:discovery-draftersource: Jesper feedback round 4, 2026-07-06confidence: 0.9v3updated 06 Jul, 19:41
REQ-32
The methodology lives in the platform: catalog, specs and rules as versioned foundation content
design/solution > foundation
v3confirmed
domain
foundation
category
technical
rationale
'Should the docs driving the documentation be available in the platform?' - Jesper. Yes, as first-class content: the specs are load-bearing machinery (agents draft from them, gap analysis measures against them). Direct git browsing would recreate the dual-truth problem the transclusion model exists to prevent.
description
A foundation level above engagements holds the re-authored methodology: the document catalog (REQ-30 naming), per-section content specs (REQ-31), and process rules — as versioned platform content that engagement profiles reference and tailor. Git remains the boundary only: markdown views are emitted (REQ-21) and edits return as proposals; there is no parallel doc-browsing surface.
acceptance criteria
  • Foundation scope exists above engagements, versioned like items
  • Catalog + content specs + rules readable in the platform UI
  • Engagement profiles reference and tailor foundation content
  • No UI surface reads methodology docs directly from git
by agent:discovery-draftersource: Jesper question round 5, 2026-07-06confidence: 0.85v3updated 06 Jul, 19:41
REQ-33
Embed display modes: title, summary, or full body per embed
design/solution > content-model
proposed
domain
content-model
category
technical
rationale
The narrative pass exposed it: a scope document embedding thirty full bodies is structurally correct and unreadable. Digestibility needs graduated disclosure - Jesper, 2026-07-07.
description
An embed can declare how much of its item to show: {{REQ-9|title}} (one line), {{REQ-9|summary}} (title + first sentence), {{REQ-9}} (full, default). Documents stay digestible at 30+ embeds without dropping the live-transclusion guarantee.
acceptance criteria
  • Render supports |title and |summary modifiers
  • Default remains full body
  • Reader indicates truncated embeds and links to the item
  • category: technical, domain: content-model
by agent:methodology-authorsource: narrative pass 2026-07-07confidence: 0.85v1updated 06 Jul, 19:48
REQ-34
Identity in three tiers: consultant login, client tokens, agent keys
design/solution > platform-security
proposed
domain
platform-security
category
technical
description
Consultants authenticate with a real login (SSO-ready); clients use tokenized, engagement-scoped links; agents use scoped keys. Every actor in the record is attributable to one of the three.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.85v1updated 06 Jul, 20:14
REQ-35
Change requests are first-class items with lifecycle and blast radius
discovery/scope > agreement
proposed
domain
agreement
category
functional
description
A CR moves proposed -> estimated -> approved/declined -> delivered, carries its computed blast radius and effort signal, and on approval becomes a scoped diff against the next baseline.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.85v1updated 06 Jul, 20:14
REQ-36
Notifications and review invitations, throttled by telemetry
discovery/scope > client-workspace
proposed
domain
client-workspace
category
functional
description
Outbound mail (chat later) for round invitations, reminders and escalations — paced by measured answer latency, never by cron-spam.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
REQ-37
Every engagement has a mail-in intake address
discovery/scope > intake
proposed
domain
intake
category
functional
description
Mail forwarded to the engagement files as a source with provenance and enters the normal cross-referencing flow.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
REQ-38
E-signature on baselines
design/solution > agreement
proposed
domain
agreement
category
technical
description
Baseline documents are signed through an e-signature integration; the signature binds to the exact release snapshot and is stored on the release.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14
REQ-39
Pre-merge deviation checks with receipts as items
design/solution > build
v2proposed
domain
build
category
technical
description
Everything articulable becomes a deterministic gate: acceptance scenarios generated from the scenario spine (BDD-style), machine-checkable rules from decisions and constraints, checked pre-merge. AI review is reserved for the unarticulated residual — evidence: deterministic checks caught 5/5 planted domain bugs where AI review caught 0/20. Every agent build session writes a receipt item (built, tested, deviated).
human gates
Human attention is budgeted, not assumed: client gates (clarifications, sign-offs) are the predicted bottleneck — prioritized by blast radius, batched, and measured by answer latency.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v2updated 07 Jul, 06:46
REQ-40
Portfolio view across engagements
discovery/scope > portfolio
proposed
domain
portfolio
category
functional
description
One view over all engagements: queues, latencies, drift, waiting-on-client — sorted by what needs a human today.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
REQ-41
Incidents as items in ops streams with SLA telemetry
discovery/scope > ops
proposed
domain
ops
category
functional
description
Incidents live in the version stream they hit, linked to broken scenarios, with SLA clocks and recurrence computed from events.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14
REQ-42
Foundation versioning and deliberate adoption
design/solution > foundation
proposed
domain
foundation
category
technical
description
Foundation content releases as versions; engagements pin and adopt explicitly; agent briefings recompile on adoption.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.75v1updated 06 Jul, 20:14
REQ-43
Engagement isolation now, provider multi-tenancy later
design/solution > platform-security
proposed
domain
platform-security
category
technical
description
Engagements are strictly isolated (data, tokens, briefings). The architecture stays multi-tenant-shaped so other providers can be onboarded when the platform has proven itself — without a rewrite.
by agent:discovery-draftersource: night discovery pass 2026-07-07: full-platform system description from all session dialoguesconfidence: 0.8v1updated 06 Jul, 20:14
REQ-44
References are items: evidence, sources and external material as first-class content
design/solution > content-model
proposed
domain
content-model
category
technical
rationale
Half the confirmed requirements cite evidence (verification tax, the 0/20 domain-rule finding, docs-as-code dominance) that currently lives only in the repo — unreachable from the record it justifies. Flagged twice in audits; never scoped until now.
description
A 'reference' item type holds evidence and sources — research findings, the methodology map, external documents — with a summary, provenance and link/location, embeddable in documents like any item. The verified research corpus and the methodology conceptual map move from repo files into foundation references.
acceptance criteria
  • reference type in the registry
  • summary + source location + retrieved-date fields
  • embeddable in documents
  • research report and methodology map ingested as foundation references
by agent:discovery-draftersource: completeness audit 2026-07-07confidence: 0.85v1updated 07 Jul, 05:08

Assumptions (3)

ASM-1
Clients will engage through a shared review workspace (tokenized access)
discovery/scope > assumptions
v3confirmed
plain
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.
still unvalidated
Whether clients actually engage at sufficient throughput remains the largest untested product assumption.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 19:41
ASM-2
Agents know general tech, not the client's business — writing client specifics down is where we win
discovery/scope > assumptions
v3confirmed
plain
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.
consequence
Prioritize capturing client-specific rules, vocabulary and constraints as items early; generic tech knowledge can stay implicit.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 19:41
ASM-3
We can sell discovery as a fixed-price product — unproven until we sell one
discovery/scope > assumptions
v3confirmed
plain
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.
consequence
Validate by selling one paid discovery engagement, not by more research.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 19:41

Clarifications (6)

CLA-1
What is the platform's name?
log/clarifications
v5answered
note
Domain/trademark checks pending on all four.
answer
Yes — naming session agreed, to be held now that scope is confirmed.
context
The platform needs a name before any client sees it. 'mkb' (methodology knowledge base) describes the engine, not the product. The name should carry the promise: agreed scope, visible status, no drift.
candidates
  • Redthread — 'den røde tråd' made literal: the thread binding scope, build and status
  • Enig — Danish for 'agreed'; the product's promise in one word
  • Baseline — what clients buy: the agreed line everything measures against (generic risk)
  • Keel — what keeps the ship straight at speed, invisibly
options considered
  • keep mkb for the engine, name the product separately
  • name it after the methodology concept (baseline, thread, scope)
  • neutral brandable name
by human:jespersource: VISION.md 2026-07-05v5updated 07 Jul, 05:08
CLA-2
What pricing posture for the productized discovery offering?
log/clarifications
v5resolved
answer
Premature — park pricing until we believe we know what we are doing.
context
The discovery->scope engine is sellable standalone as a paid product (VISION.md section 6). Decide the posture before the first external engagement: fixed-price discovery package, discovery credited against delivery if we win the build, or free discovery as sales cost. Research produced zero verified evidence on pricing - this is a bet we make deliberately.
resolution
Deliberately deferred; revisit when the discovery product is proven on a real engagement.
by human:jespersource: VISION.md 2026-07-05v5updated 06 Jul, 19:41
CLA-3
Can a release ship while some items in released sections are still proposed — or must sections be fully reviewed first?
log/clarifications
v4resolved
answer
Yes — a review round can open while some items are unreviewed, visibly marked as such (transparency model).
context
Determines release semantics: strict (clean sections only) is safer but slower; partial (withhold unreviewed items) is faster but the client sees an incomplete picture without knowing it.
resolution
Adopted. Also surfaced a new need: an answered clarification can require changes across many items -> REQ-28.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.9v4updated 06 Jul, 19:41
CLA-4
Is single-consultant confirm enough for v1, or do we need reviewer assignment / a second pair of eyes?
log/clarifications
v4resolved
answer
Start thinking multi now. Build single-consultant confirm first, but design review states, actors and assignment so multiple reviewers fit without a rework.
context
Netcompany used peer review before customer approval. Solo consultancy may not need it yet — but the state machine is hard to retrofit if we guess wrong.
resolution
Build single-consultant confirm now; model review states/actors so multi-reviewer assignment can be added without rework.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.9v4updated 06 Jul, 19:41
CLA-5
Should the client see item keys and states (e.g. 'REQ-7 · confirmed'), or clean prose only?
log/clarifications
v4resolved
answer
Two-sided: clients see everything — shared views are a key methodology principle. Same renderings, same keys and states as the consultant. What is gated is EDITING, not visibility.
context
Keys give precise reference in conversations ('about REQ-7...') but make the scope feel like a database. Clean prose reads like a document but loses addressability.
resolution
Visibility always, review by invitation. Clients can access draft documentation at any time (clearly marked draft/in-review/approved). The controlled act is the REVIEW ROUND: a document version formally sent to the client for review — grouped per document, like the classic Word cycle, just faster. Control items (risks, clarifications, status) shared live. Item keys and states visible to clients.
synthesis to confirm
Proposed reconciliation with the release gate: control items (risks, issues, clarifications, CRs, status) are shared LIVE; scope/design DOCUMENTS are shared per released version (draft wording stays internal until released). Mirrors the original methodology: clients had live Toolkit access while deliverables followed draft->review->approved.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.85v4updated 06 Jul, 19:41
CLA-6
Legacy graph data (DataLens + old foundation): keep hidden, archive, or delete?
log/clarifications
v4resolved
answer
Delete. The legacy data isn't needed, and mixing legacy with current risks coding something wrong. Clean sheet.
context
The Explorer's Matrix/Hierarchy/Entities/Gaps pages still show the pre-pivot knowledge graph (DataLens project + methodology foundation in FalkorDB). Not derived from the item store; a survivor of the old architecture. Deleting is irreversible; the DataLens knowledge might be worth re-ingesting as items later.
options
  • keep but hide (recommended)
  • export to archive, then remove
  • delete outright
resolution
Staged execution: (1) wipe FalkorDB graphs now, (2) remove legacy Explorer pages from navigation now, (3) excise legacy graph code paths (endpoints, models, MCP tools) as a cleanup work package in a coming increment.
recommendation
Keep-but-hide: label legacy pages, keep FalkorDB data untouched, revisit when the graph is rebuilt as a derived index over items.
by agent:discovery-draftersource: Jesper feedback round 3, 2026-07-06confidence: 0.9v4updated 06 Jul, 19:41

Decisions (10)

DEC-1
Typed items canonical; documents rendered views; graph derived index
design/solution > decisions
v3accepted
adr
docs/decisions/0002-typed-items-canonical.md
rationale
Scope control, clarifications, status and briefings are all state questions, so the truth must be typed items with lifecycles — stored boringly in Postgres. Documents are rendered views that cannot disagree with the record; the knowledge graph is demoted to a derived, rebuildable index. Extraction proposes; humans confirm.
consequence
ADR 0002. Postgres became the system of record; graph fragility stopped being existential.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
DEC-2
Deployment-first: no calendar phases, capabilities ship as slices
design/solution > decisions
v3accepted
source
VISION.md §7
rationale
No calendar phases: a walking skeleton ships first, and every capability lands as a deployable slice, dogfooded on the platform's own engagement. The backlog is ordered by what the next real engagement needs, not by a plan document.
consequence
Slice 1 shipped within a day of the decision; every build since runs gate -> build -> deploy -> dogfood.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
DEC-3
Single polymorphic items table + revisions + generic links
design/solution > decisions
v3accepted
adr
docs/decisions/0003-item-store-data-model.md
rationale
One polymorphic items table with JSON bodies, full-snapshot revisions and generic typed links: dozens of future item types without migrations, uniform lifecycle/diff machinery for all of them, and the scenario spine as plain data.
consequence
ADR 0003. Body validation tightens per type as the catalog's content specs land.
by human:jespersource: VISION.md 2026-07-05v3updated 06 Jul, 20:14
DEC-4
Consultant surface is the reviewable scope document, not chat; nothing reaches the client until released
design/solution > decisions
v2accepted
rationale
Consultants cannot get overview in a chat stream. The scope draft rendered from items IS the review surface: agents propose into it, consultants confirm/edit/reject in place, and an explicit release step gates all client visibility so the provider side agrees scope internally first. Mirrors the original methodology: peer review precedes customer review.
consequence
Slice 2 = review workspace + release gate; intake agents feed it. Items need a released/visibility dimension.
by human:jespersource: brainstorm session 2026-07-06v2updated 06 Jul, 19:41
DEC-5
Transparency by default: clients share the consultant's views; editing is gated, visibility is not
design/solution > decisions
v4accepted
rationale
'Clients should be able to see everything - that is a key thing in methodology. Shared views (of course not shared editing capabilities)' - Jesper. Precedent: Netcompany clients had read access to the live Toolkit; deliverables followed draft->review->approved.
consequence
No dumbed-down client renderings; clients reuse consultant views read-only with accept/comment. Drafts are visible and clearly stated. The controlled process is the per-document REVIEW ROUND (send-to-review), not content hiding. Netcompany precedent: clients could always access drafts but typically waited for the review invitation.
by agent:discovery-draftersource: Jesper review round 1, 2026-07-06confidence: 0.9v4updated 06 Jul, 19:41
DEC-6
Clean sheet: legacy graph data deleted, legacy UI and code paths removed
design/solution > decisions
v3accepted
rationale
Legacy DataLens/foundation graph data and the pages reading it create ambiguity about what is current — 'risk of coding something wrong because we don't know what is legacy'. Jesper ruled: not needed, delete.
consequence
FalkorDB graphs wiped; Explorer navigation reduced to the item-store surfaces; legacy graph endpoints/models/MCP tools excised progressively. The graph returns later only as a derived, rebuildable index over items.
by agent:discovery-draftersource: Jesper ruling 2026-07-06v3updated 06 Jul, 19:41
DEC-7
Own UI on the item store; ForgeDock adopted as ideas (and maybe later a build-phase component), never as the platform base
design/solution > decisions
v3accepted
rationale
ForgeDock has no UI to base on — GitHub issues/PRs are its interface, its users are developers. Our load-bearing needs (client magic links with shared views, signable baselines and review rounds, parallel versions over one record) have no home there. Its transferable ideas are already adopted: embedded structure in prose -> {{embeds}}, process-as-markdown-specs -> methodology re-authoring, phase receipts -> telemetry.
reference
github.com/RapierCraftStudios/ForgeDock
consequence
Stay on the item-store + Explorer path. Revisit ForgeDock at the build increments as a candidate issue-in/PR-out engine running UNDER platform governance (briefings in, pipeline receipts back as items) — integration, not foundation.
by agent:discovery-draftersource: Jesper question round 5, 2026-07-06confidence: 0.9v3updated 06 Jul, 19:41
DEC-8
Dogfood first: the platform's first customer is our own consultancy
design/solution > decisions
v2accepted
rationale
Fastest path to truth: v1 runs our own engagements with clients getting per-engagement access. The architecture stays product-shaped (multi-tenant) so productizing later is a go-to-market decision, not a rewrite — but selling to other providers waits until the platform has proven itself on real deliveries.
consequence
No tenant onboarding or billing machinery in v1; engagement #0 is the platform itself; engagement #1 will be a real client.
by agent:discovery-draftersource: vision brainstorm 2026-07-05, recorded during completeness audit 2026-07-07confidence: 0.95v2updated 07 Jul, 05:08
DEC-9
Hybrid agent model: native process agents, governed external coding agents
design/solution > decisions
v2accepted
rationale
The platform RUNS its own agents for process work — drafting scope, generating clarifications, compiling status — because that work is the product. It GOVERNS external coding agents (Claude Code and peers) via briefings, hooks and receipts, because agent runners are commoditizing and should be integrated, not rebuilt.
consequence
CAP-2/CAP-5 are native agent capabilities; CAP-7 is a governance surface. Orchestrating coding agents directly stays out of scope unless governance proves insufficient.
by agent:discovery-draftersource: vision brainstorm 2026-07-05, recorded during completeness audit 2026-07-07confidence: 0.95v2updated 07 Jul, 05:08
DEC-10
The methodology's shape: few hard baselines, parallelizable increments between them
design/solution > decisions
v2accepted
rationale
Clients need contract-grade gates (scope, design, go-live — signed); agents need speed and parallelism between them. So: client-signed baselines pin agreement, increments carry design->build->test->accept mini-cycles agents can parallelize, and item-level diffs against baselines ARE change control. Phase documents become live views, not milestone artifacts.
consequence
Replaces the classic five-phase gate cascade and pure-continuous delivery alike. Realized in CAP-4, REQ-13/16/20 and the increment model.
by agent:discovery-draftersource: vision brainstorm 2026-07-05, recorded during completeness audit 2026-07-07confidence: 0.95v2updated 07 Jul, 05:08

Risks (6)

RSK-1
Clarification queue becomes the new verification bottleneck
log/risks
v2open
mitigation
Budget human gates; prioritize by blast radius; track answer latency.
by human:jespersource: VISION.md 2026-07-05v2updated 06 Jul, 19:41
RSK-2
Findability fails — users can't locate the right information in seconds
log/risks
v2open
mitigation
Jesper's watchpoint; measured success criterion on engagement #1.
by human:jespersource: VISION.md 2026-07-05v2updated 06 Jul, 19:41
RSK-3
Graph index drifts from the item store
log/risks
v2open
mitigation
Graph is derived and rebuildable; never in the write path.
by human:jespersource: VISION.md 2026-07-05v2updated 06 Jul, 19:41
RSK-4
Review fatigue: agents draft faster than consultants review
log/risks
v2open
mitigation
Bulk confirm, confidence-ordered queues, drafting throttled to review capacity, queue-age telemetry.
description
If the proposed queue grows unbounded, review becomes rubber-stamping and the confirm state stops meaning anything — the verification bottleneck reappearing inside our own tool.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.85v2updated 06 Jul, 19:41
RSK-5
Dueling edit channels: chat edits and UI edits fork the truth
log/risks
v2open
mitigation
Single write path: every channel goes through the same item API, every change is a revision, optimistic concurrency on version.
description
Scope edited both conversationally (via agents) and in the review UI can diverge or overwrite silently.
by agent:discovery-draftersource: discovery pass: VISION.md + review-workspace session 2026-07-06confidence: 0.7v2updated 06 Jul, 19:41
RSK-6
Platform stack reliability: unexplained production restart
log/risks
open
mitigation
Watch for recurrence; on second occurrence, investigate server-level logs and Coolify events, add container restart policies and an external uptime check. The record survived intact throughout (Postgres unaffected) — the truth-model separation did its job.
description
On 2026-07-06 ~20:00 the production stack spontaneously entered 'starting' and never recovered on its own — containers down ~2.5 hours until a forced redeploy at 22:14. Cause unknown; no deployment triggered it. One occurrence is a data point; two is a pattern.
by agent:discovery-draftersource: production incident 2026-07-06confidence: 0.9v1updated 07 Jul, 05:08

Recent activity

REQ-39item.updated
agent:methodology-author07 Jul, 06:46
REQ-7item.updated
agent:methodology-author07 Jul, 06:46
DOC-3item.updated
agent:discovery-drafter07 Jul, 05:08
SCN-13item.updated
agent:discovery-drafter07 Jul, 05:08
RSK-6item.created
agent:discovery-drafter07 Jul, 05:08
CLA-1item.updated
agent:discovery-drafter07 Jul, 05:08
REQ-44item.created
agent:discovery-drafter07 Jul, 05:08
DEC-10item.updated
human:jesper07 Jul, 05:08
DEC-10item.created
agent:discovery-drafter07 Jul, 05:08
DEC-9item.updated
human:jesper07 Jul, 05:08
DEC-9item.created
agent:discovery-drafter07 Jul, 05:08
DEC-8item.updated
human:jesper07 Jul, 05:08
DEC-8item.created
agent:discovery-drafter07 Jul, 05:08
DOC-5item.updated
agent:discovery-drafter06 Jul, 20:14
DOC-5item.created
agent:discovery-drafter06 Jul, 20:14
link.created
agent:discovery-drafter06 Jul, 20:14
REQ-43item.created
agent:discovery-drafter06 Jul, 20:14
link.created
agent:discovery-drafter06 Jul, 20:14
REQ-42item.created
agent:discovery-drafter06 Jul, 20:14
link.created
agent:discovery-drafter06 Jul, 20:14
REQ-41item.created
agent:discovery-drafter06 Jul, 20:14
link.created
agent:discovery-drafter06 Jul, 20:14
REQ-40item.created
agent:discovery-drafter06 Jul, 20:14
link.created
agent:discovery-drafter06 Jul, 20:14
REQ-39item.created
agent:discovery-drafter06 Jul, 20:14