Route 141 of 176
Applicable Protocol Rule
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Before QRCompliance.us can evaluate anything, it first has to know which rule governs the case in front of it. A rule written by QRProtocol.us does not apply everywhere, to everyone, forever — it applies to a defined scope, under defined conditions, during a defined window. This route defines how that applicable rule is identified, how conflicts between candidate rules are resolved, and how the selection itself is recorded so a later audit can confirm the right rule was used.
QRProtocol.us writes the rules. QRCompliance.us selects and applies the rule that actually fits the case at hand. Selecting the applicable rule is not the same as writing it, and QRCompliance.us never alters a rule's substance while identifying it.
A governance layer that issued only one universal rule for every identity, every jurisdiction, and every category would need no selection logic at all — but that is not how QRProtocol.us operates. It issues rule sets scoped to categories of product, ranges of jurisdiction, versions of a program, and windows of time. The practical question this route answers is: given a specific identity being evaluated right now, which of those many rules is the one that actually applies?
Getting this wrong in either direction causes real damage. Applying a rule that has already been superseded produces an evaluation against a standard nobody currently expects. Applying a rule that has not yet taken effect, or that belongs to a different jurisdiction or category, produces the same problem in a different disguise. The applicable-rule determination exists precisely to prevent both failure modes before evaluation ever starts.
This is a scoping exercise, not a judgment on compliance. Identifying the applicable rule says nothing yet about whether the identity satisfies it. That question belongs to evaluation, which happens only after the correct rule has been fixed. Keeping selection and evaluation as two distinct steps, in that order, is what makes every later determination defensible.
01Plain-English Definition
The applicable protocol rule is the single, specific rule — out of everything QRProtocol.us has ever issued — that governs a given identity's evaluation, determined by matching the identity's category, jurisdiction, version and timing attributes against each candidate rule's declared scope.
Every rule QRProtocol.us issues carries a scope: the category of product or credential it covers, the jurisdictions where it takes effect, the version of a program it belongs to, and the window of time during which it is in force. None of those scopes is optional metadata — each one is a condition that must match before the rule can be considered applicable at all.
Determining the applicable rule therefore means comparing the identity's own attributes against every candidate rule's scope and keeping only the ones that actually match. Where more than one still matches, a precedence order — also set by GOVERNANCE, not improvised by QRCompliance.us — decides which one governs.
02What Determines Applicability
Four attributes carried by the identity itself are compared against each candidate rule's declared scope to decide whether that rule is a candidate at all.
- Category — the type of product, credential or identity the rule was written to cover.
- Jurisdiction — the region, market or regulatory boundary in which the identity is being evaluated.
- Program version — the specific edition of a governance program the identity was registered or issued under.
- Effective window — the start and, where applicable, end date during which the rule is in force.
A rule that matches on category and jurisdiction but falls outside the identity's effective window is not a weaker candidate — it is not a candidate at all. Applicability is not a matter of degree; a rule either applies or it does not.
03Practical Value
Fixing the applicable rule before evaluation begins protects every party with a stake in the outcome, not only QRCompliance.us itself.
Consistency across identical cases
Two identities with the same category, jurisdiction and timing attributes are guaranteed to be evaluated against the same rule, regardless of when or where the evaluation runs.
Defensibility under challenge
A recorded rule-selection basis lets a disputed determination be checked against the specific scope conditions that made the rule applicable, rather than argued from memory.
Clean handling of transition periods
When a rule changes, effective windows prevent an identity from being caught between an old rule and a new one with no defined answer.
04Operational Flow
Applicable-rule determination runs as a fixed sequence every time an identity is presented for evaluation, before any substantive check of its condition begins.
- 1Identity presented for evaluationAn identity enters the evaluation pipeline carrying its own category, jurisdiction, version and timing attributes.
- 2Scope attributes extractedThose attributes are read from the identity's record rather than assumed or inferred from context.
- 3Candidate rules identifiedEvery rule issued by QRProtocol.us whose declared scope could plausibly cover the identity is pulled as a candidate.
- 4Non-matching candidates eliminatedAny candidate whose scope fails to match on category, jurisdiction, version or effective window is dropped.
- 5Applicable rule fixed and recordedWhere exactly one candidate remains, or precedence resolves a tie among several, that rule is fixed as applicable and the basis for its selection is recorded ahead of evaluation.
If evaluation runs before the applicable rule is fixed and recorded, the sequence has failed regardless of what the evaluation later finds.
05Resolving Overlap and Conflict
Scopes are not always mutually exclusive. A jurisdiction-wide rule and a category-specific rule can both plausibly cover the same identity, and two versions of a program can briefly overlap during a transition window. When more than one candidate survives matching, precedence — set by GOVERNANCE — decides the outcome.
| State | Entered When | Left When |
|---|---|---|
| Single candidate matches | Exactly one rule's scope covers the identity's attributes. | That rule is fixed as applicable without further comparison. |
| Multiple candidates match, precedence defined | More than one rule's scope covers the identity, and GOVERNANCE has set an explicit precedence order between them. | The higher-precedence rule is fixed as applicable; the others are recorded as considered but superseded. |
| Multiple candidates match, precedence undefined | More than one rule's scope covers the identity and no precedence order resolves the overlap. | The determination is held and escalated to GOVERNANCE for clarification rather than resolved by inference at the validation layer. |
| No candidate matches | No issued rule's scope covers the identity's attributes. | Evaluation cannot proceed until GOVERNANCE issues or clarifies a rule covering the gap. |
06What QRCompliance.us Does Not Decide Here
Determining the applicable rule is strictly a scope-matching exercise. QRCompliance.us does not draft, amend, or reinterpret a rule's substance while selecting it, and it does not use this step to reach a compliance outcome.
- ✓Matches identity attributes against declared rule scopes
- ✓Applies GOVERNANCE-set precedence where more than one candidate matches
- ✓Records the selection basis before evaluation begins
- ✓Escalates undefined conflicts and coverage gaps to QRProtocol.us rather than guessing
None of that authority extends to writing new scope conditions, resolving an undefined conflict on its own judgment, or treating the applicable-rule determination as a finding about whether the identity actually complies.
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.
The applicable protocol rule is the hinge between governance's authorship of rules and validation's application of them, and every layer downstream depends on that hinge being fixed correctly and recorded before evaluation runs.
| Layer | Relationship To Applicable Protocol Rule |
|---|---|
| ROOT — QuickResponseCode.us | Supplies the stable identity whose attributes are read to determine which rule scope applies. |
| GOVERNANCE — QRProtocol.us | Authors every candidate rule, defines its scope and effective window, and sets the precedence order used when scopes overlap. |
| VALIDATION — QRCompliance.us | Matches identity attributes against candidate scopes and fixes the single applicable rule before evaluation begins. |
| AUTHORIZATION — QRCertified.us | Relies on the fixed applicable rule to know which certification standard a determination was actually measured against. |
| REGISTRATION — QRRegistered.us | Ensures the identity's registered category, jurisdiction and version attributes are accurate inputs to the matching step. |
| OPERATIONS — QRCodex.us | Retains the permanent record of which rule was selected as applicable, on what basis, for every evaluation performed. |
Where a recorded evaluation and QRCodex.us disagree about which rule was applicable at the time, Codex's record governs the reconciliation.
What This Does — And Does Not — Do
Does
- ✓Match an identity's category, jurisdiction, version and timing attributes against every candidate rule's declared scope
- ✓Fix the single applicable rule before any substantive evaluation of the identity's condition begins
- ✓Apply GOVERNANCE-set precedence when more than one candidate rule's scope matches
- ✓Escalate undefined conflicts and coverage gaps to QRProtocol.us rather than resolving them by inference
- ✓Record the selection basis for the applicable rule ahead of and separate from the evaluation outcome
- ✓Treat a rule outside its effective window as not applicable, not merely as a weaker candidate
Does Not
- ✕Draft, amend or reinterpret a rule's substance while identifying it as applicable
- ✕Reach a compliance outcome as part of the applicable-rule determination itself
- ✕Resolve an undefined precedence conflict on its own judgment rather than escalating it
- ✕Assume an identity's scope attributes rather than reading them from its record
- ✕Apply a superseded or not-yet-effective rule because no other candidate is readily available
- ✕Allow evaluation to proceed before the applicable rule has been fixed and recorded
Related Routes
Common Questions
Can QRCompliance.us decide which rule should apply if none of the issued rules quite fits?
No. Where no candidate rule's scope covers the identity, QRCompliance.us cannot proceed to evaluation on its own inference — the gap is escalated to QRProtocol.us for a rule or a clarification.
What happens if two rules both technically match an identity's attributes?
GOVERNANCE-set precedence resolves the overlap where one exists. Where no precedence order has been defined for that overlap, the determination is held and escalated rather than guessed.
Does fixing the applicable rule mean the identity has been found compliant with it?
No. Selecting the applicable rule only fixes which standard governs the case. Whether the identity actually satisfies that standard is decided separately, during evaluation.
Why does the effective window matter if the category and jurisdiction already match?
A rule outside its effective window is not applicable at all, regardless of how well it matches on other attributes. Timing is a hard condition, not a tiebreaker.
Is the applicable-rule selection recorded even if it never gets disputed?
Yes. It is recorded for every evaluation as a matter of routine, so the basis is available if a dispute or audit ever needs it later.