Route 76 of 176
Status Change History
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Not every compliance event changes a status value — many are re-evaluations that confirm the existing condition or find a trigger insufficient. Status change history narrows the broader record to the moments that mattered: each time the identity's status actually moved from one value to another. This route defines what counts as a status change, how the from-and-to values are captured, and how that narrower record is kept distinct from the full compliance event history.
QRCompliance.us records that a status changed and what it changed to. It does not decide what an enforcing layer must do in response to that change, and it does not decide, on its own initiative, which changes are worth remembering — every genuine change is kept, without selection.
A registered identity's status is a single value at any given moment — valid, revoked, locked out, under correction, restored — and that value has a history of its own, distinct from the wider record of everything that has ever been evaluated about the identity. Status change history is that narrower, sharper record: not every determination QRCompliance.us has ever made, but specifically every point at which the status value itself moved.
The distinction matters because most compliance activity does not change status. An identity can be re-evaluated a dozen times over a year and remain 'valid' throughout, with each re-evaluation confirming the same value rather than replacing it. Status change history skips past those confirmations and records only the transitions — the from-value, the to-value, the timestamp, and the basis for the move.
This makes status change history the fastest way to answer a specific, common question: has this identity's status ever actually changed, and if so, when and to what. A full compliance event history can answer that question too, but only after a reader filters out everything that was not a transition. Status change history is that filter, applied and preserved as its own record.
01Plain-English Definition
Status change history is the ordered record of every point at which a registered identity's compliance status value actually changed, capturing the prior value, the new value, the timestamp and the basis for each transition.
A 'status change' here means the status field itself took on a new value it did not previously hold — valid to revoked, locked out to restored, and so on. A re-evaluation that reconfirms the current value, without moving it, is not a status change even though it may still be recorded elsewhere as a compliance event.
This route governs how transitions are captured and preserved as their own record. It does not govern the substantive rules for when a given transition is warranted — those rules live in the routes defining revocation, lockout, correction and restoration conditions specifically.
02What Counts As A Status Change
The line between a status change and a mere confirmation has to be applied consistently, or the change history stops being trustworthy as a filtered view.
- The status field's value after a determination differs from its value immediately before that determination — this is the only test that matters.
- A revocation, a lockout, a correction acceptance, or a restoration each qualifies, because each moves the status value from one state to another.
- A re-evaluation that considers new evidence but leaves the status at its existing value does not qualify, even though the evaluation itself was substantive.
- An initial status assignment at first registration qualifies as the first entry in the change history, establishing the baseline value the identity starts from.
- A status value that is corrected for clerical reasons, without an underlying compliance basis, is still recorded as a change but flagged as administrative rather than substantive.
03Practical Value
A record limited to genuine transitions answers questions that would otherwise require wading through an identity's entire compliance event history to extract.
Volatility Assessment
A count of status transitions over a period shows whether an identity's standing has been stable or has swung repeatedly, independent of how many re-evaluations occurred without a change.
Timeline Reconstruction
A dispute over 'what was this identity's status on a given date' is answered directly by walking the change history to the most recent transition before that date.
Trend Reporting
An enterprise account managing many registered identities can report how many changed status in a period without recomputing that figure from the full event log each time.
Restoration Verification
A restoration event stands out clearly against the transition immediately before it, showing exactly what condition the identity is being restored from.
04Operational Flow
Each entry in the status change history follows the same path from the moment a transition actually occurs to the moment it becomes queryable alongside the rest of the identity's record.
- 1Status transition occursA determination changes the status field's value from what it held immediately before.
- 2From and to values are capturedBoth the prior value and the new value are captured together, so the transition is never recorded as only a destination.
- 3Basis is recordedThe determination and trigger that produced the transition are referenced, linking the change to its underlying evidence.
- 4Entry is appended to change historyThe transition is added to the identity's status change history as its own entry, without replacing any prior transition entry.
- 5Entry is linked to the full event recordThe change history entry references the corresponding compliance event, so a reader can move from the filtered view to the full determination when needed.
A status change history entry is created only when the status value itself moves. A confirmed re-evaluation that leaves the value unchanged belongs to the broader compliance event history, not to this narrower record.
05Status Change History Versus Compliance Event History
These two records are closely related but answer different questions, and keeping them distinct prevents either one from being asked to do the other's job.
| Aspect | Status Change History | Compliance Event History |
|---|---|---|
| Contains | Only entries where the status value actually transitioned | Every substantive determination, transition or not |
| Answers | When did status change, from what, to what | What was determined at every point, including confirmations |
| Size relative to activity | Smaller — a filtered subset of all determinations | Larger — the complete underlying record |
| Best used for | Volatility, timelines, and quick transition lookups | Full audit reconstruction and dispute review of any single determination |
| Relationship | Each entry links back to its source event | Each transition event is also present here, in full context |
06Transition States
Certain status values recur often enough across identities that their typical entry and exit paths through the change history are worth stating directly.
| State | Entered When | Left When |
|---|---|---|
| Valid | Initial registration determination, or a restoration from a prior revoked or locked-out state | A revocation or lockout triggered by a qualifying source |
| Revoked | A confirmed revocation determination based on a qualifying trigger | A correction accepted and a restoration determination confirmed |
| Locked Out | A confirmed lockout determination, distinct from a revocation of underlying validity | Resolution of the condition that caused the lockout, confirmed by re-evaluation |
| Under Correction | Acceptance of a corrective action plan following a revocation or lockout | Either a completed restoration or a failed correction returning to the prior restricted state |
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.
Status change history draws its entries from determinations made across the architecture while remaining, itself, only a record of validation's own status field moving over time.
| Layer | Relationship To Status Change History |
|---|---|
| ROOT — QuickResponseCode.us | Anchors every recorded transition to the same underlying identity across its entire status lifetime. |
| GOVERNANCE — QRProtocol.us | Defines which status values exist and which transitions between them are recognized as valid moves. |
| VALIDATION — QRCompliance.us | Detects each genuine status transition and captures the from-value, to-value and basis into the change history. |
| AUTHORIZATION — QRCertified.us | Reads relevant transitions, such as revocation or restoration, to decide whether certification status must move in parallel. |
| REGISTRATION — QRRegistered.us | Reflects the current status resulting from the most recent transition in the identity's registration record. |
| OPERATIONS — QRCodex.us | Retains the durable, canonical status change history as part of the permanent operational record. |
Where a status value shown elsewhere conflicts with the most recent transition recorded in QRCodex.us, Codex governs and the displayed value is corrected to match it.
What This Does — And Does Not — Do
Does
- ✓Record every point at which a registered identity's status value actually changed, including the prior and new values
- ✓Distinguish a genuine status transition from a re-evaluation that merely confirms the existing value
- ✓Capture the basis and link each transition entry to its underlying compliance event
- ✓Preserve every transition entry without editing or removing a prior one
- ✓Treat the identity's initial status assignment as the baseline first entry in its change history
- ✓Keep this narrower record distinct from, but linked to, the full compliance event history
Does Not
- ✕Record a re-evaluation as a status change when the status value did not move
- ✕Decide what enforcement action must follow any recorded transition
- ✕Select which genuine transitions are worth keeping — every transition is retained
- ✕Merge the filtered change history with the full compliance event history into one undifferentiated log
- ✕Allow a transition entry to be edited once a later transition has occurred
- ✕Treat administrative or clerical status corrections as substantive compliance transitions without flagging them as such
Related Routes
Common Questions
How is status change history different from compliance event history?
Compliance event history includes every substantive determination, including ones that confirm the existing status. Status change history is a narrower subset containing only entries where the status value actually moved from one value to another.
Does a re-evaluation that keeps the same status still get recorded anywhere?
Yes, in the full compliance event history. It simply does not appear in the status change history, because the status value did not transition.
What information does each status change entry contain?
The value the status changed from, the value it changed to, the timestamp of the change, and a reference to the determination and evidence that produced it.
Can a past status change entry be edited if the status later changes again?
No. Each transition is preserved exactly as recorded. A later transition is added as a new entry, and the earlier one remains unchanged in the sequence.
Which layer's record controls if a displayed status doesn't match the change history?
QRCodex.us holds the canonical status change history. Where a displayed value elsewhere conflicts with what Codex has recorded, Codex governs.