Release Accountability for AI-Assisted Code Changes

Choose release evidence for AI-assisted changes: independent expectations, constrained execution, artifact identity, approval validity and state recovery.

audience="Teams using coding assistants to change live applications, background jobs, dependencies or release workflows." decision="Choose which evidence permits an identified change to cross the production boundary, and which revisions require renewed review." position="Accept observable behavior and a bound release artifact, not authorship or tool confidence. Keep proposal execution away from production authority and define recovery for retained state before release." scope="A proposed engineering policy with synthetic tenants and inert export adapters, not a measured model comparison, customer incident or deployment authorization." outputs={['A change-risk contract', 'A proposal execution boundary', 'Independent acceptance fixtures', 'A revision-bound evidence packet', 'A release and recovery decision', 'An invalidation register']} />

Executive summary

An AI-assisted change should be released when the accountable team has enough current evidence for its behavior, execution permissions, dependencies, artifact identity and recovery consequences. The authoring tool's confidence does not provide that evidence. Neither does replacing an AI label with a human author's name. The risk follows what the change can do: read protected records, create persistent state, invoke an external system, alter deployment authority or change a recovery path.

This paper recommends a risk-based evidence policy rather than universal approval by test count. Define the intended behavior and independently expected outcomes first. Run unaccepted proposals in a constrained environment. Bind tests and review to the actual candidate and the conditions under which it was evaluated. Verify that the artifact selected for deployment is the artifact whose identity and origin were accepted. Keep the final decision with a named owner and disclose unresolved limitations.

The proposed example adds asynchronous CSV export to a hypothetical multi-tenant document application. The candidate introduces an endpoint, a worker, a dependency and a persisted download artifact. Synthetic tenants A and B and inert storage and notification adapters support the review. No real personal data, customer incident or model performance result is presented. The architecture is illustrative and does not imply that Ampity or a particular client operates the shown release controls.

The important distinction is between evidence and authority. A model can propose tests, summarize a diff or identify a possible defect. A test can establish a particular observed result under declared conditions. A signed provenance statement can help establish a build relationship. None of these independently decides that the business should release the change. That decision also needs current scope, consequence, operating ownership and a recovery contract. A passing local build is one observation, not a production readiness certificate.

Define the unit of accountability

Accept an identified change, not a conversation with an assistant. The change inventory includes the base revision, candidate revision, dependency lockfile, relevant generated files, schema transitions, build recipe and operating configuration. A pull request that appears to add one button may also introduce a worker identity, a storage retention policy and a new scheduled task. Those are part of the release decision even when the summary or review interface hides them behind collapsed files.

Name the owner who can explain the behavior contract and the reviewer who examines the changed boundary. Roles may be held by the same person in a small team, but independence should not be fictional. A second role title does not establish a second assessment. Document where review is independent, where it is self-review and what additional evidence compensates for the team's constraints. Do not imply that a single engineer must create an entire bureaucracy for a low-consequence wording change.

Separate accountability from blame. The purpose of the record is to make a decision reproducible and support safe recovery, not to identify whose prompt caused an incident. Record useful authoring context under the contribution policy, but avoid retaining confidential prompts merely to demonstrate AI involvement. If attribution, licensing or data-handling questions arise, assign them to the appropriate owner. An engineering review cannot provide legal clearance or establish rights to a third-party snippet simply because it compiles.

For the export example, the accepted unit is not CSV generation in isolation. It is the queued request, selected tenant data, worker execution, stored output, retrieval policy, cancellation behavior and final artifact cleanup. The reviewer should be able to trace that lifecycle using the proposed change and its fixtures. If nobody can identify where the export becomes externally visible, the current evidence is too weak to accept the disclosure boundary, regardless of the quality of the generated implementation.

Classify the change by consequence, not code volume

A useful classification asks which invariants can change and how the team would detect a violation. A small permission helper can affect every tenant. A large generated UI refactor may leave data and deployment authority unchanged while creating accessibility and navigation risk. Lines changed, model choice and author seniority can inform review effort, but none replaces a consequence map. Identify the data, actor, operation, retained state and external effect that the candidate can influence.

For a low-consequence change, focused checks and an accountable review may be enough. For a tenant export, examine admission, worker access, artifact visibility, bounded resource use and interruption. For a schema or release-workflow change, add state compatibility and execution-authority review. Define these classes using the organization's own application and business obligations. The paper does not prescribe a universal numerical risk score or imply that every generated change requires the same approval process.

Write stop conditions before running the candidate. An unexpected production credential, broadened storage access, unknown dependency, altered test gate or destructive migration should stop the current evaluation until its scope is explained. Do not treat these as harmless incidental changes merely because the feature demonstration succeeds. A proposal can be useful while still requiring a revised diff. Preserve unrelated user-owned work and inspect the actual patch rather than resetting a shared checkout to manufacture a clean review surface.

Risk classification should be revisited after the diff changes. A presentation-only request may become a data-access change when the assistant adds an API endpoint to simplify implementation. The original approval for a UI task cannot cover that new boundary. Record the transition, identify the additional reviewer and update required evidence. Review effort should follow the current candidate, not the title of the issue that originally started the task.

Compare release policies and their blind spots

An author-led policy is fast because the person proposing the change also decides whether their demonstration is sufficient. It can work for narrowly scoped, reversible changes when the team consciously accepts that independence limitation. Its weakness is correlated misunderstanding: the implementation, tests and explanation may all encode the same wrong requirement. Do not call a successful author-led exercise independent verification merely because the test framework ran in another process.

A fixed checklist policy improves consistency but can become detached from the actual change. A mandatory unit test, linter and dependency scan may still omit queued-job authorization or retained-state recovery. Checklists are valuable prompts, not universal proof. Keep a mechanism for adding a topic-specific requirement and recording a justified omission. Otherwise, the team may optimize for satisfying the named checks while the most consequential new behavior remains outside the policy.

A risk-based evidence policy starts with the changed contract, then chooses the necessary review and observations. It can require independent fixtures for tenant data, controlled interrupted runs for persistent effects and artifact binding for deployment. Its operating cost is the need for reviewers who can understand boundaries and explain exceptions. The recommended trade-off is to keep common checks automated while adding a small, explicit evidence packet for each material new consequence.

Automation is not excluded from that policy. A team may automate acceptance of a defined low-risk class if the authority, scope and tests are approved independently of the candidate. The system must prove that a change belongs to that class and cannot edit its own eligibility rules. For the export example, automated success is insufficient to grant production authority because access and persisted disclosure boundaries changed. This recommendation does not apply as a blanket prohibition on all automated releases; it limits authority to the evidence actually accepted.

Place proposal execution outside production authority

Treat repository content, issue text, generated commands and downloaded packages as inputs to a proposed execution, not trusted instructions for the release system. An assistant needs enough access to edit and evaluate the scoped code, but it does not automatically need production credentials, customer exports or the ability to merge and deploy. Choose an execution identity and network policy that match the task. Describing an environment as a sandbox does not prove that it lacks consequential permissions.

Build-time execution matters. A candidate can change an installation script, test runner or workflow even when its application code appears harmless. The reviewer should inspect what executes before granting a job credentials or artifact publication rights. GitHub's secure-use reference warns about privileged workflow contexts combined with untrusted code checkout. Apply the relevant event, checkout and permission controls to the repository's actual configuration; a workflow label alone does not enforce separation.

The proposed execution boundary permits code edits, synthetic fixture runs and a candidate artifact. It prohibits production data access, real export notifications, live infrastructure changes and deployment. A separate trusted verification context reads the declared outputs and evaluates their relationship to the intended candidate. It should treat uploaded logs, artifact names and generated approval files as claims until validated. A malicious or mistaken proposal must not gain authority by writing a file that says reviewed.

Review failure handling within the boundary. If a fixture needs a secret or permission that was intentionally withheld, first determine whether the requirement can be tested with an inert adapter or an isolated identity. Do not silently broaden access to make the test green. The honest result may be that a production-dependent property remains unverified. Record the gap and the separately authorized verification needed. Missing evidence is not a reason to erase the boundary that protects the live system.

Read the proposal-to-release trust map

The first visual answers where a candidate can be created and where release authority begins. A declared requirement enters the proposal context. The resulting candidate and observed tests cross into verification as evidence, not authority. An independent expectation contract enters that verification separately. An accountable decision binds a specific artifact to an accepted scope before a separately authorized release operation. The neutral components describe responsibilities rather than named vendor services.

Keep the decision inputs concrete. The requirement identifies the permitted user operation and exclusions. The proposal context identifies the candidate and its restricted permissions. Verification records the test environment, fixture population and unexplained results. The release decision includes exceptions, current artifact identity and the recovery limit. These inputs can be stored in ordinary repository and release records; the diagram does not require a new orchestration platform or a paid review product.

The map omits implementation details that do not establish the boundary, such as which editor or model produces the proposal. Different tools may generate the same candidate, and a human may make the final correction. The release evidence should remain intelligible after that history changes. The diagram also does not assert that a verifier is impossible to compromise. Its code, identities, settings and sources need their own governance, especially when the proposed change can modify the checks on which acceptance relies.

Separate automated feedback from independent expectations

AI review is useful for finding questions, explaining unfamiliar code and suggesting failure cases. It can also miss a defect, describe an imaginary problem or reinforce the author's interpretation. GitHub's Copilot Agents application card describes limitations and supplementary review uses. Do not convert that feedback into a claim that the implementation has been independently observed. An assistant's description of a successful test is weaker evidence than the actual retained result and candidate identity.

Independence concerns the source of the expected result, not whether a different model generated it. For the export fixture, tenant A's permitted rows should be specified from known synthetic data and the accepted policy. If an assistant reads the candidate's output and writes a matching expected file, the resulting green test cannot establish that the intended population is correct. A second assistant can help develop the fixture, but the reviewer must still identify the policy and input evidence behind the expectation.

Challenge the comparator itself. Deliberately introduce a tenant leak, a stale permission decision, an omitted row and a false success state. The suite should reject those candidates under the declared contract. This is a proposed test strategy, not a report of a measured tool benchmark. A test that never demonstrates its intended rejection behavior may be checking the wrong route, using an empty population or mocking away the boundary that matters.

Keep model output outside approval semantics. A generated comment such as safe to merge is a recommendation, not an authorized acceptance record. A repository instruction telling the assistant to approve every small patch should not override the team's protected release policy. The tool may prepare evidence, but the trusted decision mechanism determines whether the scope qualifies. If the organization deliberately delegates a narrow acceptance class, record that authority outside the proposal and test its limits explicitly.

Verify access across admission, execution and retrieval

The export starts with a request, but its disclosure may happen later when a worker reads data or a download endpoint serves a stored artifact. These stages can observe different permission states. Decide whether permission withdrawal prevents queued execution, output publication, retrieval or all three. Use the actual product policy rather than inventing a universal answer. Then create a fixture for a user whose access changes between stages and retain the expected disposition at each boundary.

OWASP's Authorization Cheat Sheet recommends default denial and validating permissions on each request. This supports request-level checks, but the proposed asynchronous lifecycle also needs an explicit worker and artifact policy. An unguessable download token is not automatically sufficient authorization, and a successful login does not establish access to another tenant's export. Verify the application's chosen protections through the public route rather than only testing a helper in isolation.

Bind tenant selection to the authoritative request context and approved worker identity. A client-supplied tenant field should not broaden the worker's query scope merely because the generated code uses a generic repository method. Test cross-tenant identifiers, changed access, expired artifacts and error responses that might expose record existence. Where shared data is intentionally accessible, record that relationship. A simplistic isolation fixture should not silently forbid a legitimate collaboration rule or excuse an unauthorized disclosure.

Keep evidence collection safe. Test fixtures should contain synthetic records and controlled credentials, and debug logs should not retain unnecessary payloads. A test artifact can be a disclosure surface if it includes raw export data and is uploaded to a broadly accessible job. The policy needs an owner for retention, access and deletion of review artifacts. Passing an application authorization check does not establish that the surrounding review environment handles sensitive data properly.

Evaluate dependencies and controls without promising certification

A generated import is not evidence that a package exists, belongs to the expected maintainer or meets the application's requirements. Identify the exact resolved dependency, its source, lockfile change, installation behavior and license question where relevant. Separate package selection from installation reproducibility and security evaluation. A pinned version can still be inappropriate, compromised or unnecessary. The review should explain why the change needs the dependency and what alternative would avoid or reduce that new execution surface.

Use a requirement standard as an organizing tool rather than a certification claim. OWASP's Application Security Verification Standard provides a basis for testing application technical controls and recommends version-qualified requirement identifiers. Select relevant requirements and preserve the version in the evidence packet. This paper does not claim ASVS certification or complete standard coverage. A few selected checks should not be presented as proof that the whole application satisfies every requirement.

Inspect dependency and workflow changes together. A new package may run code during installation, while a workflow change may grant that installation job a token it previously lacked. The resulting risk exists in the combination. Review generated scripts, action references and runner assumptions alongside the application diff. If the proposal edits the trusted verifier or bypass list, require separate scrutiny of the acceptance mechanism; it cannot simply pass its newly weakened rule and certify itself.

Record uncertainty proportionately. A scanner finding, a missing provenance record and an unresolved license question are different issues with different owners. Do not collapse them into a generic security score or claim that the absence of findings proves the absence of vulnerabilities. The useful packet records observed checks, sources, limitations and decisions. It should permit a reviewer to reject the dependency or defer release without having to invent a categorical statement that the entire package ecosystem is unsafe.

Bind evidence to the exact release candidate

The release packet should identify the source revision, accepted configuration, build inputs, artifact digest and observed environment. A successful run against an earlier commit is not evidence for a later worker fix. A rebuild with changed dependency resolution may produce a different artifact even when the displayed source title is unchanged. Prefer explicit identifiers over labels such as latest, approved or staging passed. If a system uses those labels operationally, resolve them to retained identities at the acceptance boundary.

SLSA's artifact verification guidance describes verifying provenance against trusted roots and matching its subject to the artifact digest. This supports a build-origin relationship, not a business behavior guarantee. A genuine artifact can still contain an incorrect tenant query. A correct-looking candidate can be deployed through an untrusted build path. Keep provenance, functional evidence and release authority as separate layers, and disclose which layer remains unverified.

Inspect the repository rules actually in force. GitHub's protected-branch documentation describes required checks, stale-review settings and review of recent pushes. Check sources, bypass permissions and the candidate being evaluated. Required statuses can include non-success dispositions such as skipped or neutral under documented behavior. If the team's contract requires an executed acceptance fixture, a skipped check does not establish that the fixture ran.

Release authorization should expire or be invalidated when its inputs change. An accepted candidate built with a reviewed configuration is not automatically accepted with a broadened worker identity or altered retention period. Conversely, do not rerun every irrelevant check merely to demonstrate activity. Determine the affected evidence deliberately and explain why unaffected observations still apply. A bounded invalidation rule improves both safety and review efficiency by making the relationship between change and required evidence explicit.

Follow evidence invalidation instead of accumulating green badges

The second visual maps changed inputs to the observations they invalidate. Source behavior affects contract fixtures; dependency or build changes affect artifact and execution evidence; policy or schema changes affect authorization and state recovery. Those refreshed observations feed one candidate-bound decision. The map is a dependency relationship, not a promise that a particular CI provider automatically understands those dependencies. The reviewer remains responsible for deciding whether the declared evidence scope is sufficient.

Consider a corrected export filter that changes the candidate after review. The earlier cross-tenant fixture must be rerun against the correction; approval of the old filter cannot cover it. If the correction also changes a worker's storage path, examine cleanup and retrieval behavior rather than rerunning only the failed row-count test. The packet should show which observations were replaced, which were retained and why. Deleting inconvenient earlier failures deprives the next reviewer of useful context.

Configuration drift can invalidate acceptance without a new source commit. A changed permission policy, feature flag, queue route or schema can affect the same artifact's behavior. Record how the release operator verifies the intended target conditions and what happens if they differ. The answer may be a hold, a new isolated check or a narrower accepted scope. It should not be an assumption that the target resembles the test environment because both display the same application version.

Require recovery evidence for retained and external effects

An export job can be accepted locally before its worker publishes a file. A cancellation can race with publication. A timeout can leave the caller unsure whether output already exists. Define intermediate states and the evidence that distinguishes not attempted, pending, completed, cancelled and unknown. Do not retry an unknown external operation under a new identifier merely because the first call returned an error. Where a destination supports readback, preserve the original identity and reconcile its observed state.

Use inert adapters to rehearse failure without exposing real data or sending messages. Interrupt before persistence, after job acceptance, during output publication and after a destination response is lost. Observe whether the candidate preserves ownership of pending work and whether stale workers can publish after a cancellation under the chosen policy. A mocked successful callback cannot prove these properties. State exactly which lifecycle stages the rehearsal exercised and which remain unverified.

Rollback must address state accepted by the candidate. Restoring the previous binary does not remove queued jobs, undo a schema transition, recall a downloaded file or cancel a notification already delivered. For the proposed export, explain whether the old worker can read new job records, whether new artifacts remain protected and whether cleanup ownership transfers. If retained-state compatibility is absent, choose a forward repair or controlled hold rather than calling a binary switch complete recovery.

Keep recovery authority scoped. A reviewer may approve the change while an operator separately owns release and rollback. The assistant can prepare a runbook or evidence summary, but it should not independently delete retained jobs or widen a storage permission to recover a failed rehearsal. An incident requires the organization's established authority and escalation process. This paper provides an engineering decision framework, not authorization to deploy, destroy data or alter production access.

Exercise adversarial fixtures and report coverage honestly

Choose fixtures from the behavior contract before reviewing the candidate's tests. The proposed export must include only tenant A's permitted records, refuse tenant B access, apply the chosen withdrawal rule and retain a truthful disposition after interruption. Add a changed build and a stale approval case to challenge release identity. The example does not prescribe a fixed file size, latency target or review threshold; those should come from the application's actual workload and accepted consequence.

| Synthetic condition | Required disposition | Evidence that decides | | --- | --- | --- | | Export selects another tenant's private rows | Reject the candidate | Independent permitted-row fixture and route-level observation | | Permissions change while a job is queued | Apply the declared execution and retrieval policy | Policy revision, job state and separate boundary checks | | Candidate edits its own acceptance gate | Hold pending trusted-verifier review | Gate diff, authority scope and independently approved rule | | Reviewed commit differs from the deployed artifact | Hold the release | Candidate identity, artifact digest and verified build relationship | | Publication times out after a possible effect | Preserve unknown; reconcile the original operation | Original operation identity and supported destination evidence |

Keep the intended fixture population in the denominator, including cases not run or left inconclusive. A missing observation is not a pass. When the denominator is zero, no acceptance rate exists. Report negative-path coverage separately from a successful feature demonstration, and distinguish local fixture evidence from live integration evidence. A high test count can coexist with an untested write boundary. The decision should name the behavior actually observed, not imply that arbitrary volume creates assurance.

Measure review effort as well as authoring speed. Include the time spent understanding the diff, correcting tests, evaluating dependencies, resolving unknowns and rehearsing recovery. Faster code generation may help delivery while shifting more work into review. This paper offers no measured productivity claim or model ranking. A useful team experiment compares accepted changes and escaped defects under declared conditions, rather than counting generated lines or assuming every assistant-produced test saved equivalent human work.

Acceptance checklist and the next useful artifact

Use this acceptance checklist: can the owner state the changed behavior and exclusions; are base, candidate and artifact identities retained; are expected outcomes independently grounded; does proposal execution lack unintended production authority; and are access, dependency and workflow consequences accounted for? Check the public request, asynchronous worker and retrieval boundaries separately. Retain failed, skipped and inconclusive observations with their dispositions. A report that hides those categories is not ready to support an accountable decision.

Then ask whether the current evidence remains applicable. Has the source, lockfile, build recipe, target configuration, permission policy or schema changed since review? Are the selected artifact's origin and identity verified? Can recovery preserve or safely hold new state and uncertain effects? Name each exception and its owner. If the release depends on a property that was not tested, record the gap rather than allowing a generic approval label to conceal it.

The next useful artifact is one revision-bound release packet for a narrow changed lifecycle. For the export example, include the accepted population, candidate diff, independent fixtures, observed negative paths, artifact identity, invalidation conditions and recovery boundary. A reviewer should be able to understand why the candidate is accepted or held without reading an entire assistant conversation. Expand automation only after that packet and its rejection behavior are reproducible under the chosen controls.

For an owned procedure, use the AI-generated code acceptance playbook. For a shorter discussion of independent expectations, read code review behavior evidence. Ampity's backend systems and APIs service and technology stack evaluation service provide relevant routes for discussing the changed system and accepted scope. Reading and PDF download require no contact details. An optional enquiry starts a conversation; it does not authorize a repository change or production release.