Route 68 of 176
Recurring Compliance Conditions
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Some compliance conditions are proven once and hold indefinitely; a recurring compliance condition is not one of those. It has to be re-satisfied on a defined cadence — annually, quarterly, per batch, or on some other repeating interval — and satisfying it once does not close the requirement, it only resets the clock. This route defines how that cadence is tracked, how an upcoming or missed cycle is detected, and how the identity's condition responds when a cycle is missed.
QRCompliance.us tracks whether a recurring condition's current cycle has been satisfied and evaluates the identity's condition accordingly. It does not itself send reminders as an operational communications function, and it does not enforce a lockout when a cycle lapses — those actions belong to the layers built to carry them out.
Most compliance conditions described elsewhere in this encyclopedia are evaluated against a single body of evidence and then hold as satisfied until something changes. A recurring compliance condition works differently: satisfying it is not a one-time event but a repeating obligation, and the passage of time itself is part of what determines whether the identity currently meets it. A calibration certificate that must be renewed every twelve months, an inspection that must recur every batch, or a training credential that must be refreshed annually are all examples of conditions where compliance is a cycle, not a checkpoint.
The central challenge this route addresses is that a recurring condition can lapse silently. Nothing forces attention to it the way a single failed inspection does — the cycle simply elapses, and unless something is actively tracking the cadence, the identity can drift from compliant to non-compliant without any single dramatic event marking the change. Tracking cadence, not just tracking outcomes, is therefore the core of what this route governs.
A recurring condition also differs from a one-time renewal in that it does not end. A renewal (governed elsewhere) closes out a defined validity period once. A recurring condition resets and starts again every time it is satisfied, indefinitely, for as long as the identity remains subject to that requirement.
01Plain-English Definition
A recurring compliance condition is a requirement that must be satisfied again on a defined repeating cadence, where satisfying the current cycle does not close the requirement permanently but instead resets the clock for the next one, and where the identity's condition depends on whether the current cycle is still within its interval.
The defining feature is the cadence itself: annual, quarterly, per shipment, per batch, or any other interval defined for the requirement. The specific evidence needed to satisfy any given cycle may be identical to a one-time requirement's evidence — a certificate, a test result, a signed attestation — but the obligation to produce that evidence repeats rather than concluding.
This route governs the mechanics of tracking the cadence, flagging an approaching deadline, and detecting a missed cycle. It does not define which specific requirements are recurring in the first place — that is set by the applicable requirement itself — nor does it define what happens after a missed cycle triggers a corrective or restricted state, which is addressed by the routes governing those outcomes.
02What Makes A Condition Recurring
Not every compliance condition with a date attached to it is recurring. The distinction turns on whether satisfying the condition once closes it out or merely resets it for the next cycle.
- A recurring condition has a defined interval — the length of time or number of operational events between one required satisfaction and the next.
- Satisfying the current cycle resets the interval rather than closing the requirement permanently.
- The obligation continues indefinitely for as long as the identity remains subject to the applicable requirement that made the condition recurring in the first place.
- A missed cycle changes the identity's condition even if the underlying capability being certified has not itself changed — the lapse itself is what matters.
A one-time renewal, by contrast, has a single validity period that ends and is separately re-established, without an ongoing cadence built into the requirement itself. The two can look similar from the outside but are tracked differently underneath.
03Tracking The Cadence
Tracking a recurring condition means holding, at all times, an accurate picture of where the current cycle stands relative to its interval, and doing so continuously rather than only at the moment evidence is submitted.
Interval Anchored To Last Satisfaction
Each cycle's deadline is calculated from the date the previous cycle was satisfied, not from a fixed calendar date, unless the requirement specifically defines a fixed date.
Approaching-Deadline Window
A defined window before the deadline — for example thirty days — is when the condition is flagged as approaching, distinct from being flagged as missed.
Grace Period, Where Defined
Some recurring conditions allow a short grace period after the deadline before the cycle is treated as missed; where none is defined, the deadline itself is the line.
04Operational Flow
A recurring condition moves through the same basic cycle repeatedly, and each pass through that cycle is tracked as a distinct instance rather than a continuation of the previous one.
- 1Cadence is establishedThe applicable requirement defines that a condition recurs, and the interval between required satisfactions is set.
- 2Current cycle beginsThe clock for the next required satisfaction starts from the date the current cycle was satisfied.
- 3Approaching deadline is flaggedAs the interval nears its end, the condition is flagged as approaching so that action can be taken before a lapse occurs.
- 4Cycle is satisfied or missedNew evidence is submitted before the deadline and the cycle is satisfied, or the deadline passes without satisfaction and the cycle is missed.
- 5Condition and clock are updatedA satisfied cycle resets the clock for the next one; a missed cycle changes the identity's condition and is recorded as a lapse.
Flagging an approaching deadline is an alert, not a determination. The identity's condition changes only at the deadline itself, or when a defined grace period expires.
05Cycle States
A recurring condition's current cycle is always in exactly one of a small number of states, and the transitions between them are what monitoring and alerting are built around.
| State | Entered When | Left When |
|---|---|---|
| Current | Most recent cycle satisfied and the next interval has begun | Moves to Approaching as the deadline nears |
| Approaching | Interval enters its defined pre-deadline window without new satisfaction | Moves to Current if satisfied, or to Lapsed if the deadline passes unsatisfied |
| Lapsed | Deadline (or grace period, where defined) passes without satisfaction | Moves to Current once satisfying evidence is submitted and accepted |
A lapsed cycle does not require a new determination process to be created from scratch — it is the same recurring requirement, now unsatisfied, and it returns to Current the moment it is properly satisfied again.
06Recurring Versus One-Time Requirements
Distinguishing a recurring requirement from a one-time one matters because tracking the wrong model produces the wrong alerts and the wrong condition changes.
| Aspect | Recurring Compliance Condition | One-Time / Fixed-Term Requirement |
|---|---|---|
| Interval | Resets every time it is satisfied and continues indefinitely | Runs once for a defined validity period |
| Missed deadline effect | Cycle becomes lapsed; condition changes and clock remains active | Requirement expires; a separate renewal process is needed to re-establish it |
| Alert pattern | Approaching, then lapsed, on every recurring interval | Approaching expiry once, ahead of the single end date |
| Ends when | The identity is no longer subject to the applicable requirement | The fixed term is completed or formally renewed |
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.
Recurring compliance conditions depend on the broader condition-evaluation logic for what counts as valid evidence, and feed their cycle status into the same condition that every other compliance check contributes to.
| Layer | Relationship To Recurring Compliance Conditions |
|---|---|
| ROOT — QuickResponseCode.us | Anchors the identity across every cycle so that a long history of recurring satisfactions and lapses attaches to one continuous record. |
| GOVERNANCE — QRProtocol.us | Defines which requirements are recurring, their intervals, and whether a grace period applies before a missed cycle changes the condition. |
| VALIDATION — QRCompliance.us | Tracks the current cycle's status, evaluates whether new evidence satisfies it, and updates the identity's condition when a cycle lapses. |
| AUTHORIZATION — QRCertified.us | Reflects a lapsed recurring condition in certification status where the applicable requirement makes certification depend on it. |
| REGISTRATION — QRRegistered.us | Reflects a lapsed recurring condition in registration status where the applicable requirement makes registration depend on it. |
| OPERATIONS — QRCodex.us | Retains the full cycle history — every satisfaction, every approaching flag, and every lapse — as the permanent record for the requirement. |
Where a cycle's recorded status appears to conflict with QRCodex.us's history of the identity, Codex governs and the cycle status is reconciled against it.
What This Does — And Does Not — Do
Does
- ✓Track the interval for each recurring compliance condition, anchored to the date the current cycle was last satisfied
- ✓Flag an approaching deadline within the window defined for the requirement, before any lapse occurs
- ✓Evaluate whether newly submitted evidence satisfies the current cycle and resets the clock
- ✓Change the identity's condition when a cycle lapses past its deadline or defined grace period
- ✓Preserve a continuous history of every cycle's satisfaction, approaching flag, and lapse
- ✓Treat a lapsed cycle as returning to current the moment it is properly satisfied again
Does Not
- ✕Treat a single satisfaction of a recurring condition as closing the requirement permanently
- ✕Send operational reminders or notifications as a communications function in its own right
- ✕Apply a lockout or other enforcement action directly when a cycle lapses
- ✕Confuse a recurring condition's repeating interval with a one-time requirement's fixed validity period
- ✕Require a new determination process to be built from scratch each time a cycle repeats
- ✕Alter the historical record of a prior cycle when a later cycle is satisfied or lapses
Related Routes
Common Questions
How is a recurring condition different from a renewal?
A renewal closes out a single fixed validity period and requires a separate process to re-establish it. A recurring condition never closes — satisfying the current cycle simply resets the clock for the next one, indefinitely.
Does flagging an approaching deadline change the identity's condition?
No. An approaching flag is an alert intended to prompt action before a lapse. The identity's condition changes only when the deadline, or a defined grace period, actually passes without satisfaction.
What happens to the cycle history when a lapse is later corrected?
The lapse remains visible in the identity's history even after the cycle is satisfied again. Correcting a lapse resets the current cycle; it does not erase the record of the earlier lapse.
Who decides which requirements are recurring?
The applicable requirement itself defines whether it recurs and sets the interval. This route governs how that cadence is tracked once defined, not which requirements are recurring in the first place.
Does a lapsed cycle automatically trigger a lockout?
A lapse changes the identity's compliance condition, but applying a lockout or other enforcement action is carried out by the layer holding authority over that specific control, not automatically by the recurring-condition tracking itself.