In March, your system denied a loan application. Today — maybe years later — someone asks you why. A regulator during an audit. A lawyer in discovery. The applicant themselves. The honest answer is easy to state: the rules that were in force in March said so. The hard part is proving it.
Because the rules have changed since March. The threshold moved. A new condition was added. Someone caught a mistake. To answer the question truthfully, you don't need to know what your system decides today — you need to reconstruct what it decided then: the exact logic, applied to that exact case, on that exact date. Most automated decision systems cannot do this. Not because the engineers were careless, but because versioning decisions is a genuinely hard problem, and almost nobody treats it as one until it is too late.
Versioning code is solved. Versioning decisions is not.
Software teams have versioned code for decades. Git, semantic versioning, immutable deployments — the tools are mature and the discipline is widespread. So it is tempting to assume that versioning a decision system is the same problem with a different payload. It is not.
Code versioning answers: what does the system do now, and how did we get here? Decision versioning has to answer a stranger, harder question: what did the system decide for a specific case, on a specific date, under rules that may since have been replaced, corrected, or retired — and can you prove it, on demand, to someone who does not trust you?
That is not a deployment problem. It is a problem of time, provenance, and intent — and it has pitfalls that catch even careful teams. Here are the ones that hurt the most.
The pitfalls nobody warns you about
Pitfall 1: You overwrite the past. The simplest way to ship a rule change is to edit the live rules in place. It is also the most dangerous. The instant you do, every past decision becomes unreproducible — the logic that made it no longer exists anywhere. You can still see the outcome you recorded, but you can no longer demonstrate how it was reached. An auditor does not want your assurance that the old rule said X; they want to re-run the case and watch X happen.
Pitfall 2: You treat every change as the same kind of change. There is a world of difference between “we raised the threshold because the world moved on” and “we raised the threshold because the old one was a mistake that had been quietly making wrong decisions for months.” The first is an improvement; the past was fine. The second is a defect; the past was wrong and may need remediation. Systems that lump these together under a single “update” quietly erase the distinction that matters most to a regulator — and rob you of the ability to say, truthfully, which past decisions you stand behind.
Pitfall 3: “Latest wins” routing. Most systems run whatever version is deployed right now. So when you re-run that March application to investigate it, you get today's answer, under today's rules — which may be a different answer entirely. The decision you are trying to explain silently changes underneath you as you investigate it. “Live in production” came to mean “whatever is newest,” and the moment it did, the past stopped being reproducible.
Pitfall 4: The change is ungrounded. A rule changed. Why? Who authorized it? Against which version of which source document? If the answer lives in a Slack thread, a ticket, or someone's memory, you do not have a change history — you have a guess with a timestamp. Real governance requires that every change to a live decision be traceable to an authority and a reason, not just a diff.
Pitfall 5: You cannot see the blast radius. Suppose you discover that a rule was wrong. The first question is never academic — it is “how many decisions did this get wrong, and who are they?” Most systems cannot tell you. They can fix the rule going forward, but the population of people already affected is invisible. So remediation becomes a manual archaeology project, or worse, it does not happen at all.
Pitfall 6: The rules drift from their source. Decisions are derived from something — a policy document, a regulation, a contract, a directive. Over time those sources change too. The document gets revised but the rules do not; or the rules get tweaked but no longer match any document anyone can point to. Either way the thread back to authoritative source snaps, and “why does the rule say this?” becomes unanswerable.
Each of these is survivable on its own. Together, they are how a decision system that worked perfectly on launch day becomes, two years and forty changes later, something nobody can fully account for.
The deepest pitfall: there are two clocks, not one
Underneath all of this sits an idea that most systems never make room for. When you reason about a decision, there are two different times that matter, and they are not the same:
The first is when the decision was made — the moment your system actually ran. The second is the date the case is “as of” — the application date, the policy effective date, the date of loss, whatever your domain treats as authoritative for which rules should govern.
These come apart constantly. You process a backlog of July applications in October. You re-run a 2024 claim during a 2026 audit. You backfill a decision for a case dated last quarter. In every one of these, the question “which rules apply?” has nothing to do with the wall clock and everything to do with the case's own date. A system with only one clock — “what is deployed now” — gives the wrong answer every single time. The ability to keep these two clocks separate, and to route by the one that matters, is the difference between a decision you can defend and one you merely remember.
This is not exotic. Accountants, actuaries, and lawyers have always reasoned this way — “by the rules in effect at the time.” What is rare is software built to honor it.
What it takes to get this right
Sertainly is a platform for compiling decision logic into deterministic, citation-bearing decision APIs — and versioning is not a feature bolted onto it. It is part of the foundation. Here is how each pitfall is answered by construction.
A live version never changes. Once a policy is making real decisions, it is frozen. Any change — however small — becomes a new version. You never edit live rules in place. This one discipline is what makes everything else possible: the exact rules that decided a case still exist, unchanged, ready to be re-run to prove the same answer years later.
A version that is live and making decisions never changes. Every change is a new version, and every past decision stays reproducible.
Change is typed honestly — editions versus corrections. An edition is the policy genuinely moving on; the prior version is gracefully retired, still completely valid for the period it governed. A correction means a live version was defective; it is withdrawn, not quietly retired, and its replacement applies retroactively. The platform never lets you confuse “we improved it” with “we were wrong” — because that distinction is exactly what an auditor, and your own conscience, depends on.
Decisions route by date, not by “latest.” Each release is bound to an effective date window, and every evaluation is routed to the version that was in force on the date that matters for that case — read from the case's own data. The two clocks stay separate. A loan dated March is judged by March's rules forever, even after ten newer versions ship, and even if you re-run it during a 2030 audit.
When something was wrong, you measure it — and remediate it. Mark a version as a correction and Sertainly replays every decision that version actually made, re-running those real cases through the corrected rule, and tells you precisely how many come out differently — and who they are. That is not a risk estimate. It is a remediation worklist: the specific people to re-decide and contact.
Every change is grounded; every decision traces to source. Change can only enter as grounded source — a new document version, an added document, or a captured directive with its authorizer and effective date. Nothing changes on a hunch. And every decision can be walked back, link by link, from the answer to the release in force on its date, to the version, to the requirement behind each outcome, to the exact paragraph of source text it came from. Nothing is inferred; everything is recorded.
Why this is the architecture, not a feature
You cannot add honest versioning to a system later, the way you might add a column to a table. It has to be true all the way down — in how rules are stored, how change is admitted, how a case is routed to a version, how a decision is traced. Bolt it on after the fact and you get a version label with none of the guarantees underneath: the past is still overwritten, the routing still says “latest,” the blast radius is still invisible.
That is why Sertainly treats it as foundational. The same architecture that makes a decision explainable — compiled from authoritative source, deterministic at runtime, traceable to citation — is what makes it versionable with integrity. They are the same property seen from two angles: a decision you can fully account for, today and forever.
Rules will change. Regulations republish, committees revise, mistakes surface. The question is never whether your decision logic will change — it is whether, after it changes a hundred times, you can still stand behind every decision it ever made. With Sertainly, the answer is yes. Change is constant; trust is permanent.