Standard operating procedures for the Sparq AI-Native Software Development Life Cycle. Adapted from the Anthropic AI-Native SDLC pattern, this methodology integrates the Evidence Gate as a non-negotiable gate inside the pipeline rather than treating it as an external meta-process.
The base pipeline optimizes for speed and build correctness. However, it requires a mechanism to validate whether we are building the right thing before scaling execution. Therefore, the Evidence Gate explicitly gates the transition from Intent Framing to Design — closing with the tracker sync and merge that was previously modeled as its own Plan stage, now folded into the Gate as its automatic closing action rather than a separate decision point. The commit chain (Git-tracked artifacts at every stage) remains both the operational workflow and the audit trail.
Pipeline is 7 stages, not 8. Stages 0 and 1 together are sold commercially as one unit — the Evidence Sprint — matching how discovery has traditionally been packaged, just with real signal behind it.
| Stage | Core artifact | Gate |
|---|---|---|
| 0 · Intent Framing | raw intent.md | — |
| 1 · Evidence Gate | intent.md (cleared, synced) | Promote / Iterate / Pivot / Stop + PO merge |
| 2 · Design | spec.md | Skills validation |
| 3 · Build | plan.md + code diffs | CLAUDE.md + hooks |
| 4 · Test | verification logs + eval results | Eval pass thresholds |
| 5 · Deploy | REVIEW.md + PR findings | Environment autonomy tiers |
| 6 · Maintain | bands.yaml + incident records | Metric-band triggers |
Stages are artifact order. They describe the sequence of what you produce and which governance gate you pass through. Risk shapes are the real-time operating picture — they describe which capabilities run hot right now, regardless of which stage the work is in.
A risk shape fires wherever it fires. The Feasibility shape can spike during Intent Framing if an architecture constraint surfaces early. The Value shape can stay active deep into Build if a prior assumption gets challenged. Shapes co-occur, recur, and persist — they are not bound to a single stage.
The stage tells you what artifact you owe. The live risk mix tells you what to worry about while you produce it. You are always in a stage, and you are always responding to risk shapes.
Stages have a default gravity — 0 through 6 — but change events and failed gates send you back. The change-response doctrine runs at any stage: re-read the risk, re-set the dials, decision gate, re-staff, re-price and re-time, name the next slice.
Generate the raw material and problem framing required for the pipeline without prematurely settling on narrative agreement. This session acts as structured elicitation to expose unvalidated assumptions.
First half of the Evidence Sprint.
The output must be a stack of tagged, unvalidated assumptions, not settled prose. Confidence is not agreement in a workshop.
As a consultancy, we often do not have standing authority over intent.md. Use this session to bridge the vocabulary gap and secure client agreement on the problem statement before proceeding.
Ask: "What must be true for this initiative to succeed?" Individually list, group, and rephrase as testable statements.
Ask: "It's 12 months from now. This failed. Why?" List causes and translate them into risks.
Force the identification of at least one risk per category: Value, Usability, Feasibility, Viability, and Operational. This prevents tunnel vision.
Ask: "What technical constraint could invalidate this?" Identify platform limitations, integration dependencies, performance ceilings, and security requirements.
Output: A raw intent.md (problem statement, proposed outcomes, affected systems, constraints) where every claim is explicitly tagged as an assumption. This file does not trigger CI compilation — it must proceed to the Evidence Gate.
Decide whether the raw intent.md is trustworthy enough to compile into spec.md. This is a human-driven evaluation gate to validate risk categories that cannot be caught by CI rubrics. On a Promote, the gate closes automatically: tracker sync, merge, and spec compilation fire without a separate decision.
Second half of the Evidence Sprint. This stage now includes the tracker sync and merge that was previously modeled as a separate Plan stage — it is the mechanical result of a Promote, not an independent decision point.
Run the cycle of Risk → Assumption → Slice → Signal → Confidence → Decision on tagged assumptions. Address one assumption per slice. The validation loop is prototyping — build the smallest thing that tests one assumption, read the signal, decide.
For Value/Usability risks, attach the test to a real occasion (next client conversation, stakeholder review, prospect encounter) rather than manufacturing synthetic scenarios. A slice needs something behaving in the world to react to.
Only use internal convergence checks when a real external occasion genuinely does not exist. Record the reason explicitly. Internal-only signals cap at Directional confidence, never Validated.
Make a clear decision for the intent: Promote, Iterate, Pivot, or Stop. No numeric confidence scores.
Once Promote is decided, immediately execute the dual-linkage: Markdown remains the operational source of truth in the repository, synced to legacy enterprise trackers (Jira/Azure DevOps) via MCP connectors for client governance. This merge triggers a non-interactive CI job that compiles spec.md, loading Sparq compliance skills (security, UX, brand guidelines). The Product Owner performs the final review.
Output: The intent.md either clears — merged, synced, and moving to Stage 2 — or gets sent back to Stage 0 for re-framing, or the initiative is stopped/pivoted.
Synthesize requirements and architecture into a formal specification.
Execute a compressed, single-session requirements and architecture synthesis.
Guide the synthesis utilizing organization-wide skills for security, compliance, and UX standards.
Building is the primary domain — product-interface-building and core-systems-engineering drive the synthesis. Framing constraint-checks run as secondary, ensuring the architecture stays within the boundaries set at the Evidence Gate.
Output: spec.md.
Draft implementation plans and execute code generation within isolated agent environments.
Maintain a robust context engine detailing build commands, linting rules, architectural patterns, and team-specific mistakes to avoid.
AI agents must draft plan.md before writing code. Human acceptance commits the plan to Git.
Isolate agent sessions across separate Git worktrees. Enforce a parallel session cap of 2–3 concurrent worktree sessions per engineer to preserve review quality and prevent fatigue.
Allow autonomous edit execution only where existing test coverage and build hooks are fully mature.
Utilize .claude/agents/ to store standardized helper agents across repositories — verifier agents (run the app, check behavior) and simplifier agents (strip redundant complexity post-implementation).
Output: plan.md and verified code diffs.
Continually verify code behavior and assess Feasibility and Operational risks through automated CI suites.
Agents must run builds, tests, and visual diffs, proving success in context before reporting a task complete.
Maintain 20–50 real-world task evaluations in .github/workflows/agent-evals.yml. These run non-interactively upon updates to code, skills, or hooks to establish baseline agent performance benchmarks.
CI evaluations assess Feasibility and Operational risks only. Value and Usability risks are resolved upstream at the Evidence Gate (Stage 1).
Implement pre-tool hooks that block agents from modifying existing test files during bug-fix tasks. The agent must fix the code to pass the tests — it is explicitly denied the ability to alter assertions to force a passing status.
Output: Verification logs and evaluation results.
Conduct multi-pass reviews and securely deploy artifacts across environments using defined autonomy tiers.
Automate first-pass scans for logical bugs, security gaps, and compliance against spec.md and plan.md (REVIEW.md).
Enforce deterministic pre-execution scripts for security controls, blocking unauthorized path edits.
Dev/Sandbox: full agent execution allowed. Staging: automated PR review with passing CI required. Production: explicit human release-manager authorization required.
Deploy immutable settings centrally (e.g., allowManagedHooksOnly, permissions.deny) to block shell network egress, prevent credential leakage, and disable plugin sideloading.
Output: REVIEW.md, PR findings, and deployed code.
Monitor system health continuously and trigger automated triage and incident resolution loops.
Apply deterministic monitoring using statistical control rules against operational metrics (e.g., test failure rate, post-deploy 5xx rates) via bands.yaml.
If a metric breach occurs (e.g., 3σ deviation), a background agent automatically diagnoses the root cause and writes a new intent.md into the triage queue.
Triage live production alerts via Claude Tag in Slack/Teams, execute diagnostic runbooks via MCP, and log root-cause analyses directly to the thread record.
For every resolved production incident, automatically compile a regression evaluation case into the CI suite (Stage 4) to guarantee prevention of recurrence.
Output: bands.yaml updates and incident/eval loop records.
Each stage has a primary domain driving the work and risk shapes that are typically hottest at that point. Framing tapers over time but does not hard-stop at the Evidence Gate. Proof runs at the Gate, Test, and Maintain stages, handling distinct but related evaluation tasks.
| Stage | Primary domain | Secondary | Risk shapes typically hot |
|---|---|---|---|
| 0 · Intent Framing | Framing | — | Problem clarity, Commercial / viability |
| 1 · Evidence Gate | Proof | Framing | Value, Problem clarity |
| 2 · Design | Building | Framing | Feasibility |
| 3 · Build | Building | Proof | Feasibility, AI reliability |
| 4 · Test | Proof | Building | Proof / acceptance, Feasibility, AI reliability |
| 5 · Deploy | Building | Continuity | Proof / acceptance, Adoption |
| 6 · Maintain | Continuity | Enablement | Continuity / operational, Adoption |
Risk shapes are listed where they are typically hottest, not where they only fire. Any shape can spike at any stage.
Commercial Commercial frames the pipeline — it sets the envelope and price before Stage 0, and the proof → commercial seam updates it as evidence arrives. It is not absent from the pipeline; it operates across stages rather than owning one.
Enablement Enablement activates when the Adoption risk shape fires, typically hottest at Deploy and Maintain but possible at any stage where organizational change is needed to land the work.
| Stage | AI-Native approach | Artifact | Governance |
|---|---|---|---|
| 0 · Intent Framing | Structured elicitation producing tagged, unvalidated assumptions. | raw intent.md | Facilitator ensures output stays assumption-tagged. |
| 1 · Evidence Gate | Risk validation loop for Value/Usability/Viability, closing automatically into tracker sync and spec compilation on Promote. | intent.md (cleared, synced) | Product + Delivery sign-off; Promote/Iterate/Pivot/Stop, then PO merge. |
| 2 · Design | Compressed single-session requirements and design synthesis. | spec.md | Skills validation (Security, UX, Brand). |
| 3 · Build | Plan-mode drafting, worktree-isolated implementation. | plan.md + code diffs | CLAUDE.md + path-blocking hooks. |
| 4 · Test | Continuous self-verification and CI-driven eval suites. | verification logs + eval results | Test-locking hooks and eval pass thresholds. |
| 5 · Deploy | Multi-pass agentic PR review with human risk evaluation. | REVIEW.md + PR findings | Branch protection and production deploy hooks. |
| 6 · Maintain | Metric-band monitoring auto-generating new intent items. | bands.yaml + incident records | Tiered automated response and on-call approval. |
Maintenance metrics primarily monitor infrastructure health (error rates). A sensor is needed to monitor Value/Usability drift post-launch (adoption rates, usage depth) so the pipeline does not lose signal on a shipped feature nobody wants. This remains an unresolved gap — the tactical playbook includes a candidate widened bands.yaml design as a proposal, not yet ratified.
The Stage 0 session itself is deliberately left undressed. Naming it before the shape is settled through repeated real use is an anti-pattern. We will call it what it is until it earns a name through institutional habit. This is separate from Evidence Sprint, which names the combined Stage 0 + Stage 1 commercial unit, not the Stage 0 session on its own.
How much of the Intent Framing Session includes the client versus internal Sparq preparation is inherently variable by design, not a gap to standardize away. Some engagements run heavy client involvement, others very little; headcount in the room has ranged from as few as 2 to as many as 20. This is engagement-specific and should stay that way.