Capstone: Mock Loop

Everything from here runs on one account. You discover it, demo to it, write its rollout plan, pass its security review and debrief against the bar - all on the same fictional company. That is how the real loop feels: the facts you gather in hour one are the facts you defend on the on-site.

Meet Northwind Financial. It is the account you carry through this whole module. Read the brief like an SA picking up a strategic post-sale account, not a candidate reading a prompt. Your job is to take Northwind from two teams quietly using Cursor to a board-ready expansion recommendation the CTO can defend.

The CTO's mandate is deliberately vague. Go all-in on AI-native development is a strategy question wearing a tooling-purchase costume. Treat the ambiguity as the work, not as missing information.

The constraints that shape every moveRead these as gates, not footnotes

Discovery is the deliverable, not the warm-up. If you mishear Northwind's real bottleneck here, every later artifact aims at the wrong target. You are not gathering ammunition for a pitch. You are reconstructing how this org ships software in their own words.

Treat the rubric as a gap finder, not a score to admire. Mark the weakest proof, turn it into one practice rep and keep the artifact you would show an interviewer.

Three audiences, three different conversations. Developers feel the workflow friction. The platform team owns the gates. Leadership owns the outcome and the money. Ask the same generic questions across all three and you learn nothing precise.

Your discovery question bank12 questions, grouped by stakeholder

What to extract from the answers

The discovery summary you send back

Within a day, you send a short confirmation note. It proves you listened and converts spoken answers into a shared, correctable record. If you got something wrong, this is where they fix it for free.

Subject: Northwind x Cursor - what I heard, please correct

The decision: by end of Q2, a go/no-go on standardizing AI-native
development, evidenced by a scoped pilot - not a seat purchase.

The pain we'll baseline: payments PR-to-merge cycle time (currently
~3.5 days median, per the squad) and new-hire ramp-to-first-merge.

Hard gates (platform): zero-data-retention required, SSO/SAML
mandatory, SCIM deprovisioning + admin audit before any expansion.

The skeptics' bar: principals will merge AI-authored code only if it
passes existing review + tests with no drop in defect rate.

Success = cycle time down, no governance regression, two principals
shift from skeptic to neutral-or-better.

Open unknowns: confirmed champion, budget ceiling, security-review
lead time. Proposing we close these next session.

Objections you should expect - and your live response

Same product, two completely different rooms. The principals want to see real engineering survive their standards. The CTO wants to see a strategic bet pay off. A single demo that tries to serve both serves neither.

Tailoring is the whole grade here. You earned the right to demo specific things in discovery, so demo those. Northwind's payments cycle time and the principals' merge conditions are your script, not a generic feature tour.

Demo A - for the skeptical principalsProblem → live Agent/Rules workflow → outcome

1. 1Open on their pain, not a feature. “You told me PRs sit ~3.5 days and reviews are the bottleneck. Let me show you a change moving through that, with your gates on.”
2. 2Set up Rules first, visibly. Show a .cursor/rules file encoding their conventions, test requirements and the things AI keeps getting wrong. This signals control: AI works inside their standards.
3. 3Run Agent on a real-shaped task. Pick a multi-file change in a payments-like repo. Let Agent plan, edit across files and run the tests. Narrate where you'd intervene.
4. 4Reject bad output on purpose. When Agent proposes something sloppy, decline it out loud and steer. The judgment to reject AI output is the credibility move with this room.
5. 5Land the outcome. End on the diff passing their review checklist and tests green - the exact merge condition they named in discovery.

Demo B - for the CTO and VP EngROI and the strategic bet

1. 1Frame the decision, not the tool. “You asked whether to go all-in. Here's what the bet looks like and how we'd know it's working by end of Q2.”
2. 2Show outcome, not interface. One tight live moment - a real change shipped fast - then straight to the metric: cycle time, onboarding ramp, PR throughput.
3. 3Tie to the money. Translate cycle-time gains into engineer-hours and shipping velocity at Northwind's scale. Anchor on their numbers from discovery.
4. 4Address the strategic risk head-on. Name the privacy and governance posture before they ask, so the bet looks de-risked, not reckless.

Objection handling - your top three, scripted

Self-grade: tailoring, command, storytelling

• Tailoring: did each demo use Northwind's actual discovery facts or did it drift into a generic feature tour?
• Command: did you drive Agent/Tab/Rules live and fluently, including rejecting a bad suggestion on purpose?
• Storytelling: did each demo open on the audience's pain and close on their named outcome, with one clean narrative thread?
• Recovery: do you have a concrete fallback ready before anything breaks?

Talk is gone; now you write. This section produces the documents an SA actually hands a strategic account: a phased rollout plan, a security and governance summary, an instrumented ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. narrative and a feedback brief back to Cursor's Product team. These are the artifacts the on-site judges.

1. Phased rollout planPilot → team → org

1. 1Pilot (weeks 1–6). The payments squad plus two volunteers from a second team. Baseline PR-to-merge cycle time and ramp on day one. Configure privacy mode, model routing, .cursor/rules and any MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. context sources before anyone codes.
2. 2Success gate (week 6). Cycle time down with no governance regression and no defect-rate increase and the two principals shifted to neutral-or-better. Go/no-go is honest: a failed pilot is a real output.
3. 3Team expansion (weeks 7–14). Activate the rest of payments and core banking. Convert all self-serve seats to SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave.. Stand up a champion-led enablement cadence and an internal #cursor help channel.
4. 4Org rollout (Q2). New-team activation playbook, seat-growth model and an admin dashboard the platform team owns. Hand the CTO the board-ready recommendation with the pilot evidence attached.

2. Security & governance summaryThe architecture-review section

This is the document the platform team reads first. Lead with their bar, not Cursor's features. Two principals and a skeptical legal team killed a prior AI tool, so the burden of proof sits with you.

3. Adoption + outcome metrics and the ROI narrative

4. Product-feedback brief back to Cursor

The SA charter includes carrying structured field feedback into Product and Engineering. From Northwind, that brief is specific and prioritized, not a wishlist.

Account: Northwind Financial (regulated, 3,000 eng)

Top blocker (P0): platform team wants per-model routing visibility in
the admin audit log for compliance sign-off. Currently their #1 gate.

P1: SCIM group-to-RBAC mapping requested so team roles provision
automatically from their IdP groups.

P1: principals want a per-repo rules-enforcement report (which rules
fired/were violated) to trust AI output in review.

Signal: low Copilot usage despite a mandate - strong evidence that
bottoms-up adoption + measured pilots beat top-down mandates in
regulated orgs. Worth a pattern writeup for the field.

Last rep: grade yourself against the actual bar. The Northwind work you just did is the evidence. Map it to Cursor's values, score yourself per loop stage and turn your two lowest scores into a concrete prep plan. Honesty here is the entire point.

Map your scenario work to each Cursor value

Score yourself per loop stage1 = would not pass · 5 = bar-clearing

Confirm you can do the hands-on thing

• Could you configure privacy mode, SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. and model routing in a real admin console, not just describe them?
• Could you write a working .cursor/rules file and wire an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. context source from scratch?
• Could you drive Agent and Tab through a multi-file change, reject bad output and get tests green - with no AI assist on the underlying coding?
• Could you debug a thorny broken environment live while a developer watches?

Build your final prep plan

1. 1Pick your two lowest scores. Only these. A scattershot plan that touches all six stages fixes none.
2. 2Set one concrete drill per gap. If discovery scored low, run three mock discoveries out loud and record them. If hands-on scored low, build a real .cursor/rules + MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. setup on a sample repo this week.
3. 3Schedule the reps. A date on the calendar, not an intention. Two weeks, two gaps, measurable.
4. 4Re-score after. If the number didn't move, the drill was wrong, not the goal.