If you ask someone where the business logic lives in a traditional rules engine, the answer is usually obvious. It lives in the rules.
Whether those rules are written in Drools, DMN, IBM ODM, Corticon or another technology, the executable rule base eventually becomes the authoritative representation of the organization's policy. When the policy changes, the rules are edited. Over time, they become the source of truth.
Sertainly deliberately rejects this model. In Sertainly, the source document is the source of truth. Everything else is generated. That simple idea has profound implications.
The traditional lifecycle
For decades, the lifecycle of enterprise decision logic has looked something like this:
- Read a policy document.
- Translate it into executable rules.
- Test the rules.
- Deploy them.
- Edit the rules when the policy changes.
Eventually, something interesting happens: the rules become more accurate than the policy document. Developers fix bugs. Business analysts tweak edge cases. Exceptions are added. Clarifications accumulate. Eventually someone asks, “is the policy document still correct?” — and nobody really knows. The executable rules have become the real policy. The document has become historical context.
The drift problem
This phenomenon is known as policy drift. The written policy and the executable implementation slowly diverge — sometimes intentionally, sometimes accidentally, sometimes simply because the organization forgets to update both. Over time, maintaining consistency becomes increasingly expensive.
When regulators ask why a decision was made, engineers inspect rules. When lawyers ask what the policy says, they inspect documents. Those two answers are not always identical.
AI changes the economics
Large language models fundamentally change the cost of translation. Translating policy into executable software is no longer the expensive part. Maintaining confidence that the executable software still reflects the policy is.
That shifts the optimization target. Rather than treating executable policy as a permanent artifact that evolves independently, Sertainly treats it as something that can be regenerated whenever the source changes.
The executable package becomes disposable. The policy does not.
Compiled, not authored
One useful analogy is a C compiler. Nobody edits the machine code. Developers edit the source code, and the machine code is regenerated. Enterprise policy should work the same way.
The legislation. The contract. The operating procedure. The underwriting guide. The security policy. These are the assets. BDL packages are compiled artifacts. If the source changes, regenerate them. Do not manually maintain them.
Human review doesn't change the model
This does not mean humans disappear from the process. Quite the opposite. Humans review:
- discovered use cases;
- generated requirements;
- acceptance tests;
- compiled packages;
- deployment decisions.
What they do not review is whether the generated package should become a new independent source of truth. It never does. Every approved package remains traceable back to the policy that produced it.
Version the source, not just the package
Traditional systems often focus on versioning executable rules. Sertainly versions the policy corpus itself. A new version of a regulation. A revised insurance manual. An amended contract. A new security standard. These become new source versions, and new packages can be compiled from them.
Older deployed packages continue to exist as immutable historical artifacts. Nothing silently changes in production — a discipline we treat as load-bearing in When the Rules Change.
Regeneration instead of maintenance
This is perhaps the biggest conceptual shift. Suppose a regulation changes. The traditional question is: which rules should we edit? The Sertainly question is: which source changed, and which packages should be regenerated?
That may sound like a subtle distinction. It isn't. One assumes the executable artifact is permanent. The other assumes it is reproducible.
Provenance is never lost
Because every package is derived from a source document, provenance becomes part of the lifecycle. Every decision can be traced to:
- the source document;
- the relevant passage;
- the generated requirement;
- the compiled logic;
- the acceptance tests;
- the deployed package version.
Nothing is disconnected from its origin. That dramatically simplifies audits, reviews and policy evolution — and it's why a compiled package can explain itself by construction rather than after the fact.
The compiler becomes strategic
Thinking this way also changes the role of the compiler. The compiler is no longer just translating one language into another. It becomes the mechanism that preserves intent while transforming human-readable policy into deterministic software. Its job is to ensure that:
- meaning is preserved;
- requirements are captured;
- provenance is retained;
- tests are generated;
- executable artifacts are reproducible.
The executable package is the outcome of that process — not the asset being managed.
Why this matters
Organizations rarely struggle because they cannot write rules. They struggle because policies evolve faster than implementations. Every new regulation, contract amendment or internal policy change creates uncertainty: which systems are affected? Which rules need updating? Which decisions have changed?
By treating source documents as the permanent system of record and executable packages as regenerable artifacts, Sertainly changes the maintenance model entirely.
Instead of maintaining executable policy, organizations maintain policy. Everything else can be rebuilt.
Looking forward
Software engineering has long embraced the idea that source code is the asset and binaries are disposable. We believe enterprise policy should evolve in exactly the same direction. The legislation, contracts, standards and policies that govern an organization are the assets. Executable decision packages are simply compiled representations of those assets.
That's why, in Sertainly, the source document is — and always remains — the only source of truth.