Route 143 of 176
Protocol Version Changes
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Governance rules do not stay fixed forever. QRProtocol.us periodically issues new versions of the rule sets that QRCompliance.us evaluates against — tightening a threshold, adding a required field, retiring an obsolete check. This route defines how a version change is issued, adopted and applied, and what happens to evaluations that were already run under the version being replaced.
QRProtocol.us decides what the rules say and when a new version supersedes an old one. QRCompliance.us decides whether a given identity satisfies whichever version is currently in force. A version change is authored by governance and consumed by validation — never the reverse.
A rule set is not a museum piece. As new categories of goods enter a QR-tracked supply chain, as new failure patterns surface, or as an upstream standard is amended, QRProtocol.us issues a new version of the applicable rule set. That version might add a required evidence field, change a numeric threshold, retire a rule that no longer serves a purpose, or restructure how several existing rules interact.
None of that rewriting happens inside QRCompliance.us. Version changes are authored, numbered and published by governance. What validation receives is a defined, versioned rule set together with a clear statement of when it takes effect. QRCompliance.us's only job with respect to a version change is to know which version is currently in force for a given evaluation and to apply that version consistently.
The hard part of a version change is rarely the drafting. It is the transition: identities already evaluated, certified or registered under the version being replaced do not instantly become invalid the moment a new version is published, and identities newly submitted after the change should not be evaluated against an obsolete rule set. This route defines how that transition is handled without either freezing the old rules forever or retroactively invalidating past evaluations without cause.
01Plain-English Definition
Protocol version changes are the defined mechanism by which QRProtocol.us issues a new or amended rule set, assigns it an effective date, and hands it to QRCompliance.us as the basis for evaluation going forward, while governing how identities evaluated under the prior version are treated during the changeover.
A version change is not the same thing as a single rule's day-to-day application (Route 27's territory) or the moment a rule's effective state flips on or off for a specific case (Route 144's territory). This route is about the rule set as a whole moving from one numbered version to another.
Every version carries an identifier and an effective date. QRCompliance.us records, for every evaluation it performs, which version it evaluated against. That record is what later lets an auditor determine whether an identity was judged fairly against the rules that actually applied to it at the time.
02What A Version Change Can Contain
A version change can range from a minor clarification to a substantial restructuring of what an identity must satisfy. The scope of the change determines how the transition is handled.
Threshold adjustment
A numeric or categorical threshold used by an existing rule is tightened or relaxed, without changing which rule applies or what it evaluates.
New required field
An evidence type or data field not previously required becomes mandatory for evaluation under the new version.
Rule retirement
A rule that no longer serves a governance purpose is removed from the active set, and QRCompliance.us stops evaluating against it.
Rule restructuring
Two or more rules are merged, split or reordered in how they interact, changing the evaluation logic without necessarily changing the underlying intent.
Scope expansion
A rule previously limited to one category of registered identity is extended to cover an additional category.
03Practical Value
A defined version-change mechanism keeps governance able to evolve without destabilizing the evaluations already resting on the version currently in force.
- Every evaluation can be traced to the exact rule-set version applied, supporting later audit and dispute resolution.
- Operators are not evaluated against a rule change they had no opportunity to prepare for, because an effective date is set and published in advance.
- A rule retirement does not silently invalidate every past evaluation that had relied on the retired rule's absence.
- A tightened threshold does not automatically fail identities that satisfied the version in force when they were last evaluated.
- QRCertified.us and QRRegistered.us can rely on a stable statement of which version underlies any certification or registration they act on.
04Operational Flow
A version change moves through a defined sequence from drafting to full adoption, with QRCompliance.us entering the process only once governance has finished authoring and dating the change.
- 1New version draftedQRProtocol.us authors the amended rule set, documenting exactly what changed relative to the prior version.
- 2Version published with effective dateThe new version is issued with a version identifier and a defined date on which it becomes the version in force.
- 3Compliance adopts the new versionQRCompliance.us begins evaluating any identity submitted on or after the effective date against the new version.
- 4Transition period applied where definedWhere governance specifies a transition window, evaluations in progress or pending renewal may continue briefly under the prior version.
- 5Prior evaluations reviewed for impactWhere a version change affects existing certified or registered identities, the affected records are flagged for re-evaluation on their normal review cycle rather than immediately.
QRCompliance.us does not decide when a version becomes effective. It applies whichever version governance has designated as in force on the date of each evaluation.
05Version States Over Time
A given rule-set version passes through a small number of distinct states from the moment it is drafted to the moment it is fully superseded.
| State | Entered When | Left When |
|---|---|---|
| Draft | QRProtocol.us begins authoring a new or amended rule set | The draft is finalized and assigned a version identifier and effective date |
| Published, not yet effective | The version is issued publicly ahead of its effective date | The effective date arrives |
| In force | The effective date is reached and QRCompliance.us begins evaluating against this version | A newer version is published with a later effective date |
| Superseded | A newer version becomes the version in force | All evaluations, renewals and disputes referencing this version have been resolved |
| Archived | No open evaluation, renewal or dispute references this version any longer | Never — an archived version remains part of the permanent governance record |
06Version Changes vs. Individual Rule Enforcement
It is worth separating a version change, which affects an entire rule set, from the enforcement of a single rule within a version already in force.
| Aspect | Version Change | Individual Rule Application |
|---|---|---|
| Scope | Affects the entire rule set or a defined subset of rules within it | Affects how one specific rule is evaluated for one specific identity |
| Authored by | QRProtocol.us, as a governance act with a published effective date | Already fixed by the version in force; QRCompliance.us applies it as written |
| Frequency | Periodic, tied to governance review cycles or external standard changes | Continuous, occurring on every relevant evaluation |
| Recorded as | A version identifier and effective date in QRCodex.us's governance history | An individual evaluation outcome tied to the version applied |
Confusing the two would either make every routine evaluation look like a governance event, or make a genuine version change look like an ordinary evaluation outcome — both would corrupt the audit trail's usefulness.
07System Relationship
System Chain — Six Locked Entities
- 1QuickResponseCode.usRoot / System EntryPublic entry point to the QR infrastructure.
- 2QRProtocol.usGovernance (Rules)Writes and governs the applicable rules.
- 3QRCompliance.usValidationValidates compliance readiness against applicable rules and conditions.
- 4QRCertified.usCertification AuthorityAuthorizes the QR for certification.
- 5QRRegistered.usRegistration ResultMandatorily registers the authorized QR.
- 6QRCodex.usOperations / RecordsRecords, operates, logs and preserves canonical operational truth.
No registration → no certified QR output.
A protocol version change originates in governance and is consumed downstream by every layer that relies on knowing which rule set currently applies.
| Layer | Relationship To Protocol Version Changes |
|---|---|
| ROOT — QuickResponseCode.us | Remains unaffected by a version change; the identity's foundational existence does not depend on which rule-set version is currently in force. |
| GOVERNANCE — QRProtocol.us | Authors, versions, dates and publishes every rule-set change, and defines any transition period for identities mid-cycle. |
| VALIDATION — QRCompliance.us | Applies whichever version is in force on the date of each evaluation and records that version against the evaluation outcome. |
| AUTHORIZATION — QRCertified.us | Relies on the version referenced in a compliance determination to know which rule set underlies any certification it issues. |
| REGISTRATION — QRRegistered.us | Reflects, in the registration record, the rule-set version that was in force at the time an identity was last evaluated. |
| OPERATIONS — QRCodex.us | Retains the permanent history of every published version, its effective date, and which evaluations were run against it. |
Where a dispute arises over which version applied to a given evaluation, QRCodex.us's version history governs the answer.
What This Does — And Does Not — Do
Does
- ✓Record which rule-set version was in force for every evaluation QRCompliance.us performs
- ✓Apply the version designated as in force on the effective date, not a version chosen by validation itself
- ✓Honor a defined transition period for evaluations in progress when a new version is published
- ✓Flag existing certified or registered identities affected by a version change for review on their normal cycle
- ✓Preserve a permanent, dated history of every published version and what changed relative to the prior one
- ✓Distinguish a version change affecting the whole rule set from ordinary application of a single rule
Does Not
- ✕Allow QRCompliance.us to author, amend or retire a rule on its own initiative
- ✕Retroactively invalidate a past evaluation the moment a newer version is published
- ✕Apply a new version before its published effective date
- ✕Treat a minor threshold adjustment and a full rule-set restructuring as the same category of change
- ✕Discard the history of a superseded version once it is no longer in force
- ✕Let an enforcing or authorizing layer decide for itself which version applies
Related Routes
Common Questions
Can QRCompliance.us change a rule on its own without a new version from governance?
No. QRCompliance.us only evaluates against rule sets that QRProtocol.us has authored, versioned and published. It has no independent authority to alter a rule.
Does a new rule-set version immediately invalidate identities certified under the old one?
No. Existing certified or registered identities are typically flagged for review on their normal renewal cycle rather than being invalidated the moment a new version is published.
How does an operator know which version applied to their evaluation?
Every evaluation QRCompliance.us performs records the version it was run against, and that version is retained permanently in QRCodex.us's governance history.
What happens to an evaluation already in progress when a version change is published?
Where governance defines a transition period, evaluations already in progress may continue under the prior version until that period ends.
Is a threshold adjustment treated the same as a full rule-set restructuring?
Both are version changes, but they differ in scope. The transition handling and downstream review each may trigger can differ based on how substantial the change is.