ObsidianWall vs. Policy-as-Code

How ObsidianWall relates to OPA, HashiCorp Sentinel, and other Policy-as-Code engines — and why they are not competitors at the same layer.

The most common question engineers ask when they see ObsidianWall is: how is this different from OPA, Sentinel, or Checkov?

The honest answer: they are not competitors. They operate at different layers of the governance stack.

The Short Answer

Policy-as-Code engines answer one question: did the rule pass?

ObsidianWall answers five questions every governance decision requires: should this happen, who is accountable, what does it cost, who needs to know, and did the system learn from it?

Policy-as-Code is an ingredient. ObsidianWall is the meal.

What Policy-as-Code Does Well

Open Policy Agent (OPA), HashiCorp Sentinel, and similar engines are genuinely excellent at one thing: evaluating structured data against a policy at a specific point in time.

Input:   Terraform plan JSON
Policy:  Rego / Sentinel policy file
Output:  true / false

This is fast, deterministic, and battle-tested at massive scale. Rego is a powerful, Turing-complete policy language. If you need raw evaluation logic, OPA is a mature, capable choice.

Where Policy-as-Code Stops

Three specific limitations show up the moment a policy evaluation needs to operate inside a real organization rather than a CI pipeline in isolation.

1. Binary rigidity

A raw policy engine returns pass or fail. There is no native concept of “this should require approval” or “this should notify the budget owner but proceed.” If a mission-critical hotfix violates a minor tagging rule, the binary engine simply breaks the pipeline. There is no nuance between a hard stop and a soft warning with accountability attached.

2. No human context

A policy engine cannot answer: who has the authority to override this rule? Why did they override it? Did the appropriate stakeholder sign off? When an engineer bypasses a check with a #ignore comment or a pipeline override flag, that decision typically leaves no structured, queryable record of who made it or why.

3. Point-in-time blindness

Policy-as-Code validates a static file before deployment executes. It has no visibility into whether the deployment actually succeeded, or what the infrastructure looks like five minutes — or five months — later. It captures zero “reality evidence.” There is no mechanism for verifying that the deployed state still matches what was authorized.

What ObsidianWall Adds

ObsidianWall does not replace the evaluation mechanic. It wraps it in the four things a complete governance system requires.

1. Five-level typed decisions instead of pass/fail

ALLOW
ALLOW_WITH_NOTIFICATION
ALLOW_WITH_APPROVAL_REQUIRED
DENY_WITH_OVERRIDE
DENY

Instead of a binary gate, every evaluation produces a typed decision with explicit routing. A failed condition does not have to mean a broken pipeline — it can mean a notification to the budget owner, a required approval from a security lead, or an authorized override path.

2. Named accountability on every decision

Every override, approval, and exception is captured with a named person, a named policy, and a named date — written to an immutable audit artifact. This is the structural difference between a #ignore comment buried in code and a governance decision an auditor can review six months later.

3. Technical Risk and Governance Risk as separate dimensions

A deployment can have Technical Risk of 0 and Governance Risk of Critical simultaneously. A policy engine alone cannot express this distinction — it only knows whether the rule passed. ObsidianWall separates “is this technically misconfigured” from “does this violate an organizational obligation,” because these are genuinely different questions with different owners.

4. Post-deployment verification

Verdict evaluates before deployment. Sentinel verifies after. The two together check that the operational reality stayed aligned with what was authorized — closing a gap that point-in-time policy evaluation cannot see by design.

The Architectural Relationship

                    Human Intent
                         │
                         ▼
              ┌─────────────────────┐
              │  ObsidianWall        │
              │  (Governance Layer)  │
              │                      │
              │  Five-level decision │
              │  Accountability      │
              │  Risk separation     │
              │  Post-deploy verify  │
              └──────────┬───────────┘
                         │
                         ▼
              ┌─────────────────────┐
              │  Policy Evaluation   │
              │  (Mechanic Layer)    │
              │                      │
              │  OPA / Rego          │
              │  Or ObsidianWall's   │
              │  native YAML engine  │
              └──────────┬───────────┘
                         │
                         ▼
                  Terraform Plan /
                  CloudFormation

A policy engine could sit underneath ObsidianWall as the evaluation mechanic. ObsidianWall’s current native policy format is simpler YAML rather than Rego — by design, to lower the barrier for platform and security teams who are not engineering specifically in policy DSLs. But the architectural relationship is what matters: ObsidianWall orchestrates evaluation, accountability, risk separation, and verification. Policy-as-Code engines provide the evaluation primitive.

When to Use What

Use raw Policy-as-Code (OPA, Sentinel) when:

  • You need maximum flexibility in policy logic
  • Your team already has Rego expertise
  • You only need pass/fail enforcement with no accountability layer
  • You are governing at a layer where post-deployment drift is out of scope

Use ObsidianWall when:

  • You need typed decisions beyond pass/fail
  • You need named accountability for overrides and exceptions
  • You need compliance coverage mapping (HIPAA, SOC 2, CIS v8, NIST AI RMF)
  • You need to separate technical misconfiguration from governance violations
  • You need evidence that survives an audit six months later
  • You want pre-deployment and post-deployment verification working together

The Bottom Line

Policy-as-Code gives you the technical ability to check a file.

ObsidianWall gives you the institutional guarantee that the decision was accountable, the risk was understood in both technical and governance terms, the right people were notified, and the deployed reality still matches what was authorized.

These are not competing answers to the same question. They are answers to different questions.

Install Verdict → · What is Programmable Assurance? →