Imagine an engineer designing a bridge. Before anyone is allowed to drive across it, the structure is analyzed, simulated and tested. Critical joints are inspected. Welds are examined. Materials are subjected to stress. Engineers actively look for weaknesses before trusting the structure with real-world loads. No engineer would consider that optional.
Now consider enterprise policy. Policies determine who receives healthcare, who qualifies for insurance, whether a financial transaction is approved, how taxes are calculated, whether an AI agent may perform an action, or whether an employee gains access to sensitive systems. In many organizations, these decisions affect millions of people every day.
Yet the policies themselves are often accepted with remarkably little structural analysis. That raises an interesting question.
Why do we engineer bridges more rigorously than we engineer the policies that govern our businesses?
A lesson from structural engineering
One technique used in structural and materials engineering is the wedge test. A wedge is inserted into a bonded joint or structural seam to deliberately apply stress. The objective isn't to break the structure. The objective is to reveal weaknesses that already exist.
If a crack propagates, if an adhesive fails, or if a hidden defect becomes visible, the wedge has done its job. It hasn't created the weakness — it has exposed it. Only after those weaknesses are understood can engineers have confidence in the finished structure.
Enterprise policies also have structural weaknesses
Business policies rarely fail because someone wrote bad software. More often, the software faithfully implements a policy that was never structurally sound in the first place. Anyone who has worked with regulations, contracts or operating procedures has encountered statements like these:
- “Use reasonable discretion.”
- “Escalate significant cases.”
- “High-risk customers require additional review.”
These sound perfectly reasonable to a human reader. A compiler sees something different. What is “reasonable”? How is “significant” measured? What defines “high risk”? The software cannot infer these answers. Neither should it.
Compilers are surprisingly honest
Traditional software compilers are uncompromising. If a program contains contradictory or incomplete instructions, compilation stops. Enterprise policy deserves the same treatment.
When Sertainly compiles policy into executable decision services, it deliberately searches for structural weaknesses:
- Does the policy contradict itself?
- Is an important concept undefined?
- Are approval thresholds inconsistent?
- Does one clause invalidate another?
- Has an edge case been forgotten?
Rather than making assumptions, Sertainly stops and surfaces what it calls a Wedge.
The Wedge doesn't fix the policy
This is an important distinction. The Wedge is not an AI correction. It isn't an automated rewrite. It isn't an attempt to guess what the policy author probably meant. Instead, it identifies the exact location where human judgment is required. The compiler effectively says:
“This policy cannot yet be compiled with confidence. Here's why.”
That's a fundamentally different philosophy from systems that silently invent behavior to bridge gaps in incomplete requirements — the same reason a compiled decision package isn't the same thing as AI-generated code that merely runs.
Pressure reveals structure
The name “Wedge” is intentional. Just as engineers apply controlled stress to evaluate a structural joint, Sertainly applies analytical pressure to enterprise policy. If the policy is internally consistent, compilation proceeds. If hidden weaknesses exist, they are exposed before they become production defects.
This is not about making policy more complicated. It is about making policy more trustworthy.
Engineering policy
Software engineering transformed dramatically when compilers became commonplace. Developers stopped thinking in machine code. Modern engineering disciplines introduced testing, verification, static analysis and continuous integration. Physical engineering followed similar paths decades earlier.
Enterprise policy is only beginning to experience the same evolution. Historically, policies have been treated as documents. Then they became business rules. We believe the next step is to treat them as engineered systems. Engineered systems deserve:
- structural analysis;
- deterministic compilation;
- traceability;
- repeatable testing;
- explainable behavior;
- and rigorous validation before deployment.
The Wedge is one small part of that philosophy — the same one that makes a compiled decision explain itself by construction, and treats the source document as the system of record.
The cost of hidden weaknesses
Most policy failures are discovered the hard way. A customer is incorrectly denied. A tax calculation is wrong. A compliance audit fails. An AI agent makes an unauthorized decision. By then, the weakness has already reached production.
Engineering has always preferred finding defects before deployment. Policy should be no different.
Looking forward
As organizations increasingly rely on AI to transform policy into executable software, confidence in the underlying policy becomes more important — not less. AI can accelerate implementation. It should not reduce engineering discipline.
The Wedge embodies a simple principle borrowed from structural engineering: before trusting a structure, deliberately apply pressure to reveal its hidden weaknesses. We believe enterprise policy deserves exactly the same treatment.
The wedge doesn't create the crack. It finds it — while there's still time to fix it.