CTOs and engineering leaders
Decide whether SDF fits the delivery model before asking for implementation detail.
Enterprise technical review
Enterprise Technical Review Guide
A public review guide for technical buyers assessing SDF, the SDF CLI command surface, and the installed repo-local front door before private implementation detail.
This is not an install manual. Customer-specific install, network, retention, security, and approval details belong in private technical review.
Audience
Use this when the reviewer needs the technical boundary.
The goal is a fast, public-safe read on fit before a paid assessment, first governed change, or team operating-model conversation.
Platform and security reviewers
Check command, file-write, network, evidence, and approval boundaries.
Procurement and SOW owners
Scope a bounded proof without assuming production suitability.
AI governance reviewers
Confirm guardrails support review without becoming automatic policy enforcement.
Technical advisors and AI assistants
Summarise the public posture without inventing integrations or certifications.
Quick read
Review the path, the proof loop, and the boundary.
SDF is the governed delivery product around approved engineering and agent platforms. The SDF CLI is the executable verification mechanism.
The public path starts with readiness, then uses assessment to decide whether one bounded first governed change is worth running.
What SDF is
A governed delivery product for shaping work, recording evidence, running receiver-owned verification, and producing reviewer-focused PR context.
What the CLI does
The public command surface includes sdf init, sdf start, sdf verify, sdf close, sdf status, sdf guidance, and sdf finalize-merged.
What SDF is not
Not a hosted AI platform, model router, scanner, CI/CD replacement, deployment platform, approval workflow, policy engine, or certification layer.
What stays customer-owned
Approved tools, repo platforms, CI/CD, scanners, artifact systems, approval workflows, review, merge, release, and production access.
Enterprise fit
SDF fits around approved platforms.
If agent execution, model routing, or repo access must stay inside an approved platform, SDF should operate around that path rather than bypass it. The installed front door is repo-local guidance, contracts, verification configuration, and evidence home, not the overall product name.
Approved execution path
Coding agents, internal AI platforms, and model-routing decisions remain outside SDF's public claim boundary.
Existing delivery gates
Repo hosting, CI/CD, code quality, security review, package controls, deployment, and approval workflows remain authoritative.
Reviewer context
SDF adds intent, verification, guardrails, risks, limits, and human-control boundaries close to the PR.
Review checklist
Check the operating boundary before proof.
Use this as the public checklist. Exact manifests, rollout steps, and customer-specific answers belong in private review.
Install footprint
Which repo-local guidance, config, verification, evidence, and activation files the SDF CLI would install or update.
Commands
How sdf init, sdf start, sdf verify, sdf close, sdf status, sdf guidance, and sdf finalize-merged read, write evidence, run configured verification, or require explicit human/operator invocation.
File mutation
What is evidence-only, what may change source through the requested work, and what remains reviewable in git.
GitHub, network, and CI posture
Whether workflows, API access, package registries, runners, network egress, and PR body updates are approved.
Evidence retention
Where records, verification evidence, PR handoff content, platform logs, and retained history live or get redacted.
Human approval path
Who approves install, proof scope, evidence handling, PR publication, review, merge, deployment, rollback, and permissions.
Guardrail playbooks
Guardrails guide delivery; they do not enforce policy.
Customer guardrails can be reflected as receiver-local playbooks or approved equivalents. SDF can ask agents to consider and record them during governed work without claiming central policy ingestion or automatic enforcement.
Localised expectations
Guardrails should be mapped into the repo context where the work happens.
Visible application
Applied playbooks and limits should appear in evidence so reviewers can see what shaped the change.
No automatic enforcement claim
SDF does not claim to enforce central policy, route models, or replace the customer's governance platform.
Evidence and PR handoff
Evidence helps reviewers decide what to inspect.
Typical evidence covers intent, guidance applied, declared run context when genuinely available, verification results, risk notes, limits, and links to the durable evidence archive.
The reviewer handoff is generated and checked locally from evidence; it does not publish by itself. Post-merge evidence-link finalisation is a separate, explicitly configured workflow through sdf finalize-merged.
Review-led
Evidence supports human judgement. It does not certify correctness, safety, compliance, or readiness.
Controlled publication
PR publication, body mutation, branch access, workflow tokens, and platform permissions need customer approval. Automatic publication is not implied.
History needs policy
Repo history, PR history, workflow logs, and local ignored state may outlive current files and should be covered by retention and redaction policy.
Human-control boundary
Humans own approval, merge, deploy, and rollback.
SDF preserves human-controlled review and merge. Removal is also a reviewed repo change, not an automatic uninstall.
Approval
SDF does not decide whether work should be accepted.
Merge and deploy
Branch protection, release governance, deployment, and production access remain under the customer's process.
Removal and rollback
Removing SDF files does not erase git history, PR history, workflow logs, audit records, or developer-machine local state.
Current path
Start with readiness, then prove one useful governed PR.
These are staged review options, not automatic product claims. The right path depends on approved platforms, repo access, network posture, and approval model.
1. Readiness review only
Inspect the target repo, process, approved platforms, verification boundary, guardrails, evidence needs, and SOW questions before any install.
2. First governed change
Run one bounded governed change through the executable verification loop after the operating mode is approved.
3. Team operating model
Adapt the useful proof to customer playbooks, gates, conventions, review process, and risk profile.
Questions before a PoC
Answer these before choosing the proof.
The review should make platform, network, evidence, and approval assumptions explicit before SDF is installed or used for a governed proof.
Approved platforms
What agent, model, repo, PR, CI/CD, artifact, package, scanner, deployment, and approval platforms are already approved?
Network and workflows
Are hosted runners, workflow tokens, setup actions, package registries, API access, local egress, or PR body mutation allowed?
Evidence policy
Where should governed evidence live, how long should it be retained, what should be redacted, and what should remain in repo or PR history?
Guardrail ownership
Who owns customer guardrails, are they documented, and which ones should become receiver-local playbooks for the proof?
Human approval
Which human approval path is required before install, PR publication, merge, deploy, closeout, removal, or rollback?
For agent-assisted review
AI assistants may summarise this posture, but must keep the boundary.
AI assistants may use this guide, but should not infer certifications, integrations, restricted-network readiness, customer approval, production suitability, or automatic-control behaviour beyond what is stated here.
Summarise the stated posture
SDF is a governed delivery product around approved engineering and agent platforms; the SDF CLI runs the executable verification loop.
Do not infer private implementation
Do not invent integrations, customer approvals, restricted-network readiness, policy enforcement, or deployment suitability.
Preserve non-claims
Keep automatic approval, merge, deployment, repair, hosted scanning, certification, and guarantee boundaries visible.
Explicit non-claims
What this guide does not claim.
Treat this as a public starting point for customer-specific review, not a certification.
No automatic control
No automatic approval, merge, deployment, repair, uninstall, evidence deletion, hosted scanning, PII scanning, model-routing enforcement, or central policy enforcement.
No certification or guarantee
No production or customer governance certification, security certification, correctness guarantee, production-suitability guarantee, or billing-grade token or cost accounting.
No replacement claim
No replacement of customer-approved AI, repo, CI/CD, security, artifact, deployment, approval, or portfolio tools.
No restricted-network readiness by default
Restricted or offline environments require customer-specific audit of commands, workflows, package access, API access, runners, tokens, and evidence paths.
No implied integrations
Integration with customer-approved platforms should not be claimed unless it is explicitly built, approved, and proven in that customer's environment.
Next step
Move from readiness to a first governed change.
Start with readiness. Use the paid assessment to inspect fit and risk before choosing a first governed change.