Route 04 of 176
Compliance Status
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Compliance status is the durable, readable label attached to a registered QR identity so that anyone reading it — public or authorized — knows where the identity stands without re-deriving the underlying finding.
The status is a publication of the condition, not the condition itself. It is built to be read; the condition is built to be evaluated.
A finding that only machines can parse is not the whole job. Somewhere the system has to hand a person — a customer, an inspector, an operator — a label they can read at a glance and trust to be current. That label is the compliance status.
Status exists because conditions are evaluated per-scan and can carry detail unsuited to a public-facing surface: applicability logic, record fields, exception states. Status takes that finding and renders it as a short, stable, versioned statement fit for human consumption at two different levels of detail.
Status is easy to conflate with the condition it comes from, with the flags that may drive it, and with the lifecycle state change that may follow it. Each has its own route; this one is about the published label itself — how it is set, versioned, and read.
01Plain-English Definition
Compliance status is the published, human-readable label the validation layer sets from a registered identity's current condition.
Where a condition is a structured finding meant for machine consumption — requirements applied, result, basis, time — a status is a short statement meant for a person: 'Compliant', 'Restricted', 'Under Review', 'Expired'. The mapping from condition to status is deliberate and governed, not a matter of formatting taste.
Because a status is meant to be read and trusted, it is set through a defined step, carries a version, and is retained historically. A status that changed silently, with no record of when or why, would not be worth publishing at all.
02Status Versus Its Neighbours
Status sits between condition and lifecycle. Getting the boundaries right avoids reading the wrong artefact for the wrong purpose.
| Concept | How It Differs From Status |
|---|---|
| Compliance condition (route 3) | The moment-accurate, structured finding evaluation produces. Status is derived from it for human reading; it is not the finding itself. |
| Compliance flags (route 5) | Markers bound to identity signalling specific issues. Flags are inputs the condition weighs; status is an output, several layers downstream of any single flag. |
| State change (route 10) | A transition in the identity's lifecycle — activated, suspended, retired. A state change can prompt a new status, but the two are governed by different rules and can move independently. |
| Scan response | What a scanner actually receives, which may show status, more, or less depending on routing and who is asking. |
Status is a publication surface, not a decision. The decision is the condition. QRCompliance.us validates and publishes; it does not enforce.
03How Status Is Set
- 1Condition is evaluatedValidation produces a fresh condition, as described in route 3, complete with basis and time.
- 2Status mapping is appliedA governed mapping converts the condition's result into one of a fixed set of published status labels. The mapping is defined upstream, not chosen ad hoc at publication time.
- 3Status is composedThe label is paired with an effective date, a version number, and a pointer back to the condition that produced it.
- 4Status is publishedThe new status becomes the record any reader — public or authorized — encounters until it is superseded.
- 5Status is retainedThe prior status is not discarded; it is kept as history, so anyone reviewing later can see what was published, when, and why it changed.
Because status is derived mechanically from a governed mapping, two identities with the same condition receive the same status label. Consistency of labelling is what makes the status trustworthy across the whole population of registered identities.
04Publication And Versioning
A status that cannot be dated is not auditable. Every published status carries a version marker and an effective timestamp, and every prior version remains retrievable.
- Each status change increments a version, so 'which status was showing on a given date' is always answerable.
- The effective date marks when the new status became the one presented to readers, distinct from the condition's evaluation time.
- A superseded status is retained, not overwritten, so the published history forms a continuous record.
- Every status version carries a reference back to the condition that produced it, preserving the chain from finding to publication.
- Version history is part of the operational record held at QRCodex.us, not a convenience log kept by the display layer.
Versioning also protects against a subtler failure: a reader caching an old status and treating it as current. A versioned, timestamped status makes staleness visible instead of silent.
05Public Read Versus Authorized Read
Not every reader needs — or is entitled to — the same detail. Status is designed with two read surfaces in mind.
| Aspect | Public Reader | Authorized Operator |
|---|---|---|
| Label | Sees the current published label only | Sees the label plus version history and effective dates |
| Basis | No visibility into the underlying condition's basis | Can trace the status back to the condition and its basis |
| Flags | Cannot see raised-but-unresolved flags directly | Sees flags contributing to the current status |
| Access | Reads at the point of scan | Can query status outside of a scan event, for oversight |
This split exists because a public label has to be simple enough to be useful instantly, while an authorized operator needs enough depth to investigate, correct, or escalate. Both readers are looking at the same governed status; they are simply given different amounts of it.
06Status Categories
| State | Entered When | Left When |
|---|---|---|
| Compliant | Published when the underlying condition is fully satisfied. | Superseded when a new condition evaluation produces a different result. |
| Restricted | Published when the condition is satisfied only within defined limits. | Superseded once the limiting factor is resolved or exceeded. |
| Under Review | Published when the condition carries an unresolved exception. | Superseded once review supplies the missing basis and a definite condition is reached. |
| Non-Compliant | Published when the condition shows a failed requirement. | Superseded once correction is recorded and re-evaluated. |
| Expired | Published when a time-bound requirement has lapsed. | Superseded upon recorded renewal. |
These labels are deliberately few and stable. A published status vocabulary that changes often defeats the purpose of publishing a status at all.
07System Relationship
Status is validation's public face — the layer-appropriate artefact for anyone who needs a readable answer rather than a structured finding.
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 Status |
|---|---|
| ROOT — QuickResponseCode.us | Establishes the authority under which a published status carries meaning. |
| GOVERNANCE — QRProtocol.us | Defines the fixed status vocabulary and the mapping from condition to label. |
| VALIDATION — QRCompliance.us | Derives, versions and publishes status from the condition. Sole publisher. |
| AUTHORIZATION — QRCertified.us | May reference published status when authorizing certified output. |
| REGISTRATION — QRRegistered.us | Supplies the identity the status is published for. |
| OPERATIONS — QRCodex.us | Holds the canonical version history that status publication is written to. |
If a displayed status ever disagrees with the version history in QRCodex.us, the recorded history governs and the display is corrected.
What This Does — And Does Not — Do
Does
- ✓Publish a short, human-readable label derived from the current compliance condition
- ✓Carry a version and effective date for every change
- ✓Retain prior status versions as part of the operational record
- ✓Present a public read surface and a deeper authorized-operator read surface
- ✓Point back to the condition that produced each version
- ✓Use a fixed, governed vocabulary of status labels
Does Not
- ✕Evaluate requirements itself — that is the condition's job
- ✕Create or clear compliance flags directly
- ✕Change the identity's lifecycle state on its own
- ✕Enforce restrictions or revoke anything
- ✕Show authorized-operator detail to public readers
- ✕Invent new status labels outside the governed vocabulary
Related Routes
Common Questions
Is compliance status the same thing as the compliance condition?
No. The condition is the structured, moment-accurate finding from evaluation. Status is the short, published, versioned label derived from that finding for human reading.
Who sets the compliance status?
The validation layer, QRCompliance.us, applies a governed mapping from condition to status. It is not chosen manually at publication time.
Can the public see the full history of an identity's status?
No. Public readers see the current published label. Authorized operators can see the version history and the condition each version traces back to.
Does a status change always mean the identity's lifecycle state changed?
No. Status responds to the condition and can change without any lifecycle state change, and a lifecycle state change does not automatically alter status by itself.
Why does status need a version number?
So that any reader can establish exactly which label was published on a given date, and so a superseded status remains part of an auditable record rather than disappearing.
Can a flag change the status directly?
Not directly. A flag contributes to the condition evaluation, and a resulting change in condition may then produce a new published status.