Spec-Anchored Evolutionary Development

Spec-Anchored Evolutionary Development (SAED) is a standalone, tool-independent method for carrying an authorized software change from explicit intent to evidence-backed continuation. It lets the design evolve without letting implementation silently rewrite the agreement or a passing test overstate what has been proved.

Specify the intent, evolve the design in bounded slices, preserve material decisions, and make no claim stronger than the evidence.

SAED is intentionally narrower than a full SDLC or enterprise architecture method and broader than a spec-to-code workflow. Its job is the control seam between them: route each change by consequence, keep one bounded packet authoritative, record material learning, feed verified deltas back into architecture, and cap every completion claim at the evidence available.

Start here

Adopt SAED	Compare the alternatives	Connect it to a larger framework
Adoption guide Map SAED into an independent, team, or governed setting without replacing useful existing practices.	Comparison brief Review SAED beside Spec Kit, OpenSpec, Kiro, BMAD-METHOD, AWS AI-DLC, TDD, BDD, continuous delivery, and related practices.	Framework fit See the handoffs to an SDLC, TOGAF-style architecture work, assurance, release, operations, and outcome review.

For a first change, use the 10-minute quickstart. For exact rules and required semantics, use the normative methodology.

Why SAED—and when not to add it

SAED exists for a practical gap. Spec-driven tools are often strongest from specification through implementation. Delivery and architecture frameworks cover a much wider lifecycle. Between them, a project can still lack one consistent rule for routing a change, preserving revised intent, returning verified lessons to architecture, and separating “the code passed” from “the release worked” and “the outcome improved.” SAED makes that rule set explicit. It does not claim the gap exists in every project.

Your primary need	Start with	Where SAED fits
Generate a spec, plan, tasks, and implementation	A spec-driven tool or workflow	Add SAED only if you also need durable amendment authority, risk routing, release evidence, or outcome state.
Drive behavior through examples and tests	TDD, BDD, or ATDD	Link those checks as implementation evidence; SAED does not replace the test technique.
Automate build, deployment, rollback, and telemetry	Continuous delivery and operations tooling	Use pipeline and runtime records as evidence; SAED is not a delivery engine.
Govern an enterprise lifecycle or architecture portfolio	An SDLC, TOGAF, or the applicable organizational framework	Use SAED inside an authorized project and return verified change evidence to the wider process.
Keep intent, architecture, decisions, release proof, and outcome claims coherent as a change evolves	SAED	Use one risk-routed packet as the hub and map every companion artifact to one declared authority.

A mature delivery system may already answer the same questions with issues, tests, ADRs, pipelines, observability, and outcome reviews. If it has one coherent authority model and preserves the evidence boundary, map those controls to SAED or keep the existing system; do not create duplicate truth. The comparison brief contains the full pros, cons, coverage matrix, primary-source review, and evidence gaps.

The minimum standalone loop

1. Start with an authorized need, stable project boundary, and accountable owner.
2. Route the change to L1, L2, or L3 and declare an exploration, alpha, beta, or operational delivery posture.
3. Baseline one bounded change packet.
4. Implement an independently verifiable slice.
5. Gather evidence and converge intent, code, tests, architecture, and documentation.
6. Release and observe only when separately authorized.
7. Validate the real-use outcome, then accept, amend, defer, stop, or continue.

The smallest useful installation needs one declared authority for packet state, one accountable decision owner, explicit rigor and posture decisions, acceptance evidence appropriate to the risk and claim, a visible record of material learning, and a truthful closeout with a continuation point.

One bounded authorization normally carries reversible local work through implementation, focused verification, in-scope repair, documentation, and an ordinary local commit. SAED adds another owner gate when the contract, risk, or consequence changes—not merely because the next step is called planning, review, staging, or commit.

Three independent dimensions

SAED separates the consequence of a change, the operating context of the adopter, and the readiness claim of the current delivery posture.

Axis	Values	Decides
Change rigor	L1, L2, L3	How much specification, review, recovery, and evidence this change needs
Adoption context	independent, team, governed	How roles, approvals, storage, and automation are implemented
Delivery posture	exploration, alpha, beta, operational	Which evidence and completion claim are appropriate now

The dimensions do not substitute for one another. A solo maintainer can have an L3 alpha change. A governed organization can use L1 for a local reversible operational edit. Context and posture never lower the rigor required by the actual consequence.

Reach alpha without importing production ceremony

The alpha-light L2 template has two routine checkpoints: accept one thin package, then review one integrated usable slice. Reversible planning, research, implementation, repair, focused checks, documentation, staging, and ordinary local commits happen inside that boundary. Production operations, release, and outcome evidence may stay explicitly deferred when the alpha does not cross those boundaries.

Alpha is not a safety waiver. Live or sensitive data, credentials, money, destructive migration, public release, established dependents, or other consequential effects still activate the applicable L3 and human authority.

Support parallel workers and agents

One accountable owner may fan a parent packet into bounded child lanes. Each lane pins its input, dependencies, owned paths or read-only scope, permission, acceptance check, and stop condition. Concurrent writers use isolated, non-overlapping workspaces. One integrator reconciles typed receipts and verifies the combined candidate. Lane success is evidence—not merge, deployment, publication, or risk-acceptance authority.

Choose a starting level

Level	Use when	Minimum record
L1 — bounded change	Local, reversible work inside established authority and architecture	Outcome, scope, risk, reversal, acceptance, focused proof
L2 — feature	A meaningful capability, workflow, state, integration, or multi-slice change	Feature brief, architecture delta, phases, evidence plan, amendments, closeout
L3 — structural / high-risk	Authority, security, privacy, money, canonical data, migration, infrastructure, recovery, or high-blast-radius changes	L2 packet plus decisions, failure analysis, compatibility, rehearsal, recovery, observation, named approvals

When uncertain, start with the lowest level that appears adequate and escalate as soon as new risk appears.

What SAED governs

• One hub: the packet links the outcome, scope, non-goals, invariants, architecture delta, decisions, risks, acceptance, evidence, and closeout. Existing artifacts may fill those roles.
• Visible evolution: material learning changes an active packet through an amendment. Accepted packets become history instead of being silently rewritten.
• Two feedback loops: feature work updates the product; repeated verified lessons update current architecture, decisions, invariants, or fitness functions.
• A proof ceiling: specification review, implementation verification, exact-release operation, and real-use outcome validation are separate claims.
• Separate authorities: planning a change does not authorize deployment, publication, spending, migration, or risk acceptance.

SAED does not replace product discovery, task execution, programming technique, test design, CI/CD, observability, incident management, specialist assurance, or portfolio governance. The framework-fit guide identifies those connecting pieces and the gaps an adopter still has to own.

Standalone and integrated adoption

The canonical public mainline profile is saed-standalone, pinned to the unreleased method 1.4 candidate. The latest immutable public release remains v1.3.0.

• Standalone: use repository issues or Markdown for packets, the existing test system for verification, and release notes or an operations log for observation.
• Integrated: map an upstream intake system, project bootstrapper, spec-to-code tool, CI/CD platform, runtime observability, or portfolio registry through the generic interfaces.

Integration is optional. External tools must not become hidden prerequisites or silently take ownership of SAED packet state.

Repository map

Path	Purpose
DEVELOPMENT_METHODOLOGY.md	Normative SAED 1.4 mainline candidate
docs/QUICKSTART.md	Smallest useful adoption loop
docs/ADOPTION_GUIDE.md	Independent, team, and governed adoption
docs/COMPARISON_BRIEF.md	Near-neighbor comparison, tradeoffs, and evidence gaps
docs/FRAMEWORK_FIT.md	SDLC, TOGAF, and small-project mapping
docs/INTEGRATION_INTERFACES.md	Optional upstream and downstream contracts
profiles/	Neutral portable profile and adoption template
templates/	L1, alpha-light L2, full L2, L3, amendment, and closeout records
ARCHITECTURE.md	Public repository boundaries and extension model
docs/STATUS.md	Maturity, publication state, evidence gaps, and continuation
scripts/	Dependency-free distribution validation

Status and release boundary

• Published method: SAED 1.3 remains a working standard.
• Mainline method: SAED 1.4 is an unreleased candidate pending prospective alpha and parallel-delivery pilots.
• Distribution state: v1.3.0 remains the public release under Apache-2.0.
• Latest tagged source: v1.3.0.

“Working standard” describes the method's maturity; “public release” describes whether a reusable distribution has been published. Neither label proves external adoption or better outcomes. Local validation establishes distribution consistency, while exact hosted refs and workflow runs remain external facts that must be checked directly.

The whole repository is licensed under the Apache License, Version 2.0. The license decision records the scope, Apache-2.0 Section 5 inbound contribution terms, absence of a NOTICE file and per-file headers, and the separate trademark boundary. Publication, licensing, external adoption, and method effectiveness remain separate claims.

Contributing

Read CONTRIBUTING.md, GOVERNANCE.md, and the Code of Conduct. Run:

python3 scripts/run_checks.py

Security-sensitive reports should follow SECURITY.md.