Governance · Assurance · AI

The Institutional Linter: Static Analysis for Your Organisation

You pass every audit. You may still be structurally broken. Audit checks whether you followed the procedure — it was never able to afford the four deeper questions. Now it can.

By Scott Farrell, LeverageAI  ·  A field guide for chief risk, assurance and internal-audit leaders

Somewhere in your organisation there is a control nobody dares remove. A double sign-off on a class of decision. A monthly report that lands on a desk and is filed. A safety check that has run, unchanged, for a decade. Every one of them was put there by someone, for a reason. The reason is written down — in a board minute, a post-incident email, a policy revision, a line of system config. And for most of your organisation's history, reading all of that back was simply unaffordable.¹

So it stayed. And the quiet consequence is this: your organisation can pass every audit it faces and still harbour ceremonial controls, orphaned obligations and risks that nobody is watching. Not because anyone was negligent. Because the checking that would surface those defects was, until very recently, too expensive for any human institution to perform.

Software organisations already solved a version of this. They point AI at their source code and scour it for issues, vulnerabilities and unsafe assumptions — advanced static analysis, running continuously, finding the defects a passing test suite sails right past.² The proposition here is blunt: do that to the organisation itself.

Use AI to inspect the organisation itself as though it were a legacy codebase.

Why the audit doesn't catch it

The trap is a comfortable assumption large organisations make almost unconsciously: the thing we do now is correct. We approved it. The workflow is correct, the reports are correct, the procedures are being followed. Audit confirms that last clause beautifully — and stops there.

That is not a criticism of audit; it is a description of its economics. Traditional audit, process mining and conformance checking all answer one question: did the activity follow the documented process? Process mining's own founders call it exactly that — "do we do what was agreed upon?" But look at what an event log actually records: an activity, a case, a timestamp. Sequence, never justification.⁴ It can prove step B followed step A a hundred thousand times. It is structurally incapable of telling you whether step A should still exist.

That single question — did we follow the procedure? — is the top rung of a five-rung ladder. The other four rungs hold the defects that actually hurt, and they were never economical to inspect. This piece is about making them inspectable.

The organisation is a codebase

The analogy is more precise than it first sounds. Map it out and every part of the software estate has an organisational twin.

To lint code you first compile it. The organisational compiler already exists in our published work: BI for Soft Data converts the unstructured exhaust — emails, reports, minutes, system rules — into an intermediate representation of claims, relationships, dependencies, authorities, exceptions, supersession and provenance.¹ It even recovers something software can't: organisations run two systems at once — the as-designed in the policy manual and the as-operated in what people actually do — and the compile holds every disagreement between them as a contested edge with receipts attached.

Once that compiled representation exists, the organisation becomes lintable.

The five-level assurance ladder

Here is the spine of the whole discipline. Each rung asks a harder question than the one above it, and each was, until now, harder to afford.

1. ConformanceDid the organisation follow the documented procedure? This is traditional audit, process mining, compliance checking. Necessary, mature, and only the beginning.
2. ImplementationDoes the procedure actually implement the current obligation? Governance may have changed three years ago while the operating procedure, reporting template and system config stood still. Every local team can follow its procedure perfectly while the organisation is systemically wrong.
3. EffectivenessEven when followed, does the control still reduce the risk it was designed for — or does it merely record that an activity occurred? A report completed, reviewed, signed and archived every month can be perfect procedural compliance with an ineffective control.
4. Assurance integrityAre the watchers genuinely independent, or all reading the same representation of reality? Three departments confirming a control is effective — from one source report, produced by the control owner — is not three lines of defence.
5. Negative-space assuranceWhat should be tested but is absent from the assurance model entirely? The hardest rung: not "did the control operate?" but "which failure could occur without producing any alert at all?"

Move down that ladder with worked findings and the abstraction turns concrete. Take a transmission network operator — a regulated, safety-critical, long-lived organisation, the kind that accretes governance sediment for decades. The linter doesn't hand it another dashboard. It hands it findings like these.

That is dead-code elimination for organisations.⁸ The point is not to tear the fence down blindly, nor to preserve it superstitiously, but to attach the receipt and let the process owner decide.

This is where the linter operationalises a diagnosis we have written about before as Compliance Cosplay: the gap between what is documented and what is actually enforced.⁶ The contribution here is mechanical — cosplay detection stops being a question a clever auditor happens to ask and becomes a lint pass you can run over the whole estate, on a schedule.

Who watches the watchers is a graph query

Level 4 deserves its own section, because it is the one that quietly defeats the entire "three lines of defence" model organisations trust.⁷ The comforting picture is three independent layers of assurance. The uncomfortable reality is often three reports that all trace, through different departments, back to a single source produced by the very team being assured.

That is not three lines of defence. It is one assumption reflected through three mirrors.

Once the soft estate is compiled, independence stops being a claim on an org chart and becomes a property you can query. For every important control, map the risk being controlled, the originating obligation, the current policy, the operating procedure, the control owner, the evidence producer, the reviewer, the approving authority, the source systems, the exceptions, and whether the control can actually block execution. Then ask the graph directly:

Does the reviewer depend on evidence generated by the control owner? Do the first, second and third lines all rely on the same underlying data? Can the control prevent an action, or does it merely document that the action happened? Is any assurance function testing the completeness of the assurance model itself?

The risk nobody wrote a check for

Level 5 is the hardest because a normal audit cannot get there by design. Audit begins with the established controls and asks whether they operated. Negative-space assurance begins one step earlier — with the risk, the intent and the operating environment — and asks which disqualifying conditions have no check, which safety margin exists in policy but nowhere in reporting, which assumptions have never been revalidated.

That is the organisational equivalent of finding a security vulnerability nobody had written a test for.

The way to make negative space measurable is to borrow test coverage from software and rename it Governance Coverage: have all mandatory risks, disqualifiers, failure modes and safety margins been checked somewhere — and is each check actually capable of detecting or preventing failure? Coverage is measured per risk-register entry, which is exactly why a first pass need not boil the ocean: you can score one policy domain and see its holes.

The Institutional Linter

Assemble those five levels into a standing system and you get the flagship:

Its operating loop is deliberately borrowed from software engineering, because the vocabulary carries the discipline with it:

1. Compile the soft-data estate into an organisational model.
2. Lint for contradictions, supersession, orphaned obligations, dead constraints and missing implementation.¹¹
3. Regression-test current policies against existing workflows and historical cases — replay a governance change across everything it should have touched.⁹
4. Adversarially verify controls using mechanically different evidence sources.
5. Diff the organisation over time: what changed, what didn't change but should have, and what silently became inconsistent.
6. Produce proof-carrying findings, not confident verdicts.
7. Refactor at human pace, with engineering, safety, risk and operational owners deciding what changes.

Step six is the trust contract, and it is non-negotiable. The linter never issues a ruling. Every finding ships with its provenance chain so a human can check the reasoning and disagree. The oracle asks for faith; the navigator offers receipts.¹ This is what makes the system safe to run against something as consequential as a safety case: it directs expert attention, it does not replace expert judgement. Running quietly in the background, never answering today's management question but continually searching for the one nobody asked, it is the Institutional Third Lane — made affordable, for the first time, by cheap idle cognition.¹²

The honesty clause

One guardrail matters more than any finding. Organisations are not software, and the tempting final move — "the AI read everything, so let's regenerate the org" — does not transfer. You can delete and regenerate a codebase because code has no morale, tenure or trust. An organisation has all three. A big-bang restructure justified by "the AI read everything" would be the same catastrophe restructures have always been, with better paperwork.

Read at AI prices. Refactor at human pace. Never big-bang.

What this is not

The linter reads the codified organisation. Three adjacent problems are deliberately out of scope, each its own discipline: