The Master Sprint Guide.

This guide is the operational backbone of a Lighthouse Sprint. The Lighthouse Operating Framework (USO-LH-01) defines what a sprint is — the principles, the four stages, the six roles, the governance wrapper, the pattern library. This Master Sprint Guide defines how to run one.

Every procedure, meeting cadence, gate review, role handoff, pattern extraction ritual, and commercial artifact is specified here. Where day-by-day detail is required, this document hands off to the four phase playbooks (Discovery, Redesign, Build, Handoff). Where cross-phase governance mechanics are required, it hands off to the Governance Operations manual. Where a filled artifact is required, it hands off to the P0/P1 template set in this directory.

The reading path for a new Sprint Lead is: framework first, this guide second, the discovery playbook third. Then apply. The operational knowledge is load-bearing — you cannot skim it and be effective in week one.

A Lighthouse Sprint is a fixed-scope, time-boxed engagement running 6–10 weeks for a Standard Sprint. The framework describes four stages. In practice, the lifecycle has seven phases — three outside the framework boundary (qualification, mobilization, 30-day window) and four inside it (Discovery, Redesign, Build, Handoff). A Sprint Lead needs the full picture.

Every phase boundary is a formal gate with a defined audience, named deliverables, a go/no-go outcome, and an explicit off-ramp if the sprint needs to end early. Gates are not status meetings — they are decision events. A sprint cannot progress to the next phase until its entering gate is signed.

The work that determines whether a sprint succeeds happens before the sprint starts. A bad fit dressed up as a good lead is the most expensive mistake Studio can make: it consumes weeks, signals inconsistent outcomes, and pollutes the pattern library with examples that shouldn’t have been attempted.

Every prospective engagement is scored against the Fit Assessment Rubric (lighthouse-fit-assessment-rubric.xlsx) before the SOW is issued. The rubric has 12 criteria scored 1–5 across four dimensions: workflow fit, data fit, organizational fit, and commercial fit. A rubric score below 36/60 triggers a qualification call with the Executive Sponsor to surface the concern explicitly before contracting.

These are not tie-breakers — they are hard stops. Any one of them means Studio should decline or push the scope back to Discovery Only and let the client use that 2-week window to resolve the blocker.

Every Lighthouse Sprint has six defined roles. Role clarity eliminates ambiguity about who owns decisions, who does the work, and who signs off at each gate. In early engagements, one person may hold multiple Studio roles — the roles still exist as distinct accountability structures.

A sprint produces a lot of information. Without protocol discipline, that information leaks into Slack DMs, one-off emails, and side conversations that the Sprint Lead cannot reconstruct three weeks later. Communication protocols are how Studio maintains a single source of truth.

Gate reviews are tightly structured. The Sprint Lead follows this agenda without deviation — it prevents the meeting becoming a status update and forces a decision.

Gates are the single most important operational discipline in a Lighthouse Sprint. Each gate has named deliverables, a defined audience, explicit go/no-go criteria, and an off-ramp. If a gate is compromised — waved through, deferred, passed without deliverables — the sprint will fail at a later stage with 3× the unwind cost.

Studio runs engagements on a small, opinionated toolset. The goal is never the tooling itself — it’s a minimally-viable operational environment that reduces administrative load and keeps state visible. Any tooling decision that adds complexity without reducing engagement risk is rejected.

Every engagement runs from a single Google Sheet called the Sprint Dashboard. It is the Sprint Lead’s daily cockpit. It lives in the shared client folder and is visible to all six roles.

Every engagement has one folder structure. It exists before Day 1. It does not evolve mid-sprint — any restructuring happens at Gate boundaries only.

The Risk Register (lighthouse-risk-register.xlsx) is maintained from Day 1 of Discovery through 30 days post-Handoff. The template ships pre-populated with 10 common sprint risks. The Sprint Lead adds engagement-specific risks, assigns probability (1–5) and impact (1–5), computes severity (P × I), and names an owner. The register is reviewed in the weekly client sync and at every gate.

Studio engagements are fixed-fee. The client knows the total cost at SOW signing. Payment milestones are tied to gates, which makes the commercial arc align naturally with the delivery arc — Studio is paid for crossing gates, not for burning time.

A change order is any request that modifies scope, schedule, or deliverables after SOW. Every change order goes through a standard flow regardless of size:

The Pattern Library (USP-001 through USP-018 as of v1.0) is Studio’s compounding asset. Every engagement must contribute. A sprint that ships outcomes but adds no patterns is only half-complete — the next client deserves to benefit from this one.

The Indietheka sprint produced 14 of the 18 live patterns (USP-001 through USP-014). Eleven of those were not in the initial Redesign Blueprint — they emerged during Build and were codified as the system matured in production. Every one is traceable to a specific dated incident or design decision. This is the operational standard: the pattern library grows from real production, not from slide deck speculation.

Indietheka, a Spanish-language indie music publication, was the first Lighthouse Sprint. The editorial pipeline was human-bottlenecked end-to-end, but only 15% of the work required genuine editorial judgment. What follows is how the framework was applied in practice.

The qualification call surfaced three facts that made the engagement a strong fit: (1) the workflow ran every working day and was clearly repeatable, (2) the Executive Sponsor and Workflow Owner were the same person (common in founder-led media), (3) all inputs and outputs were accessible via standard APIs (WordPress, Spotify, Meta Graph). The Fit Assessment Rubric scored 52/60.

Mobilization took four days. Credentials for WordPress, Yoast SEO, Google Sheets, the Spotify API, and Meta Graph API were provisioned. A single Google Sheet became the Sprint Dashboard. The stakeholder interview slate was one person — the founder — scheduled across five one-hour slots.

The Workflow Audit captured 12 discrete steps in the editorial pipeline. Stopwatch exercise ran for 5 working days across one representative week. Key findings: 85% of editorial time was mechanizable. Only album listening (step 4) and voice/angle decisions (step 5) required genuine editorial judgment. End-to-end cycle time was 210 minutes per article; throughput was 2–3 articles per week; error rate 8%.

Gate 1 outcome: Go. The Discovery Report named 10 bottleneck-to-agent candidates and 2 partial-automation candidates. The baseline was documented in lighthouse-baseline-metrics.xlsx against 8 KPIs. The Sprint Lead recommended a Standard Sprint with an extended 5-week Build phase.

The allocation framework workshop produced a Redesign Blueprint targeting six agents/automations in the initial scope. Five were classified fully autonomous; three had a human-approved gate via a spreadsheet column. The Governance Design specified a Google Sheet as state machine with an API endpoint backing all writes — the first appearance of what became USP-009.

Gate 2 outcome: Approved with Changes. One change: add a cover-art verification step to the Album Reviews agent before the sprint began, after the Workflow Owner flagged historical trouble with AI-fetched cover images. That change order was signed, logged, and added to the Agent Spec Sheet for AGT-03 before Build Week 1.

Three weeks of Build rather than five. The shortened Build was possible because all integrations were well-known APIs (WordPress, Spotify, Meta) and the client was a solo operator with no complex approval chain. Agents deployed in this sequence: RSS Poller (Week 5), WP Publisher + Distribution Agent (Week 6), Album Reviews + Spotify Playlist Sync + Weekly Recap Carousel (Week 7).

Four agents were not in the Blueprint. They emerged in the following weeks as gaps became visible: AGT-07 Release Radar (the discovery half of the review pipeline), AGT-08 Content Proposals (data-driven editorial ideas), AGT-09 Technical SEO (page-level audit), and AGT-10 Weekly Calendar Update (the closed learning loop). These four were added post-Gate 3 as explicit extensions and tracked as a second mini-sprint under the same engagement.

Gate 3 outcome: Ready. All six original agents passed acceptance criteria. The Governance Wrapper was operational. One rollback rehearsal was completed on the WP Publisher: a test post was published, then reverted to draft via the kill switch, within 14 seconds.

Handoff was compressed because the Workflow Owner and Executive Sponsor were the same person — the same human who would operate the system. Two training sessions covered the governance dashboard and the Editorial Approval Queue. Supervised operation ran for five business days during which Studio triaged four production incidents (wrong cover art; carousel vs. featured image ratio; two false-positive verification blocks). Each incident left an addition to the Pre-Publish Verification Protocol — what grew into USP-005’s 9-check-group architecture.

Gate 4 outcome: Verified. Outcome Report signed: weekly throughput +7× (2–3 → 15–20 articles), human hours per article −90% (3.5 hrs → 20 min), error rate −88% (8% → <1%), platform distribution +4 platforms. Ten agents in production (six original plus four that emerged post-G3). Fourteen patterns extracted and cataloged.

The 30-day window surfaced additional patterns: the Two-Step SEO Metadata Update (USP-008, from a backlog cleanup of 85 posts), Page Builder Safety (USP-014, from a homepage layout break after a standard API call), and the Temporal Claims Verification rule (USP-011, from a Coachella Weekend 2 false claim). None required Studio intervention — the Workflow Owner resolved each incident using the Governance Runbook, and Studio logged each as a Pattern Library addition.