A plan written by an LLM in fifteen minutes is not the problem. A plan that drifts every time it is revisited is. CIOs evaluating AI inside an implementation program have already seen the convincing first draft — the architecture document, the project plan, the configuration spec. What they are watching for now is what happens to that draft by week six, when it has been refined twice, regenerated once, and inherited by a new team member who asked the LLM the same question slightly differently.
Why implementation plans drift
Implementation programs do not lose their intent in the build phase. They lose it across the chain of translations between intent, plan, specification, and configuration. Every translation is a handoff. Every handoff introduces drift. The drift is silent on day one and visible by month four — surfacing as scope creep, change requests, and alignment cycles that look like execution problems but originate further upstream.
Revenue change programs typically run three to five times their projected timelines for this reason. The build is rarely the constraint. The translations are. This is not a process problem. It is an architectural one.
What an ungoverned LLM gets wrong about planning
Open prompting produces a plan. It does not produce a governed plan. An LLM without deterministic constraints emits a snapshot, not a model — regenerate it tomorrow and the result is related but not identical, refined in places and quietly redrawn in others. That is acceptable for content. It is not acceptable for an implementation plan that will be revisited, reviewed, refined, and built against by multiple people over months.
The CIO question is not whether an LLM can write a plan. It is whether the plan it writes today and the plan it writes next Tuesday will produce the same implementation. A more capable model does not solve this. Better prompts do not solve this. Determinism is not a prompt-engineering outcome — it is an architectural property of what sits around the model, not what is sent into it.
What deterministic governed skills actually do
A governed skill is the way a skilled implementation lead would frame the work — vocabulary, patterns, decision constraints, validation rules — made executable. The LLM does not reason in an open frame. It reasons inside a frame the organisation defines, owns, audits, and improves over time. The plan it produces conforms to the frame by construction, not by review.
This matters because skills accumulate. Every engagement sharpens the planning surface rather than adding noise to it. The LLM stays useful — fast, articulate, exploratory — but the output is constrained to what the organisation already knows works. Governance moves out of the review cycle and into the planning step itself.
How viax provides the determinism
For revenue execution implementations, Revenue Motions are the deterministic substrate. Every motion carries a governed model — vocabulary, grammar, validation rules, execution behaviour. An LLM planning a revenue execution implementation against viax operates inside this library. It cannot propose a motion the platform cannot execute. It cannot draft a configuration the validation rules will not pass.
Discovery, design, specification, and configuration stop being separate document types. They become refinements of the same governed model. The plan and the execution stop being two artefacts. They become the same one, refined.
AI reasons. viax executes. ERP records. The LLM reasons about the motion. viax constrains the planning surface to what is executable. ERP continues to record. None of the three is asked to do work it was not built for.
What a CIO should expect from this
Implementation timelines compress because the alignment cycles between phases collapse. There is one governed model, not four serial translations of it. Risk drops because every revision returns to the same constrained surface — the week-six divergence between what was approved and what is being built does not occur, because the plan and the configuration are the same artefact under two views.
AI lands on a substrate the IT organisation governs, not on the team’s individual practice. AI-readiness becomes an architectural property of the platform, not a process maturity question. The board question — can AI plan our next implementation? — has a defensible answer: yes, when the skills around the LLM are deterministic and the execution layer underneath them is governed.
Intent is not lost in the build. It is lost in the translations between phases. Determinism in the planning skills — and a governed execution layer underneath them — is how it survives. The plan a CIO commits to in month one is the plan that ships.
