Route 22 of 176
Identity Status Changes
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
A registered identity does not sit in a single fixed condition for its entire life. It moves between a defined set of statuses — active, suspended, restricted, revoked, expired, reinstated — as facts about it change. This route defines that set of statuses, which transitions between them are permitted, what evidence or authority a transition requires, and how each change is captured so the identity's status history remains a reliable, ordered record rather than a single overwritten value.
QRCompliance.us validates that a status transition is supported by the applicable conditions and evidence. It does not itself flip the switch on routing, certification or registration — those consequences belong to the layers built to carry them out.
Every registered identity carries a status, and that status is not decorative. It determines what a scan of that identity's QR code is permitted to do, whether a company can still transact under it, and whether a certified output can still be issued that references it. Because so much depends on it, status cannot be an informal label attached loosely to a record — it has to be a defined value drawn from a known, closed set of possibilities.
What makes status changes worth a dedicated route, rather than being folded into the definition of status itself, is that a status by itself says little. What matters operationally is the transition: what state the identity was in before, what state it moves to, what triggered the move, and whether that particular move is even one the system recognizes as valid. An identity cannot leap from active to reinstated, for instance, because reinstated only makes sense as a return from a prior restriction or revocation — the transition graph itself carries meaning.
This route treats status changes as first-class events rather than incidental updates to a field. Each change has a cause, a timestamp, an actor or trigger, and a resulting state, and each of those elements is preserved so that anyone reviewing the identity's history later can reconstruct exactly how it arrived at its current condition, not merely what that condition currently is.
01Plain-English Definition
An identity status change is a recorded move of a registered identity from one defined status to another — such as from active to suspended, or from revoked to reinstated — carried out only along transition paths the system recognizes, and preserved together with the fact that caused it.
Status is not the same thing as compliance condition in the general sense discussed elsewhere in this encyclopedia. Status is the specific, closed-set value attached to the identity as a whole — active, suspended, restricted, revoked, expired, reinstated, and any other status the governing layer has defined. It is coarse by design, because routing and certification decisions need a small, unambiguous set of values to key off, not an open-ended description.
A status change, then, is the event of moving between two of those values. It is distinct from the underlying reason for the move — a lockout or revocation trigger, for instance, is the cause, while the resulting status change is the recorded effect that this route governs.
02The Recognized Statuses
A registered identity moves through a bounded set of statuses. Each status has a distinct operational meaning, and no identity holds two statuses at once.
| State | Entered When | Left When |
|---|---|---|
| Active | Registration completed and all applicable conditions currently satisfied. | Moves to suspended, restricted, revoked, or expired when a triggering fact changes the condition. |
| Suspended | A temporary, correctable issue has been identified pending review or evidence. | Returns to active once the issue is resolved, or escalates to restricted or revoked if unresolved. |
| Restricted | Certain routing, geographic, or transactional uses are limited while the identity remains valid overall. | Returns to active when the restriction's basis is cleared, or escalates to revoked if it worsens. |
| Revoked | The identity's underlying validity has been withdrawn by a confirmed trigger. | Moves only to reinstated, and only through a defined corrective process — never directly back to active. |
| Expired | A time-bound validity period lapsed without a completed renewal. | Moves to active only through a completed renewal process, not through the passage of time alone. |
| Reinstated | A prior revocation or lockout has been resolved through a defined corrective process. | Functions as active going forward, while the record retains the fact of the earlier revocation. |
03Valid Transition Paths
Not every pair of statuses defines a valid transition. The set of permitted paths is itself part of the governing logic, because allowing an arbitrary jump between statuses would let a serious condition be cleared without going through the corrective process that condition actually requires.
- Active can move to suspended, restricted, revoked, or expired, but never directly to reinstated.
- Suspended can return to active or escalate to restricted or revoked; it cannot move directly to expired.
- Restricted can return to active or escalate to revoked; it cannot skip straight to reinstated.
- Revoked can move only to reinstated, and only once a defined corrective process is completed and confirmed.
- Expired can move only to active, and only through a completed renewal — never through inaction or elapsed time alone.
- Reinstated is treated as functionally active for routing purposes, while the record permanently retains the earlier revoked status as history.
This structure exists so that severity is never quietly bypassed. A revoked identity cannot be nudged back to active by a small administrative correction; it must pass through reinstatement, which itself depends on the corrective and reinstatement conditions defined elsewhere.
04Operational Flow
A status change moves through a consistent sequence regardless of which pair of statuses is involved, so that every change — however routine or however serious — is handled with the same rigor.
- 1Current status is establishedThe identity's present status is read from the record before any change is considered.
- 2A triggering fact or request arrivesNew evidence, an expiry date, a corrective completion, or an authorized request initiates review of the status.
- 3The requested transition is checked against allowed pathsQRCompliance.us confirms the proposed move from current status to new status is one the transition rules permit.
- 4The transition is validated against substantive conditionsBeyond being structurally allowed, the transition must be supported by the actual facts or evidence relevant to that specific move.
- 5The new status is applied and loggedThe record is updated to the new status, with the prior status, the trigger, and the timestamp preserved alongside it.
A status change is valid only if both the path and the substance support it. A structurally permitted transition with no supporting evidence is refused just as firmly as a structurally forbidden one.
05Who May Trigger A Change
Different statuses are reachable through different combinations of automated triggers and authorized human action, and the route distinguishes clearly between the two.
Automated Triggers
Expiry dates lapsing, monitoring systems detecting a defined anomaly, or scheduled re-evaluations against evidence already on file can initiate a status review without human initiation.
Authorized Manual Action
A responsible company, a regulator, or another party recognized by governance rules can submit a request or new evidence that initiates review of a specific identity's status.
Corrective Process Completion
Completion of a defined corrective process is itself the fact that supports a move from revoked to reinstated, or from suspended back to active.
In every case, the party or process that triggers review is distinct from QRCompliance.us's evaluation of whether the resulting transition is warranted. A trigger opens the question; it does not answer it.
06Status History As A Record
Because each status change is preserved rather than overwritten, an identity's status is best understood as a history, not a single value — a sequence of dated transitions each carrying its own trigger and basis.
- ✓The prior status is preserved alongside the new one for every transition.
- ✓The triggering fact or request is referenced by the transition record, not merely implied.
- ✓A revoked status is never deleted from history once reinstated — it remains visible as a past event.
- ✓Automated and manually triggered transitions are distinguished from one another in the record.
- ✓The evaluation that supported the transition is retained separately from the fact that triggered it.
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.
Identity status changes sit at the point where a fact about an identity becomes an operational signal that other layers act on, and each entity in the architecture has a distinct role in that process.
| Layer | Relationship To Identity Status Changes |
|---|---|
| ROOT — QuickResponseCode.us | Anchors status changes to the same persistent identity across every transition, so a revoked identity is never confused with a distinct or newly issued one. |
| GOVERNANCE — QRProtocol.us | Defines the closed set of recognized statuses and which transitions between them are structurally valid. |
| VALIDATION — QRCompliance.us | Evaluates whether a proposed transition is supported by the applicable facts, evidence, or completed corrective process. |
| AUTHORIZATION — QRCertified.us | Reflects a confirmed status change in whether certified outputs referencing the identity may continue to be issued. |
| REGISTRATION — QRRegistered.us | Applies the new status to the registered record and governs the routing consequences tied to that status. |
| OPERATIONS — QRCodex.us | Retains the full, ordered history of status transitions as the durable record of the identity's condition over time. |
Where a routing layer's current behavior appears out of step with the status history in QRCodex.us, Codex governs and the routing behavior is reviewed against it.
What This Does — And Does Not — Do
Does
- ✓Define a closed set of recognized identity statuses and the transitions permitted between them
- ✓Evaluate whether a proposed status transition is supported by applicable facts or completed corrective process
- ✓Preserve the prior status, trigger, and timestamp for every status change, without overwriting history
- ✓Distinguish automated triggers from manually submitted requests within the transition record
- ✓Refuse a structurally permitted transition that lacks supporting substantive evidence
- ✓Require revoked and expired identities to pass through defined paths back to active rather than a direct jump
Does Not
- ✕Allow an identity to move directly from revoked to active without a completed reinstatement path
- ✕Allow a status change to occur without a recorded triggering fact or request
- ✕Treat the passage of time alone as sufficient to move an expired identity back to active
- ✕Delete or overwrite a prior status once a new status has been applied
- ✕Allow QRCompliance.us to apply the operational consequence of a status change itself
- ✕Recognize an informal or undefined status value outside the closed governing set
Related Routes
Common Questions
Can a revoked identity go straight back to active status?
No. A revoked identity can move only to reinstated, and only after a defined corrective process is completed and confirmed. It cannot skip directly back to active.
Does an expired identity become active again automatically once conditions improve?
No. An expired identity moves back to active only through a completed renewal process. The passage of time or improvement in underlying conditions alone does not restore active status.
Who decides whether a status change is warranted?
QRCompliance.us evaluates whether the proposed transition is supported by the applicable facts or completed process. The party submitting the triggering request or evidence does not decide the outcome itself.
Is a status change the same thing as a compliance condition?
No. Status is the closed-set value — active, suspended, restricted, revoked, expired, reinstated — attached to the identity as a whole, while the underlying compliance condition is the broader set of facts that may justify a given status.
Is a past revocation erased once an identity is reinstated?
No. Reinstatement restores functional active status going forward, but the record permanently retains the earlier revoked status as part of the identity's history.