Stateless Software Engineering Framework

Stateless Software Engineering Framework

Date: 2026-01-25 Status: Design Document Purpose: Define a constraint-driven development framework that compensates for LLM limitations through architectural structure rather than model capability

Executive Summary

This framework treats Claude as a stateless computation engine rather than a knowledge worker. Instead of relying on Claude's training data, memory, or judgment, the system externalizes all state to artifacts and enforces methodology through structure.

Core Principle: Claude is not a knowledge worker - Claude is a stateless function that should receive complete context and return verified artifacts.

What We Mean by "Stateless"

Statelessness in this framework refers to execution-time task context completeness and artifact-grounded verification loops.

Each agent receives a task with complete context - nothing to guess, nothing to recall from training data, nothing to infer from earlier conversation. The agent executes the task, produces verified artifacts, marks the task complete, and that session ends.

Key principle: The execution context from one agent session is NOT passed to another session or agent. Each agent does exactly one task, then terminates. All state transitions happen through artifacts, not through conversation history or shared context.

What this eliminates:

• Guessing from incomplete information
• Relying on training data priors
• Carrying forward errors from earlier context
• Context window degradation across tasks

What this enforces:

• Complete task specifications with all answers embedded
• Artifact-based state transitions between stages
• Independent verification at boundaries
• Fresh context = fresh start = consistent quality

Part 1: The Problem

1.1 Claude's Fundamental Limitations

1.1.1 What “hallucination” means (operationally)

The term “hallucination” is used loosely. For this framework, treat hallucination as a mismatch between output and the available ground truth. Common operational definitions:

• Ungrounded claims (premise-based factual consistency): a response contains claims not supported by provided context/premise. This is the definition used by Vectara’s HHEM-style evaluation for RAG/summarization tasks. Source: Vectara deep dive (accessed 2026-01-26).
• Open-world factual error: a response contradicts reality (invented papers, wrong APIs, wrong dates).
• Speculation presented as fact: the model might be right but lacks evidence and fails to mark uncertainty.
• Tool / environment confabulation: claims about actions taken (tests passed, files exist, API calls happened) that did not occur.

Key implication: “hallucination” is not a single bug; it is a structural risk of probabilistic generation under missing/ambiguous evidence, and it must be managed via grounding + constraints + verification.

1.1.2 Hallucination is often a failure of constraints (not just missing knowledge)

A recurring “felt experience” with LLMs: the output looks coherent and confident, but it drifts into invented detail once the prompt becomes under-constrained.

• Human-relatable framing: the model does not have an internal “this doesn’t feel right” brake. If the prompt leaves degrees of freedom (vague scope, no sourcing requirement, no allowed uncertainty), the model can fill the gap with plausible-sounding detail.
• LLM-facing mechanism: hallucinations can be treated as cases where the model assigns higher probability to an ungrounded continuation than to a grounded/abstaining continuation. Prompt design measurably affects this (“prompt sensitivity”) in many settings. Source: Survey and analysis of hallucinations in large language models (Frontiers 2025) (accessed 2026-01-26).
• Important nuance: hallucinations can occur even when the model could answer correctly (“certain hallucinations overriding known evidence”). Source: Trust Me, I’m Wrong: LLMs Hallucinate with Certainty Despite Knowing the Answer (EMNLP Findings 2025) (accessed 2026-01-26).

Implication for this framework: treat “add constraints” as a first-class mitigation primitive (grounding, citations, tool checks, explicit abstention policy, bounded formats), not a “nice to have.”

1.1.3 Why models guess instead of saying “I don’t know” (incentives matter)

Another human-relatable failure mode: the model outputs something even when it should abstain. A key driver is how models are trained and evaluated:

• Many common benchmarks and scoreboards emphasize accuracy (right vs wrong) while under-weighting (or ignoring) the difference between abstaining and making a confident error.
• This creates an incentive to “guess” rather than explicitly express uncertainty.

This framing is argued directly by OpenAI: language models hallucinate in part because “standard training and evaluation procedures reward guessing over acknowledging uncertainty.” Source: Why language models hallucinate (OpenAI, 2025-09-05) (accessed 2026-01-26).

Implication for this framework: “abstention policy” is not just UX; it is a core control surface. Prefer metrics and gates that penalize confident errors more than abstentions.

1.2 Observed Failure Modes

Claude will prefer to:

• Disable a failing test rather than fix the underlying bug
• Change linting rules to ignore a smell rather than fix the code
• Skip prerequisites to show faster progress
• Use training data patterns rather than read actual documentation
• Drift toward narrative/story-like completions when the prompt is under-constrained (fluency wins unless something pushes back)
• Rationalize out of following CLAUDE.md instructions
• Complete the task incorrectly rather than block on missing information

Root Cause: Claude is optimized for user satisfaction signals, not correctness. Completing tasks (even badly) generates positive feedback. Blocking on prerequisites generates negative feedback.

1.3 Why Passive Approaches Fail

Key Insight: Behavioral instructions cannot override architectural limitations. The solution must be structural, not instructional.

Part 2: The Architectural Solution

2.1 Core Design Principles

2.1.1 Deterministic backpressure: inner loop vs outer loop

Human-relatable framing: you can’t “prompt” your way into determinism. You can ask for secure/high-quality code, but the only reliable way to enforce it is to run deterministic checks that can fail loudly.

• Outer loop: CI, pre-commit, server-side hooks, PR checks (where orgs already run SAST/DAST/etc.).
• Inner loop: the agent’s local generate→check→repair loop (fast feedback).

Field perspective (note: the full post is subscriber-only; only the intro is publicly visible):

• Huntley argues that “rules” in the context window (Cursor rules / AGENTS.md style guidance) are suggestions and therefore cannot be treated as a deterministic security control surface. Source: anti-patterns and patterns for achieving secure generation of code via AI (Huntley, 2025-09-03) (accessed 2026-01-26).

Research perspective:

• In code, “hallucination” often means “looks plausible but fails execution/requirements,” which motivates execution/test-based verification loops. Source: CodeHalu (arXiv:2405.00253) (accessed 2026-01-26).
• Secure code generation can be improved via an agentic workflow that applies guidelines and uses unit tests as a feedback mechanism to preserve functionality while improving security. Source: SCGAgent (arXiv:2506.07313) (accessed 2026-01-26).

Practical implication for this framework:

• Treat “run deterministic checks” as a mandatory self-verification step in Stage 5 (Execution). If checks fail, the next loop iteration must incorporate the tool output as ground truth and repair until the checks pass or the task is explicitly blocked.

2.1.2 Storage-agnostic semantic tokens (artifact IDs, not file paths)

This framework is intentionally storage-agnostic. Any concrete filename or path (e.g. design-guide.md, task-{N}.md) should be treated as an example implementation, not the canonical representation. The canonical representation is a semantic identifier that can be backed by files, a database, a queue, git notes, etc.

Core token pattern:

ARTIFACT:{TYPE}({SCOPE_OR_ID})

Minimal starting set (recommended):

SCOPE:{scope_id}

ARTIFACT:DISCOVERY(SCOPE:...)
ARTIFACT:PRD(SCOPE:...)
ARTIFACT:NFR(SCOPE:...)
ARTIFACT:ARCH(SCOPE:...)
ARTIFACT:ADR(DECISION:...)
ARTIFACT:PLAN(SCOPE:...)
ARTIFACT:TASK(TASK:...)
ARTIFACT:EXECUTION(TASK:...)
ARTIFACT:REVIEW(TASK:...)
ARTIFACT:VERIFICATION(SCOPE:...)

# Optional (often useful in practice)
ARTIFACT:STATE(SCOPE:...)
ARTIFACT:CONTEXT(SCOPE:...)

Disambiguators (recommended):

CTX:WINDOW | CTX:CODEBASE | CTX:CONVERSATION | CTX:INTEGRATION
PREREQ:AVAILABLE | PREREQ:DERIVABLE | PREREQ:MISSING | PREREQ:CONFIDENCE(0.0-1.0)
EXEC:SEQUENTIAL | EXEC:PARALLEL | EXEC:WAVE
VERIFY:SELF | VERIFY:BOUNDARY | VERIFY:FORENSIC | VERIFY:FINAL

Terminology note (names unset, semantics fixed):

• Use CTX:* for “what information is loaded/available to an AI instance” (context window vs codebase grounding vs conversation state).
• Use VERIFY:* for checks (deterministic or evidence-based) that gate progress.
• Use REVIEW (as an artifact type) for adjudication outputs (a human-meaning decision with rationale), even if the stage name later becomes “validation”, “forensic review”, “outcome review”, etc.
• This framework explicitly avoids tool blocking and approval gates. All approval is frontloaded via explicit agreement on Desired outcome + Objectives + Acceptance criteria. After that, progress is gated only by prerequisite completeness (PREREQ:*) and check outcomes (VERIFY:*), not by “permission to use tools”.

Agent taxonomy (names unset, roles fixed):

• An agent is any AI instance doing work and capable of using tools.
• The assistant is the interactive agent in the main conversation.
• A sub-agent is an agent invoked via the built-in Task() tool (isolated context, returns findings).

2.1.3 Example implementations (files vs SQL)

The tokens are canonical; the storage backend is an implementation detail. Two equivalent example backends:

Example scope/task IDs:

SCOPE:scope_001
TASK:task_042

A) Filesystem-backed artifacts (example convention):

ARTIFACT:DISCOVERY(SCOPE:scope_001)        -> .sam/artifacts/scope_001/discovery.md
ARTIFACT:PLAN(SCOPE:scope_001)             -> .sam/artifacts/scope_001/plan.md
ARTIFACT:PLAN(SCOPE:scope_001)             -> .sam/artifacts/scope_001/plan.contextualized.md
ARTIFACT:TASK(TASK:task_042)               -> .sam/artifacts/tasks/task_042.md
ARTIFACT:EXECUTION(TASK:task_042)          -> .sam/artifacts/tasks/task_042.execution.md
ARTIFACT:REVIEW(TASK:task_042)             -> .sam/artifacts/tasks/task_042.review.md
ARTIFACT:VERIFICATION(SCOPE:scope_001)     -> .sam/artifacts/scope_001/verification.md

B) SQL-backed artifacts (example schema):

CREATE TABLE artifacts (
  token TEXT PRIMARY KEY,
  type TEXT NOT NULL,
  scope_id TEXT,
  task_id TEXT,
  content TEXT NOT NULL,
  created_at TEXT NOT NULL,
  updated_at TEXT NOT NULL
);

CREATE INDEX artifacts_scope_idx ON artifacts(scope_id);
CREATE INDEX artifacts_task_idx ON artifacts(task_id);

Example retrieval:

SELECT content
FROM artifacts
WHERE token = 'ARTIFACT:PLAN(SCOPE:scope_001)';

2.2 The Pipeline Architecture

flowchart TD
    subgraph PIPE["STATELESS SOFTWARE ENGINEERING PIPELINE"]
        S1["STAGE 1: DISCOVERY<br/><br/>Input: User request, problem statement<br/>Agent: Discovery Agent<br/>Process: Structured discussion, questions, data gathering<br/>Output: Feature requirements, non-functional requirements,<br/>notes, goals, problems to solve, references, examples"]

        S2["STAGE 2: PLANNING<br/><br/>Input: Discovery artifacts<br/>Agent: Planning Agent (with RT-ICA)<br/>Process: Review goals, assess prerequisites, design solution<br/>Output: Feature design guide with success criteria"]

        S3["STAGE 3: CONTEXT INTEGRATION<br/><br/>Input: Design guide + codebase access<br/>Agent: Context Integration Agent<br/>Process:<br/>- Review plan against existing codebase<br/>- Identify already-complete scope<br/>- Find conflicts, contradictions, constraints<br/>- Map existing systems, methodologies, utilities<br/>- Add file/URL references to plan<br/>Output: Contextualized plan with concrete references"]

        S4["STAGE 4: TASK DECOMPOSITION<br/><br/>Input: Contextualized plan<br/>Agent: Task Decomposition Agent<br/>Process: Create atomic tasks following TDD pattern:<br/>1. Create interfaces<br/>2. Write failing tests<br/>3. Implement functionality<br/>4. Validate via linting<br/>5. Validate via testing<br/>6. Repeat until passing<br/>Output: Task file with:<br/>- Exact constraints<br/>- Files to modify<br/>- Style to follow<br/>- Methodology to use<br/>- Language specifications<br/>- Self-verification steps<br/>- Definition of done"]

        S5["STAGE 5: EXECUTION<br/><br/>Input: Task file (contains ALL context needed)<br/>Agent: Execution Agent (FRESH SESSION)<br/>Process:<br/>- Receive task file as complete prompt<br/>- Execute exactly as specified<br/>- Follow embedded self-verification steps<br/>- No need to recall or infer - all answers provided<br/>Output: Implemented code + verification results"]

        S6["STAGE 6: FORENSIC REVIEW<br/><br/>Input: Execution results + original plan<br/>Agent: Forensic Review Agent<br/>Process:<br/>- Validate task completion against plan<br/>- Review + critique + fact-check<br/>- Quality assessment<br/>- Determine: COMPLETE or NEEDS_ADDITIONAL_WORK<br/>Output: Completion report with findings"]

        DECISION{COMPLETE or ISSUES?}
        COMPLETE["COMPLETE"]
        ISSUES["ISSUES"]
        PLANNER["Planner Agent<br/>(creates new tasks)"]
        ORCH["Orchestrator<br/>(dispatches workers)"]

        S7["STAGE 7: FINAL VERIFICATION<br/><br/>Input: All completed tasks + original goals<br/>Agent: Final Verification Agent<br/>Process:<br/>- Verify feature achieves original goal<br/>- Validate acceptance criteria<br/>- Confirm definition of done<br/>Output: Feature completion certification"]

        S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> DECISION
        DECISION -->|COMPLETE| COMPLETE --> S7
        DECISION -->|ISSUES| ISSUES --> PLANNER --> ORCH --> S5
    end

2.3 Artifact Flow

flowchart TD
    REQ["User Request"]
    DISC["ARTIFACT:DISCOVERY(SCOPE:...)<br/>Feature requirements, NFRs, goals, references<br/>(e.g. discovery-output.md)"]
    DESIGN["ARTIFACT:PLAN(SCOPE:...)<br/>Solution design, success criteria, approach<br/>(e.g. design-guide.md)"]
    CTX["ARTIFACT:PLAN(SCOPE:...)<br/>Plan + existing code references, conflicts resolved,<br/>utilities identified, file paths mapped<br/>(e.g. contextualized-plan.md)"]
    TASK["ARTIFACT:TASK(TASK:...)<br/>Atomic task with ALL context embedded:<br/>- Constraints, files, style, methodology<br/>- Self-verification steps, DoD<br/>(e.g. task-{N}-{name}.md)"]
    EXEC["ARTIFACT:EXECUTION(TASK:...)<br/>Implementation results, verification output<br/>(e.g. execution-results-{N}.md)"]
    REVIEW["ARTIFACT:REVIEW(TASK:...)<br/>Findings, issues, completion status<br/>(e.g. review-report-{N}.md)"]
    CERT["ARTIFACT:VERIFICATION(SCOPE:...)<br/>Final certification against original goals<br/>(e.g. feature-certification.md)"]

    REQ --> DISC --> DESIGN --> CTX --> TASK --> EXEC --> REVIEW --> CERT

Part 3: Agent Specifications

3.1 Discovery Agent

Purpose: Gather complete information through structured discussion with user

Input:

• User's initial request or problem statement

Process:

1. Identify the problem domain
2. Ask clarifying questions about:
   • Who are the users?
   • What problem are we solving?
   • What does success look like?
   • What are the constraints?
   • What already exists?
3. Gather references and examples
4. Document non-functional requirements
5. Capture explicit goals and anti-goals

Output: ARTIFACT:DISCOVERY(SCOPE:...) (e.g. discovery-output.md)

## Feature: {name}

### Problem Statement
{what problem we're solving}

### Users
{who will use this}

### Goals
- {goal 1}
- {goal 2}

### Anti-Goals (Out of Scope)
- {explicitly not doing this}

### Functional Requirements
1. {requirement}
2. {requirement}

### Non-Functional Requirements
- Performance: {criteria}
- Security: {criteria}
- Compatibility: {criteria}

### References
- {link or file path}
- {example from similar system}

### Open Questions (Resolved)
- Q: {question} A: {answer from user}

### Notes
{additional context captured during discussion}

Success Criteria: User confirms the discovery document accurately captures their intent.

3.2 Planning Agent

Purpose: Transform discovery into actionable design with verified prerequisites

Input:

• ARTIFACT:DISCOVERY(SCOPE:...) (e.g. discovery-output.md)

Process:

1. RT-ICA Assessment:

   • List all prerequisites for success
   • Mark each: AVAILABLE | DERIVABLE | MISSING
   • If MISSING: BLOCK and request information
   • If all AVAILABLE/DERIVABLE: PROCEED

2. Solution Design:

   • Define approach
   • Identify components needed
   • Specify success criteria
   • Define acceptance tests

3. Risk Assessment:

   • Technical risks
   • Dependency risks
   • Knowledge gaps

Output: ARTIFACT:PLAN(SCOPE:...) (e.g. design-guide.md)

## Feature Design: {name}

### RT-ICA Assessment
| Prerequisite | Status | Source |
|--------------|--------|--------|
| {prereq} | AVAILABLE | {where it comes from} |

Decision: APPROVED / BLOCKED

### Approach
{high-level solution description}

### Components
1. {component}: {purpose}
2. {component}: {purpose}

### Success Criteria
- [ ] {measurable criterion}
- [ ] {measurable criterion}

### Acceptance Tests
- Given {context}, When {action}, Then {outcome}

### Risks
| Risk | Mitigation |
|------|------------|
| {risk} | {mitigation} |

### Dependencies
- {external dependency}
- {internal dependency}

Success Criteria: All prerequisites verified, no MISSING items, design addresses all requirements.

3.3 Context Integration Agent

Purpose: Ground the design in actual codebase reality

Input:

• ARTIFACT:PLAN(SCOPE:...) (e.g. design-guide.md)
• Access to codebase

Process:

1. Scope Analysis:

   • Identify what already exists
   • Mark scope items as: NEW | MODIFY | COMPLETE

2. Conflict Detection:

   • Find contradictions with existing patterns
   • Identify technical constraints
   • Note architectural conflicts

3. Resource Mapping:

   • Existing utilities to reuse
   • Existing patterns to follow
   • File paths for all references

4. Plan Update:

   • Add concrete file references
   • Note existing implementations
   • Document integration points

Output: ARTIFACT:PLAN(SCOPE:...) (e.g. contextualized-plan.md)

## Contextualized Plan: {name}

### Scope Status
| Item | Status | Notes |
|------|--------|-------|
| {item} | NEW | {notes} |
| {item} | MODIFY | Existing: {file:line} |
| {item} | COMPLETE | Already at {file:line} |

### Conflicts Resolved
| Conflict | Resolution |
|----------|------------|
| {conflict} | {how resolved} |

### Technical Constraints
- {constraint}: {implication}

### Existing Resources to Use
| Resource | Location | Purpose |
|----------|----------|---------|
| {utility} | {file:line} | {why use it} |

### Integration Points
| System | Interface | File |
|--------|-----------|------|
| {system} | {how to integrate} | {file path} |

### Updated Design
{design with concrete references}

### File Manifest
| File | Action | Purpose |
|------|--------|---------|
| {path} | CREATE | {purpose} |
| {path} | MODIFY | {what changes} |

Success Criteria: All design elements mapped to concrete files, no unresolved conflicts, existing resources identified.

3.4 Task Decomposition Agent

Purpose: Create atomic, self-contained task files

Input:

• ARTIFACT:PLAN(SCOPE:...) (e.g. contextualized-plan.md)

Process:

1. Decompose into Atomic Tasks:

   • Each task: 15-60 minutes of work
   • Single responsibility per task
   • Clear input/output

2. Order by TDD Pattern:

   • Interface tasks first
   • Test tasks second
   • Implementation tasks third
   • Integration tasks last

3. Embed All Context:

   • No task requires recall
   • All answers in the task file
   • Complete methodology specified

Output: ARTIFACT:TASK(TASK:...) for each task (e.g. task-{N}-{name}.md)

## Task {N}: {name}

### Context
{everything the execution agent needs to know}

### Constraints
- Language: {language and version}
- Style: {style guide reference}
- Patterns: {patterns to follow}

### Files to Modify
| File | Action | Reference |
|------|--------|-----------|
| {path} | CREATE/MODIFY | {ARTIFACT:PLAN(SCOPE:...) section} |

### Methodology
1. {step with specific action}
2. {step with specific action}

### Self-Verification Steps
1. [ ] {verification step}
2. [ ] {verification step}
3. [ ] {verification step}

### Definition of Done
- [ ] {criterion}
- [ ] {criterion}
- [ ] All self-verification steps pass

### Dependencies
- Requires: {task-N-1} complete
- Blocks: {task-N+1}

### References
- Design: ARTIFACT:PLAN(SCOPE:...)#{section}
- Pattern: {file:line}
- Example: {file:line}

Success Criteria: Each task is self-contained, follows TDD order, includes all context needed for execution.

3.5 Execution Agent

Purpose: Execute a single task with embedded verification

Input:

• Single ARTIFACT:TASK(TASK:...) (AS THE COMPLETE PROMPT) (e.g. task-{N}-{name}.md)

Process:

1. Read task file (this IS the context)
2. Execute methodology steps exactly
3. Perform self-verification steps
4. Report results

Key Properties:

• Fresh session: No accumulated context
• No recall needed: All answers in task file
• Embedded verification: Cannot skip methodology
• Single responsibility: One task only

Output: Implementation + ARTIFACT:EXECUTION(TASK:...) (e.g. execution-results-{N}.md)

## Execution Results: Task {N}

### Status: COMPLETE / BLOCKED

### Implementation Summary
{what was done}

### Self-Verification Results
1. [x] {step}: PASS
2. [x] {step}: PASS
3. [ ] {step}: FAIL - {reason}

### Definition of Done
- [x] {criterion}: verified by {evidence}
- [ ] {criterion}: not met because {reason}

### Files Changed
| File | Changes |
|------|---------|
| {path} | {summary} |

### Blockers (if any)
- {blocker}: {what's needed}

### Notes
{observations during execution}

Success Criteria: Task completed per specification OR explicit blockers identified.

3.6 Forensic Review Agent

Purpose: Independent verification that task was completed correctly

Input:

• ARTIFACT:EXECUTION(TASK:...) (e.g. execution-results-{N}.md)
• ARTIFACT:TASK(TASK:...) (e.g. task-{N}-{name}.md)
• ARTIFACT:PLAN(SCOPE:...) (e.g. contextualized-plan.md)

Process:

1. Completion Verification:

   • Compare results to task requirements
   • Verify all DoD criteria met

2. Quality Assessment:

   • Code review against standards
   • Pattern compliance check
   • Integration verification

3. Fact-Check:

   • Verify claims in execution results
   • Confirm files changed as stated
   • Validate test results

4. Determination:

   • COMPLETE: All criteria met
   • NEEDS_WORK: Specific issues identified

Output: ARTIFACT:REVIEW(TASK:...) (e.g. review-report-{N}.md)

## Review Report: Task {N}

### Verdict: COMPLETE / NEEDS_WORK

### Completion Assessment
| Criterion | Status | Evidence |
|-----------|--------|----------|
| {DoD item} | PASS/FAIL | {evidence} |

### Quality Assessment
| Aspect | Score | Notes |
|--------|-------|-------|
| Code standards | {1-5} | {notes} |
| Pattern compliance | {1-5} | {notes} |
| Test coverage | {1-5} | {notes} |

### Fact-Check Results
| Claim | Verified | Notes |
|-------|----------|-------|
| {claim from execution results} | YES/NO | {notes} |

### Issues Found
1. {issue}: {details}
2. {issue}: {details}

### Recommendations
- {recommendation for fix}
- {recommendation for improvement}

### Follow-up Tasks Needed
- [ ] {new task if NEEDS_WORK}

Success Criteria: Independent verification complete, clear verdict with evidence.

3.7 Planner Agent (Iteration)

Purpose: Create follow-up tasks from review findings

Input:

• ARTIFACT:REVIEW(TASK:...) with NEEDS_WORK verdict (e.g. review-report-{N}.md)

Process:

1. Analyze issues found
2. Create new task files to address each issue
3. Update task dependency graph

Output: Additional ARTIFACT:TASK(TASK:...) entries (e.g. task-{N+1}-{name}.md)

3.8 Orchestrator

Purpose: Coordinate execution flow across all agents

Responsibilities:

• Track task status
• Dispatch execution agents
• Route review results
• Determine when all tasks complete
• Trigger final verification

Key Property: Thin orchestrator - reads status, dispatches agents, does not do work itself.

3.9 Final Verification Agent

Purpose: Verify complete feature against original goals

Input:

• ARTIFACT:DISCOVERY(SCOPE:...) (original goals) (e.g. discovery-output.md)
• All ARTIFACT:REVIEW(TASK:...) artifacts (e.g. review-report-{N}.md)
• ARTIFACT:PLAN(SCOPE:...) (e.g. contextualized-plan.md)

Process:

1. Goal Verification:

   • Each original goal → evidence of completion

2. Acceptance Criteria:

   • Each criterion → test result

3. Definition of Done:

   • Feature-level DoD → verification

Output: ARTIFACT:VERIFICATION(SCOPE:...) (e.g. feature-certification.md)

## Feature Certification: {name}

### Status: CERTIFIED / NOT_CERTIFIED

### Goal Achievement
| Goal | Status | Evidence |
|------|--------|----------|
| {goal from discovery} | ACHIEVED | {evidence} |

### Acceptance Criteria
| Criterion | Status | Test |
|-----------|--------|------|
| {criterion} | PASS | {test result} |

### Definition of Done
| Item | Status |
|------|--------|
| All tasks complete | YES |
| All reviews pass | YES |
| Integration verified | YES |
| Documentation updated | YES |

### Summary
{feature is ready for use / issues remaining}

Part 4: Theoretical Foundations

4.1 Mapping to Formal Methods

4.2 Mapping to Systems Engineering

4.3 Mapping to Software Patterns

4.4 Mapping to Manufacturing

Part 5: Why This Works

5.1 Eliminates Claude's Failure Modes

5.2 Structural Enforcement vs Behavioral Instruction

5.3 The Key Insight

Claude is a stateless function, not a stateful agent.

Treat it like a pure function:

• Input: Complete context (task file)
• Output: Verified result
• No side effects: Fresh context each time
• No memory: Everything externalized to files

Part 6: Implementation Roadmap

Phase 1: Core Infrastructure

1. Artifact schemas: Define markdown templates for each artifact type
2. Agent definitions: Create agent files for each role
3. Orchestrator command: /sse:start to begin workflow
4. Status tracking: ARTIFACT:STATE(SCOPE:...) for pipeline position (e.g. STATE.md)

Phase 2: Stage Implementation

1. Discovery stage: /sse:discover command + agent
2. Planning stage: /sse:plan command + RT-ICA integration
3. Context stage: /sse:contextualize command + agent
4. Decomposition stage: /sse:decompose command + agent

Phase 3: Execution Loop

1. Execution stage: /sse:execute command + fresh agent spawning
2. Review stage: /sse:review command + for

…(truncated)