Route 11 of 176
Applicable Compliance Requirements
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Applicable compliance requirements are the requirements that actually apply to one particular registered identity. Determining that set correctly is the step evaluation depends on entirely; get it wrong, and the resulting condition is meaningless no matter how carefully it was computed.
Requirement text is written and owned by QRProtocol.us. QRCompliance.us determines which of it applies here — it does not author or interpret the rules themselves.
Route 03 describes evaluation as comparing a record against 'the requirements that apply.' That phrase does a lot of work, and it is not automatic. A jurisdiction's food-safety requirement does not apply to a fire-safety device; a requirement scoped to one certification tier does not apply to an identity outside that tier; a requirement amended last month may or may not have been in force when an earlier scan occurred.
Applicability is therefore its own determination, made before evaluation runs, not a side effect of it. It answers a narrower question than 'is this identity compliant' — it answers 'which rules govern this identity, in this context, at this moment' — and every subsequent finding depends on getting that answer right.
Because applicability can be ambiguous, contested, or simply unresolved for an edge case, the system also needs an honest way to say so rather than defaulting silently in either direction.
01Plain-English Definition
Applicable compliance requirements are the subset of all governed rules that actually bind one registered identity, selected by matching the identity's attributes against each rule's declared scope.
The full body of requirement text is written and maintained by QRProtocol.us. Applicability is the mapping step: for this identity, at this time, which parts of that body are in scope. It is a determination, not a copy of the rulebook.
Two identities can be subject to entirely different applicable sets even while both are governed by the same overall protocol, because their jurisdiction, object type or certification scope differ. Applicability is what makes a single body of governance usable across a diverse population of identities.
02How Applicability Is Determined
Applicability is decided by matching declared attributes of the identity against declared scope conditions on each requirement. Five factors do most of the work.
| Factor | What It Filters |
|---|---|
| Jurisdiction | Requirements scoped to a geography or regulatory territory the identity operates within. |
| Issuer | Requirements attached to the issuing company's category or accreditation. |
| Object type | Requirements written for a class of object — food, device, document, facility — matching what the identity represents. |
| Certification scope | Requirements tied to the tier or scope of certification the identity holds or seeks. |
| Time | Requirements in force at the moment being evaluated, respecting effective and expiry dates on the rule itself. |
All five are evaluated together, not in isolation. An identity can match a jurisdiction and object type but fall outside a requirement's certification scope, in which case that requirement is not applicable despite the partial match.
03Governance Ownership Of Requirement Text
Applicability determines which text applies; it never determines what the text says. Authorship, wording and interpretation of requirements sit entirely with QRProtocol.us as governance.
- Requirement text is drafted, published and amended exclusively under governance authority.
- Validation reads requirement text as fixed input; it does not paraphrase, soften or extend it during evaluation.
- A perceived gap or ambiguity in requirement text is referred upstream for clarification, not resolved locally.
- Scope conditions — jurisdiction, object type and the rest — are themselves authored by governance as part of the requirement.
QRCompliance.us determines applicability and evaluates against it. It does not write, interpret away, or waive requirement text.
04Amendment And Effective-State Handling
Requirements are not static. Governance amends them, and the applicable set for a given identity can change on the amendment's effective date without anything about the identity itself changing.
- 1Amendment publishedGovernance issues a new or revised requirement with a declared effective date.
- 2Prior text remains authoritative until effectiveEvaluations occurring before the effective date continue to use the prior text, preserving historical accuracy.
- 3Applicability re-run at the boundaryFrom the effective date forward, applicability is recalculated using the amended text for every identity it now covers.
- 4State change where the outcome differsIf the amendment alters an identity's condition, the event is recorded as a state change (Route 10) caused by the amendment.
This is why a past evaluation is never silently rewritten by a later amendment. The requirement text that was in force at evaluation time is what that historical finding is measured against, permanently.
05Applicability Categories
| State | Entered When | Left When |
|---|---|---|
| Applicable | All scope conditions on the requirement match the identity's attributes at evaluation time. | A scope condition, or an identity attribute it depends on, changes. |
| Not applicable | One or more scope conditions fail to match; the requirement is out of scope for this identity. | A relevant attribute of the identity changes so the match now succeeds. |
| Pending effective | A requirement is published but its effective date has not yet arrived. | The effective date is reached and applicability is recalculated. |
| Superseded | An amendment has replaced the requirement for evaluations from its effective date forward. | None — historical evaluations retain the superseded text permanently. |
| Unresolved | A scope condition cannot be matched because a needed identity attribute or rule detail is missing. | The missing attribute or rule detail is supplied and applicability is redetermined. |
06Unresolved Applicability
Sometimes the match cannot be made cleanly — an identity's jurisdiction is not yet recorded, a new object-type category has no scope rule written for it yet, or two requirements appear to overlap in a way governance has not addressed.
- ✓Unresolved applicability is never defaulted to 'not applicable' to avoid a false pass.
- ✓It is never defaulted to 'applicable' either, to avoid inventing an obligation governance never wrote.
- ✓It is raised as an exception condition, the same outcome used when evaluation itself cannot complete (Route 03).
- ✓The exception is routed to governance or registration, whichever holds the missing fact, rather than guessed at by validation.
- ✓Resolution is recorded, and evaluation runs cleanly from that point forward.
Treating unresolved applicability as its own honest outcome protects both sides: an identity is not held to a rule that was never confirmed to apply, and a rule is not silently ignored because the match was inconvenient to determine.
07System Relationship
Applicability is the hinge between governance's rule text and validation's evaluated conditions — the step that turns a general body of requirements into a specific, defensible set for one identity.
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 Applicability |
|---|---|
| ROOT — QuickResponseCode.us | Establishes the authority under which any requirement can bind an identity at all. |
| GOVERNANCE — QRProtocol.us | Authors requirement text and its scope conditions. Owns amendments and effective dates. |
| VALIDATION — QRCompliance.us | Determines the applicable set for each identity and evaluates against it. Sole determiner. |
| AUTHORIZATION — QRCertified.us | Relies on applicability having been determined correctly before trusting the resulting condition. |
| REGISTRATION — QRRegistered.us | Supplies the identity attributes — jurisdiction, object type, scope — that applicability is matched against. |
| OPERATIONS — QRCodex.us | Retains the applicable set used at each evaluation as part of the historical record. |
Where a determined applicable set appears to contradict QRCodex.us, Codex governs and the determination is corrected against it.
What This Does — And Does Not — Do
Does
- ✓Match identity attributes against requirement scope conditions across jurisdiction, issuer, object type, certification scope and time
- ✓Recalculate applicability at an amendment's effective date without rewriting prior evaluations
- ✓Treat the applicable set as an input to evaluation, determined before comparison runs
- ✓Raise an exception when applicability cannot be cleanly matched
- ✓Preserve superseded requirement text for historical evaluations
- ✓Route unresolved matches to whichever layer holds the missing fact
Does Not
- ✕Author, interpret or amend requirement text — that is governance's function alone
- ✕Default an unresolved match to applicable or not applicable to avoid raising an exception
- ✕Apply an amended requirement retroactively to evaluations before its effective date
- ✕Merge applicability determination with the evaluation it feeds
- ✕Assume attributes it was not supplied by registration
- ✕Waive a requirement because matching it was inconvenient or ambiguous
Related Routes
Common Questions
Who decides what a requirement actually says?
QRProtocol.us, as governance, authors and amends requirement text. QRCompliance.us determines which requirements apply to a given identity and evaluates against the text as written.
Can the same protocol produce different applicable sets for different identities?
Yes. Applicability is matched per identity against jurisdiction, issuer, object type, certification scope and time, so two identities under the same governance can face entirely different applicable requirements.
What happens to past evaluations when a requirement is amended?
Nothing. Prior evaluations remain measured against the requirement text in force at their evaluation time. The amendment applies from its effective date forward.
What if applicability cannot be determined for an identity?
It is raised as an exception, the same outcome used when evaluation itself cannot complete. It is never assumed applicable or not applicable by default.
Does applicability change without any change to the identity?
Yes. A governance amendment with a new effective date can alter the applicable set for identities that have not changed at all, since the rule itself moved.
Is applicability part of the evaluation, or separate from it?
Separate and prior. Applicability is determined first; evaluation then compares the record only against the requirements that determination selected.