Partner workflow — visual navigation map

Looking for the step-by-step? Use the partner walkthrough. This page is a one-glance map of the same motion — useful for orientation, not for execution.

How to use this page: scan once to orient yourself across the seven stages and three responsibilities. Then open the walkthrough and follow it top-to-bottom. Come back here only if you lose the thread.

This page is a navigation map. Stage details (how to run discovery, how to scaffold, what "good" looks like) live in the linked docs and win on conflict. The node reference table below is canonical for node → first-action doc → playbook stage mapping; if the diagram and the table disagree, the table wins.

Responsibilities, not job titles. At a small partner, one person may wear both the Delivery Lead and Partner Engineer hats. The Customer Ops lane is always customer-owned — that's who runs the solution after handover. The lanes below show who does what when, not who must be hired.

This is the partner-facing end-to-end motion for cloning the accelerator and shipping a customer-specific agentic AI solution. The diagram below maps three responsibilities (Delivery Lead · Partner Engineer · Customer Ops) across the seven stages of docs/partner-playbook.md (discover → scaffold → provision → iterate → UAT → handover → measure).

Each node's click target is its first-action doc — the thing you actually open to get moving.

---

The workflow

---

Node reference (same as the diagram)

Each row states why this step matters. "Authority" is the doc that owns the motion; "Start with" is the first action-oriented doc to read. What to do lives in those docs.

#	Who	Step	Why	Authority (playbook)	First action (click target)
D1	Delivery Lead	Scope + discover	Decides whether the engagement is workshop-ready, produces the solution brief + ROI hypothesis that drives everything downstream. Supports both blank-start (canvas → workshop) and PRD-in-hand (/ingest-prd pre-drafts, /discover-scenario gap-fills).	Stage 1	discovery/how-to-use.md
E1	Partner Engineer	Scaffold from brief	/scaffold-from-brief turns the brief into working code — prompts, tools, retrieval, HITL, evals, manifest.	Stage 2	QUICKSTART.md Step 3 · first time only: run enablement/hands-on-lab.md once before your first customer engagement
EP	Partner Engineer	Preflight (landing zone + GitHub Environment)	/configure-landing-zone picks the tier (standalone / avm / alz-integrated); /deploy-to-env registers the GitHub Environment and wires the OIDC federated credential so CI can deploy without secrets. Skipping this is the #1 cause of first-deploy auth failures.	Stage 3	QUICKSTART.md Step 4
E2	Partner Engineer	Provision customer Azure	azd up provisions Foundry + Search + KV + ACA + App Insights in the customer's subscription with MI. No keys.	Stage 3	getting-started/setup-and-prereqs.md
E3	Partner Engineer	Iterate with Copilot	Every change goes through PRs that lint + quality evals + redteam must pass. Keeps HITL + RAI invariants intact.	Stage 4	QUICKSTART.md Step 7
E4	Partner Engineer	UAT support	Engineer is on-call for eval tuning, HITL approver wiring, and scenario fixes while customer runs UAT against acceptance evals.	Stage 5	partner-playbook.md Stage 5
D5	Delivery Lead	UAT sign-off	Customer sponsor walks the acceptance evals, approves production deploy. Gate before handover.	Stage 5	partner-playbook.md Stage 5
D6	Delivery Lead	Handover meeting	Formal session with customer ops — walk the packet + runbook, confirm approvers, test killswitch, hand over alerts.	Stage 6	handover/handover-packet-template.md
C1	Customer Ops	Receive handover packet	Customer ops owns the deployment from here. The engagement-specific packet is primary; the generic runbook is fallback (packet wins on conflict).	— (customer-owned)	Your engagement-specific handover packet (from the partner) · customer-runbook.md as fallback
C2	Customer Ops	Ongoing day-2 ops	Monitoring, killswitch, eval re-run, secret rotation, model swap, incident response. Steady-state, not a finish line.	— (customer-owned)	Your handover packet · customer-runbook.md as fallback
D7	Delivery Lead	Monthly value review	Measure realized KPIs against the ROI hypothesis from D1. Feeds the next engagement; justifies renewals.	Stage 7	partner-playbook.md Stage 7

Loopback note. The dashed C2 ⇢ D1 arrow is for new feature or expansion requests only — those legitimately restart discovery as a follow-on engagement. Incidents stay inside C2 and the customer runbook. The dashed C2 ⇢ D7 is the usage signal (what adoption and value look like in practice) feeding the Lead's monthly review; it is not a net-new engagement trigger.

---

Lower-frequency steps not in the diagram

These happen inside the stages above but aren't first-order navigation targets:

• ROI quantification — fill docs/discovery/roi-calculator.xlsx after solution brief Section 3 / Section 4 are confirmed, during D1. Feeds telemetry KPI names in E1. See discovery/how-to-use.md.
• Pattern switch — if the brief's solution shape isn't supervisor-routing, run /switch-to-variant during E1 before scaffolding. See .github/chatmodes/switch-to-variant.chatmode.md.
• Incident feedback loop — the dashed arrow C2 ⇢ D7 represents customer ops surfacing incidents or usage gaps back to the delivery lead for next-engagement learnings; no dedicated chatmode.

---

Related

• partner-playbook.md — narrative companion; the 7-stage motion in prose, with "what good looks like" per stage.
• ../QUICKSTART.md — 15-minute mechanics summary (for the engineer persona).
• ../README.md — the repo-level router.
• ../.github/chatmodes/delivery-guide.chatmode.md — the delivery-guide entry point; other chatmodes sit alongside it and win on conflict with narrative docs.

---

← Back to the partner walkthrough

This page is the workflow map reference. The actionable step-by-step lives in the partner walkthrough — start there, or return to whichever step sent you here.