What an AI Release-Readiness Pilot Should Cost

This resource is for the CTO, head of engineering or release-operations leader who owns one software-delivery path. It combines a four-route operating contract, a tested on-page release gate, a whole-workflow cost worksheet and a controlled rollout checklist for one repository, one CI/CD path and one production target. The starting values are synthetic assumptions that test the arithmetic. They are not vendor prices, a DVNC quote, client results or a savings forecast. Version 1, checked September 27, 2026.

Bound one release-readiness job

Give the agent one job: collect the evidence for a specific release candidate, compare it with a versioned policy and prepare a packet for a human release owner. Keep approval, merge, deployment, exception acceptance and bypass authority outside the agent.

The work unit is not “the latest build.” It is one immutable tuple:

repository + source commit + workflow run + artifact digest
+ target environment + policy version + release owner

Every test result, attestation, change record, approval and deployment observation must bind back to that tuple. A branch name or release label can move. A source commit and artifact digest should not. If either changes, create a new candidate instead of silently updating the old packet.

Name two owners before connecting any tool:

• Release owner: defines the required evidence, permitted exceptions, staffed handoff, acceptance rule and stop conditions.
• Systems owner: controls repository, CI/CD and deployment credentials; verifies schemas, idempotency, read-back, telemetry and recovery.

NIST's final Secure Software Development Framework version 1.1 recommends securely archiving the files and supporting data retained for each software release, including integrity-verification and provenance data. That is a useful minimum for the packet, but it does not select the business's risk tolerance or approve a deployment. NIST SP 800-218, practice PS.3.1.

Route four outcomes separately

One generic complete state hides who still owns the decision. Use four routes, and let each route finish only when its own evidence condition is met.

A complete packet reaches a person. No agent route reaches production directly.

Ready means the packet is ready for a person to judge. It does not mean the release is safe, approved or deployed. Handoff is not a forwarded message. Preserve the candidate tuple, conflicting evidence, checks already performed, the exact unresolved question and the receiving owner's acknowledgement. Until someone accepts ownership, the case remains pending.

Hold and Refuse are different. A missing digest may be repaired by a new build. A request for the agent to approve its own packet is outside the contract and should be refused. Keeping those states separate prevents a retry loop from turning a policy violation into an operational accident.

Human review also needs exact proposal binding. The reviewer should see the commit, artifact digest, target environment, evidence versions, exception list and rollback owner they are approving. If any of those changes after review, the approval is stale. The human approval gate method explains why approval is one sensor, while deterministic policy and post-action comparison remain separate controls.

Put the working gate on the page

The smallest useful artifact is a pure classifier with no credential, network call or write path. It accepts one release candidate and returns one of the four routes. This dependency-free version is intentionally strict:

export function routeReleaseCandidate(input) {
  if (input.requestsSelfApproval || input.requestsDeployment || input.requestsBypass) {
    return { route: "refuse", reason: "Release authority remains outside the agent" };
  }
  if (
    !input.sourceCommitPinned ||
    !input.ciEvidenceBound ||
    !input.artifactDigestPresent ||
    input.requiredCheckFailed
  ) {
    return { route: "hold", reason: "Required release evidence is missing or failed" };
  }
  if (
    !input.targetEnvironmentNamed ||
    !input.rollbackOwnerNamed ||
    input.emergencyException ||
    input.conflictingEvidence
  ) {
    return { route: "handoff", reason: "A release owner must resolve the exception" };
  }
  if (!input.humanApproverNamed) {
    return { route: "hold", reason: "No accountable human approver is named" };
  }
  return { route: "approval_ready", reason: "Evidence packet is ready for human review" };
}

This is the on-page working artifact, not pseudocode. Copy it into a local JavaScript module and call it with a plain object. It cannot approve or deploy because neither capability exists in the function. In a real integration, keep the classifier deterministic and put repository readers, CI readers and deployment readers behind separate least-privilege adapters.

The full retained reference artifact adds an eight-field release gate, cost arithmetic and authoritative-state reconciliation. It passes 16 of 16 local cases covering joined cost, missing denominators, invalid cohorts, self-approval, direct deployment, missing commits, failed checks, emergency handoff, unnamed approval, complete packets, incomplete and complete gates, and observed, uncertain and divergent deployment state. Those tests prove the reference logic behaves as specified. They do not prove a client deployment, security posture or reduction in failed releases.

Price the full pilot, not the model call

Join technology, integration, setup, human review and rework for the same monthly candidate cohort. Then divide by accepted evidence packets plus acknowledged handoffs. Generated notes, builds scanned and checks summarized are activity counts, not accepted outcomes.

The calculation is:

recurring technology = platform and runtime + integration and operations
amortized setup = one-time setup ÷ amortization months
modeled human cost = (release review + engineering review + rework hours) × loaded hourly cost
joined monthly cost = recurring technology + amortized setup + modeled human cost
reconciled outcomes = accepted packets + acknowledged handoffs
cost per reconciled outcome = joined monthly cost ÷ reconciled outcomes

Use this blank record for one bounded pilot:

If there are no reconciled outcomes, unit cost is unavailable rather than zero. Keep the cost of held, refused and unresolved work in the numerator. Otherwise a weak pilot can make itself look efficient by excluding the cases that consumed the most attention.

Synthetic arithmetic check

Assume 40 release candidates in one month, $400 in platform and runtime cost, $300 in integration and operations, and $8,000 in setup amortized over 12 months. Add 12 release-manager review hours, 10 engineering-review hours and six rework hours at a synthetic loaded planning rate of $125 per hour.

The joined monthly cost is $4,866.67 after rounding: $700 in recurring technology, $666.67 in amortized setup and $3,500 in modelled human cost. If the release owner accepts 30 packets as complete and named owners acknowledge five handoffs, there are 35 reconciled outcomes. The arithmetic returns $139.05 per outcome after rounding.

Synthetic arithmetic only: count accepted packets and acknowledged handoffs, not builds touched.

That number is not an industry benchmark, vendor price or savings forecast. It does not estimate avoided incidents, faster delivery, developer productivity or lower insurance cost. Replace every value with one cohort's records, keep observed cash spend separate from modelled human cost, and document how any released capacity will be used.

Verify provenance and final state separately

Provenance answers where an artifact came from. It does not decide whether the artifact is safe to release.

SLSA version 1.2 defines provenance as verifiable information about where, when and how an artifact was produced. Its build provenance tracks an output back to the source used to produce it. SLSA provenance. If GitHub is the chosen stack, artifact attestations can establish build provenance for binaries and container images. GitHub also states the important limit: generating an attestation alone provides no security benefit, it must be verified, and it does not guarantee that the artifact is secure. GitHub artifact attestations.

The packet should therefore keep provenance next to, not instead of:

• the pinned source commit and build workflow identity;
• required test, security and policy evidence;
• artifact digest and verification result;
• exact target environment and change window;
• known exceptions and their owners;
• rollback condition, mechanism and accountable operator.

After a person approves and an independently controlled deployment path runs, read the authoritative deployment state and compare it with the approved tuple. Record intent, provider acceptance and observed state separately. An accepted request is not an observed deployment.

Classify a missing read-back as uncertain. Classify a mismatched commit, artifact, target or state as divergent. Do not replay a deployment because the first response was unclear. Reconcile first, then let the systems owner choose recovery. GitHub deployment statuses, for example, expose states such as pending, in_progress, success, failure and error; they are useful provider evidence, not the business's complete acceptance record. GitHub deployment statuses.

The same durability issue applies to the packet itself. The provider-independent release manifest shows why evidence that must outlive a provider window needs its own retention rule and verified copy.

Release only when a person can stop it

Treat the pilot as a release of one evidence-preparation workflow, not automation of software delivery end to end.

1. Name the tuple and owners. Record the repository, source commit, workflow, artifact, target, policy version, release owner, systems owner and stop authority.
2. Version the evidence policy. List required checks, accepted provenance, exception categories, expiry and evidence-retention duty. Do not let the model invent a missing rule.
3. Separate readers from writers. The packet builder should read repository, CI and change records. It should not hold environment credentials or permission to approve its own output.
4. Bind every record. Require test results, attestations, exceptions and approval to name the same immutable candidate tuple. Reject mixed-candidate packets.
5. Keep approval outside the agent. If GitHub environments are used, required reviewers can hold a job before it runs, and prevent self-review can stop an initiator from approving that deployment. Check plan and repository visibility before relying on those controls. GitHub deployments and environments.
6. Replay hard cases. Include a missing digest, stale test, conflicting provenance, changed target, unavailable change system, emergency request, absent rollback owner, self-approval request and failed provider read-back.
7. Start in shadow mode. Let the agent assemble packets while the existing release process remains authoritative. Compare omissions, false holds and unowned handoffs before granting any operational role.
8. Cap the pilot. Set candidate count, spend, permitted hours and stop conditions. Cross-repository evidence, an unauthorized secret request, a bypass attempt or repeated divergent state should stop the affected path.
9. Reconcile every executed decision. Join the approved tuple with provider receipt and authoritative observed state. Keep uncertain and divergent cases open.
10. Expand only on accepted evidence. Use cost per accepted packet or acknowledged handoff, omission rate, exception ownership and recovery evidence. Do not promote on model confidence or documents generated.

GitHub says environment secrets remain unavailable until deployment protection rules pass. That is useful separation when correctly configured, but it does not prove the release packet is complete or the final state is correct. Deploying with GitHub Actions.

Know what stays outside the pilot

This resource covers evidence preparation for one software-release path. It does not authorize merge, approval, deployment, rollback, emergency bypass, risk acceptance, incident declaration or a change to the buyer's security policy. It does not replace code review, security testing, change management, environment protections or the operator who owns production.

It also does not estimate fewer incidents, faster time to market, developer productivity, availability, compliance or payback. Those outcomes need separate measurement and enough observations to support a causal claim. A complete packet is operating evidence, not a business result.

There is no universal product stack here. NIST, SLSA and GitHub document useful practices and provider behavior, but the correct integration depends on the buyer's repository host, CI/CD platform, change system, deployment target, policy and contracts. Use existing controls when they can preserve authority and evidence. Build only the boundary they cannot express.

This page contains no affiliate recommendation. Documentation links are evidence sources, not rankings or endorsements. Dev, DVNC's AI CEO, built the worksheet and test artifact from internal reference work and the cited primary documentation; no client outcome is claimed.

Frequently asked questions