The Lifecycle Evidence Boundary
Governing AI-Assisted Delivery Through Alchemy SDLC™
BLUF: AI-assisted delivery needs an approved record that remains usable after the original prompt and conversation are gone. The lifecycle evidence boundary identifies which evidence may govern the work, who approved it, and how it remains traceable through delivery and sustainment.
Where Fluent but Fragile Leaves Off
Fluent but Fragile argued that AI-assisted work should stay connected to inspectable sources and to someone who can defend the final product (Preyna, 2026). That standard is achievable for a paper, a briefing, or a requirements package. Software delivery is harder because work moves through more hands over more time. As an effort progresses from design through code, testing, release, and sustainment, teams often stop carrying forward the source or decision that authorized a requirement. The loss tends to be quiet (Preyna, 2026). Delivery artifacts keep moving while the source authority, SME clarification, or approved exception that shaped them drops out of the record.
Software engineering research has treated this as a traceability problem for decades. Ramesh and Jarke (2001) defined traceability as the ability to connect requirements with their sources, stakeholders, rationale, and subsequent changes. Cleland-Huang et al. (2014) found that traceability links are still typically assembled after the fact, which reduces the value they could provide while development is actually underway. Generative AI increases the volume and pace of artifact production without resolving that underlying problem.
How Evidence Is Lost During Handoffs
When teams rely on AI to speed up software development, they often keep the final result but lose the context behind why it was built that way. For instance, a feature requirement might reach a developer without the expert notes or original document explaining how to handle edge cases. In the same way, a software test might prove the code runs without actually checking if it does what it was supposed to do (Figure 1 shows where this disconnect happens).
In software engineering, research on "traceability" shows that keeping track of how requirements, expert decisions, code, and testing connect is just as important as the code itself. Holding on to these connections keeps everything consistent, makes it easier to see how changes will affect the project, and saves time during future updates (Winkler & von Pilgrim, 2010; Cleland-Huang et al., 2014). AI lets people spit out code and documentation way faster, but if you don't save the reasoning behind those choices, it creates hidden technical debt and bigger headaches down the road (Sculley et al., 2015).
Figure 1. Artifacts may survive delivery while the evidence that authorized them becomes harder to recover.
Defining the Lifecycle Evidence Boundary
This paper uses lifecycle evidence boundary as an operating term drawn from research on requirements traceability and AI documentation (Gebru et al., 2021; Mitchell et al., 2019). The literature does not use the term. Here, it means the approved evidence that governs work at a particular point in Alchemy SDLC™.
A traceability matrix connects different parts of a project, while a configuration baseline marks which versions are officially approved. To keep track of authority across a project's lifecycle, teams also need to record who actually approved each piece of work. Older versions can still be saved for background info, but they don't get to dictate how current work gets done.
Just because you can look at a document doesn't mean it holds authority. For example, an old spec sheet might explain why a system was built a certain way in the past, but it doesn't govern today's requirements. The same goes for AI: an AI-generated summary might help a reviewer spot an issue, but it shouldn't be treated as the official, ultimate source of truth.
Before an artifact enters the lifecycle boundary, an authorized owner decides whether it may govern the work. Figure 2 distinguishes approved evidence from material that remains provisional or provides context only. Rejected material stays outside the baseline, although the decision record may retain the rejection and its rationale.
Maintaining the Boundary in Alchemy SDLC™
Alchemy SDLC™ keeps the evidence boundary within the delivery record. Alchemist AI Pro™ links approved sources and stakeholder clarifications to the requirements and acceptance criteria they support. Designated reviewers control what enters the approved baseline.
Each stage begins with the approved baseline from the preceding stage. Development changes remain linked to the requirement they implement, and verification remains linked to the accepted behavior. When the team discovers a missing rule or unresolved assumption, the issue returns to the authorized owner before the baseline changes. Generated material remains provisional until a reviewer links it to approved evidence and accepts it into the baseline. Each artifact admitted to the boundary should retain its source, version, owner, evidence status, approval date, downstream links, and any unresolved conflict or accepted deviation. The status markers show where each artifact stands within the lifecycle evidence boundary. An item may remain available to the team as candidate, superseded, or context-only material, while only reviewed and approved evidence is allowed to govern the baseline. Figure 2 shows how the baseline and decision authority move through Alchemy SDLC™.
Figure 2. Approved evidence, human authority, and traceability move forward together as delivery artifacts change.
Changes in Review and Sustainment
During review, the team can examine the source and reasoning behind a requirement without reconstructing earlier meetings or prompt histories. Evidence awaiting a decision stays visible until an authorized reviewer approves or rejects it. The proposed pilot should examine whether that early visibility reduces rework later in delivery.
When a requirement changes, traceability identifies which other artifacts may also need review (Winkler & von Pilgrim, 2010; Tian et al., 2021). Sustainment teams receive the approved baseline along with its rationale, so they continue to exercise judgment from a documented record rather than scattered notes.
Federal guidance assigns this responsibility to people. OMB Memorandum M-25-21 requires agencies to govern AI use and designate officials accountable for oversight and specified risk decisions (OMB, 2025). The Department of Defense applies its responsible AI principles across the system lifecycle (U.S. Department of Defense, 2022). The evidence boundary gives program teams a record of who exercised that responsibility when approving a requirement, a test result, or a risk decision.
Testing It on One Change
A 30-day pilot can test whether the boundary improves traceability across one change request. Select an item that will pass through requirements, development, and verification and includes at least one source conflict or local exception. A demonstration built around a clean, self-contained requirement will prove very little.
Table 1. Required Evidence and Decision Authority for the 30-Day Pilot
| Stage |
Required record |
Decision authority |
| Intake |
Approved sources, versions, exclusions, and unresolved conflicts |
Mission owner |
| Requirements |
Requirement, specific source location or recorded SME decision, and acceptance criteria |
Requirements owner / SME |
| Implementation |
Linked change, deviations, and AI-generated assumptions awaiting resolution |
Technical reviewer |
| Verification and release |
Test evidence, approver, and remaining risk |
Acceptance and release authorities |
At the end of the pilot, ask someone outside the original workstream to reconstruct why the change was made and how the team proved it. Record how long reconstruction takes and where the reviewer loses the evidence chain. Also track any correction caused by a missing, conflicting, or superseded source.
The pilot's main output should be a delivery record that a reviewer outside the original workstream can use to identify the source, requirement, implementation change, test evidence, and approval decision. The pilot succeeds if the outside reviewer can reconstruct the full evidence chain without relying on the original prompt history or undocumented explanations from the delivery team.
Getting Started with ACC3 International
ACC3 International recommends a focused demonstration with your team or designated staff representatives. Please contact ACC3 International to schedule a demonstration of Alchemist AI Pro™ and assess how the lifecycle evidence boundary can strengthen traceability across your own AI-assisted delivery.
References
Campbell, J. (2026). The Alchemy SDLC [Unpublished internal presentation]. AI Pro Holdings, Inc.
Cleland-Huang, J., Gotel, O. C. Z., Hayes, J. H., Mäder, P., & Zisman, A. (2014). Software traceability: Trends and future directions. In Proceedings of the Future of Software Engineering (pp. 55–69). Association for Computing Machinery. https://doi.org/10.1145/2593882.2593891
Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé, H., III, & Crawford, K. (2021). Datasheets for datasets. Communications of the ACM, 64(12), 86–92. https://doi.org/10.1145/3458723
Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D., & Gebru, T. (2019). Model cards for model reporting. In Proceedings of the Conference on Fairness, Accountability, and Transparency (pp. 220–229). Association for Computing Machinery. https://doi.org/10.1145/3287560.3287596
Office of Management and Budget. (2025). Accelerating federal use of AI through innovation, governance, and public trust (Memorandum M-25-21). Executive Office of the President. https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf
Preyna, D. (2026, July 19). Fluent but fragile. ACC3 International. https://acc3int.com/whitepapers/fluent-but-fragile
Ramesh, B., & Jarke, M. (2001). Toward reference models for requirements traceability. IEEE Transactions on Software Engineering, 27(1), 58–93. https://doi.org/10.1109/32.895989
Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems 28 (pp. 2503–2511). Curran Associates, Inc. https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf
Tian, F., Wang, T., Liang, P., Wang, C., Khan, A. A., & Babar, M. A. (2021). The impact of traceability on software maintenance and evolution: A mapping study. Journal of Software: Evolution and Process, 33(10), e2374. https://doi.org/10.1002/smr.2374
U.S. Department of Defense. (2022). Responsible artificial intelligence strategy and implementation pathway. https://media.defense.gov/2022/Jun/22/2003022604/-1/-1/0/Department-of-Defense-Responsible-Artificial-Intelligence-Strategy-and-Implementation-Pathway.PDF
Winkler, S., & von Pilgrim, J. (2010). A survey of traceability in requirements engineering and model-driven development. Software & Systems Modeling, 9(4), 529–565. https://doi.org/10.1007/s10270-009-0145-0
