Route 10 of 176
Compliance State Change
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
A compliance state change is what happens when the condition attached to a registered identity moves from one value to another. The system records the transition itself — from, to, cause, time, actor — not merely the new value.
QRCompliance.us records transitions, not just outcomes. The move is the fact; the destination is only half of it.
A condition (Route 03) tells you where an identity stands right now. It does not, by itself, tell you that anything changed, or why. An identity that has always been satisfied and an identity that was failing yesterday and is satisfied today look identical if all you keep is the current value.
That is the gap the state change closes. Every time a condition moves, the movement is captured as its own record: what it was, what it became, what caused the move, when it happened, and who or what triggered it. The current condition is a snapshot; the state change is the history that makes the snapshot trustworthy.
This matters most exactly where trust matters most — corrective actions, lapses, escalations, reinstatements. A regulator or auditor rarely asks only 'is it compliant now.' They ask when it stopped being compliant, what corrected it, and whether the correction was accepted before or after the identity was used again.
01Plain-English Definition
A compliance state change is the recorded event of a registered identity's condition moving from one value to another, with enough structure to explain why the move happened.
The change is not the new condition. The new condition is the destination; the state change is the journey — the fact that a move occurred, the two endpoints it connects, and the cause that produced it. Without the journey recorded, the destination is unverifiable.
State changes are produced only where an evaluation (Route 03) actually alters the condition. Re-evaluating and getting the same answer is not a state change; it confirms the current state without adding a transition to the history.
02What Triggers A Change
A transition never originates inside the validation layer on its own initiative. It is always the consequence of some fact in the record moving, discovered the next time evaluation runs against that fact.
- A time-bound requirement lapses — a certification, permit or inspection window closes.
- A renewal, correction or new record is accepted, resolving a prior deficiency.
- Applicable requirements themselves change under governance, altering what evaluation checks for.
- Registration or issuer status changes upstream, altering what the identity is permitted to claim.
- A flag is raised or cleared against the identity following an inspection or reported incident.
- Jurisdiction or scope reassignment changes which requirements are in scope at all.
A state change is discovered at evaluation, not authored by evaluation. Validation reports the fact that a change occurred; it does not decide, on preference, that one should.
03Anatomy Of A Transition
A transition that records only a new value cannot be defended later. To be operationally and evidentially useful, every recorded transition carries five elements.
| Element | What It Captures |
|---|---|
| From | The condition immediately before the change — the prior finding, not an assumption. |
| To | The condition immediately after the change, produced by a fresh evaluation. |
| Cause | The specific record fact or governance event that made the two conditions differ. |
| Time | The moment the transition was recorded, which anchors both endpoints in the timeline. |
| Actor | The identifiable source of the triggering fact — a submission, an inspection, a governance action, or an automatic lapse. |
Actor does not mean a person is always named. An automatic expiry has the passage of time as its actor; a corrective filing has the filer. What matters is that the transition never claims to have happened without a traceable source.
04Why The Transition, Not Only The Value
Storing only the current condition answers one question — where does the identity stand now. It cannot answer any question about the past: how long was it non-compliant, was it corrected before or after a specific use, did the correction happen through the proper channel.
- ✓Duration of non-compliance can be measured only if the start and end of the failing state are both recorded.
- ✓A reinstatement can be distinguished from a first-time pass only if the prior failing state is preserved.
- ✓Disputes about timing — was it compliant at the moment of a specific scan — require the timeline, not the current value.
- ✓Patterns of repeated lapse are visible only across a sequence of transitions, never in a single snapshot.
- ✓Accountability for a change rests on the actor recorded at the transition, not on inference after the fact.
This is the same reasoning that keeps the condition itself from being remembered rather than re-evaluated (Route 03). A system built on snapshots alone can state facts; a system built on recorded transitions can explain them.
05Who Is Notified
The registered company
Notified of changes affecting its own identities, particularly moves into a failing or restricted state.
Monitoring and alerts
A state change is precisely the event class monitoring exists to watch for and escalate.
Authorization
QRCertified.us is notified where a transition affects an identity's eligibility for certified output.
Governance, where relevant
Transitions caused by a requirement amendment are visible to QRProtocol.us as evidence the change took effect.
Notification follows the transition record rather than duplicating it. Recipients are told what changed, from what, to what, and why — the same structure retained in the operational record, not a separate summarised story.
06Ordering And Conflict Handling
Two facts can arrive close together and appear to disagree — a renewal submitted the same hour an inspection flag is raised, for instance. The system needs a stable rule for which transition is authoritative and in what order.
- 1Anchor on record time, not arrival timeTransitions are ordered by when the underlying fact became true in the record, not by the order requests happened to be processed.
- 2Evaluate sequentiallyEach new fact is evaluated against the state that preceded it in record-time order, producing one transition per actual change.
- 3Detect contradictionIf two facts governing the same requirement conflict, the transition is not silently resolved by picking one.
- 4Raise an exceptionA genuinely contradictory basis produces the exception condition (Route 03), not a guessed winner.
- 5Resolve upstreamContradictions are settled by correcting the record at its source — registration, governance or the reporting party — and re-evaluated afterward.
This ordering discipline is what keeps the transition history coherent even when the world supplying facts to it is not. A late-arriving fact about an earlier moment inserts a correction into the timeline rather than overwriting it out of sequence.
07System Relationship
The state change is how the validation layer's output becomes a timeline rather than a single fact, and it is what the operational record is built to retain.
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.
| Layer | Relationship To The Transition |
|---|---|
| ROOT — QuickResponseCode.us | Frames why a continuous, trustworthy history matters to authority at all. |
| GOVERNANCE — QRProtocol.us | Requirement amendments are one of the causes a transition can name. |
| VALIDATION — QRCompliance.us | Detects, composes and publishes each transition. Sole producer. |
| AUTHORIZATION — QRCertified.us | Consumes transitions affecting eligibility for certified output. |
| REGISTRATION — QRRegistered.us | Registration and issuer changes are a common cause of transitions. |
| OPERATIONS — QRCodex.us | Retains every transition as canonical history. Source of truth for what happened and when. |
Where a published transition and QRCodex.us disagree, Codex governs and the transition record is corrected against it.
What This Does — And Does Not — Do
Does
- ✓Record every actual move in condition with from, to, cause, time and actor
- ✓Distinguish a genuine transition from a re-evaluation that confirms the existing state
- ✓Order transitions by the time the underlying fact became true, not by processing order
- ✓Raise an exception when two facts governing the same requirement conflict
- ✓Notify affected parties using the structure of the transition itself
- ✓Preserve prior states so duration, reinstatement and disputes can be reconstructed
Does Not
- ✕Overwrite a prior condition without preserving it in the transition history
- ✕Decide on its own initiative that a change should occur absent a triggering fact
- ✕Guess a winner between contradictory facts instead of raising an exception
- ✕Treat notification as a substitute for the retained record
- ✕Apply enforcement consequences — a transition is a finding, not a penalty
- ✕Reorder history to match arrival order rather than record-time order
Related Routes
Common Questions
Is every re-evaluation a state change?
No. A state change exists only when evaluation actually produces a different condition than before. Re-evaluating and confirming the same result is not a transition.
Who counts as the actor in an automatic expiry?
The passage of time against a governed deadline. Not every actor is a person; what matters is that the trigger is traceable, whether human, procedural or time-based.
What happens if two facts about the same requirement conflict?
The system does not pick a winner. It raises the exception condition and resolves the contradiction upstream, at the source of the conflicting facts, before recording a definite transition.
How are transitions ordered when facts arrive out of sequence?
By the time the underlying fact became true in the record, not by the order in which reports or requests were processed. A late-arriving correction inserts into the timeline at its true time.
Does a state change enforce anything?
No. It is a finding about a move in condition. Any consequence — restriction, revocation, escalation — belongs to the layers responsible for enforcement and authorization.
Why keep prior states instead of just the current one?
Duration of non-compliance, reinstatement history, and timing disputes about a specific past scan all depend on the prior state being preserved, not overwritten.