Engineering leaders
Assess where SDF fits in an approved delivery operating model.
Enterprise technical review
Enterprise Technical Review Guide
How to assess SDF before using it inside an enterprise software delivery environment.
This guide is a public review wrapper. Customer-specific install, network, retention, security, and approval details belong in private technical review.
Audience
Who this guide is for.
This guide is written for human and agent readers who need a plain-language view of SDF's enterprise posture before a proof of concept.
Platform and security reviewers
Review install, command, file-write, network, evidence, and approval boundaries.
Procurement and SOW owners
Scope a safe first review path without assuming production suitability.
AI governance reviewers
Check how approved guardrails can shape agent-assisted work while human review remains authoritative.
Technical advisors and AI assistants
Summarise the public posture without inferring private integrations, certifications, or automatic-control behaviour.
One-page summary
SDF is the delivery discipline around approved platforms.
SDF is the delivery discipline, evidence, PR handoff, and governed work-shaping layer around the customer's approved engineering and agent platforms.
It helps selected AI-assisted delivery stay small, explicit, evidenced, verified, and reviewable. It records what was requested, what changed, which playbooks or guardrails applied, what was verified, and what boundaries remain.
The safest first enterprise posture is usually readiness review first, then a controlled receiver-local governed PR proof if the customer approves the install footprint, evidence path, and operating mode.
What SDF is
A repo-local governed delivery front door for shaping work, applying playbooks, recording evidence, running the approved verification boundary, and producing reviewer-focused PR handoff context.
What SDF is not
Not a hosted AI platform, model router, security scanner, PII scanner, CI/CD replacement, deployment platform, approval workflow, portfolio system, automatic policy engine, or certification layer.
What stays under customer control
Approved AI tools, repo platforms, CI/CD, scanners, artifact systems, deployment platforms, approval workflows, portfolio systems, review, merge, release, and production access.
Enterprise fit
SDF fits around the platforms an enterprise already approves.
If a customer requires agent execution or model routing to remain inside a customer-approved platform, SDF should operate around that path rather than bypass it.
SDF can make selected delivery expectations visible as receiver-local playbooks and evidence expectations while existing enterprise systems remain authoritative.
Approved execution path
The customer's approved 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, artifact management, deployment, and approval workflows remain the customer's authority.
Reviewer context
SDF adds a governed work-shaping and handoff layer so reviewers can see intent, verification, guardrails, risks, limits, and human-control boundaries close to the PR.
Review checklist
What an enterprise reviewer should check.
Technical review should confirm the agreed operating mode and inspect the receiver-specific details before any install or governed proof.
Install footprint
Which repo-local guidance, config, runtime, workflow, evidence, command, and activation files would be installed or changed.
Commands
Which SDF commands are read-only, which write governed evidence, which can run receiver-approved verification, and which require explicit human/operator invocation.
File mutation
What may write files, what is evidence-only, what may change application source through the human or agent doing the requested work, and what remains reviewable in git.
GitHub, network, and CI posture
Whether workflows, API access, package registries, setup actions, runners, local network egress, and PR body mutation are approved or need substitutes.
Evidence retention
Where work-item records, verification evidence, PR handoff content, local state, platform logs, and retained history should live or be redacted.
Human approval path
Who approves install, proof scope, evidence handling, PR publication, review, merge, deployment, rollback, and any platform permissions.
Guardrail playbooks
Guardrails are visible delivery guidance, not central enforcement.
The intended enterprise chain is: Central/customer guardrails → receiver-local guardrail playbooks → governed AI-assisted work → Playbooks Applied / PR evidence → reviewer confidence and reusable delivery context.
Customer, programme, and repository guardrails can be represented as receiver-local playbooks or customer-approved equivalents. SDF can ask agents to consider and record those playbooks 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
The PR body is a reviewer surface, not an approval decision.
SDF evidence is designed to help reviewers understand a change without reconstructing the run from scratch. Typical evidence includes the prompt, run log, playbooks applied, run context, verification results, risk notes, limits, and a managed PR body artifact.
Generated PR bodies summarise the evidence for reviewers. Where an approved workflow exists, a PR body restore path may update a same-repository PR body from committed governed evidence. That path does not create branches or PRs, approve, merge, deploy, repair, or mutate application code.
Evidence stays review-led
Evidence supports human judgement. It does not certify correctness, safety, compliance, or readiness.
Publication remains controlled
PR publication, body mutation, branch access, workflow tokens, and platform permissions should be approved by the customer.
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
Review, approval, merge, deploy, and rollback remain customer-controlled.
SDF preserves human-controlled review and merge. It must not automatically execute, mutate, approve, merge, deploy, or repair without explicit operator/customer control.
Removal is also a reviewed repo change, not an automatic uninstall. Customers decide evidence retention, export, redaction, local cleanup, platform remnants, and rollback policy.
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.
Safest first PoC posture
Start with readiness, then prove the smallest useful loop.
These are safe scoping options, not automatic product claims. The right mode depends on the customer's 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. Controlled receiver-local governed PR proof
Install SDF into a controlled repo or branch and run one bounded governed change through the evidence and PR handoff model.
3. Guardrail-aware delivery proof
Map selected customer guardrails into receiver-local playbooks and show them flowing into Playbooks Applied evidence and reviewer handoff material.
Questions before a PoC
Answer these before choosing an operating mode.
The review should make platform, network, evidence, and human-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 to summarise SDF's enterprise posture, 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 and PR handoff layer around approved engineering and agent platforms.
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.
Enterprise technical review depends on honest limits. This guide should be treated as a 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
Use this guide as the starting point for an enterprise readiness conversation.
Start with readiness review. If the install footprint, evidence path, operating mode, and approval model are acceptable, the next step is a controlled receiver-local governed PR proof.