What is the short answer?
When the law, guidance, or your interpretation changes, publish a new fixed version of the compliance workflow. Do not silently edit the version that produced earlier decisions.
The safe model is straightforward:
- keep the old published version unchanged;
- prepare the updated interpretation as a new version;
- record what changed and why;
- test the new version against the cases it is meant to handle;
- move new work to it deliberately; and
- leave every earlier record tied to the exact version it used.
This is not versioning for its own sake. It answers a question that appears whenever someone reviews an old compliance decision:
What did this workflow ask, check, and conclude at the time?
If the underlying logic can be rewritten after completion, that question becomes surprisingly difficult to answer.
Why is overwriting the current workflow dangerous?
Imagine an incident-notification assessment completed in January. It collected five facts, applied a threshold, and concluded that notification was not required.
In June, new guidance changes the interpretation. The team edits the live workflow in place. It now collects a sixth fact and applies a different threshold.
The January record still says “notification not required,” but what does that statement now mean?
- Was the sixth fact asked and left unanswered?
- Did the old or new threshold produce the conclusion?
- Did the person see the old warning or the revised warning?
- Was the exception available at the time?
- Can the original decision be reproduced?
A timestamp alone does not answer those questions. The record also needs a stable relationship to the questions, rules, calculations, explanations, and source material used at that time.
The accountability principle in GDPR Article 5(2) requires a controller to be able to demonstrate compliance with the Article 5 principles. That provision does not prescribe software versioning. But it illustrates the wider operational problem: saying that a compliant process existed is weaker than being able to show which process actually governed a particular event.
Regulatory interpretation changes even when the underlying article number stays the same. The European Data Protection Board, for example, publishes its breach-notification guidance with an identifiable status and version; its current page presents Guidelines 9/2022 as final version 2.0. If authoritative guidance can have editions, the operational workflow derived from that guidance needs an equally legible history.
What should a version preserve?
A useful version is more than a copy of the visible form.
It should preserve the complete interpretation used to produce the result:
- Source and scope: the law, provision, guidance, jurisdiction, and circumstances the workflow claims to cover.
- Questions: the facts collected, their types, and which answers were required.
- Conditions: when a question appeared, became required, or triggered another action.
- Calculated outcomes: the applicability decision, deadline, score, category, or next step derived from the answers.
- Validation: what blocked completion, what produced a warning, and what information was merely advisory.
- Presentation: the labels, explanations, placeholders, and choice wording shown to the person completing it.
- Time logic: which interpretation applied on a particular legal or operational date.
- Release context: who published it, when it was published, and the explanation of what changed.
Presentation belongs on that list for a reason. Changing “Are you established in the EU?” to “Do you offer goods or services to people in the EU?” is not a cosmetic rewrite. It can change how people understand the question and therefore change the answers entering the decision.
Even a genuinely cosmetic correction should create a new published version if published versions are meant to be permanent. The release note can say that no decision logic changed. The important thing is that the historical version remains honest.
Is a release version the same as an effective date?
No. They answer different questions.
The release version identifies the fixed workflow document. It tells you exactly which questions, rules, calculations, and wording were published together.
The effective date chooses which legal time period applies to the facts. It tells the engine which interpretation to use for a case dated before or after a legal change.
Suppose a reporting threshold changes on 1 January 2027. A new workflow version might be published in December 2026 so teams can test it before the change. Inside that version, one time period can retain the rules valid through 31 December 2026 and another can begin on 1 January 2027.
That separation matters because the date of software publication is not necessarily the date a legal rule becomes effective.
It also supports late work. A case entered in February 2027 might concern an event that happened in December 2026. If the workflow only knows “the newest rules,” it may apply the wrong threshold to the old event. A temporal model can select the December interpretation while the completed record still identifies the exact workflow release that performed the calculation.
A practical rule is:
- use a new release when the published interpretation document changes; and
- use legal time periods when different rules must apply to different effective dates inside that document.
Do not use a version number as a disguised validity date. And do not assume that “latest” always means “legally applicable to this event.”
Should a workflow follow the latest version or stay fixed?
It depends on what the workflow is for.
Follow the latest compatible version
This is useful when an organisation relies on a maintained interpretation and wants new completions to receive safe updates without reconnecting the workflow manually.
It fits situations where:
- the publisher is trusted to maintain the interpretation;
- the organisation wants routine corrections and legal updates;
- the new release remains compatible with the chosen Flow experience; and
- internal change controls permit managed automatic updates.
“Latest” should still mean the latest compatible published release, not whatever happens to be in an author’s draft.
Stay fixed to one published version
This is useful when the organisation must approve every change before it affects production.
It fits situations where:
- a regulated process has a formal validation or sign-off cycle;
- an integration expects a stable set of fields or outcomes;
- a contract names a particular interpretation;
- training or internal procedures depend on the current wording; or
- the organisation needs a controlled migration window.
Fixed does not mean forgotten. The organisation should still monitor newer versions, deprecation warnings, and changes in the controlling source.
The choice is therefore not “safe” versus “unsafe.” It is a choice between two kinds of change control: managed adoption of compatible releases, or explicit approval before migration.
What counts as a meaningful change?
If a change can affect what a person is asked, what they understand, whether they can complete, or what result the workflow produces, treat it as meaningful.
Clear examples include:
- adding or removing a required fact;
- changing an applicability threshold;
- altering an exception;
- changing a deadline calculation;
- adding a new possible outcome;
- changing which answers create a warning or error;
- changing a confirmation the respondent must make;
- changing the jurisdiction or legal reference; and
- changing a time period or the rules attached to it.
Some changes do not alter the legal conclusion but still deserve a new version:
- clarifying an instruction;
- correcting a misleading label;
- replacing an outdated official source link;
- adding a placeholder or information note; or
- improving the order in which facts are collected.
The release note should distinguish these. “Clarified the incident description; no rules or outcomes changed” is much more useful than “minor update.”
What should not count as a published change? Work inside an unpublished draft. Authors need freedom to edit, test, and discard unfinished ideas without creating a public version for every keystroke. The boundary is publication: drafts can move; published versions should not.
How do you release a change without breaking history?
A reliable process does not need to be bureaucratic. It needs to make the important decisions visible.
1. Identify the trigger
Record what prompted the update: amended legislation, new regulator guidance, a court decision, a corrected interpretation, user feedback, or an operational defect.
Link to the controlling source where possible. “The law changed” is not enough for the next reviewer.
2. Start from the current published version
Create a new working version from the release already in use. This preserves continuity and makes the comparison meaningful.
Do not edit the published release. Do not create an unrelated copy that loses its history.
3. Separate present rules from future rules
If the change has a future effective date, represent that date explicitly. Keep the earlier legal period available for cases that still belong to it.
4. Review the complete difference
Look beyond visible fields. Compare rules, calculations, possible outcomes, legal references, time periods, attestations, and presentation guidance.
A short field list can hide a large decision change.
5. Test decisions, not just screens
Use cases on both sides of every changed condition. Test the boundary itself, the value immediately below it, and the value immediately above it.
If a deadline changed, test dates before, on, and after the transition. If an exception changed, test a case that qualifies and one that almost qualifies.
6. Explain the change in ordinary language
A useful release note answers:
- What changed?
- Why did it change?
- Who will receive a different result?
- When does the new interpretation apply?
- Does an adopter need to change an integration or procedure?
7. Publish, then migrate deliberately
Publishing makes the version available. It should not rewrite earlier records.
Flows that follow compatible latest releases can move according to their policy. Fixed Flows should remain where they are until their owner approves the new version.
What should happen to the old version?
Keep it.
An old version can stop being recommended for new work without disappearing. That is what deprecation is for.
Deprecation should communicate:
- that a newer or corrected version exists;
- why the old version should not be chosen for new work;
- which replacement to use; and
- whether existing completions or integrations remain available.
Deleting the old version destroys part of the explanation for historical records. Replacing its contents is worse: the identifier remains, but its meaning changes underneath the records that cite it.
The old version is not clutter. It is evidence of what the system knew and did at the time.
There is one important distinction: preserving a workflow version does not require preserving every piece of personal data forever. Retention and deletion rules still apply to completed records and their contents. The stable release explains the logic; the record-retention policy controls how long case data remains available.
How does ProseID handle regulatory change?
ProseID separates working changes, published versions, legal time periods, and completed records.
An author edits a private working version, reviews the complete difference, explains the change, and prepares a fixed version for review or publication. Once published, that version remains protected. Further work begins as the next version rather than altering the release already in use.
Within a schema, legal time periods can select different definitions, rules, calculations, and sign-offs according to the record’s effective date. That lets one maintained interpretation handle a transition without pretending that the new rule governed older events.
When an organisation creates a Flow, it can follow the latest compatible release or remain fixed to one published version. Every completion creates a record tied to the exact release used, including its validated responses and calculated outcomes.
That gives each layer one job:
- the working version is where change happens;
- the published version is what users and integrations can depend on;
- the legal time period determines which dated interpretation applies;
- the Flow policy determines whether new compatible versions are adopted; and
- the completed record preserves what happened in one case.
If you are modelling the interpretation yourself, the visual schema builder guide explains how questions become rules and calculated outcomes without requiring code. You can also try a real ProseID Flow before creating a schema in your workspace.
The objective is not to make regulatory change disappear. It is to make each change deliberate, reviewable, and compatible with the history that already exists.