Before
Clarify scope, acceptance criteria, relevant playbooks, guardrails, known risks, and what would make the change reviewable.
How SDF fits
Where SDF Fits
SDF sits around AI-assisted delivery. It helps teams shape work, apply delivery guardrails, capture evidence, support review, and preserve handoff context while existing tools remain authoritative.
SDF is pro-AI and pro-engineering discipline. It does not replace engineers, reviewers, or the tools your team already trusts.
Around the work
SDF sits before, during, and after AI-assisted delivery.
AI tools can help produce work. SDF helps teams govern the delivery context around that work so reviewers are not reconstructing intent, risk, and verification from scattered clues.
During
Keep evidence, verification status, risk notes, and limits visible while the change is being shaped.
After
Preserve PR handoff context, reviewer notes, and delivery memory for future humans and agents.
What stays authoritative
What SDF does not replace.
SDF is designed to fit around an existing engineering environment, not sit above every system as a new source of truth.
Approved AI tools and internal agent platforms
Teams can keep their chosen AI tools. SDF focuses on delivery discipline and reviewer context.
Central AI policy layer
SDF can reflect delivery expectations, but it does not claim central policy enforcement.
CI/CD and code quality checks
Existing checks still decide whether code passes the team's verification gates.
Security and data policy controls
SDF does not replace security review, data policy, scanning, or approval controls.
Approved package and dependency controls
Package managers, scanners, dependency policies, and ownership controls remain authoritative.
Portfolio and work-item systems
SDF can carry work context, but roadmap and portfolio systems remain the planning source of truth.
Engineers, reviewers, and engineering leaders
SDF supports human judgement. It does not decide what should be approved, merged, or deployed.
What SDF adds
Delivery discipline before the PR exists.
The value is not another comment layer on generated code. The value is a clearer delivery surface before a reviewer is asked to trust the change.
Reviewer-ready evidence
Intent, acceptance criteria, verification, risk, confidence, limits, and handoff context stay close to the work.
Guardrails as delivery-time playbooks
Expectations are applied while the work is being done, then made visible for review.
Handoff context
Future maintainers and agents can see what was asked, what was checked, and what remains uncertain.
Clearer proof boundaries
SDF helps teams distinguish what was proven, what was not proven, and where human review remains required.
Current boundaries
What this public guide is not claiming.
SDF is intentionally claim-bounded. Public guidance should make fit clearer without implying hidden automation, replacement of existing controls, or private operating mechanics.
No automatic approval
SDF does not approve work for the team.
No automatic merge or deploy
Review, merge, release, and production ownership remain human- and team-controlled.
No central policy or model routing enforcement
SDF does not claim to enforce central AI policy or route models for the organization.
No hosted scanning claim
SDF does not replace security scanning, data policy controls, package controls, or CI/code quality checks.
No certification or guarantee
SDF does not certify compliance, correctness, security, production readiness, measured savings, or billing-grade economics unless those are actually captured and evidenced.
Next step
Start with readiness, then prove the approach on one governed change.
The current public path is the repo review and readiness check. Use that path to decide whether SDF fits your environment before discussing private implementation details.