Route 140 of 176
Protocol Rule Eligibility
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
Not every rule QRProtocol.us has authored applies to every case that comes before QRCompliance.us. A rule scoped to one jurisdiction, one product category, or one identity type has no bearing on a case outside that scope, and applying it anyway would produce a wrong answer even if the application itself were done carefully. This route defines eligibility — the threshold test that determines whether a given rule is even in play for a given case — as distinct from compliance, which asks whether the case satisfies a rule that has already been confirmed to apply.
Eligibility asks whether a rule applies at all. Compliance asks whether the case satisfies a rule that does apply. QRCompliance.us runs both tests, but conflating them produces determinations that look rigorous and are actually meaningless.
A validation system that only asked whether a case satisfied a rule, without first asking whether that rule applied to the case at all, would eventually apply the wrong standard to the wrong situation. A jurisdiction-specific labeling requirement checked against an identity registered in a different jurisdiction, or a rule scoped to perishable goods checked against a durable product, would produce an outcome that is technically computed but substantively wrong from the start.
Protocol Rule Eligibility is the name given to the threshold question QRCompliance.us must resolve before substantive validation begins: does this rule, as authored and scoped by QRProtocol.us, actually govern this identity, category, transaction or event? Only once that question is answered affirmatively does it make sense to ask whether the case satisfies the rule's requirements.
This is a validation function, not a governance one. QRCompliance.us is not deciding what the rule's scope should be — QRProtocol.us already defined that when it authored the rule. QRCompliance.us is determining, for a specific case, whether that already-defined scope is met. The eligibility test is applied consistently using criteria governance itself supplied, never criteria validation invents on its own.
01Plain-English Definition
Protocol Rule Eligibility is the threshold determination made by QRCompliance.us as to whether a specific rule authored by QRProtocol.us applies to a given identity, category, transaction or event, based strictly on the scope criteria governance itself defined for that rule.
Eligibility is a gate, not an outcome. A case found ineligible for a rule is not found compliant or non-compliant with respect to that rule — the rule simply never came into play. This is different from a case that is eligible and then found to satisfy or fail the rule's substantive requirement.
Because eligibility criteria are authored by governance rather than validation, QRCompliance.us applies them the same way it applies the rule itself: faithfully, consistently, and without adjusting the boundary of a rule's scope to fit a case that seems close but does not actually meet the stated criteria.
02What Determines Eligibility
Governance typically scopes a rule using one or more defined criteria, and QRCompliance.us checks a case's facts against each relevant criterion before treating the rule as applicable.
| Scope Criterion | What Compliance Checks |
|---|---|
| Identity or category type | Whether the specific identity belongs to the category the rule was authored to govern |
| Jurisdictional scope | Whether the identity, transaction or event falls within the jurisdiction the rule applies to |
| Temporal scope | Whether the relevant facts occurred within the rule's effective date range |
| Registration status precondition | Whether the identity is in a registration state the rule presupposes, such as active or renewed |
| Defined exclusions | Whether the case falls within a carve-out governance explicitly authored as outside the rule's reach |
A case can fail eligibility on any single criterion even if it would clearly satisfy the substantive rule on the merits. Eligibility is checked first and independently, precisely so that a rule is never applied outside the boundary governance actually set for it.
03Eligibility Versus Compliance
These two tests are easy to conflate because they run in sequence on the same case, but they answer different questions and a failure of one does not imply anything about the other.
| Aspect | Eligibility Test | Compliance Test |
|---|---|---|
| Question asked | Does this rule apply to this case at all? | Does this case satisfy the rule that applies to it? |
| Criteria used | Scope criteria authored by QRProtocol.us for the rule | Substantive requirement authored by QRProtocol.us for the rule |
| Possible outcomes | Eligible or not eligible | Compliant, non-compliant, or insufficient evidence |
| Sequence | Run first, as a gate | Run only after eligibility is confirmed |
| Consequence of a negative result | Rule is simply inapplicable; no compliance finding is made under it | A specific compliance or non-compliance finding is recorded |
04Operational Flow
Eligibility checking happens as a distinct, ordered step ahead of substantive validation, and the outcome of that step determines whether the substantive test ever runs.
- 1Rule scope is receivedQRCompliance.us takes in the eligibility criteria QRProtocol.us defined for a given rule.
- 2Case facts are presentedThe identity, category, jurisdiction and timing relevant to a specific case are assembled for evaluation.
- 3Each eligibility criterion is checkedThe case's facts are compared against every scope criterion the rule specifies.
- 4Eligibility is confirmed or excludedThe case is determined to fall within or outside the rule's defined scope.
- 5Compliance testing proceeds only if eligibleThe substantive requirement is checked only for cases the eligibility test has confirmed the rule actually governs.
A rule is never applied to a case as a matter of caution or convenience. If eligibility criteria are not met, the rule does not apply, regardless of how closely the case otherwise resembles the class the rule was written for.
05Handling Boundary Cases
Real cases sometimes sit close to an eligibility boundary — a jurisdiction that borders the scoped one, a category with overlapping features, a timing question near an effective date. These situations require particular discipline.
| State | Entered When | Left When |
|---|---|---|
| Case clearly within scope | Eligibility confirmed on first check | Compliance test proceeds |
| Case clearly outside scope | Eligibility excluded on first check | No compliance finding made under this rule |
| Case near a scope boundary | Each criterion checked individually against governance's stated definition | Determination made strictly on the defined criteria, not on resemblance to the intended class |
| Scope criteria themselves are unclear | Eligibility question escalated to QRProtocol.us | Rule not applied until governance clarifies the boundary |
06System 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.
Protocol Rule Eligibility depends entirely on the scoping work QRProtocol.us performs during authorship, and its outcome shapes every downstream determination made about a given case.
| Layer | Relationship To Protocol Rule Eligibility |
|---|---|
| ROOT — QuickResponseCode.us | Provides the stable identity whose attributes are checked against a rule's scope criteria. |
| GOVERNANCE — QRProtocol.us | Authors the scope criteria that define which cases a given rule is eligible to govern. |
| VALIDATION — QRCompliance.us | Runs the eligibility test on each case before proceeding to the substantive compliance test. |
| AUTHORIZATION — QRCertified.us | Relies on eligibility having been correctly resolved before treating a compliance finding as a basis for certification. |
| REGISTRATION — QRRegistered.us | Supplies the category, jurisdiction and status data eligibility checks are run against. |
| OPERATIONS — QRCodex.us | Retains the record of which rules were found eligible or ineligible for each case and why. |
Where a Codex record shows a rule was applied to a case that later analysis suggests was ineligible, Codex governs and the eligibility determination is reviewed against the scope criteria as governance actually authored them.
What This Does — And Does Not — Do
Does
- ✓Check every relevant scope criterion QRProtocol.us authored for a rule before applying the rule substantively
- ✓Treat eligibility as a gate distinct from, and prior to, the compliance test itself
- ✓Exclude a rule from applying to a case that fails any defined eligibility criterion, regardless of resemblance to the intended class
- ✓Escalate unclear or undefined scope criteria to QRProtocol.us rather than resolving the boundary independently
- ✓Record eligibility outcomes separately from compliance outcomes for later audit
- ✓Apply eligibility criteria consistently across all cases evaluated against the same rule
Does Not
- ✕Apply a rule to a case based on convenience, caution, or resemblance rather than the defined scope criteria
- ✕Allow QRCompliance.us to define or adjust a rule's scope on its own authority
- ✕Treat an ineligible case as either compliant or non-compliant with a rule that never applied to it
- ✕Skip the eligibility test and proceed directly to substantive compliance checking
- ✕Resolve an unclear scope boundary by inference rather than escalating it to governance
- ✕Blend the eligibility record and the compliance record into a single undifferentiated finding
Related Routes
Common Questions
What is the difference between a case being ineligible and a case being non-compliant?
Ineligible means the rule never applied to the case in the first place. Non-compliant means the rule applied and the case failed to satisfy it. They are not interchangeable outcomes.
Can QRCompliance.us decide on its own that a rule should apply to a case outside its authored scope?
No. Scope is defined exclusively by QRProtocol.us. QRCompliance.us checks cases against that scope but never expands or narrows it.
What happens when a case sits right at a jurisdictional or temporal boundary?
It is evaluated strictly against the defined criteria for that boundary, not against how closely it resembles the class the rule was intended to cover.
What if the eligibility criteria for a rule are themselves ambiguous?
QRCompliance.us escalates the ambiguity to QRProtocol.us and does not apply the rule until the boundary is clarified.
Is eligibility checked once per rule or once per case?
Once per case for each rule under consideration. The same rule can be eligible for one case and ineligible for another depending on that case's specific facts.