I20 · Evidence and control · 6 min read
AI SDLC in practice: what a failed check and a repair prove
A historical Java demonstration records a cross-tenant test failure followed by an implementation repair under unchanged checks. Reading both attempts reveals more than the final green result.
By AISDLC Editorial · Published 2026-10-03 · Reviewed 2026-10-03
A repaired candidate passes its tests. Did the implementation improve, or did the conditions for acceptance move? That is the engineering question behind a useful failure-and-repair record. A final success badge cannot answer it alone. The record needs to connect the rejected candidate, the check that exposed its defect, the changed implementation, and the checks run again.
The published Java gate summary gives us a small historical case to examine. Recorded on 6 September 2026, it concerns a synthetic Java 21 eligibility policy and uses no customer data. This article interprets that existing record; it does not report a new experiment or a customer implementation.
Read the failed attempt alongside the repair
| Attempt | Candidate commit | Actions run | Recorded result |
|---|---|---|---|
| 1 · Defective | f98773904b2bdedea87fc138a55ceda9aa5ab8e0 | 34075238511 | 9 tests; 1 failure in a cross-tenant test. ArchUnit checks passed. |
| 2 · Repaired | 96d725bb7621874f5301175855958f55c3c0a884 | 34075373975 | 9 tests; 0 failures, 0 errors, 0 skips. |
The material limitation is timing: branch protections were enabled after both demonstration runs. The record therefore does not prove an enforced merge rejection at the time, independent human approval, full AISDLC-CQ conformance, or production customer results. Supporting source, logs, and artifacts are held in a private repository for authorized review; this public summary is not a publicly reproducible source-and-test package.
The first run is useful evidence because different checks answer different questions. Passing architecture checks did not erase the cross-tenant test failure. The second run is useful because the reported comparison keeps the repair from being explained by a changed test suite, build configuration, or workflow. The supported conclusion is bounded to those checks and that seeded defect. It does not describe every property of the eligibility policy.
Map the observation to a per-change record
The AISDLC-CQ per-change evidence kit organizes candidate identity, gate results, repair lineage, and release disposition. Applied here, it is a way to see both the useful observations and the missing fields. It does not fill those gaps automatically.
What the public record establishes for each field
- Candidate identity
- Both full commit identifiers are published, each paired with an Actions run. The public summary does not supply a complete environment manifest or released artifact digest.
- Failed gate
- The first attempt records one cross-tenant test failure out of nine tests. The failed assertion text and retained report digest are not established by this public record; authorized reviewers can inspect the supporting material.
- Repair identity
- The repaired commit and an implementation-only change are recorded. The summary reports unchanged test, POM, and workflow comparisons. The exact repair instruction and who received it are not established by this public record.
- Rerun
- The second run records nine tests with no failures, errors, or skips. A complete matrix of every AISDLC-CQ gate, its thresholds, and independently retained report digests is not established by this public record.
- Disposition
- A passing repaired run is recorded. An artifact-bound production approval, named independent approver, and deployment decision are not established by this public record. Subsequently configured branch protection is a separate observation.
This mapping helps a reviewer ask a specific next question. For example, the unchanged-check comparison addresses whether acceptance conditions moved during the repair. It does not establish who could edit those conditions. A run identifier helps locate evidence; it is not itself a retained report or proof of the producer’s independence. Record the distinction when deciding what additional evidence is needed.
Exercise one refusal path in your own workflow
The following exercise is a proposal for a permitted test environment, not work executed for this article. Keep it small enough that a reviewer can follow the entire sequence. Choose an accepted requirement whose failure matters, such as a tenant boundary in a synthetic application. Agree the expected result and the person responsible for interpreting it before introducing a defect.
A failure-and-repair exercise
- Identify the candidate and acceptance condition. Record its commit or artifact digest, the test, the workflow revision, and the intended rejection. Use synthetic data and an environment in which the exercise is authorized.
- Run a deliberately defective candidate. Preserve the unsuccessful result and the actual failure output under the organization’s evidence policy. Confirm which check failed; do not infer refusal from a model’s critique.
- Repair the implementation without weakening the checks. Compare test and policy revisions. If an acceptance condition genuinely needs to change, route that decision separately and explain why.
- Rerun the required checks on the repaired candidate. Link each result to that exact version, retain the reports, and account for absent, skipped, or inaccessible evidence.
- Record the disposition and its authority. Explain whether the exact candidate is held, rejected, or approved within a stated scope, and identify any remaining obligation or release condition.
For the broader design pattern, read An AI SDLC release gate must prove what it accepted. The AI SDLC category guide places verification in the wider lifecycle. LockedIn Labs publishes AISDLC and offers AI implementation services; that publisher relationship is disclosed here, and the historical demonstration remains distinct from any service outcome.
Primary sources
AISDLC Insights publishes source-informed editorial synthesis and implementation positions. It is reference material, not a standard, certification, legal opinion, or authorization to deploy an agent.