Hub-and-spoke: skills never pass data to each other directly — facts route through the
Airtable MASTER base (through the review gate), artifact pointers through deal.json.
Two swimlanes: the DEAL band (top) holds everything scoped to one transaction; the GENERAL
band (bottom) holds lender intelligence that outlives every deal. Any line crossing the
divider is a deliberate bridge — there are only three. Hover to trace a workflow's
connections; click to pin it and read the detail below. Canonical wiring lives in
DATAFLOW.md; this render is as of 2026-07-31.
live skill / engine DEAL-scoped knowledge (one deal's facts & artifacts) GENERAL knowledge (reusable across every deal) in development NOT BUILT (dashed, tagged) borderline twins — open merge questiongated writes are labeled in the detail panel
Deal pipeline — one transaction's knowledge (blue hubs)
every line crossing this divider is a deal ⇄ general bridge
General — reusable lender intelligence, outlives every deal (green hub)
Click any node
Its inputs, outputs, and standing rules appear here. Amber arcs mark borderline twins — hover either end to see the open merge question.
Not built yet (dashed + tagged on the map)
uw-package — Phase 2, the biggest gap: deal-package hard-deprecates into it (spec v0.2 agreed; cashflow_tab.py built, summary tab next). Shown on-map inside the deal-package node.
lender-match — Phase 3. The green hub's main payoff; PROGRAMS is being accumulated ahead of it.
narrative-gen → om-draft — Phase 4 (first manual narrative run done on a deal).
trigger layer — item 9; until it lands, every run is Bryan-invoked.
market-data-organizer — deferred by decision; manual transcription bridges it.
rent-comps / sales-comps — Phase 2; sales-organizer returns as a uw-package module.
sponsor-organizer — name reserved; builds with Phase 4.
email-scan is IN DEVELOPMENT (dotted), not unbuilt — it runs, but writes to no external system yet.
Borderline twins — open merge questions
triage-email ⇄ email-scan — Bryan's own open question (IDEAS 2026-07-29): should email-scan have been an extension of triage-email rather than a third sibling? Merging is cheaper the earlier it happens. They already share the noise-sender config. Decision: Bryan, ideally before email-scan's taxonomy is ratified.
diligence-intake ⇄ folder-keeper — the filing half is already superseded; absorbing the date-extraction half into the keeper flow is on ROADMAP item 13's open list, after which diligence-intake has no remaining job. Decision: mechanical once item 13 resumes; legacy inbox-era deals are the only holdout.
filerename (deal-canon mode) ⇄ folder-keeper — formal retirement of the deal-canon mode is open on item 13; GENERAL mode survives regardless. Decision: mechanical, same session as the above.
double-review ⇄ Narrative Gen prose scripts — the OM-only gemini/openai twins are generalized by double-review's --profile om; consolidating the OM path onto the skill is an open Bryan decision (SKILLS.md boundary note). Until called, OM may use either. Decision: Bryan.
readiness resolver ⇄ deal-advance — read side vs execute loop over the SAME graph; sequenced by design (12 before 14) precisely so the graph isn't invented twice. Also pending: whether the deal knowledge graph (IDEAS 2026-07-31) becomes a third tab of the same internal page. Decision: at item-12 build.
deal-package ⇄ uw-package — not open: merge already DECIDED (hard-deprecation, Phase 2). Listed so nobody re-litigates it.
Litigated non-twins, kept separate on purpose: deal-email-sweep vs marketing-summary (opposite directions on the same data) · demographics vs comps (trade area vs comparables) · list-skills vs wrap (read vs reconcile).