Governance First
Controlling the Path from AI-Assisted Requirements to Production Code
BLUF: ACC3's internal work points to the need for a governed delivery path once an Alchemist AI Pro™ package has been reviewed. In one Alchemy SDLC™ effort, feature-level links remained intact throughout delivery. A separate human-led project kept no comparable record. The projects were not conducted under controlled conditions, so the difference cannot support a valid performance comparison. It does, however, offer a useful process observation. Alchemy SDLC™ gives teams a stronger record when they need to explain what was built, why it changed, and how the work was verified.
Kiro can keep project requirements, design files, task lists, and steering materials loaded in as background context before and while it generates code (Kiro, 2026a; Kiro, 2026b). That context shapes the project right from the start. Once the team picks its starting materials, sets the scope, and decides what success looks like, those choices carry over into everything built afterward. Unfortunately, any misunderstood or completely missing requirements carry over right along with them.
Evidence note: These ACC3 examples are based on Patrick Grau's direct account and an internal case study. The projects were done separately and weren't set up as an official, side-by-side experiment, so they're presented here just as real-world process observations. It's also worth noting that ACC3 didn't independently audit every single requirement, piece of code, test result, or user-approval record behind them.
The National Institute of Standards and Technology (NIST) treats governance as a function that cuts across the entire AI risk-management process. In AI-assisted software delivery, that principle applies to the material provided to the system as well as the artifacts produced from it. Office of Management and Budget Memorandum M-25-21 reinforces the expectation requiring agencies to assign accountable AI governance roles and use risk-management practices suited to the anticipated risk of the intended use (NIST, 2023; OMB, 2025).
NIST's Secure Software Development Framework recommends integrating secure-development practices into each SDLC implementation (Souppaya et al., 2022). AI-assisted coding adds a related control. The organization must decide what the development system may treat as authoritative.
Not all project inputs carry the same weight. A current requirement can easily end up sitting right next to an outdated policy, and random, unverified assumptions can slip into the workspace looking just like real rules. On top of that, testing criteria might cover basic day-to-day functions while completely missing critical exceptions. Once those materials get imported into a project, they end up driving how the code gets built, whether they were actually valid or not. That's why the handoff from requirements to code needs strict rules to prove which inputs were actually checked, approved, and authorized to guide development.
Alchemist AI Pro™ works with subject-matter experts and available source material, including documents and existing code, to produce versioned development artifacts. ACC3's internal account describes a package containing requirements, use cases, specifications, and test material. The package can be delivered as readable documents, structured files for requirements platforms, or steering material for an AI development environment (Grau, 2026).
Figure 1 shows how source material gets turned into an approved package and then becomes part of the final project record. That package can guide either a human developer or an AI coding tool, carrying approved plans all the way through coding, testing, release, and long-term maintenance.
Figure 1. The governed steps for turning raw source material into a traceable project record. Source: Author's summary based on Grau (2026) and Kiro (2026a, 2026b).
Packaging matters because coding systems need instructions in a format they can work with. Kiro's spec workflow breaks things down into separate requirements, design plans, and actionable coding tasks. At the same time, its steering files supply ongoing background context that keeps guiding the generated code as the project moves forward (Kiro, 2026a; Kiro, 2026b).
Why the Delivery Path Matters
The comparison focused on what happened to the approved record once implementation began and whether the delivery approach preserved traceability.
The human team received the Alchemist materials, condensed them, and made its own decisions while building the short-term rental application. The finished product included ideas introduced during development, but the delivery record no longer preserved feature-level links to the approved requirements, use cases, and test scripts. In the separate Alchemy SDLC™ effort, those links remained in place. Implemented features stayed connected to the artifacts that authorized them, and the same identifiers carried forward into testing and user acceptance (Grau, 2026).
Figure 2 shows the two workflows ACC3 used to examine what happened to the approved record after development began.
Figure 2. Alchemist AI Pro™ provided both development paths with a reviewed starting package. In the Alchemy SDLC™ effort, feature-level links remained intact from the approved artifacts through implementation and review. The human-led effort did not preserve a comparable delivery record.
The two paths were selected deliberately, although they were carried out in separate projects. ACC3 used one effort to observe how a human team worked from an Alchemist package and another to see what happened when the same class of artifacts moved through Alchemy SDLC™. The comparison looks at whether the approved record remained traceable once implementation began. It was not intended to measure human performance against AI (Grau, 2026).
What the AlchemyProCRM Effort Demonstrated
ACC3 used their full AI-assisted workflow to build AlchemyProCRM, an internal app for managing clients, contacts, and marketing campaigns. The team imported the entire set of Alchemist materials into a local Kiro workspace, added the needed spec sheets and task files, and supervised the project all the way through user testing. Whenever the starting plans were vague, team members cleared up the confusion and logged their decisions. In the end, the app went through four full iterations of the Alchemy SDLC™ process before it was finished (Grau, 2026).
The first user-acceptance cycle identified requirements gaps, including operational capabilities that had not been documented. Figure 3 traces the missing-login example from the requirement record into the generated application.
Figure 3. The missing-login finding from the initial AlchemyProCRM user-acceptance cycle. Source: Grau (2026).
The reviewed requirement set did not include login, and the initial application did not provide that capability.
This internal ACC3 case is a process observation drawn from separate projects. It indicates that a development package does not preserve its own traceability. The delivery approach, its tools, and the discipline used to maintain the record influence whether requirements, implementation decisions, and test evidence remain connected as the work changes.
What the ACC3 Experience Shows
Looking at both efforts together shows just how fast solid requirements can lose their paper trail once coding actually starts. Since these two projects were run completely separately, they can't really be used to compare AI coding directly against human coding. Human developers naturally interpret, condense, tweak, and add onto the materials they get. In the exact same way, AI tools make their own implementation choices based on whatever context they happen to have in front of them.
Keeping a full project record gives reviewers a clear way to trace any feature back to the requirement that approved it, see how it was tested, and follow any changes made along the way. Without those connections, a team might still end up delivering working software, but they won't have much proof showing how the finished system actually connects back to what was originally approved.
The governance concern is whether judgments made during implementation remain visible and reviewable after the build. ACC3 uses Alchemy SDLC™ to preserve that record across human and AI-assisted work.
Alchemy SDLC™ as a Governance Record
ACC3 describes Alchemy SDLC™ as a way to keep everything connected throughout the whole project, linking approved requirements directly to the actual code, test results, and user-approval records. Basically, the code and related files stay clearly tied back to the exact text and IDs that were used to create them in the first place (Grau, 2026).
Tian et al. (2021) found that traceability was used most often to support change management during maintenance. They also identified the effort required to create and maintain those links as its primary cost. Building those relationships during delivery can reduce the need to reconstruct them later, but only if teams keep the record current and the underlying requirements remain reliable.
Figure 4 shows the evidence chain the delivery record is intended to preserve. A reviewer can follow an approved need into a requirement, builder instruction, implemented feature, test result, and changed baseline.
Figure 4. Illustrative evidence chain across Alchemy SDLC™. The identifier rail represents a consistent artifact reference carried through the lifecycle. Source: Author's synthesis based on Grau (2026).
In the end, traceability is only as good as the information you're linking in the first place. Reviewers still have to make sure sources are legitimate, clear up any confusion, and approve changes as the project moves along. Keeping a clear project record just keeps all those decisions out in the open, so nobody has to rely on memory or unwritten rules when trying to figure out why something was built.
Human Authority at the Control Points
Before a requirement enters development, an authorized reviewer confirms that its source is identifiable, current, and valid for the decision. Stakeholder approval must be recorded, and the requirement needs enough detail to support implementation. Later checkpoints assess whether the software meets the approved need, testing covers material conditions and exceptions, and an authorized official has accepted the remaining risk.
Alchemy SDLC™ maintains the record behind these decisions. The product or mission owner provides operational approval. Testing, security, and release authorities review the evidence within their areas. The system records what each reviewer examined, the approved version, and the authorization date.
When one AI system produces material that another uses to generate software, unsupported assumptions can move quickly from a plausible specification into working code. In the first AlchemyProCRM run, the development record lacked an expected behavior, and the generated system followed that record without providing it.
What to Test Next
For the pilot, select one controlled change that includes either a local exception or a conflicting source. Preserve the approved evidence chain from intake through implementation, then ask a reviewer outside the workstream to reconstruct the decision from the source. Record requirements corrected before coding, where traceability breaks, and rework caused by missing or ambiguous input. Code coverage may provide context, but it should remain secondary. The useful result is a record that makes review easier without treating traceability as a measure of overall software quality.
References
Grau, P. (2026). Alchemy SDLC™ proof case study [Unpublished internal case record]. ACC3 International.
Kiro. (2026a). Specs. https://kiro.dev/docs/specs/
Kiro. (2026b). Steering. https://kiro.dev/docs/steering/
National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1
Office of Management and Budget. (2025, April 3). 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
Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST SP 800-218). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-218
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
