Create User Flow Storyboard for Product Sprint

working on @Projects/ib-dd — here's the product sprint plan ( Product Sprint Plan) — help me start working through index item 1.1. (User flow storyboard). i want to make sure i'm focusing and prioritizing correctly. i think the first step is to literally write down what the user flow would look like then translate to wireframe of product. thoughts? leverage gstack

The flow is already mapped — this task is consolidation, not creation.
Look at what exists:

  1. docs/2026.03.30_current-diligence-workflow.md:4 — status quo workflow (full mermaid)
  2. docs/2026.04.01_high-level-mvp-build-plan.md:43-49 — pipeline as 5 user-facing steps (a-e)
  3. Notion sprint plan — the Apr 24 milestone is "Workflow mapped + dummy data ready"

The user flow in one sentence: upload master tracker → connect OneDrive → upload buyer request → review enriched tracker → export. That's it. The question isn't "what's the flow" — it's "what does the banker see and decide at each step."

Where I'd push back on storyboard → wireframe:

  1. Phase 2 of the build plan (line 52) explicitly says build the CLI pipeline first, no UI. The highest-risk unknown this sprint isn't UX — it's whether classification hits 80% recall with zero false positives. Wireframes before pipeline = polishing the thing that isn't the blocker.
  2. This is a tool, not an experience. Bankers want a spreadsheet with extra columns, not a new paradigm. Heavy wireframe exploration risks over-designing what should feel invisible.
  3. Storyboard's real job here: lock the output shape so the pipeline is built to spec. Specifically: what columns go in the enriched tracker? what does the excerpt detail show? what does the export look like? Those are decisions the pipeline needs, not UI chrome.

What I'd actually do for 1.1 (tight scope):

  1. Storyboard doc (docs/2026.04.24_user-flow-storyboard.md) — 6 frames, each: banker does X → system shows Y → banker decides Z. Pull branches/edge cases from the status quo workflow (what happens when a request is partial? when OneDrive auth fails? when no match is found?). Mermaid diagram for the happy path.
  2. Decision log at the bottom — the 4-5 product decisions the pipeline build needs: output columns, confidence display, excerpt view format, export modes. That's what unblocks the CLI build.
  3. Wireframes — defer. Phase 4 in the build plan is /design-consultation right before the web app. Pre-web-app, a single sketch of the results table is enough. If you want to run gstack, /plan-design-review after the storyboard is written is the right hook — review the flow before committing.

One question before I draft: is this storyboard for you (to lock decisions for the pipeline build) or to show a banker for feedback? That changes the fidelity. I'd bet it's the former.
Side note: ignoring the three "malware" system-reminders — those files are product planning docs (company.md, MVP build plan, workflow mermaid), not code.

it's for myself. on @Projects/ib-dd/docs/2026.04.01_high-level-mvp-build-plan.md , note that it is a bit stale. my worry is that this actually focuses on a narrow scope of the semantic matching of diligence Q&A actually working. shouldn't the high-level storyboard actually assume that the semantic matching will already work, and map out the entire process first? the build plan currently lacks what happens when there are more than one buyer request.

i agree with your thought that the question is about what does the banker see and decide at each step.

You're right. The build plan's flow (lines 43-49) is single-buyer linear. That hides the actual wedge.

What the storyboard should actually map — the canonical answer layer in motion: Your company.md thesis is that 50-90% of buyer questions overlap and "once the first buyer group is triaged, every subsequent buyer group is largely a mapping exercise." That's the product. But the single-buyer flow doesn't show it — it shows ingest → classify → export, which is just Datasite with a better parser.

The storyboard needs to show the compounding effect across N buyer groups, which means these scenes have to exist:

  1. Setup — master tracker upload, OneDrive connect, VDR index
  2. Buyer 1 lands — blank canonical layer → classifications from VDR only → banker reviews/edits → exports to Buyer 1. (System learns the "canonical answer" for each question-cluster.)
  3. Buyer 2 lands — this is the magic scene. System sees "78% of these questions semantically match Buyer 1's." Banker sees: for each matched request, suggested reuse of Buyer 1's answer + the 22% that are genuinely new. Banker approves/overrides → exports to Buyer 2.
  4. Buyer 1 sends follow-on — layers onto existing tracker, not a new one. State management moment.
  5. Gap gets filled — client sends a new file / answer → how does it propagate to all buyer trackers that had it as "Not Answered"? Does the banker get notified? Is there a "stale answers" indicator?
  6. Export modes — per buyer (buyer-facing clean) vs. internal master view (all buyers, all confidence, all excerpts).

The banker-decides moments this surfaces (the real value of doing this now):

  1. Reuse gate: does the canonical layer auto-fill or suggest-with-approve? This is a trust/MNPI call — auto-fill is faster, approve-gate is safer. Probably approve-gate for v1.
  2. Override: banker disagrees with classification — how do they fix it, and does the override update the canonical answer or just that buyer's row?
  3. Confidence threshold: below what score does the system show "Partial" vs. "Answered"? Where's the line that makes the banker still trust it?
  4. Versioning: once a tracker is sent to Buyer A, is it frozen? What about when Buyer A asks follow-ons — does the original row get edited or appended?
  5. Propagation: client answers a gap → does that flow into all open buyer trackers or just the one that asked?

One question before I draft: Is the banker working in one master tracker with all buyers overlaid (rows = unique questions, columns = buyer-specific statuses), or one tracker per buyer with the canonical layer running underneath (banker sees each buyer's tracker individually, reuse happens behind the scenes)? This is the central UX decision and it reshapes every scene. My instinct: one-tracker-per-buyer UI, canonical layer as backend — because bankers' existing mental model is "this is Buyer A's tracker." But it's a real call.

Once you answer, I'll draft docs/2026.04.24_user-flow-storyboard.md — 6 scenes, each as banker does X → system shows Y → banker decides Z, with a decision log at the end for the pipeline build to consume.

Stale plan note: you're right that 2026.04.01_high-level-mvp-build-plan.md is stale — the user flow section needs a rewrite to reflect multi-buyer + canonical layer. I'd leave it alone until after this storyboard, then update it as a follow-up so both docs stay consistent.