Before
Clarify scope, acceptance criteria, relevant playbooks, risk, and what would make the change reviewable.
How SDF fits
Where SDF Fits
AI tools produce work. SDF gives that work an executable verification loop: scoped intent, receiver-owned guidance, configured checks, verification truth, evidence, limits, and human review.
SDF is pro-AI and pro-engineering discipline. It supports human review; it does not replace approved tools, controls, or engineering judgement.
Around the work
SDF fits around the work, not above the team.
The useful question is not which AI tool wrote the code. It is whether the team can see what was asked, what changed, what was checked, and what still needs human judgement.
During
Keep evidence, verification status, risk notes, and limits close to the change while it is shaped.
After
Hand reviewers the delivery story and preserve useful context for future humans and agents.
What stays authoritative
Your approved tools and controls still do their jobs.
SDF is designed to fit around an existing engineering environment. It does not become the new authority over every system.
AI coding tools
Codex, Claude Code, Cursor, Copilot, internal agents, and whatever comes next can keep producing work inside the team's approved workflow.
Engineering checks
CI, code review, static analysis, test suites, package controls, and release checks remain authoritative.
Security review
SDF does not replace security review, data policy, scanning, threat modelling, or approval controls.
Engineering judgement
Engineers, reviewers, and leaders still decide what is acceptable to approve, merge, deploy, or defer.
Current public path
Start with readiness. Prove it on one governed PR.
The guide explains the fit. The offer path stays practical and staged, so teams do not jump from interest straight to broad implementation.
Readiness check
Qualify fit and spot obvious gaps before a deeper assessment.
Paid assessment
Diagnose readiness, missing evidence, blockers, risks, and the safest first proof.
First governed change
Run one bounded change through the SDF CLI loop with acceptance criteria, verification truth, evidence, limits, and human review.
Team operating model
Adapt the useful proof into repo-local guidance, configured checks, evidence expectations, review process, and risk profile.
Current boundaries
Evidence supports review. It does not make the decision.
Evidence and verification truth support review; they do not approve the work. Public guidance should make fit clearer without implying hidden automation, replacement controls, or private operating mechanics.
No automatic approval or merge
SDF does not approve, merge, deploy, or release work for the team.
No automatic repair or enforcement
SDF does not repair code, run hosted enforcement, enforce central AI policy, or route models automatically.
No replacement controls
SDF does not replace CI, code review, security review, data policy controls, package controls, or engineering ownership.
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
Ready to evaluate fit?
Start with the readiness check. Use the assessment journey when you want the full buyer path before discussing private implementation details.