Intent should align with outcomes.
It sounds obvious.
Yet most organizations have no reliable way to verify that it does.
Policies exist.
Controls exist.
Accountability often does not.
Evidence is fragmented.
The gap between intent and outcomes is where governance failures live.
Modern organizations run on software.
Infrastructure is programmable.
Identity is programmable.
Security is programmable.
AI systems are programmable.
Governance is not.
Programmable Assurance is the discipline of ensuring it is.
About three weeks ago I published a definition of Programmable Assurance that I was genuinely proud of.
Then I spent three weeks building, shipping, watching an AI independently discover and classify what I was building without being told what it was, and having a lot of uncomfortable conversations about what governance actually means to people who are not engineers.
I realized the definition was too small.
Not wrong. Too small.
The original definition described the mechanism.
The new definition describes the outcome.
Here is what I wrote in June:
"The discipline of expressing organizational intent as executable, verifiable, explainable, and continuously enforceable governance logic."
When I said that to engineers, they understood it immediately.
When I said it to a Chief Risk Officer, she heard "developer problem."
When I said it to a General Counsel, he asked if it was a compliance scanner.
That is not a communication problem.
That is a definition problem.
The original definition explained how Programmable Assurance works technically.
It did not explain what problem it solves organizationally.
The New Definition
Programmable Assurance is the discipline of continuously aligning intent with outcomes through executable governance, accountability, evidence, and feedback.
For those who want the full scope boundary:
Programmable Assurance is the discipline of making governance intent executable, continuously enforceable, and accountable — governing the organizational decisions, systems, and responses through which intent becomes reality, with evidence and feedback that close the gap between the two.
The shorthand explains the outcome.
The canonical definition explains the mechanism.
Both describe the same idea.
The problem Programmable Assurance solves is not fundamentally a technical problem.
It is an organizational one.
Why the Original Definition Was Too Narrow
The original definition treated intent as an engineering design pattern.
YAML conditions.
Policy DSL files.
Terraform plans.
That framing works when you are governing infrastructure.
It breaks the moment someone asks whether Programmable Assurance applies to an NDA policy, a procurement approval, or a board-level risk acceptance.
Those have no pipeline.
No condition expression.
No deployment.
But they still have intent.
They still have decisions.
They still have accountability.
And when they fail, someone still needs evidence of what happened.
The original definition excluded those cases by accident.
I had been so focused on the infrastructure use case — which is where my own implementation starts — that I wrote a definition for a product instead of a category.
That mistake compounds.
If the category definition is too narrow, every future expansion requires re-educating the market.
I would rather define it correctly once.
What Programmable Assurance Actually Argues For
Programmable Assurance is not a topology.
It is not a deployment model.
It is not a governance architecture.
It is a behavioral argument.
Whatever governance you have — wherever it lives — it should behave four ways.
Intent Must Be Executable
Governance that exists only as a document is aspiration, not governance.
Intent becomes governance when it can influence, constrain, verify, or record the behavior it governs.
For a security policy that might be a condition that evaluates before a deployment executes.
For a procurement policy it might be an approval gate.
For a board-level risk acceptance it might be a signed ledger entry recording who accepted the risk and when.
The form changes.
The requirement does not.
Enforcement Must Be Continuous
Annual audits tell you what happened.
They do not prevent what happens next.
By the time an auditor reviews a control, the violation has already occurred.
The breach has already happened.
The bill has already arrived.
Real governance operates at the speed of change.
It runs whenever relevant decisions occur.
Not months later.
Every Decision Must Be Accountable
This one is personal.
I have watched security teams get blamed for outcomes created by decisions that nobody documented.
The risk was raised.
Leadership declined to act.
The record disappeared into email threads.
Years later, when something went wrong, nobody could reconstruct who decided what.
Accountability is not blame.
Accountability is the record that connects intent to decision to outcome.
Without that record, governance becomes theater.
With it, governance becomes defensible.
Outcomes Must Feed Back Into Intent
Governance that does not learn eventually becomes wrong.
Organizations change.
Risk profiles change.
Regulations change.
Business priorities change.
A governance system that cannot observe outcomes has no mechanism for knowing when its assumptions no longer match reality.
The feedback loop is what keeps intent aligned with outcomes over time.
Without feedback, governance stagnates.
With feedback, governance improves.
The Scope Boundary
Programmable Assurance applies wherever organizational intent can be translated into governable decisions, evidence, accountability, and feedback.
It does not govern human free will.
It governs the systems and decisions that respond to, record, authorize, and account for human behavior.
A harassment incident cannot be prevented by software.
But the investigation workflow, the evidence chain, the accountability record, and the organizational response absolutely can be governed.
Those systems matter.
And they are governable.
The Founding Insight
The insight did not come from a single incident.
It emerged repeatedly across every layer I operated in.
Because of the nature of my work, I was often responsible for the entire lifecycle.
I helped establish intent.
I translated that intent into policies and controls.
I implemented those controls across cloud platforms and security systems.
I operated the environments those controls governed.
I investigated the outcomes when things failed.
And I was responsible for the financial consequences when they did.
Most people experience only one layer of that process.
An engineer sees implementation.
A compliance officer sees policy.
A security analyst sees findings.
A finance team sees costs.
I was moving between all of them.
And from every layer, I kept encountering the same failure in a different form.
As an engineer, I saw tools that reported what had already gone wrong.
The cloud bill arrived after the spend.
The breach notification arrived after the incident.
The compliance finding arrived after the audit.
Systems designed to monitor outcomes rather than prevent them.
As a security practitioner, I watched engineers encounter controls they did not understand.
A policy blocks a deployment.
The engineer sees friction.
They find a workaround.
The control fails not because it was wrong—but because it never explained why it existed.
Nobody told them the business reason, the regulatory obligation, or the financial consequence attached to disabling it.
A control that is enforced but not understood creates friction.
A control that is enforced and understood creates alignment.
When I was starting out, I wished someone had explained the why behind every enforcement.
That MFA was not just a configuration checkbox.
It was a regulatory obligation with financial exposure attached.
That understanding would have made me a better engineer faster.
It would have made compliance drift less likely.
As a policy author implementing controls in Microsoft Purview, Azure Policy, and Entra ID, I stopped one afternoon and asked a simple question:
Will any engineer who encounters this control know why it exists?
The answer was no.
And I realized something larger.
The intent was in SharePoint.
The policy was in Azure Policy.
The enforcement was in Entra ID.
The evidence was in Azure Monitor.
The budget controls were somewhere else entirely.
None of those systems had any awareness of the others.
No shared vocabulary.
No shared evidence.
No shared feedback.
Each system saw only its own slice of the picture.
Different systems.
Different layers.
Different problems.
The same underlying failure.
Organizations define intent in one place,
execute it somewhere else,
measure it somewhere else,
and explain it nowhere.
That is Governance Fragmentation.
That is the Intent-Reality Gap.
That is the problem that kept appearing from every angle, no matter which layer I was operating in.
The cloud bill was a symptom.
The bypassed control was a symptom.
The policy nobody could find was a symptom.
The risk acceptance nobody could reconstruct was a symptom.
The disease was always the same:
intent and outcomes were disconnected.
Programmable Assurance closes that gap.
Not with more policies.
Not with better dashboards.
With systems that connect intent to outcomes—and carry that intent all the way to the execution layer where it can actually change behavior—with evidence that proves it did.
The vision existed long before I had language for it.
The definition finally says it in a way that scales with it.
Aisha Ibrahim. is the founder of ObsidianWall, building infrastructure for Programmable Assurance. obsidianwall.com
If you missed the original definition article, it is here.
Top comments (0)