kushi-agents 3.4.1

package/plugin/reference-packs/fde/core-fde-reference.md

@@ -0,0 +1,427 @@
+# FDE Reference — What Good Looks Like
+
+> Source: Forward Deployed Engineering — Customer Presentation.pptx (Microsoft ISD)
+> This is the authoritative definition of FDE. All project analysis, risk assessment, CRM notes, and status outputs produced by Kushi's `fde-report` skill (and FDE-shaped answers from `ask-project`) **must** be grounded against this reference.
+
+---
+
+## What FDE Is
+
+Forward Deployed Engineering (FDE) embeds elite engineering crews directly with customers to deliver transformative, measurable business outcomes. It uses the Azure platform, proven production accelerators, and AI-assisted Hypervelocity Engineering to deploy mission-critical solutions in **weeks — not months**.
+
+Core equation: **FDE = Engineering + Delivery + Trust + Product Code Impact**
+
+---
+
+## What FDE Is NOT
+
+| Anti-pattern | Why it disqualifies |
+|---|---|
+| Scale motion or staff augmentation | FDE is intentionally selective, reserved for highest-impact, mission-critical opportunities |
+| Long phased transformation before value | Not designed for multi-quarter planning cycles; built for weeks-to-impact |
+| Platform-agnostic | Only for customers committed to Azure/Microsoft platform choices and engineering patterns |
+| Slow governance environments | Not for environments that can't support rapid decisions, tight feedback loops, and frequent iteration |
+| Out-of-the-box scenarios | If need can be met with standard Microsoft products or typical partner delivery, FDE is not the right tool |
+| Traditional consulting / advisory | FDE does not produce strategy decks. Crews ship production-grade software and own measurable outcomes |
+| Long-term outsourcing | Success = customer self-sufficiency. Not prolonged Microsoft dependency or ongoing operational ownership |
+
+---
+
+## What Makes a Great FDE Engagement
+
+### Use Case Criteria
+- **Novel and complex agentic use cases** requiring customized software for horizontal and vertical platform integration
+- **Mission-critical** — not exploratory or "nice to have"
+- **High business impact** — directly affects P&L
+- **Industry-defining and frontier** in nature — yields patterns that reduce future customer costs and improve products
+- **Cannot be solved** with existing Microsoft products, services, or typical partner delivery models
+
+### Sponsor and Customer Criteria
+- **C-level sponsor with direct access** — able to pick up the phone and unblock decisions
+- **Committed to Azure/Microsoft stack** — not platform-agnostic
+- **Can operate at hypervelocity** — rapid decisions, tight feedback loops, frequent iteration
+- **Clearly accountable business owner** actively engaged through production deployment (IT alone is not the unlock)
+- **Can co-build with Microsoft** — dedicating developers, data scientists, and product owners to work side-by-side
+- **Ready for meaningful financial investment** — customer-funded or ECIF/ESIF
+
+### Team Criteria (MS side)
+- Business-value obsessed — focuses on products, not demos
+- Executive presence, learn-it-all mindset, generous knowledge sharing
+- Agentic AI across the full SDLC: envisioning, requirements, scope, backlog, features, code, docs, security, deployment
+- Leverages accelerators and high-quality, high-context development environments
+
+---
+
+## FDE Fitness Checklist (Use Against Any Customer)
+
+| # | Criterion | Good Signal | Risk Signal |
+|---|---|---|---|
+| 1 | Use case is mission-critical | Business-impacting, in critical system/process | Exploratory, innovation budget only |
+| 2 | Cannot be solved with existing product/partner | Custom multi-platform integration needed | Standard ISV/out-of-box solution exists |
+| 3 | Azure/Microsoft platform commitment | Committed to Azure as primary platform | Multi-cloud, AWS/GCP primary, or undecided |
+| 4 | C-level sponsor with access | Named exec, can be reached directly | Sponsor is IT-only or mid-management |
+| 5 | Customer can operate at hypervelocity | Rapid approvals, agile delivery culture | Heavy governance, slow procurement cycles |
+| 6 | Business owner actively engaged | Business owner in every sprint/meeting | IT is the only contact; business is absent |
+| 7 | Customer co-builds (developers, POs) | Dedicated engineers committed to co-build | Customer expects Microsoft to do everything |
+| 8 | Funding clarity | ECIF, ESIF, or customer-funded confirmed | Funding unclear; no budget owner named |
+| 9 | Measurable outcomes defined | Named KPIs, success metrics from day one | Vague outcomes, no measurement plan |
+| 10 | Contracting/procurement can move fast | Pre-existing agreements, framework in place | New SOW/MSA required; legal cycles expected |
+
+---
+
+## FDE Delivery Model
+
+- **Phase 1 — Environment Readiness & Team Priming**: access, security, governance, data alignment
+- **Phase 2 — Prototyping & Building**: iterative sprints, working prototypes → production deployments
+- **Phase 3 — Scale & Launch**: production-ready solutions, reusable code, IaC, docs
+- **Phase 4 — Handoff**: customer self-sufficiency, operational readiness, go-live support
+
+Deliverables include: production-ready Azure code, documented success metrics, MVP, reusable playbooks/blueprints, security/compliance/governance docs, observability/monitoring, AI-enabled technical documentation, and outcome monitoring.
+
+---
+
+## CRM Triage Plan Status Meanings
+
+Use the CRM `Status` field as a primary engagement-lifecycle signal in reports, readouts, portfolio summaries, and status interpretations. Do not treat the numeric label as cosmetic metadata; it indicates where the request sits in the FDE operating flow.
+
+| CRM Status | Meaning | Reporting Interpretation |
+|---|---|---|
+| 1 - New | Submission entered the system and awaits initial review | Very early intake; do not imply staffed engagement readiness |
+| 2 - Intake Review | FDE Intake Team is assessing completeness and readiness for triage; no team assigned yet | Pre-triage; scope and ownership are still being validated |
+| 3 - Triage | FDE Recon team is named, assigned, and actively connecting with the account team to clarify request, customer, and likely funding model | Active shaping stage; leadership, funding path, and customer signals should still be treated as in validation |
+| 4 - Technical Assessment | "The WHAT". Discovery with the customer covers business goals, personas, users, and technical requirements | Customer-facing discovery is underway; this is the strongest early signal that the opportunity is becoming concrete |
+| 5 - Deal Closure & Legal Agreements | Paperwork is being finalized; billable SOW or non-billable legal agreement should be agreed and stored | Commercial and legal closure is the gating signal; avoid calling the work fully staffed execution yet |
+| 6 - Assigned | "The HOW". Scope is agreed with the resources who will execute the project | Execution team and delivery shape are committed; this is the strongest pre-delivery readiness signal |
+| 7 - In Progress | Project is in execution mode with hands-on delivery | Active FDE delivery |
+| 8 - Completed | Project completed; resources are no longer working on it | Closed engagement; use past-tense reporting and focus on outcomes, handoff, or follow-on need |
+| 9 - Withdrawn | Withdrawn | Closed without delivery continuation; do not frame as active pipeline or normal completion |
+| `<New>` On Hold | On Hold | Temporarily paused; distinguish from withdrawn and from active delivery |
+
+### Reporting Guardrails for CRM Status
+
+- `8 - Completed` and `9 - Withdrawn` are both closed states, but they mean different things. `Completed` implies the engagement ran and is now done; `Withdrawn` implies the request was stopped and should not be described as delivered work.
+- `4 - Technical Assessment` is not the same as `7 - In Progress`. It signals customer discovery and shaping, not execution.
+- `6 - Assigned` is stronger than `5 - Deal Closure & Legal Agreements` because the delivery scope and resources are committed.
+- `3 - Triage` and earlier statuses should be reported as pipeline shaping or intake, not as active execution.
+- If CRM notes, transcripts, or local artifacts conflict with the CRM status, call out the mismatch explicitly rather than silently overriding either source.
+
+---
+
+## FDE Value Proposition
+
+- **3–5× faster deployment velocity** via Hypervelocity Engineering + production accelerators
+- Working prototypes in **days**, production deployments in **weeks**
+- Elite expertise without overhead of large consulting teams
+- De-risked implementations with proven patterns
+- Capability building — not just delivery; customer independence is the goal
+
+---
+
+## Risk Categories to Always Evaluate
+
+When assessing any FDE engagement or project, evaluate risk against these FDE-specific dimensions:
+
+### 1. Competitive & Strategic Fit Risk
+- Is the customer evaluating or already using a competing platform (Google/ADK, AWS, Palantir, Salesforce)?
+- Is the use case novel enough to require FDE, or could standard product/partner delivery suffice?
+
+### 2. Funding and Commercial Risk
+- Is funding confirmed (ECIF, ESIF, customer-funded)?
+- Is the financial investment commitment from the customer real and named?
+
+### 3. Contracting / Procurement Risk
+- Does a new contract need to be negotiated? (Prior engagements have failed when this dragged on)
+- Are prior Microsoft engagement histories with this customer understood? (COIN, ISD, etc.)
+
+### 4. Sponsorship Risk
+- Is there a named C-level sponsor with actual accessibility and authority?
+- Is business ownership present beyond IT, with engagement in sprints?
+
+### 5. Hypervelocity / Culture Risk
+- Can the customer operate at FDE pace (rapid decisions, frequent iteration)?
+- Have they demonstrated or committed to co-build resourcing?
+
+### 6. Scope / Use Case Fit Risk
+- Is the use case well-defined with measurable KPIs?
+- Has the distinction between "agentic platform" vs. "specific use case" been resolved?
+- Could a standard ISV solution or Copilot product solve it without FDE?
+
+### 7. Resourcing Risk (MS side)
+- Are senior principal-level engineers confirmed for the engagement?
+- Is there sufficient SE/FDE capacity for the required depth?
+
+### 8. Handover / Sustainability Risk
+- Is there a plan for customer self-sufficiency after FDE completes?
+- Will the customer be able to run, maintain, and extend what FDE builds?
+
+---
+
+## Spotlight: What Great Looks Like (Reference Cases)
+
+### Global Oil & Gas
+- 2+ year partnership; evolved from MVE to multi-workstream $1B value target by 2030
+- CEO personally requested Microsoft help; demo to board led to direct ask to Satya Nadella
+- Key: Milestone 0 MVE investment + C-level relationship + co-creation (not doing it for them)
+
+### Confidential (Engineering/Defense)
+- 3rd customer-funded engagement; 20 Microsoft FDEs; board-level contact
+- Customer realized they couldn't succeed without FDE
+- Novel, complex customized software — no ISV solution existed; SIs couldn't cross the MS platform ecosystem
+- Key: Co-creation + novel requirements + sustained C-level partnership
+
+---
+
+## Customer Readiness Criteria (Preparing for FDE)
+
+1. Agree to engagement model with shared accountability
+2. Align on clear business outcomes and success metrics **before** project start
+3. Commit to co-investment (financial or resource-dedicated)
+4. Provide dedicated domain experts to work **daily** with FDE
+5. Enable real-time collaboration with engineers, architects, and product teams
+6. Support agile decision-making and feedback loops throughout
+7. Grant timely access to systems, data, environments
+8. Align on security, compliance, governance from day one
+9. Prepare infrastructure for deployment and testing
+10. Participate in user training, adoption, handover, and operational readiness
+
+---
+
+## FDE Intake Stages, Gates, and Checklists
+
+**Purpose**: Define what must be true at each stage before an engagement advances to the next. Use this to answer "What is pending for \[project\] at this stage?" and "What should we prepare for the next stage?"
+
+**Operating Principles**:
+- One front door: All requests enter via FDE Front Door and move through defined stages
+- Fast signal > perfect detail: Early stages optimize for routing quality; deeper scoping happens after team engagement
+- Two paths to Technical Assessment: (1) non-D2ISE through Recon/Triage; (2) D2ISE may move directly from Intake Review
+- Keep / Share / Give: Recon/Triage may keep (small, high-impact cycle), share (bring in receiving studio), or give (hand-off to best-fit team)
+- Stage gates are mandatory: Do not advance until exit criteria are met and documented
+
+---
+
+### Stage 1 — **New**
+
+**Definition**: Submission has entered the FDE Front Door and awaits initial review. No team is assigned yet.
+
+**Primary Objective**: Confirm the request is valid, complete enough to process, and has a reachable submitter/contact.
+
+**Minimum Checklist**:
+- Request created in intake system and visible in reporting
+- Basic metadata captured (customer, contact, scenario summary, region, funding selection if known)
+- Duplicates checked and consolidated if needed
+- Submitter/account team contacted if clarifications are obvious
+
+**Exit Criteria** (must be true before advancing to Intake Review):
+- Submission reviewed for completeness and duplicates
+- Submitter/contact validated (someone reachable and accountable)
+- Ready for Intake Review discussion
+
+**Responsible**: FDE Intake team
+
+---
+
+### Stage 2 — **Intake Review**
+
+**Definition**: Cross-org intake review to determine readiness for triage and which team will lead next steps.
+
+**Primary Objective**: Get to initial routing decision: who leads evaluation next (Recon/Triage vs direct receiving team), and what clarifications are required.
+
+**Minimum Checklist**:
+- Intake review held (cross-functional cadence) and submission discussed
+- Missing minimum info collected from submitter (scenario summary, key contacts, urgency)
+- Determine if request is D2ISE (pre-vetted) or requires Recon/Triage evaluation
+- Identify likely receiving team(s): primary + any collaboration partners
+- Ensure record has clear next owner and next meeting/cadence
+
+**Exit Criteria** (must be true before advancing):
+- Primary team identified (or identified as "Recon/Triage lead" if not D2ISE)
+- Collaboration teams identified where applicable
+- Named point of contact for each assigned team
+- Notes updated with intake decision and clarifications required
+- Status advanced to **Triage** (non-D2ISE) OR **Technical Assessment** (D2ISE pre-vetted)
+
+**Responsible**: FDE Intake team (with V-team consulted)
+
+---
+
+### Stage 3 — **Triage**
+
+**Definition**: Internal evaluation to determine viability, scope, and appropriate engagement model; results in clear recommendation and ownership.
+
+**Primary Objective**: Decide Keep / Share / Give, confirm receiving owner, and produce usable handoff packet for Technical Assessment.
+
+**Minimum Checklist**:
+- Account team completes triage questionnaire prior to Triage call
+- Initial triage conversation(s) held with account team and light customer touchpoints if needed
+- Commercial context clarified (MACC windows, competitive pressure, executive sponsorship)
+- Scenario made concrete (workflow, personas, day-1 experience)
+- Engineering ability and technical readiness validated (customer resources, partner landscape, ops ownership)
+- Estimated start date captured as forecast
+- Funding fork decision made: billable (customer-funded/ECIF) vs non-billable vs redirect
+- For billable: initial determination of Standard vs Advanced
+- Findings documented using Triage Assessment Output template
+
+**Exit Criteria** (must be true before advancing to Technical Assessment):
+- Named owner for next stage (receiving team lead/TPM)
+- Customer and Microsoft stakeholders identified (AE/ATS/CSA/IA + customer sponsor/PO/tech lead if known)
+- Funding model decision recorded (billable vs non-billable vs redirect)
+- Recommendation recorded (proceed, redirect, or withdraw) with rationale
+- Triage Output / hypothesis artifact completed and linked
+- Status advanced to **Technical Assessment** OR **Withdrawn** with reason documented
+
+**Responsible**: Recon / Triage lead
+
+---
+
+### Stage 4 — **Technical Assessment**
+
+**Definition**: Customer-facing discovery to define what will be built and validate feasibility; establishes success criteria, scope, and engagement plan.
+
+**Primary Objective**: Get to "studio-ready" scope with clear outcomes, constraints, and agreed path to start.
+
+**Minimum Checklist**:
+- Receiving team confirmed; working cadence set with account team + customer stakeholders
+- Discovery/workshops ("boots on ground") conducted: problem statement, workflow, data/integration, constraints, success metrics
+- Hypotheses to test and evaluation methods aligned
+- Engagement shape defined: Standard vs Advanced, timebox, crew profile, milestones
+- Commercial/Deal team engaged early if billable; MSX/opportunity mechanics confirmed
+- Primary output artifact drafted:
+  - **Billable**: Draft SOW + pricing/approvals path
+  - **Non-billable**: Game Plan Lite with objectives, deliverables, timeline, roles
+- Required legal artifacts identified (NDA/CWAA/ESWO/etc.) and owner/ETA captured
+
+**Exit Criteria** (must be true before advancing to Deal Closure & Legal):
+- Customer workshop(s) completed and scope validated with customer + account team
+- Success criteria agreed (KPIs or measurable outcomes; definition of done)
+- Draft SOW (billable) or Game Plan Lite (non-billable) produced and linked
+- Funding path confirmed (customer/ECIF or approved non-billable prioritization)
+- Status advanced to **Deal Closure & Legal Approvals**
+
+**Responsible**: Receiving (Primary) team (with Recon support as needed)
+
+---
+
+### Stage 5 — **Deal Closure & Legal Approvals**
+
+**Definition**: Complete deal closure and legal review; execute required documentation (billable or non-billable).
+
+**Primary Objective**: Ensure legal and commercial clearance to start with no ambiguity on scope, funding, IP terms.
+
+**Minimum Checklist**:
+- Engagement scope artifacts finalized (SOW / Game Plan) and matched to intake record
+- Required contracting completed (NDA/CWAA/ESWO or other required agreements)
+- Funding approval confirmed (customer PO, ECIF approval, or non-billable approval)
+- Delivery start prerequisites confirmed: customer access path, environments, key customer roles
+- Constraints and known risks documented
+
+**Exit Criteria** (must be true before advancing to Assigned):
+- All required legal documents executed (or documented exception with explicit approvals)
+- Commercial prerequisites satisfied (funding confirmed; deal desk approvals complete)
+- Engagement start date is realistic and agreed (internal + customer)
+- Status advanced to **Assigned**
+
+**Responsible**: Deal team + Receiving team TPM/PM (shared accountability)
+
+---
+
+### Stage 6 — **Assigned**
+
+**Definition**: Engagement is approved; Primary Team is confirmed; delivery readiness is completed and start date is established.
+
+**Primary Objective**: Move from "paper-ready" to "start-ready": crew staffed, operating rhythm set, customer unblocked.
+
+**Minimum Checklist**:
+- Crew roles and named individuals confirmed (dev lead, TPM/PM, data/AI roles, security/RAI support)
+- Kickoff date/time, cadence, governance confirmed (steering, checkpoints, escalation)
+- Access prerequisites confirmed in motion (tenants, repos, data access, network constraints, customer accounts)
+- Delivery tracking created/confirmed (ADO/project tracking) and linked to intake record
+- First sprint / milestone aligned; day 1 deliverable defined
+
+**Exit Criteria** (must be true before advancing to In Progress):
+- Named Primary Team and delivery lead/TPM confirmed
+- Start date established and agreed with customer + account team
+- Tracking artifacts created (project tracking + initial backlog) with links captured
+- Status advanced to **In Progress**
+
+**Responsible**: Receiving team
+
+---
+
+### Stage 7 — **In Progress**
+
+**Definition**: Engagement is actively delivered by assigned team; hands-on engineering is underway.
+
+**Primary Objective**: Deliver agreed milestones while maintaining engineering fundamentals and producing reusable artifacts.
+
+**Minimum Checklist**:
+- Kickoff run; working agreements established (repos, branching, PR process, comms channels)
+- Backlog maintained (user stories, acceptance criteria, definition of done/ready)
+- Risks, decisions, dependencies tracked; escalation early when gates threatened
+- Stakeholder communication maintained (weekly/biweekly updates; steering cadence)
+- Engineering fundamentals addressed (security, observability, RAI) and documented
+
+**Exit Criteria** (must be true before advancing to Completed):
+- All committed deliverables complete and accepted (per SOW/Game Plan)
+- Customer handoff completed (docs, runbooks, follow-on backlog, ownership assigned)
+- Closure notes and links captured in intake record
+- Status advanced to **Completed**
+
+**Responsible**: Receiving team (crew lead + TPM/PM)
+
+---
+
+### Stage 8 — **Completed**
+
+**Definition**: Engagement is finished; all deliverables are met.
+
+**Primary Objective**: Close cleanly with clear handoff, measurable outcomes captured, and learnings reusable.
+
+**Minimum Checklist**:
+- Deliverables acceptance and customer sign-off confirmed
+- Final documentation delivered (architecture notes, runbook, deployment, known issues/limitations)
+- Measurable outcomes captured vs success criteria
+- Follow-on recommendations and ownership documented
+- Intake record and delivery tracking updated
+
+**Exit Criteria** (must be true to close):
+- All closure artifacts linked and owner identified for remaining backlog
+- Final status set to **Completed**; record is "reporting ready"
+
+**Responsible**: Receiving team
+
+---
+
+### Stage 9 — **Withdrawn**
+
+**Definition**: Submission is withdrawn from the process either upon request or because it fails to meet required criteria.
+
+**Primary Objective**: Close quickly, clearly, and respectfully.
+
+**Minimum Checklist**:
+- Closure reason selected (e.g., not FDE fit, insufficient customer readiness, no funding, duplicate, redirected, deprioritized, unable to contact)
+- Decision and "next best path" documented (warm handoff if redirected)
+- Submitter/account team and involved catchers notified
+- Record hygiene completed: notes, links, disposition
+
+**Exit Criteria** (must be true to close):
+- Closure reason and disposition documented
+- Handoff completed and receiving owner captured if redirected
+- Status set to **Withdrawn**
+
+**Responsible**: Owner of current stage (Recon/Triage lead or Receiving team)
+
+---
+
+### Quick Reference: What Must Advance a Stage (Consolidated Gates)
+
+| Stage | Minimum Must-Haves | Next Stage |
+|---|---|---|
+| **New** | Intake record exists; reviewed for completeness; contact validated | **Intake Review** |
+| **Intake Review** | Primary team identified; routing decision documented; contacts named | **Triage** or **Technical Assessment** (if D2ISE) |
+| **Triage** | Triage Output completed; Keep/Share/Give decided; funding model recorded; receiving owner named | **Technical Assessment** |
+| **Technical Assessment** | Draft SOW (billable) or Game Plan Lite (non-billable); discovery complete; success criteria + scope validated | **Deal Closure & Legal** |
+| **Deal Closure & Legal** | All legal documents executed; commercial cleared; funding confirmed; start date agreed | **Assigned** |
+| **Assigned** | Crew named and staffed; kickoff scheduled; access plan complete; delivery tracking linked | **In Progress** |
+| **In Progress** | All deliverables complete and accepted; customer handoff done; closure notes captured | **Completed** |
+| **Completed** | Closure artifacts linked; final status set; record reporting-ready | *Closed* |
+| **Withdrawn** | Closure reason + disposition documented; handoff completed if redirected | *Closed* |

package/plugin/reference-packs/fde/intake-questions.md

@@ -0,0 +1,168 @@
+# FDE Intake — Questions and Role Rules
+
+> Canonical question set + role rules for the FDE Intake document (`00-FDE-Intake-<project>.md`). Consumed by `fde-intake` skill.
+
+Cite as: `[source: reference-packs/fde/intake-questions.md · packaged]`.
+
+---
+
+## Why FDE Intake exists
+
+The FDE Intake is the **first artifact** in any FDE engagement. It is consumed by the FDE Triage process to decide which team is best suited for the project and whether it is billable or non-billable. It provides a centralized strategic brief that answers the fundamental FDE Intake questions.
+
+The FDE Intake creates a single front-door queue across all Microsoft FDE teams — enabling coordinated cross-organization resource allocation, transparent tracking, and ensuring no requests fall between organization cracks.
+
+## Principles
+
+- **Outcome-driven, not deliverable-driven.** Frame the engagement around the business outcomes the customer wants to achieve — not the technical artifacts the FDE crew will build. Answer "what business result will change?" before "what will we build?"
+- **Quantify, don't assert.** Financial value, business impact, and success criteria MUST use concrete numbers. If a number is not yet known, the document MUST state what is unknown, who owns getting the answer, and by when.
+- **Frame cost against business value, not hourly rates.** Provide enough financial context that the cost of an FDE crew can be compared against the potential business gains for the customer — enabling an ROI conversation rather than an hourly-rate comparison against existing partners.
+- **Plain English, no jargon.** Both technical and non-technical stakeholders consume this.
+- **Each section stands alone.** A reader should be able to skim any one section and get value.
+- **One to two paragraphs per section.** Thorough but not verbose.
+
+## Output
+
+`<engagement-root>/<project>/Reports/00-FDE-Intake-<project>.md`
+
+The intake is the FIRST artifact in the engagement's `Reports/` folder — it does **not** use the date-prefixed naming convention used by `fde-report` shapes. It is meant to be updated in place as the engagement evolves.
+
+## Document header
+
+```markdown
+# FDE Intake — <<Customer Name>> · <<Brief Engagement Title>> (<<Division / Team>>)
+
+**MSX Opportunity:** `<<MSX Opportunity ID>>`
+```
+
+If MSX Opportunity ID is unknown, prompt the user. If there is no MSX Opportunity, write a `Rule 4.2` validation warning into the document.
+
+---
+
+## The 6 Question Cards
+
+Each question is rendered in its own block. The answer MUST be max one to two paragraphs, grounded in specific context with names, dates, technologies, and scenarios. Generic statements that could apply to any customer are a defect.
+
+When an answer cannot be derived from Evidence and the user has nothing to add, embed a `Rule 9.1` validation warning so the user can fix it later.
+
+### Q1 — Provide context of who you are currently engaged with or have engaged with
+
+Lists the Microsoft stakeholders involved so far. For each: name, title, nature of involvement (e.g. "John Doe, Account Executive — primary point of contact for the customer").
+
+**Required roles** — at least one MUST be present:
+
+- **Account Team (ATU)** — Account Executive, Account Technical Strategist, or other ATU member.
+  - If no ATU member is referenced → `Rule 4.1` warning: "ATU representation missing — required for FDE intake."
+- **Industry Team** — commonly represented by an Industry Advisor, Regional Leader, or other member reporting to Shelly Bransten.
+  - If no Industry Team member is referenced → `Rule 4.1` warning: "Industry Team representation missing — required for FDE intake."
+
+**Optional roles** — list if present; explicitly note absence:
+
+- **Industry Solutions Engineering (ISE)** — reports under John Shewchuk.
+  - Absent → state "No ISE involvement to date".
+- **Industry Solutions Delivery (ISD)** — partner delivery org.
+  - Absent → state "No ISD involvement to date".
+- **Executive Sponsor** — someone outside ISE at the CVP level, **explicitly** identified as exec sponsor.
+  - A CVP attending a meeting is NOT automatically an exec sponsor.
+  - Absent → state "No executive sponsor identified".
+- **Product Group (PG)** — reports under Scott Guthrie.
+  - Absent → state "No PG involvement to date".
+
+### Q2 — What is the business scenario or technical blocker that FDE would solve?
+
+**Lead with business impact, not technical problem.** Describe what the customer stands to gain or lose in quantifiable terms before describing the technical scenario.
+
+Must address:
+
+- Is FDE the right offer here, or is the team still scoping?
+- Is FDE needed for a partial contribution or the whole project?
+- Time frame — any deadlines coming?
+- What is the FDE team expected to do in the next 30 days?
+- Is this scenario a pattern seen across multiple industries / customers (reusability lens)?
+- Is there a billable option opportunity?
+- **Quantified business impact**: "The customer estimates $X per quarter in lost revenue / excess cost / missed opportunity due to [problem]." If not quantified → `Rule 4.3` warning + state who will quantify, by when.
+- **Outcome chain**: brief mapping that traces the path from technical work to business result. (2–3 bullets — technical interventions → KPIs → business outcome.)
+
+### Q3 — Why are current offers / solutions not suitable for this customer's needs?
+
+Explain why existing Microsoft solutions or third-party offerings are not sufficient. Highlight gaps in functionality, performance, integration, or other factors that make current options inadequate.
+
+Must address:
+
+- If Copilot Studio (or similar low-code) was considered — why isn't it sufficient (vs a pro-code solution)?
+- If the customer has an existing SI partner — what gap does FDE fill?
+- If there is no public Microsoft product yet — is this a "PG accelerator" opportunity vs an FDE crew?
+
+### Q4 — What does success look like for the customer?
+
+**Focus on measurable business outcomes, not technical outputs.** "Deploy a model" / "build an MVE" is a deliverable, not a success criterion. Success is defined by the business result that changes.
+
+Required substructure:
+
+1. **Outcome Hypothesis** — a testable statement of what business result will change, by how much, for whom, within what timeframe, and against what baseline. Format:
+   > *"If we [intervention], then [KPI] will improve by [target] within [timeframe], as measured by [method] against [baseline]."*
+   If the hypothesis is not yet fully formed → state what is known + what must be resolved before mobilization.
+
+2. **Quantified success criteria** — at least 2 KPIs with concrete numeric targets. Placeholders ("X%", "significant improvement", "measurable uplift") are a defect. If targets pending → state the KPI, that target is pending, and when it will be confirmed.
+
+3. **Baseline** — how the customer currently measures the KPIs. If no baseline exists → state that establishing a baseline is a prerequisite (typically in the engagement's first iteration). **Do not reference "uplift vs. baseline" without documenting what the baseline actually is.**
+
+4. **ROI framing** — enough financial context to compare FDE engagement cost against expected business value. Format: *"A 6-month FDE engagement at $X enables $Y/quarter in [outcome] — payback within [timeframe]."*
+
+5. **Value realization plan** — how will we verify that expected outcomes actually materialized after the engagement? Who checks, at what intervals (30/60/90 days), what is measured?
+
+Must also address:
+
+- Customer's production deployment plan / path.
+- Commercial path after the initial prototype is built.
+- **Catcher team** — who owns the outcome after the FDE engagement ends?
+
+### Q5 — Please list the relevant technology (1st party / 3rd party) workloads being used
+
+List specific technologies, platforms, tools. Include Azure services, M365 workloads, third-party software, on-premises systems.
+
+Must address:
+
+- Already building in Azure?
+- Azure landing zone set up for the data?
+- Azure data lake / Fabric in use?
+- Microsoft Foundry / agentic platform in use?
+- Agent 365 / agentic governance layer in use?
+
+### Q6 — Give a description of the work completed so far (if any)
+
+Summarize discovery work, proofs-of-concept, architecture design, or other relevant activities done to date. Include a statement about how ready the customer is to engage with FDE and whether they want co-build or want the project delivered without co-build.
+
+Must address (use specific dollar figures; "significant" / "substantial" is a defect):
+
+- **Current yearly ACR** at this customer — specific dollar figure.
+- **ACR growth trajectory** in the account.
+- **Expected ACR** if this program is successful — specific dollar figure or range.
+- **MACC** — in place? size? pending? — dollar amount(s).
+- **Customer's own ROI** from this engagement — distinct from Microsoft ACR; essential for framing cost against business gains.
+- **Customer readiness** — devs ready to collaborate? what have they tried already? maturity assessment done?
+
+If any required commercial fact is missing → `Rule 4.2` validation warning.
+
+---
+
+## Validation summary
+
+| Rule | Triggered when |
+|---|---|
+| `Rule 4.1` | Required role (ATU or Industry) missing from Q1. |
+| `Rule 4.2` | Required commercial fact (MSX Opportunity, MACC, ECIF, ACR) missing or non-numeric. |
+| `Rule 4.3` | Business impact / outcome metric / baseline missing from Q2 or Q4. |
+| `Rule 6.1` | Customer engagement legal posture (CWAA/EMA/contract) absent. |
+| `Rule 8.1` | Any answer paragraph lacks an inline `[source: …]` citation. |
+| `Rule 9.1` | Free-text gap — neither Evidence nor user could fill the answer. |
+
+All validation warnings follow `report-doctrine.md § Rule 4`.
+
+---
+
+## See also
+
+- `core-fde-reference.md` — FDE operating model, anti-patterns, fitness criteria, stage gates.
+- `report-doctrine.md` — validation warnings protocol, source resolution gate, recency precedence.
+- `README.md` — pack overview.