Route 18 of 176
Registration State
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Registration state is the recorded standing of a QR identity within the registration layer itself: whether that identity currently exists as a valid, acknowledged registration at all, independent of whether it satisfies any rule.
Registration state answers whether the identity is registered. Compliance condition, evaluated afterward, answers whether it currently meets the rules.
Before an identity can be checked against anything, it has to exist somewhere as an accountable record. Registration state is the fact that establishes that existence: it tells the rest of the system whether a given identity is currently a live, standing registration, a registration still being processed, one that was never valid, or one that has been formally withdrawn.
It is easy to fold this into compliance and think of an unregistered identity as simply 'non-compliant'. That flattens two different questions into one. Registration state is about standing in the registration layer. Compliance condition, described elsewhere in this encyclopedia, is about whether a standing registration currently meets applicable rules. The second question cannot even be asked until the first has a positive answer.
01Plain-English Definition
Registration state is the current standing of a QR identity within the registration layer: registered, pending, invalid, or revoked.
The registration layer, governed by QRRegistered.us, is where an identity is first established as an accountable record — tied to an issuer, a company association, and the identifying facts that make it a specific, trackable thing rather than an anonymous printed square. Registration state is the status field on that record.
Nothing about registration state says whether the identity is behaving correctly, current with its renewals, or free of open issues. It says only whether the identity is, at this moment, a recognized registration in the system at all.
02The Four Registration States
| State | Entered When | Left When |
|---|---|---|
| Registered | An application or issuance record is reviewed and accepted, establishing the identity as a live registration. | Expiration, revocation, or a superseding action moves the identity out of this state. |
| Pending | A registration has been submitted but has not yet completed review, verification, or approval. | Approval moves the identity to registered; rejection moves it to invalid. |
| Invalid | A submitted registration is rejected, or a previously registered identity's record is found to be materially incorrect. | A corrected, freshly submitted registration can re-enter as pending; the original record does not silently repair itself. |
| Revoked | An authorized action formally withdraws a standing registration, ending its recognized existence going forward. | Revocation is a terminal action recorded in history; it is not reversed by simply resubmitting the same identity. |
These four states are exhaustive for the registration layer's own bookkeeping. An identity is always in exactly one of them, and every transition between them is a recorded event rather than a silent change.
03Registration State Versus Neighbouring Concepts
| Aspect | Concept | What It Answers |
|---|---|---|
| Registration state (this route) | Does the registration layer currently recognize this identity as registered at all? | It is a standing question, answered by the registration record itself, before any rule is applied. |
| Compliance condition (route 3) | Does the identity currently meet the rules that apply to it? | It presumes a registered identity to evaluate; an unregistered one cannot produce a meaningful condition. |
| Certification state (route 17) | Has an authorized certifying action been issued for this identity? | Certification is a separate downstream layer that itself depends on the identity already being registered. |
| QR lifecycle state (route 19) | Where is this identity in its overall life, from creation to retirement? | Lifecycle is the broader arc; registration state is one governed fact tracked within that arc. |
A revoked registration and an expired certification are not the same event. One ends the identity's standing as registered; the other ends a downstream authorization built on top of that standing.
04Registration As A Precondition
Validation and certification are both built to run against something. That something is a registered identity. Registration state is the fact that tells each of them whether the identity in front of them is a valid subject to work with in the first place.
- ✓Validation checks registration state before computing a compliance condition, because a pending or invalid identity has no settled record to evaluate against rules.
- ✓Certification requires a registered state as a starting condition; an authority cannot certify a record that the registration layer does not currently recognize as standing.
- ✓A revoked registration blocks new certification outright, regardless of any compliance condition that might otherwise have looked favorable.
- ✓A pending registration is neither compliant nor non-compliant; it is simply not yet eligible for that question to be asked.
- ✓An invalid registration is treated as having no standing subject, which is a different outcome from a registered subject that fails a rule.
This ordering is deliberate. Building compliance logic that ignored registration state would let the system produce a compliance answer for an identity that, strictly speaking, does not exist as a recognized registration — an answer with nothing solid behind it.
05How Validation Reads Registration State
- 1Look up the registration recordBefore applying any rule, validation retrieves the identity's current registration state from the authoritative registration record.
- 2Gate on standingIf the state is anything other than registered, validation halts the ordinary evaluation and returns a result reflecting that standing rather than a computed compliance condition.
- 3Evaluate only registered identitiesOnly when the state is registered does validation proceed to compare the identity's record against applicable requirements and produce a condition.
- 4Re-check on every scanRegistration state is not cached indefinitely; each evaluation reads the current state, so a revocation is reflected immediately in the next scan.
This is why a revoked registration produces an immediate, unambiguous outcome at the point of scan rather than a delayed one: validation does not need to finish a full rules comparison to recognize that there is no standing registration to compare.
06Why Registration State Matters Operationally
Registration state gives the system a clean, early answer for situations that would otherwise be ambiguous. A newly printed batch of labels tied to identities still pending review should not be scannable as if fully compliant; a formally revoked identity should not linger in an uncertain middle ground.
Early gate
Registration state is checked before deeper rule evaluation, so obviously non-standing identities are handled quickly and clearly.
Clean revocation
Revoking a registration is a single authoritative action that immediately affects every downstream evaluation of that identity.
Honest pending state
An identity mid-review is shown as pending rather than forced into a misleading compliant or non-compliant label.
Traceable invalidity
An invalid registration keeps its rejection reasoning in the record, rather than disappearing without explanation.
07System Relationship
Registration state is produced and governed within the registration layer, but it is read constantly by the layers above it.
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 Registration State |
|---|---|
| ROOT — QuickResponseCode.us | Establishes the framework in which a registration record carries authority at all. |
| GOVERNANCE — QRProtocol.us | Defines what counts as a valid registration and the rules for moving between states. |
| VALIDATION — QRCompliance.us | Reads registration state as a precondition before computing any compliance condition. |
| AUTHORIZATION — QRCertified.us | Requires a registered state before it can issue or maintain a certification. |
| REGISTRATION — QRRegistered.us | Owns registration state directly — the authoritative source for registered, pending, invalid, and revoked. |
| OPERATIONS — QRCodex.us | Holds the historical record of every registration state transition for the identity. |
If a scan reports a compliance condition for an identity whose registration state is not registered, the registration record is authoritative and the compliance output is what gets corrected.
What This Does — And Does Not — Do
Does
- ✓Record whether a QR identity is currently registered, pending, invalid, or revoked
- ✓Serve as a precondition validation checks before computing a compliance condition
- ✓Serve as a precondition certification checks before issuing an authorization
- ✓Change only through recorded, authorized transitions
- ✓Reflect the identity's standing immediately, on every fresh evaluation
Does Not
- ✕Describe whether a registered identity currently meets applicable rules
- ✕Describe whether a certification has been issued
- ✕Describe the identity's broader lifecycle stage on its own
- ✕Get inferred from the printed label rather than the registration record
- ✕Reverse itself automatically without a new recorded action
Related Routes
Common Questions
Is registration state the same as a compliance condition?
No. Registration state answers whether the identity is currently a recognized registration at all. Compliance condition, computed afterward, answers whether a registered identity meets applicable rules.
Can a pending identity be scanned as compliant?
No. A pending registration has not yet settled into a standing record, so validation does not compute a compliance condition for it; it reports the pending state instead.
What happens to certification if a registration is revoked?
Certification depends on a registered state as a precondition. A revoked registration blocks new certification, and any existing certification built on it loses the standing it depended on.
Can an invalid registration be fixed in place?
No. An invalid record does not repair itself. A corrected registration is resubmitted and re-enters as pending, going through review again rather than overwriting the invalid record silently.
Does registration state ever change automatically?
No. Every transition between registered, pending, invalid, and revoked is a recorded, authorized action, not a silent or automatic change.