development
On Intent Coherence
The dominant failure mode in modern systems isn’t error. It’s drift.
This is the discipline behind two products I’m building at Viewyonder: Coherence and Injectionator.
A senior engineer refactors a function that has worked for a year. All tests pass. The pull request is approved. Six months later, an attacker exploits a vulnerability that didn’t exist before the refactor. The “fix” silently removed a defence that had been load-bearing — but invisible to tests, lint, and review, because no one in the chain remembered why the original code was structured the way it was.
This is not a bug in any sense the standard tools recognise. The new code is correct. It is well-typed. It compiles. It passes its tests. It is, by every conventional measure, fine.
It just no longer does what someone, at some point, decided it should do.
This failure mode has a name in some domains, partial answers in others, and no name at all in software — until now, when the speed of AI-assisted code generation has made it the dominant failure mode rather than an occasional one. This essay is about that failure mode, the discipline required to address it, and why I think the discipline applies far beyond the software industry where the problem first became acute.
I will call the discipline intent coherence. The rest of the essay argues for the term, sketches its mechanics, distinguishes it from neighbouring disciplines it is sometimes confused with, and walks through where it applies — including two products I am building under it.
1. The shape of the problem
Every sufficiently complex engineered system has a layered structure of intent. There is a layer of high-level commitments — what we are building and why. There is a layer of specifications — what the system must do and what invariants it must hold. There is a layer of implementation — the actual code, configuration, operating procedures, or field operation that realises those specifications. Each layer encodes intent more concretely than the layer above it.
The layers are touched at different rates. Implementation is touched constantly. Specifications are touched occasionally — when the requirements change, when an invariant is added or removed. High-level commitments change rarely; they are by design supposed to be stable.
This produces a structural drift problem. Every edit at a lower layer is an opportunity for the relationship between layers to change. Most edits propagate intent faithfully. Some don’t — and over time, those non-faithful edits accumulate. Because the lower layer is touched far more often than the upper layer, the drift is asymmetric: in nearly every case, the lower layer is the one that has wandered.
This is true for software. It is also true for industrial process control, aviation operations, clinical care, financial compliance, military operations, and any other domain with the same layered structure.
The problem is not new. In some domains, it is centuries old. Military doctrine has explicit concepts for it — commander’s intent in the modern English-speaking tradition, Auftragstaktik in the Prussian/German one — both of which exist precisely because subordinate units cannot anticipate every situation, and must act in a way that is coherent with higher intent even when literal orders run out. Engineering disciplines have design intent — a body of rationale that explains why a system was specified the way it was, intended to survive the people who designed it. Regulated industries (aerospace, automotive, medical devices) maintain requirements traceability matrices — exhaustive maps from each requirement to each implementing module to each test case — because regulators demand them.
These are all attempts to address pieces of the same problem: making sure the bottom layer of a system remains in coherent relationship with the top, even as the bottom changes faster than the top.
What is new is two things. First, the bottom layer of many systems is now generated by AI — written at a speed human review cannot match. Second, the upper layers are increasingly textual and machine-readable, which means the inference work that has historically required humans can now be done by machines. Together, these two changes make the old problem newly acute and newly tractable.
2. What the discipline is
I will define intent coherence as: the property of a system that its lower layers remain in faithful, traceable relationship with its higher layers — and the discipline of producing systems with that property.
This is a property of the relationship between layers, not of any single layer. A system can have correct code and a clear specification and still lack intent coherence, if the relationship between them has drifted. Intent coherence is about whether the bottom layer is doing what the top layer asked for, not about whether either layer is, considered in isolation, any good.
It is a distinct concern from:
Correctness. Correctness asks whether the implementation works against its own apparent contract. A function can be perfectly correct and still incoherent with what the spec actually called for.
Quality. Quality asks whether the implementation is well-built. Well-built code can have drifted from its spec. Badly-built code can be perfectly coherent.
Completeness. Completeness asks whether everything specified got implemented. A complete implementation can still have drifted in how it implements the spec.
Compliance. Compliance asks whether implementation meets external rules. Coherence asks whether implementation meets project-internal intent. The two often correlate, but they are different questions and they fail in different ways.
The closest existing concepts are requirements traceability (in regulated engineering) and commander’s intent (in military doctrine). Intent coherence borrows from both. From traceability, it takes the idea that the relationship between layers should be explicit and auditable. From commander’s intent, it takes the idea that lower layers must carry forward the why, not just the what, of higher layers — because the why is what tells you whether a change preserves or breaks coherence.
What’s different is the mechanism. Traceability matrices are maintained by hand, are brittle to refactoring, and are usually done only because regulation demands it. Commander’s intent is transmitted by training, doctrine, and rehearsal, and is hard to formalise outside human heads. Intent coherence as I am proposing it is derived — built from the textual artifacts a system already produces, by the same machinery that now generates the implementation layer. It does not require new artifacts. It requires that existing artifacts be authored at the right layer of granularity, and then it builds the rest.
3. Drift has direction
If you accept that intent coherence is a real concern, the next question is: when intent and implementation disagree, which one is wrong?
The answer is asymmetric, and it follows from the touch-frequency argument above. The artifact touched more often since the layers were last in agreement is the artifact more likely to have drifted. Implementation drifts from specification more often than specification drifts from implementation. Specification drifts from high-level commitment more often than commitment drifts from specification. The most-touched artifact is the most likely to have wandered.
This is not a law. It is a strong prior, and specific evidence can flip it. A spec edited yesterday and an implementation that has not moved in a month is the reverse case. But the prior holds in the typical case, and any drift-detection mechanism worth using should report not just that there is drift, but also which side has likely drifted, and what the recommended action is.
“Drift detected” is useless. “Code drift, likely; recommended action: bring code back to spec, or revise spec if intent has changed” is something a human can act on. The asymmetry is what makes drift detection actionable rather than merely accurate.
This is also why intent coherence is an engineering discipline rather than a verification one. Verification produces a binary verdict: pass or fail. Intent coherence produces a direction and a recommendation. It is meant to inform a human decision, not to gate a build.
4. The intent map
The mechanism that makes intent coherence operational, in software at least, is what I will call an intent map: a derived, queryable view of how upper-layer claims relate to lower-layer artifacts.
Three properties matter.
It is derived, not authored. Developers keep writing the artifacts they already write — plans, specifications, code. The map is built from those artifacts plus inference. It is cached but cheaply regenerable. If it disappeared, it could be rebuilt without losing anything. It is not a fourth artifact engineers maintain. If it were, the cure would be worse than the disease.
This is the principle that distinguishes intent coherence from, say, requirements traceability matrices in regulated engineering. The matrix is a thing humans maintain, painfully. The intent map is a thing software maintains, automatically. The discipline is the same; the labour is different by orders of magnitude.
It traces intent paths, not coverage. Most code does not need a direct edge to a specification claim. A token-verification function in a security product is not described by any single threat-model claim — it serves several. A logging adapter is not described by any claim — it supports everything. A configuration loader is acknowledged infrastructure.
The right question is whether a code node has an intent path to a commitment somewhere in the project. Possible relationships include: direct intent (the node implements a specific claim), inherited intent (the node is depended on by code with direct intent), ambient intent (the node belongs to acknowledged infrastructure), and no intent path (the node has no traceable connection to project intent).
The first three are coherent. The fourth is the finding. “No intent path” is a much sharper signal than “no spec edge” — it asks the question the user actually cares about: can we trace why this exists?
It treats confidence as a routing signal, not an accuracy claim. Inferred edges have confidence levels. We do not pretend these are ground-truth probabilities. They route attention: high-confidence edges report quietly, mid-confidence edges report individually with the inference engine’s reasoning, low-confidence edges report as candidates for explicit anchoring. The author can ignore all of this and still get useful output. The author can also choose to anchor specific high-stakes edges and lift confidence selectively. The system gives the option without demanding the work.
The intent map produces two outputs that matter to humans. One is the current state — the map itself, queryable by any axis the team cares about. The other is the journal — an append-only record of how the map has changed between runs. I expect the journal to be the more valuable of the two, especially in code review, audit, and post-incident analysis. Reviewers care about deltas, not states. A line in the journal that reads this code path lost its only intent edge in commit 3a4f2 is the kind of evidence trail that makes intent coherence a defensible discipline rather than a vibe.
5. What intent coherence is not
I want to be specific about adjacent disciplines, because the failure mode I most worry about is intent coherence being mistaken for something it isn’t.
It is not static analysis. Static analysis asks whether code is correct against fixed, universal rules — typing, security patterns, code smells. Intent coherence asks whether code is coherent with project-specific intent. The former is universal; the latter is local. Static analysis is a verification tool. Intent coherence is a maintenance tool. A product can include both, but they answer different questions, produce different outputs, and serve different stakeholders.
It is not test coverage. Tests verify behaviour against a particular contract. Intent coherence verifies alignment between layers of intent. A 100% test-covered codebase can be 100% intent-coherence-broken; the tests pass against the implementation, not against the specification.
It is not coverage enforcement. I will not produce a “percent of code mapped to specs” metric. That metric drives the wrong behaviour — it incentivises spec inflation rather than coherence. The actionable metric is closer to “edges where confidence is low and stakes are high,” which is a much smaller, more focused set.
It is not architecture review. Intent coherence does not score code on factoring or elegance. The only architectural property it cares about is whether intent remains legible through the structure. Highly factored code is coherent if intent paths remain traceable through it. Over-factored code becomes a coherence concern only when those paths disappear.
It is not a compliance product. It produces evidence a compliance audit would value, but the framing is engineering hygiene, not regulatory check-the-box. If the engineering hygiene is right, the compliance value falls out as a side effect. If it leads with compliance, it ends up being a checklist tool, which is not the same thing.
These distinctions matter because each adjacent discipline is established, has tooling, has buyers, and has a mental model that a reader will reach for first. Intent coherence is none of them. It is the missing layer between them.
6. Where the discipline applies
So far the framing has been heavy on software. The argument generalises further than that. Any system with the following properties has an intent coherence problem:
- Layered structure of intent. Top-level commitments → mid-level specifications → bottom-level operations. The layers are conceptually distinct.
- Asymmetric touch frequency. The bottom is touched far more often than the top.
- Textual artifacts. Each layer is recorded somewhere readable — written policy, written specification, written procedure, written code. Even partial textuality is enough.
- Stakes. Drift between layers produces costs that the standard verification machinery does not catch.
When all four hold, the discipline of intent coherence applies. Some examples:
Cybersecurity at the enterprise level. Most organisations have written security policy, written security standards or control frameworks, and operational implementation across infrastructure, applications, and processes. These layers drift constantly. Policy says all production data is encrypted at rest; standards specify which algorithms and key-management approaches; implementation is mostly compliant, partly compliant, occasionally non-compliant in ways nobody noticed during a migration two years ago. The current solution is periodic audit — expensive, point-in-time, often stale by the time findings are remediated. Intent coherence applied here is a continuous, derived map from policy to control to implementation evidence. Not a replacement for audit, but a transformation of what audit finds. The map updates as the system changes; the audit becomes a sample-and-judge exercise rather than a discovery exercise.
IT Service Management. Service catalogues, service definitions, operating runbooks, change-management procedures, incident-response procedures — all are textual layers of intent. All drift relative to operational reality. A runbook says to follow steps A-B-C-D; over time, operators learn that step C is no longer necessary; the runbook is never updated; nobody notices until a new operator follows the now-stale procedure during an incident. An intent map across service definitions and operational reality would surface this drift before the incident. Same shape; same discipline.
Compliance generally. Regulation → corporate policy → procedure → operational behaviour. The longer the chain, the more drift. Compliance theatre is what happens when the bottom of the chain is no longer in coherent relationship with the top, but everyone keeps pretending it is. Intent coherence is the engineering discipline that, applied at scale, makes the theatre unnecessary because the relationship is continuously verifiable.
Industrial process control. Design intent → P&IDs → control logic → set-points → field operation. This is the domain where intent drift produces the most spectacular catastrophes. Many of the well-known process-safety failures — Bhopal, Texas City, Deepwater Horizon — have intent-coherence stories embedded in their causal chains: a parameter was changed for a reason, the reason was not propagated upward to the design intent, a later change interacted badly with the earlier one, and nobody on the spot had the layered context to catch the interaction. The discipline already exists informally in process safety; making it continuous and derived would be a step change.
Aviation operations. Regulation → fleet manuals → operating procedures → individual flight operations. Aviation is one of the few domains that has worked very hard at intent coherence and largely cracked it for the regulated layers, through painstaking manual maintenance of trace matrices, mandatory revision processes, and exhaustive crew training. The cost is enormous. The discipline scales because aviation is willing to pay for it. Most domains aren’t.
Clinical care. Guidelines → care pathways → individual patient encounters. This is the domain where intent coherence has been least formalised, and where the gap is largest. Guidelines are written and updated; clinical practice drifts; the relationship between the two is largely managed in the heads of senior clinicians. AI-assisted clinical decision support is going to force this issue, much as AI-assisted code generation has forced it in software.
The pattern is the same in each case. The cost of drift varies; the discipline of detecting and addressing it does not.
7. Why now
The discipline is old in some domains. Why is it now becoming a generally interesting topic?
Two structural changes.
First, the bottom layer is now machine-generated in many domains. AI-assisted code generation is the leading edge, but AI-assisted operational tooling, AI-assisted clinical decision support, AI-assisted compliance, and AI-assisted security all exist or are being built. The common feature is that the bottom layer of the system can now be produced at a speed human review cannot match. The drift problem that was previously bounded by human productivity is now unbounded.
Second, the inference required to maintain an intent map is now tractable. Linking a written policy to a control to an implementation used to be a job for a person. Linking a specification claim to the functions that implement it used to be a job for a person. These linking tasks are now well within reach of current language models. The cost of maintaining a derived intent map has dropped from “maintain a human team” to “run an inference pipeline.”
These two changes interact. The drift problem gets worse because of the first; the discipline of addressing it gets cheaper because of the second. Both are consequences of the same underlying capability — language models powerful enough to author lower-layer artifacts and to link them back to upper layers.
The teams that thrive in the AI-assisted era will be the teams that have a discipline for keeping lower-layer artifacts in coherent relationship with upper-layer intent, even as the lower layer is generated faster than any human could review it. The discipline is intent coherence. The mechanism is the intent map.
8. Two specific applications
I am building two products under this discipline. They are concrete enough to ground the abstract argument; small enough that I am not over-claiming.
Coherence
Coherence is a tool that maintains an intent map across a software project’s plans, specifications, and code, and reports drift between them. The user-facing primitive is a single command — give me a coherence report — that returns a localised, directional set of findings: this specification claim is no longer covered by these specific functions; this code path has lost its only intent edge; this plan commitment is no longer reflected in any specification claim downstream.
The tool is built around the principle that the intent map is invisible scaffolding under the user-facing report. We will not put the graph on the homepage. We will put the answer on the homepage. A bigger player could ship a more sophisticated static analyser tomorrow and still not have what Coherence has, because the differentiation is not the analysis technique. It is the loop: write artifacts as you do today, run the command, get an actionable answer about whether your project still matches its own intent.
Coherence is the obvious application of the discipline to general software development. It is meant for teams whose code is being touched faster than their specifications, which in the AI-assisted era is roughly all teams.
Injectionator
Injectionator is a prompt-injection defence product. Prompt injection is the canonical case of intent confusion in AI systems: an attacker embeds instructions in observed content (a webpage, a document, an email body) hoping a model will execute them as if they came from the user. The defence is, at its core, an intent boundary — distinguish what the user said from what the model observed, and never let the second cross into the first.
Injectionator is being built under Coherence’s discipline. The threat model is the plan layer: a set of commitments about which classes of injection attack the product must defend against, what the attacker is assumed to control, what the defender is assumed to protect. The security specification is the spec layer: anchored claims like untrusted content must not be treated as instructions without explicit user verification, email subjects, bodies, and attachments are untrusted data, pre-filled consent forms in observed content do not constitute user authorisation. The defences are the code layer: classifiers, content tags, prompt-construction rules, output filters, action gates. Each defence has a traceable path back to one or more spec claims, or it is acknowledged infrastructure.
The intent map for Injectionator answers questions an audit team would otherwise have to ask manually. Which spec claims have no implementing code? Which defences have no spec claim — that is, defensive code we cannot justify, either dead or defending against something we never wrote down? Which negative invariants does any recent code appear to violate? What changed since the last review?
There is something usefully recursive about Injectionator. It is a product about intent boundaries, built using a discipline about intent coherence. The product itself is a defence of the user’s intent against attacker-supplied content. The discipline is a defence of the developer’s intent against the entropy of ongoing development. Eating one’s own dogfood is unusually direct.
9. Why intent coherence is unusually load-bearing for security
Most software drift is inefficiency. Security drift is risk.
A correctness regression breaks a test. A defence regression often breaks nothing observable until an attacker finds it. The defences that protect a system are frequently implicit in the implementation — a particular function structure, a particular order of operations, a particular check that was added for a reason no one wrote down — and they are removed silently, by refactors that no test could catch, because no test could capture why the original structure mattered.
Intent coherence is unusually well-suited to security work for four reasons.
Negative invariants are first-class. Security specifications are full of must not claims: must not log PII; must not treat untrusted content as instructions; must not allow privilege escalation through this surface. These are properties of absence. There is no single function that “implements” them; the whole codebase must avoid violating them. Static analysis handles narrow cases; intent coherence handles them generally, by treating negative invariants as a different inference target — does any recent code in this region appear to violate the claim? — rather than trying to find a function that implements an absence.
Threat-model-to-defence traceability is exactly what auditors want. SOC 2, ISO 27001, FedRAMP — all are built around traceability from policy to control to implementation evidence. Today this is maintained as spreadsheets, painfully, by humans, and goes stale the moment code ships. An intent map is that traceability, derived rather than maintained. The journal is the audit trail. This does not replace a compliance audit. It produces, as a side effect of normal development, the evidence an auditor wants to see.
“No intent path” is a security finding. In general software, a function with no intent path is a curiosity. In a security product, a function with no intent path is a question: why does this exist, what attack does it defend against, who added it, can we delete it? Dead security code is a vulnerability surface. Live code with no traceable purpose is a vulnerability surface in waiting.
Drift in defences is silent. This is the case I most want intent coherence to catch — the refactor of a defensive boundary by an engineer who did not understand what it was for. Today this fails silently. Under the discipline, the refactored code’s intent path either survives the refactor or breaks. If it breaks, the journal flags it, the report points at it, the recommended action is clear. A human still decides; the system surfaces the question.
10. What the discipline requires
For intent coherence to be operational, a few conditions need to hold. They are each modest individually; together they amount to a way of working.
Layers must be written down at appropriate granularity. This is the only authoring tax. A specification claim that is too vague to be falsifiable is a claim that cannot be linked to anything. A plan commitment that is just make it secure is not a commitment any defensive code can be coherent with. The granularity that matters is the layer at which a claim is falsifiable — neither finer nor coarser. For specifications, this is usually a numbered claim in a tabular structure. For plans, it is a numbered commitment with a stated rationale.
Layers must be authored independently. Conflating plan with specification produces a single artifact that is too abstract to verify and too concrete to commit to. The hierarchy is load-bearing; collapse it and the discipline collapses with it.
The intent map must be derived from the artifacts, not maintained as a fourth artifact. This is the principle that distinguishes the discipline from regulated-engineering trace matrices. If the map becomes a thing humans maintain, the cure is worse than the disease.
Drift findings must be local, directional, and actionable. “There is drift” is useless. “Spec claim AUTH-3 is no longer covered by authMiddleware because the requireAuth check was removed in commit 3a4f2; recommended action: restore the check or revise AUTH-3” is something a human can act on.
Confidence must route attention, not claim accuracy. The system does not know with certainty which edges are real. It has stronger and weaker reasons to believe. The report should reflect that. Reading a coherence report should feel like reading a thoughtful colleague’s notes, not a static analyser’s verdict.
These conditions are achievable in software today. They are partially achievable in cybersecurity, ITSM, and compliance — the artifacts exist, the granularity is sometimes there, the inference is now possible. They will become achievable in domains like clinical care and process control as those domains push their textual layers toward machine-readability, which AI-assisted operations is already doing.
11. Closing
The era of the bottom layer is generated faster than the top layer is reviewed is permanent. It started with code and AI-assisted development. It is spreading to operations, security configuration, compliance procedure, clinical decision support, and any other domain where a high-volume bottom layer can now be produced by language models against a low-volume textual top layer.
The teams that thrive in this era will be the teams that have a discipline for keeping the layers in coherent relationship — not by slowing the bottom down to human-reviewable speed, which is no longer possible, but by raising the rate at which the relationship between layers can be checked.
That discipline is intent coherence. It is older than software, broader than software, and now newly tractable because the same machinery that has made the drift problem acute has also made the inference problem cheap.
I am building Coherence and Injectionator under this discipline because I believe it is the discipline that keeps high-volume AI-assisted systems honest. The same argument applies in your domain, whatever it is, if your domain has layers of textual intent and a bottom layer that has started generating faster than humans can audit it.
Most domains have. The rest will.
If your domain has layered intent and a bottom layer that has started generating faster than humans can audit it, this is the kind of work I do at Viewyonder. Get in touch.
Steve Chambers writes about coherence infrastructure for AI-assisted development. Coherence and Injectionator are early-stage products built under the discipline described here.