Application logic can be bypassed. Database constraints can enforce approval for ordinary application writes when access is properly separated. Privileged schema changes need their own controls.
- No self-approval
- No uncleared release
- Every action recorded
View the original NEMS approval queue
In 1999 I took a job at KPMG Consulting, later renamed BearingPoint, running global resource operations for the high-technology practice. On paper it was a staffing role. In practice it was ten thousand consultants and subcontractors, thirty-odd managers, and about thirty million dollars a month in subcontractor spend moving through a system nobody could see end to end.
What that job cured me of was a belief in individual brilliance. At that scale, the outcome has very little to do with how clever anyone is on a given Tuesday. It has to do with whether the system underneath makes the right thing easy and the wrong thing hard. I have spent the years since on variations of the same question.
Programs don't collapse. They stall.
The public conversation about failed transformation is mostly about technology choices, and that conversation is nearly always beside the point. I have watched large modernization programs go wrong across tax, licensing, regulatory and public-service systems, and the technology was rarely the thing that broke.
What breaks is ownership. Approvals that nobody is accountable for. A plan every stakeholder has agreed to and no one is executing. Programs of this kind almost never collapse, and a collapse would at least be legible. They stall, out of sight, while everyone involved is working hard and reporting green.
That is the failure mode I built a firm around. And when generative AI arrived, it did not change the diagnosis. It raised the stakes, because a system that drafts faster than anyone can review produces stalled work at a speed no one has seen before.
Fast drafting with slow judgment is just a backlog with better formatting.
Procedural rules are suggestions
Every organization I have worked with has a governance policy. Most have a good one. What matters is less whether the rule exists than where it lives.
A rule that lives in a policy document is a suggestion. A rule that lives in application code is a strong suggestion, right up until a competent engineer under deadline pressure works around it for a defensible reason. I have been that engineer's manager, and the reason is usually good.
An enforced schema rule can stop ordinary application writes from releasing a document without a recorded approval from someone other than its author. That protection depends on correct modeling and permissions. A privileged administrator can alter or drop a constraint, so schema changes must be separately authorized, reviewed, and recorded.
This is why the design principle I would defend anywhere is narrow and slightly unglamorous: critical approval rules should be enforced in the data model as well as in the application, with controlled privileges and schema changes. Three of them do most of the work.
No one approves their own work. Maker and checker are different people, structurally, not by convention. Nothing is released that wasn't cleared. The released state is unreachable without the approval record. Every action leaves a record of who took it. That record is a row the rest of the model depends on, not a log that can be pruned.
Where the AI actually goes
People expect the interesting part of an AI system to be the model. In our work it is the boundary around the model.
NGOS is the system our firm runs itself on: capture, proposal, staffing, compliance, delivery. AI drafts throughout it. A person approves anything that matters. NEMS is the governance layer around that: controlled documents, maker-checker approval, risk, audit, corrective action.
The distinction that makes it work is between drafting and deciding. A model is good at producing a first version of a document, a schedule, a response. It is not accountable for the consequences of that document, and it cannot be. So the architecture puts the model on one side of a line it cannot cross by itself, and puts a named human on the other.
That sounds like a limitation. In practice it is the thing that makes the speed usable. You can let a system draft aggressively precisely because you know what it cannot do unilaterally.
We ran it on ourselves first
We built this for our own operation before we offered it to anyone. Roughly five hundred controlled documents and the whole of the firm's work run on it.
That is not a marketing position, and I would not make much of it except that selling an operating discipline you do not practice is a particular kind of dishonest. If the governance is real, it should be inconvenient for us sometimes. It is.
More than three decades in, the question hasn't changed. Only the tools have, and the tools got fast enough that the question finally became urgent.
Saif Rehman is the founder and CEO of NextGen Consulting. More on the work is on the business page.