A learning management system had been built with generative development tooling, but the operating conditions from enrollment through completion still had to be confirmed separately. At the biofoundry training LMS of company M, we verified the missing requirements and exception paths against actual behavior.
There is a course screen, and the enrollment button works. Completed lessons are displayed, and so is completion status. The required features have been built. Is this enough to run a training program on?
The LMS for company M's biofoundry training program was a system built with generative tooling. The requested features could be executed, but how far the unstated conditions and exceptions had been reflected was not yet clear.
In the verification carried out in 2026, the standard was the outcome of actual training operations rather than the way the code had been produced. Distinguishing "the feature exists" from "it behaves correctly under the required conditions" was the starting point.
We judged by execution results, not by impressions of the code
There is no need to rate the deliverable lower just because AI wrote the code. Conversely, the fact that the code was produced quickly does not prove that it is ready to operate.
Before starting, we agreed the verification criteria. Instead of assessing code style or how it was written, we would judge by the behavior confirmed by running the system.
This approach also shifts responsibility from the code to the user's experience. Whatever form the internal implementation takes, it has to satisfy the conditions the training operator needs. What mattered was not an explanation that the code contains a statement handling a case, but what result actually comes out under that condition.
The same standard applies when verifying any system built with generative development tools. Before asking what the tool built, an organization must be able to explain what it intends to operate.
From enrollment to completion, we treated it as one flow
The critical verification flows were enrollment, progress credit, and completion. Rather than checking each screen in isolation, we followed the flow of a learner joining a course and receiving a result.
These three stages are connected. The operating outcome depends on who the enrolled user is, which learning counts as progress, and how that result feeds into the completion criteria.
For example, the fact that progress appears on screen does not by itself mean that the completion decision is correct. Whether the displayed progress and the conditions used to decide completion follow the same standard has to be confirmed separately. This is not to say a specific defect was found; it is a relationship that is easy to miss when the verification scope is defined from a feature list alone.
In the project, these critical flows were executed as scenarios and the results recorded. The aim was to go beyond whether each feature exists and actually confirm the agreed behavior.
Over-capacity enrollment and mid-course withdrawal went into the operating scenarios
Normal enrollment and completed learning are not enough to describe how a training program operates. The enrollment capacity may fill up, some users may not finish, and people with different permissions may gain access.
The verification included over-capacity enrollment, mid-course withdrawal, and access conditions by user permission. We confirmed what the system produces outside the normal path of the originally requested features.
Exception conditions are not an exercise in imagining every rare event. They are a check of the rules the service will actually operate under. Capacity, completion, and permissions look like operating policy outside the screen, but they are conditions that change the system's results.
If these conditions were not stated during implementation, a development tool cannot know the organization's intent in their place. Making the conditions concrete during verification is also connected to finding the missing requirements.
When the explanation and the execution differed, we went back to the execution result
An explanation that the code contains a certain handling and the result of executing it can diverge. Accepting the explanation as it stands risks ending verification on the assumption that the behavior already works.
In the project, the result of executing under the agreed conditions was the basis for judgment. Where it differed from the expected behavior, we recorded it as a missing requirement or a point that needed supplementing.
Rather than simply collecting odd screens, we recorded scenario by scenario which condition produced which result. The record had to be in a form the person making the fix could re-check and the operator could use to understand which rules needed to be set.
This record is useful to the person using the generative development tool as well. The next change request can be made concrete as "under this condition, this result is required" instead of "something is off, please fix it."
What we delivered was the evidence for reviewing the release
Through the verification, we organized the missing requirements and the areas that needed further confirmation. The results of the executed scenarios were left alongside the scope that could not be confirmed.
Rather than declaring a release decision while not every verification item was in place, what mattered was gathering the facts needed to decide. Once it is clear which flows were confirmed and which conditions still need a closer look, the next steps can be defined concretely.
The result of verifying the existing system led to requirements to supplement and a scope for the next round of confirmation. The subsequent fixes and the release decision are separate steps to be taken on the basis of this record.
The faster development becomes, the clearer the process of confirming that what was built satisfies the conditions of the work has to be. At company M, we made visible in the record what remained between code that runs and a training system that can be operated.
