⚙️ What Comes After GRC Engineering...

Last issue I argued that PR approvals are quietly losing their meaning, and I ended with a promise. When a PR approval stops meaning what your control says it means, whose job is it to define the new receipt? I said I'd answer, so here it is.

The screenshot still looks the same

Your change management control probably says something like: every production change is reviewed and approved by a second person. The evidence is the PR approval. The auditor samples 25 of them, sees green checkmarks, moves on. This has worked for fifteen years.

Now look at an engineering floor in 2026. Agents write most of the code. A human approves 30 PRs a day, or a review bot approves for them. The checkmark is pixel-identical to the 2019 checkmark. What it attests to is gone.

Nothing on your dashboard flagged this. The control still passes. Every check is green. The question the control existed to answer, "was this change actually looked at by someone accountable," stopped being answered, and no tool told you.

What AI broke is the meaning of our evidence. And meaning was the one thing we never wrote down, because it never used to move.

GRC was calibrated for a slower world

Annual audits, sampled evidence, screenshots in a folder: that machinery assumed the thing being verified changed quarterly at worst. That was reasonable then.

Today the interpretation behind a control changes per deploy. An annual, sampled, after-the-fact test of a per-deploy activity is archaeology.

GRC Engineering fixed half of this

The half we fixed: the mechanics. We automated evidence collection, wired controls to APIs, put checks in pipelines. I spent years pushing exactly this, and I'd do it again.

Then, buried in a playbook on running coding agents in regulated industries, the author drops one sentence I can't put down. Agent output can "pass automated checks but fail audit."

The person building the check infrastructure is telling you the check and the audit are different tests. A check verifies a rule fired. An audit asks whether the rule maps to the obligation, whether the evidence would convince an examiner who disagrees, and who signs the mapping.

Somebody translates "demonstrate controlled change management" into "this gate, these parameters, these repos." Today that translation lives in a config file, written by whoever was closest, reviewed for syntax, signed by nobody. Agents are now multiplying those translations at generation speed. The signatures are not keeping up, because there were never any signatures.

So more engineering was never going to be the answer. The answer came from watching a neighbouring discipline solve its own version of this, a few years ahead of us.

The playbook worth stealing

Platform engineering took internal infrastructure, the ticket-queue world every engineer hated, and rebuilt it as a product people want to use. Their playbook maps onto GRC almost embarrassingly well:

And two of their tools translate directly, as mental models you can adopt tomorrow and as systems you can actually build:

The compiler 

Your interpretation of an obligation is source code. A named person signs it once, and it compiles into everything downstream: the checks your pipeline runs, the context your agents load, the answers your trust page serves. Change the interpretation and everything downstream recompiles, with a reviewable diff. You even get a type system:

control: change_review
interpretation: v3        # signed: J. Doe, GRC, 2026-08-12
assurance_class: live_telemetry
evidence: screenshot_march.png   # TYPE ERROR: a screenshot cannot back a live_telemetry claim
expires: 2026-03-15              # COMPILE ERROR: expired assertion in a release path

Declaring a control "continuously monitored" and backing it with a screenshot stops being an awkward audit conversation. It's a type error.

The debugger

An audit finding is a stack trace: finding → signal → control → interpretation → obligation. When every frame is a record instead of a memory, "why did this fail" is a query you walk in minutes. The root-cause committee becomes a JOIN.

Even food safety left us a tool, decades ago. Your yogurt ships with better expiry semantics than your SOC 2.

GRC needs the same reframe: from the team that collects proof after the fact to the layer everyone else consumes. A layer that spans the stack instead of supervising it from above.

The one part their playbook can't cover

To be clear about what we're borrowing: it's how they think, applied to our problems. Their way of thinking transfers almost completely. It already reaches into our mechanics: there's even a Security Platform Engineer role now whose job description includes compiling compliance requirements into automated checks.

The exception is the one piece platform engineering never needed for itself. Nobody examines their interpretations. No one shows up once a year and asks a platform team to defend what "approved" means, with consequences if the answer doesn't hold. Our domain has that examiner.

So next to everything we borrow, one thing stays ours: a named person who signs the translation from obligation to check, and stands behind it when the examiner disagrees. I went looking for that job in the playbooks, the postings and the startups: everyone builds the checks, nobody signs the meaning. The seat is empty, and it was ours all along. We just never built a platform under it.

To the platform engineers reading this: thank you for the way you think. We're borrowing it. The signature stays with us.

The name

This is a different job from the one in GRC's job description today. Different enough that it needs its own name, and I've been careful with names since watching what the market did to the last one I helped coin.

Developers didn't scale by writing more scripts. The center of gravity moved: DevOps made delivery everyone's job, platform engineering turned the tooling into a product, developer experience became the yardstick, and now the same stack is being rebuilt for agents. Each wave kept the last one and asked a better question. GRC Engineering was our DevOps wave. This is the rest of the ladder.

Remember the north-star metric I told you to hold? Platform engineering's is developer experience. The entire discipline is measured on how it feels to consume what they built.

I call it GRC Experience. GRCX for short. GRC rebuilt as the layer everyone else experiences: on tap, embedded, machine-readable, signed.

It's what comes after GRC Engineering because it's where GRC Engineering was heading the whole time. The engineering was the tool. The job is the meaning, and the job was open.

The part where I could be wrong

This ships with its falsification conditions attached, because a discipline that measures everyone else should enjoy being measured.

If builders and their agents, offered answers on tap and compliant paths that are also the easy paths, still route around GRC, the experience bet dies: you can't claim the DX playbook if nobody enjoys consuming what you built.

If auditors and customers, offered evidence that is bound to a deploy and expires, still choose more static evidence, and their reasons hold up, the evidence half dies. And if the measurable version fails to beat its own baselines where it's being piloted, you'll read those numbers here, ugly as found.

Next issue: the GRCX canon. The principles, the ontology, and what a GRC compiler actually compiles.

That’s all for this week’s issue, folks!