SDLC Enterprise Framework

Latest release: v7.1.2-alpha · Main: Unreleased · Release status: ALPHA

Version: 7.0.0 (the framework version live docs are verified against, read by scripts/check-version-declared.sh) | License: MIT

Status: ACTIVE Owner: @dttai71 Consumer: first-time readers and teams deciding whether to adopt the framework Review by: 2026-12-26

Who reads this: anyone deciding whether to adopt the framework, or opening this repo for the first time. When: before anything else. It takes ten minutes; the layout and reading order are at the end of this page.

What the framework is

Version 7 is the framework’s second generation: rebuilt, not upgraded. The first generation (v6 and earlier) is archived unmodified in archive/; what still holds was harvested into this tree, one row per source in MIGRATION-MAP.md. Nothing from the first generation applies unless it has a row there.

1. A methodology for building software with AI agents and a few people — often one.
2. You own four assets. Vendors supply the rest: agents, models, runtimes, in-session orchestration.
3. Rules sit in three classes. Only deterministic checks block.
4. Controls scale with the risk of the thing being built, not with team size.
5. A rule names a runnable command and the real incident (burn case) that justifies it.
6. A rule without a command is reference material, not a rule.
7. Gates default to ADVISORY with a counter and a deadline, and climb only on measured rates. A narrow control against irreversible harm may enter MACHINE directly — only under the exception contract in controls/rule-contract.md.
8. Incidents flow back into rules through one path (lessons-to-rules).
9. The framework gates itself in CI: doc count, rule tables, version declarations.
10. Promise: fewer rules, more of them enforced. Every section says what it shortens.

The four assets you own

Everything else is rented: agent CLIs, subagents, skills, hooks, models, CI runners. Adapters to them are generated and disposable. The policy is not. This repo’s skills/ are such adapters: they route an agent to the files that hold the rules, and are not a fifth asset. Shortens: you build and maintain nothing a vendor already ships.

Tier by risk of the artefact, not headcount

• Tier = max(repo evidence, declared service metadata, deploy evidence). Declare up only; below evidence is a violation.
• One person building ENTERPRISE gets ENTERPRISE gates. Three people building a sandbox get no ritual.
• Detail: controls/tiers.md.

Three classes

A probabilistic model is never MACHINE, however accurate. It adds a differently-blind check. It never replaces a deterministic one.

Gate contract

Every gate is a script you own. Exit 0 = pass. Exit 1 = cannot measure — the default code of anything that crashes lands here, so a crash is never reported as a violation. Exit 2 = violation, and the script must return it on purpose. ≥3 is reserved. No exit $? that passes another tool’s code through. The last stdout line is a label: result=pass|insufficient_evidence|violation gate= reason= [fix=…]. Every gate ships --selftest with at least one red case that must fail and one green case that must pass. A gate nobody has made red is unmeasured, not green. Full contract and rule table: controls/rule-contract.md.

Adopt in a repo

1. Policy repo. One repo holds tiers, rules, hats, approvers, gates. Product repos pin a release tag; generated files record the resolved SHA.
2. Generated adapters. adapters/gen.sh writes the vendor files (for example Claude Code and Qwen Code settings) from the policy. A hand edit is drift; CI catches it.
3. Reusable workflow. Product CI calls the policy repo’s workflow at the pinned ref. The tier comes from the policy, never from an input the product sets.

Day one for a developer: clone, open the agent CLI. Nothing to remember. Detail: adoption/adoption.md.

Layout of this repo

Folders are named by what kind of document they hold. Nothing is named after a version: the version is in each file’s SDLC Framework Version field, in git tags and in CHANGELOG.md, so paths survive the next major version.

Reading order:

Website: the v6 site remains at its last deployment; v7 has no site (no new components).

Lineage

v7 is the second generation of one methodology, not a new framework: the first generation (v1–v6.x) evolved release by release; the second was rebuilt. The goals never changed: know what each member (human or AI) is doing, know what they have done, coordinate them.

• What the first generation got right stays. The ten stages, the docs/00–09 project layout and the documentation standards are kept, shortened, in core/lifecycle.md and standards/. The second generation adds gates that check them instead of relying on memory.
• v6.x reached 189 live files and was archived on 2026-09-25. Today the framework governs its documents by owner, consumer and review date (DOC-2), not by a document ceiling. The history stays in CHANGELOG.md.
• Archive rule. Archive, never delete. From 2026-09-26 an archived file is not edited at all; where its content went is recorded in MIGRATION-MAP.md. (Files archived on 2026-09-25 carry a legacy note; those notes stay.) A file that changes meaning without a record breaks the past silently — no later gate catches that.
• Ownership rule. Every live doc names an Owner, a Consumer and a Review-by date; a missing field or a passed date blocks (scripts/check-doc-ownership.sh). The doc count above 40 is only flagged (scripts/check-doc-count.sh): forty docs with owners and readers beat thirty that merge five topics to pass a number. Each doc ≤150 lines. See CONTRIBUTING.md.