The discovery session
Run the session and let the harness turn consented notes into structured findings and success criteria — the contract the whole build traces back to.
- Run a discovery session that listens for verbs, not feature names
- Turn consented notes into attributed, numbered findings
- Treat the findings and criteria as the contract for Part III
You run the session. The question set was generated and then human-curated — the machine drafts forty, you keep the twenty that a person in this room would actually answer. In the room you listen for verbs, not feature names: “we rebuild the pipeline deck every quarter,” “reps swivel-chair six systems,” “KYC chases documents by email.” Verbs are where the pain is; features are what you sell later.
By the end you have six findings and six things the demo will have to prove. These are the findings that land:
- D1 — No unified client view — relationship data split across ClientTrack, email, spreadsheets, fund accounting, and a consultant-database subscription; "who at Contoso knows Meridian's CIO" takes days.
- D2 — Pipeline is a quarterly PowerPoint exercise; stage definitions differ by region; consultant influence isn't first-class data.
- D3 — RFP/DDQ responses take 3–6 weeks; answers live in old documents; SMEs re-answer the same questions.
- D4 — Onboarding averages 92 days; KYC document collection is email-based; refresh backlog flagged in audit.
- D5 — 40% of service inquiries are "where is my report / what are my holdings"; reps use six systems; quarterly reporting quadruples volume.
- D6 — Leadership mandate: "AI in the flow of work, not another portal"; Security requires tenant-grounded, auditable AI.
And the success criteria the close will map back to, one by one:
- S1 — One client 360.
- S2 — One mandate lifecycle with stage-appropriate AI.
- S3 — RFP first-draft from weeks to hours, with provenance.
- S4 — Onboarding orchestration with visible state and automated document chase.
- S5 — Tier-1 service deflection safely grounded in client data.
- S6 — Every capability shown has a governance answer.
The discovery-scribe turns the consented notes or transcript into
02-discovery/findings.md: structured findings, each with a quote attributed to
the person who said it, and the success criteria each one implies. It has no
external tools at all — it reads what you consented to share and writes
structure, nothing more. It cannot browse, and it will not invent a quote.
That findings file is the most important artifact in the engagement. It is the contract for Part III: every table you model, every row you fabricate, every demo beat you script will trace back to a D-number and an S-number. If a later artifact cannot name the finding it serves, it does not belong.
Why attribution matters
A finding without a face is an opinion. “Onboarding takes 92 days” is a claim; “Dan Whitfield, who owns onboarding and has the audit finding to prove it, says it takes 92 days” is a quote you can put on screen and defend. The scribe keeps the attribution because the demo will need it — when you show the onboarding board in Part IV, you are answering Dan, by name.
In the field
Take a set of notes from a real or mock discovery — with consent — and run the discovery-scribe over them. Check that every finding carries an attributed quote and at least one success criterion. That is the shape of a findings file you can build a demo against.
Part II is done
The engagement has a dossier you can defend and a findings file that is now the contract. In Part III, the clock starts: two weeks to build the environment those findings describe.
- 02-discovery/findings.md — findings D1–D6 with attributed quotes
- The six success criteria S1–S6 the demo must hit