Route 07 of 176
Compliance Failure
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Failure is a specific value the compliance condition can hold: an applicable requirement was checked and found unmet on the current record. It is a finding, not a punishment, and it is reversible the moment the record changes.
Failure means a requirement was checked and not met. It does not mean the identity is unresolvable, and it does not by itself remove anything.
Route 3 defines the compliance condition and lists failing as one of its category states. Route 6 defines the evaluation act that produces any condition, including a failing one. This route is about the failing condition specifically: what makes a finding a failure rather than something else, and what happens to an identity once it holds one.
Failure is easy to conflate with two neighbours. It is not the same as an exception, where evaluation could not complete at all because a rule or fact was unresolved — failure requires that the requirement was actually checked. And it is not the same as revocation, which is an enforcement action some other layer may take after a failure exists, not the failure itself.
Keeping those boundaries precise matters because routing, monitoring and correction all behave differently depending on which one applies. Treating an exception as a failure produces wrong holds; treating a failure as a revocation skips a correction path that should have been available.
01Plain-English Definition
A compliance failure is a compliance condition in which at least one applicable requirement was evaluated against the current record and found not satisfied.
The requirement was in scope, the record was readable, and the comparison completed. The outcome of that completed comparison is 'not met,' not 'could not be determined.' That completeness is what separates failure from an exception.
Failure describes the record's relationship to the requirement at the moment of evaluation. It says nothing on its own about whether the identity keeps operating, loses authorization, or is flagged for review — those are consequences other layers attach to the finding, not part of the finding itself.
02Failure, Exception, And Revocation
These three are the most commonly confused outcomes an identity can end up with, and they come from different places in the system.
| Outcome | What Produced It | Reversible By |
|---|---|---|
| Failure | A requirement was evaluated and found not satisfied on the current record | Correcting the record so re-evaluation finds it satisfied |
| Exception | A requirement or fact could not be resolved, so evaluation could not complete | Supplying the missing basis or resolving the governing rule |
| Revocation | An enforcement action taken by an authorized layer, typically after failure | A separate authorized reinstatement action, not evaluation alone |
Exception handling and its escalation path are covered on their own route. Failure assumes the check ran to completion; exception means it did not.
03What Constitutes A Failure
A finding qualifies as a failure only when specific conditions are met by the evaluation act described in route 6.
- ✓The requirement was determined to be applicable to this subject before comparison.
- ✓The current record was successfully read, with the relevant fact present.
- ✓The comparison between requirement and record fact completed without ambiguity.
- ✓The result of that comparison is that the fact does not satisfy the requirement.
If any of the first three is untrue, the correct outcome is an exception, not a failure. A missing fact, an unresolved rule, or an unresolved applicability question is not evidence against the identity — it is evidence the check itself was not completed.
04Failure Categories
Not all failures carry the same weight or the same correction path. Recognisable categories help routing and monitoring respond proportionately.
Expiry failure
A time-bound requirement's validity window has closed. Usually the most mechanical to correct through renewal.
Scope failure
The record satisfies the requirement in one context but the current scan falls outside it — wrong facility, jurisdiction, or use.
Documentation failure
A required record entry is present but does not meet the standard the requirement sets, distinct from being absent.
Standing failure
An upstream flag or hold placed on the identity itself causes requirements dependent on good standing to fail.
Categorizing a failure this way is descriptive, not a separate finding type. The compliance condition still reports simply as failing; the category explains why, for anyone correcting it.
05What Routing And Monitoring Do With A Failure
A failing condition is an input other layers act on, exactly as route 3 describes for conditions generally.
- State-driven routing resolves the scan response to a hold or notice appropriate to a failing identity, rather than its normal destination.
- Monitoring treats the transition into a failing condition as an event worth alerting on, particularly for identities previously satisfied.
- Authorization consumes the failing condition to withhold certified output that depends on the unmet requirement.
- Nothing in this list revokes anything. Revocation, where it happens, is a separate decision layered on top of the failure, not automatic from it.
Whether a given failure triggers escalation toward revocation, versus simply routing to a correction notice, depends on rules those consuming layers own — not on the validation layer that produced the finding.
06Correction Path To Reinstatement
- 1Identify the unmet requirementThe retained evaluation record from the failing act names exactly which requirement was not satisfied and why.
- 2Correct the underlying factThe record is updated through an authorized action — renewal, documentation submission, scope adjustment.
- 3Re-run evaluationThe act described in route 6 runs again in full, resolving applicability fresh rather than only rechecking the one prior failure.
- 4New condition composedIf the correction is sufficient, the requirement now compares as satisfied and the overall condition updates accordingly.
- 5Downstream consumers re-syncRouting, monitoring and authorization observe the new condition on the next relevant scan or check — the failure is not manually cleared for them.
Reinstatement is nothing more than a later evaluation act finding the requirement satisfied. There is no separate reinstatement mechanism to invoke; correcting the record and letting evaluation run again is the entire path.
07System Relationship
Failure is a value the validation layer's output can take. It neither originates in, nor is acted on by, the validation layer alone.
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 A Failing Condition |
|---|---|
| ROOT — QuickResponseCode.us | Establishes the framework in which a failure has any meaning at all. |
| GOVERNANCE — QRProtocol.us | Defines the requirement that was not satisfied. |
| VALIDATION — QRCompliance.us | Detects and states the failure. Does not act on it. |
| AUTHORIZATION — QRCertified.us | Withholds certified output that depends on the failed requirement. |
| REGISTRATION — QRRegistered.us | Holds the record whose correction can turn failure back into satisfaction. |
| OPERATIONS — QRCodex.us | Retains the failure and its correction history as canonical record. |
QRCompliance.us states that a requirement failed. It does not decide what happens next; that belongs to the layers this table names.
What This Does — And Does Not — Do
Does
- ✓Report when an applicable requirement was checked and found unmet
- ✓Distinguish itself from an exception by requiring the check to have completed
- ✓Name the specific requirement and record fact behind the finding
- ✓Feed routing, monitoring and authorization as an input they consume
- ✓Remain reversible through correction and re-evaluation
- ✓Preserve the categories of failure for whoever must correct them
Does Not
- ✕Revoke, lock out, or otherwise enforce against the identity itself
- ✕Apply to requirements that could not be evaluated at all
- ✕Persist once the underlying record is corrected and re-evaluated
- ✕Decide whether an identity is escalated toward revocation
- ✕Require a separate reinstatement mechanism beyond correction and re-evaluation
- ✕Originate from anywhere other than the evaluation act in route 6
Related Routes
Common Questions
Is every unmet requirement a failure?
Only if it was applicable, the record was readable, and the comparison completed. If the check itself could not be completed, the correct outcome is an exception, not a failure.
Does a compliance failure automatically lead to revocation?
No. Failure is a validation finding. Revocation is an enforcement action a different layer may or may not take afterward, governed by its own rules.
How does an identity move out of a failing condition?
The underlying record is corrected through an authorized action, and evaluation runs again. There is no separate reinstatement step beyond correction and re-evaluation.
Can one identity be failing on one requirement and satisfied on another at the same time?
Yes. Requirements are evaluated individually, so the overall condition reflects a mix, and the failing requirement is named specifically rather than reported as a single opaque verdict.
Who decides how routing responds to a failure?
State-driven routing owns that decision, using the failing condition as its input. The validation layer supplies the finding, not the response.
Is a failure category — expiry, scope, documentation, standing — part of the condition itself?
It's descriptive detail attached to the finding, useful for whoever corrects it. The condition itself still reports simply as failing.