Business Objectives to Code · Part 1 of 4
From Requirement to Running Infrastructure
Following one requirement from an approved requirement to running infrastructure, where deterministic contracts carry the intent a coding model cannot preserve on its own.
There is a sentence in a repository I built that reads: “All Azure resources must be defined in Bicep, no portal-created resources.” It carries an identifier, REQ-IAC-001, and a priority of “must.” Underneath it sit three acceptance criteria written in the plain Given, When, Then form: given an operator queries the cloud for every resource in an environment, then every resource has a matching definition in the repository and a deployment tag the pipeline set; given a pull request tries to create a resource outside that pipeline, then the build rejects it and names the offending change; given a resource is found with no definition behind it, then the compliance check flags it as drift and blocks the next promotion until it is resolved. I want to follow that one sentence from the moment a person approved it to the infrastructure that exists because of it, because the path it takes is the actual subject of this piece.
I built this system to test a method, not to deliver work for a client. The target was the cloud infrastructure for a multi-tenant system I built as a personal project, and the point of the exercise was to see whether a coding model could stand up that infrastructure under discipline I could actually inspect afterward. My own account is that the working infrastructure came together in about two days, and that I did it without prior depth in this particular cloud. I state that as my experience rather than as a benchmark. The speed is the least interesting part of it. What matters is that the result is traceable, and that the tracing is enforced by code that does not care how confident the model sounded.
REQ-IAC-001 did not begin as code. It began as a business objective, OBJ-INFRA-001, whose success metric is stated in a way you can check: every resource in every active environment is defined in a template in source control, and zero resources exist that were created or modified through the portal or a workstation. The requirement also names the operator journeys it serves. It is not a free-floating rule; it earns its place by tracing up to something a person decided the business needed, and the requirement format makes that trace mandatory. A requirement marked “must” is not considered complete unless it points to both an objective and a journey. The link is a validated property of the file, not a convention someone is trusted to remember.
Between that requirement and any code sits a compiler. A script reads the approved requirement set and generates the specifications the build works from, and as it does, it writes a lock file. The lock records one entry per requirement, keyed by the requirement’s own identifier, with a SHA-256 hash of the exact source file, the task assigned to build it, and the feature it belongs to. REQ-IAC-001 becomes an entry in that lock, tied to a task and to a feature file grouped by area. The identifier is the join key the whole system turns on. It appears in the lock, in the generated projection of the requirement, in the feature specification, and in the build plan, each time carrying a marker that ties the task back to the requirement it satisfies. Nothing downstream invents its own numbering. The requirement’s identity travels with it.
When the coding model finally builds, it is not working from a prompt I typed that morning. It is working from a specification the compiler produced from a locked requirement, inside a harness that checks the work at the boundary. The task that carried REQ-IAC-001 is marked done in the build plan, and its completion note records what was produced: the shared infrastructure template, a validation script that rejects manual resource creation, and a local pass of the checks. The requirement that started as an approved sentence is now a definition in the repository and a check that fails the build if anyone tries to route around it. You can read the chain in either direction. From the running definition you can find the task, the feature, the lock entry, the requirement, and the objective the business approved. From the objective you can find every requirement that serves it and the state of the work against each one.
The same move at every stage
Step back from the single requirement and the shape of the system becomes clear. There are three stages between an intention and running infrastructure, and the same move recurs at each one. A model does the semantic work, the work of judgment and language, and non-model code decides whether that work is allowed to move forward.
The first stage is authoring the requirements. A model helps turn source material into objectives, journeys, and requirements, but the output is written into a strict schema, and deterministic scripts enforce that schema before anything is considered real. One validator checks structure and rejects a requirement that traces to an objective or journey that does not exist. Another applies a set of quality rules and will block on the ones that matter, such as a requirement with no acceptance criteria or a threshold stated too vaguely to test. When the set is judged ready, a governance marker in the project flips the requirement set from open authoring to locked. After that point, a requirement cannot be quietly changed without an explicit exception. The model proposed; the schema and the lock disposed.
The second stage is compilation, and it is the most purely deterministic of the three. The bridge script does not reason. It reads the locked requirements and emits the specification set, the per-requirement projections, the feature files, and the lock with its hashes. Because it hashes the source of every requirement, it can tell later whether an upstream requirement has changed since the build was generated. That check is not decorative. When a work session starts, the harness re-hashes the upstream sources, and if a requirement that was already built has drifted, it halts the session and refuses to proceed until a person acknowledges the change. There is no flag to skip the check. The compiler is where the requirement layer’s intent becomes fixed, and the drift gate is what keeps that intent from silently going stale under the build.
The third stage is the build itself, and this is where most people expect the discipline to live and where, on its own, it would not be enough. The coding model generates infrastructure definitions. Around it sits an envelope of checks that run on the work rather than on the model’s good intentions. Validation hooks fire on the model’s own file edits, not after the fact. A task is not allowed to reach done until every one of its acceptance criteria carries recorded evidence. A set of build validators enforces properties the model cannot be trusted to hold on its own, including a rule that bans constructs that would make the infrastructure non-idempotent, so that deploying the same definition twice produces the same result rather than a perpetual difference. The requirement I followed, the one that forbids resources created outside the pipeline, is itself enforced by one of these validators. The rule the requirement states became a check that runs forever.
The contract is written before the model runs
The move that makes this more than a pile of guardrails is where the acceptance criteria live. In an ordinary build, the person or model doing the work also decides, at the end, whether the work is good. The definition of success and the attempt to meet it come from the same place, which is exactly the arrangement you would not accept from a vendor. This system inverts that. The criteria that judge each stage are written before that stage runs, and they are written one layer up.
The requirements carry the acceptance criteria the build is measured against, and they are locked before the build starts. Above even that, the requirements project maintains expected-deliverables documents that describe, ahead of time, what the compiler and the build must produce for each area. The lock file is the mechanism that makes this binding rather than aspirational, because it fixes the exact text of each requirement, by hash, at the moment of compilation. The model, at every stage, is filling semantic slots inside a contract it did not author and cannot rewrite to suit its output. That is the cleanest way I can describe the relationship between deterministic and semantic work: the deterministic layer carries the intent that the model cannot be trusted to preserve on its own, and it carries that intent forward across stage boundaries where a model’s memory would otherwise fade.
This is the same principle I have argued belongs in enterprise systems generally, that deterministic and semantic components should sit next to each other and each do the work it is strongest at. Here the principle is doing structural work rather than rhetorical work. It is the load-bearing structure of a build that exists. The requirement’s identifier is a deterministic join key. The lock is a deterministic record. The validators are deterministic checks. The model’s contribution, the reading of source material, the phrasing of a testable criterion, the generation of a working definition, is semantic, and it is real work that the deterministic parts could not do. Neither half is sufficient. The engineering is in the seam, in the specific places where the deterministic code refuses to let the semantic output proceed.
I want to be precise about the evidence, because the honest version of this case is stronger than an inflated one. The chain from an approved requirement, through the lock, to a generated specification, to a build task with a recorded completion, is real and inspectable on disk. I traced it for REQ-IAC-001 and the trace holds at every hop. The requirement’s identifier genuinely threads through the lock, the projection, the feature, and the plan.
The last step, from a finished build task to a live resource running in a production environment, is where I will not overclaim. The lock and the projections were generated once and were not re-synchronized as the work completed, so they still record the requirements as unimplemented even though the build plan marks the tasks done. Completion, at that final hop, lives as written evidence in the plan rather than as an automatically maintained ledger that flips itself from requirement to running resource. The only machine-generated deployment artifact committed in the repository is a single preview of a planned change in the development environment, and it belongs to a feature that was hand-authored outside the compiled chain. The development environment deploys cleanly; the higher tiers are not yet provisioned. So the defensible claim is this: the upstream chain, from business objective to built task, is enforced and traceable by construction, and the final mile to running production infrastructure is demonstrated by recorded notes and a validated preview rather than by an end-to-end automated trace. A system that tells you exactly where its own evidence is thin is easier to trust than one that presents every stage as equally proven.
Why this is the question that matters
The common objection to letting a model build real infrastructure has little to do with whether it can produce plausible definitions quickly. It obviously can. The objection that matters to anyone accountable for a system is whether the result is governable: whether you can show what was built, tie it back to a reason someone approved, prove it was checked, and stop the model from certifying its own work. Those are the questions a technology leader has to answer before any of this is allowed near something consequential, and they are answerable here with mechanisms rather than reassurance. What was built traces to a requirement and an objective. What was checked is recorded as evidence against named criteria. What stops the model from grading itself is that the criteria were written and locked a layer above it, before it ran.
The durable lesson is the pattern rather than the specific harness. It held at all three stages and would hold at more: put the deterministic contract where the model is least reliable, author that contract ahead of the work it judges, and let the model do the semantic work inside boundaries it cannot move. Speed is what people notice first when a model builds infrastructure in a couple of days. Governability is what determines whether that speed is worth anything, and it is a property you engineer into the seams, not a promise you attach at the end.