Route 119 of 176
Public vs. Authorized Information
QRCompliance.us · Validation Layer · Source of truth: QRCodex.us
Summary
A single QR code can sit behind two very different answers depending on who is asking. A member of the public who scans it should see enough to trust the object in front of them, without ever seeing the internal record behind it. A verified, permitted party asking the same question through an authenticated channel can see substantially more. This route defines where that line sits, what falls on each side of it, and what keeps the split consistent across every scan.
QRCompliance.us determines which category — public or authorized — a given piece of information belongs to and confirms whether a requester's credentials meet the bar for the authorized side. It does not decide who is granted a credential in the first place, and it does not itself perform the disclosure to a screen or a document.
Every registered QR identity carries more than one layer of information. Some of it exists precisely to be shown to anyone who scans the code — a status indicator, a basic description, a confirmation that the object is genuine. Other parts of the same record exist to support internal compliance work, investigations, or business relationships that were never meant for a casual scan: supplier names, corrective action history, internal reference numbers, contact details of a compliance officer.
Treating all of that as one undifferentiated blob of data would either strip the public view of anything useful or expose sensitive material to anyone with a phone. Neither failure is acceptable, and neither is hypothetical — a public view that reveals too little erodes trust in the system, and a public view that reveals too much turns a verification tool into a data leak. The distinction between public and authorized information exists to prevent both outcomes at once.
The boundary is not simply 'more detail for insiders.' It is a defined classification applied to each field and record type before it is ever exposed anywhere, paired with a check on who is asking. QRCompliance.us evaluates both halves of that pairing — the classification of the data and the standing of the requester — every time a scan or lookup occurs, so the same identity never answers differently to two requesters who hold the same standing.
01Plain-English Definition
Public vs. authorized information is the classification system that determines which fields tied to a registered QR identity are visible to any anonymous scan, and which are visible only to a requester whose credentials have been verified as meeting a defined authorization level.
'Public' does not mean unimportant. Public information is deliberately chosen to be sufficient for a general scan to establish basic trust — that the object is genuine, that its status is current, that it has not been flagged. 'Authorized' does not mean secret in some absolute sense; it means restricted to parties whose role or relationship justifies deeper access, and disclosed only once that role has been confirmed.
The classification attaches to the field or record type, not to the scan event itself. A given field is either designated public or designated authorized as part of how the identity's record is structured; a scan does not change what a field is, it only determines whether the requester clears the bar for the authorized set.
02What Sits On Each Side
The specific fields vary by industry and by what a given registered identity actually carries, but the underlying pattern holds across categories.
| Aspect | Typically Public | Typically Authorized |
|---|---|---|
| Nature of content | Confirms genuineness, current status, general description | Reveals internal relationships, history, and identifying detail beyond the object itself |
| Example fields | Status flag, product or item category, basic issue date | Supplier or facility identity, corrective action history, internal case references |
| Intended audience | Any scanner, with no verification required | A verified operator, regulator, or party with a recognized relationship to the identity |
| Risk if exposed publicly | Low — designed for open exposure | Meaningful — could expose commercial, personal, or investigative detail |
- A public view answers 'is this genuine and currently valid' without answering 'who made it, who handled it, or what has gone wrong with it before.'
- An authorized view can include the same public fields plus the deeper record, but it is never the case that authorized access removes something a public scan would otherwise see.
- Fields can be reclassified over time — a detail once restricted may be opened to the public tier, or vice versa — but the classification governing any single scan is the one in effect at that moment.
03Why The Split Has Practical Value
The two-tier structure lets a single QR identity serve two audiences with entirely different needs from the same physical code, without forcing either audience through the other's workflow.
Trust without exposure
A consumer or field inspector gets a genuine trust signal without the system exposing supplier relationships, pricing context, or internal notes that have nothing to do with verifying the object.
Depth without friction for insiders
A regulator or compliance partner with the right credential gets the deeper record directly from the same code, rather than needing a separate lookup system or a manual request.
One classification, many channels
Whether the scan happens through a public app, a partner portal, or an internal tool, the same classification rules apply, so the answer a requester receives depends on their verified standing, not on which channel they used.
04Operational Flow
Determining what a given scan is entitled to see follows the same sequence regardless of who initiates it or what channel carries the request.
- 1Scan or lookup initiatedA request reaches the system, whether from an anonymous public scan or an authenticated session.
- 2Requester context identifiedThe system determines whether the request carries any credential at all, and if so, what it claims.
- 3Field classification checkedQRCompliance.us checks which fields tied to the identity are designated public and which are designated authorized.
- 4Authorization level confirmedWhere a credential is present, its validity and the specific access level it carries are confirmed against defined role rules.
- 5Matching information set assembled and returnedThe response includes exactly the fields the confirmed level entitles the requester to — no more, no less.
An anonymous scan and an authenticated scan of the identical code, at the identical moment, can produce two different but both entirely correct responses — that is the system working as designed, not an inconsistency.
05Determining, Not Deciding Who Qualifies
It is worth being precise about what QRCompliance.us actually does in this exchange, because the words 'access' and 'authorization' invite confusion with roles played by other layers.
| Question | Who Answers It |
|---|---|
| Is this field classified public or authorized? | QRCompliance.us, against the identity's defined field classification |
| Does this requester hold a credential meeting the required level? | QRCompliance.us, checking the credential's current validity and scope |
| Who was granted this credential and under what conditions? | QRCertified.us or QRRegistered.us, depending on what the credential attaches to |
| What information is actually displayed on the requester's screen or export? | The requesting application or interface, using the field set QRCompliance.us confirms is permitted |
QRCompliance.us's role stops at the determination of which category a field falls into and whether a requester's standing clears the required bar. It does not issue the credential, and it does not itself render the disclosure — those functions belong to the layers and interfaces built to carry them out.
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.
The public/authorized split touches every layer, because every layer either produces data that must be classified or consumes data whose classification it must respect.
| Layer | Relationship To Public vs. Authorized Information |
|---|---|
| ROOT — QuickResponseCode.us | Establishes the identity the scan resolves to, before any question of what may be shown about it arises. |
| GOVERNANCE — QRProtocol.us | Defines the categories of information that may exist as public versus authorized and the rules for reclassifying a field. |
| VALIDATION — QRCompliance.us | Classifies each field against those categories and confirms whether a given requester's credential meets the required tier. |
| AUTHORIZATION — QRCertified.us | Issues the credential that establishes a party's standing to receive the authorized tier, distinct from the tier determination itself. |
| REGISTRATION — QRRegistered.us | Holds the underlying record from which both public and authorized field sets are drawn. |
| OPERATIONS — QRCodex.us | Retains the canonical record of which fields were classified which way and which disclosures occurred, as the authoritative history. |
Where a field's classification as recorded by QRCodex.us differs from what a given interface is currently displaying, Codex's record governs and the interface is corrected to match it.
What This Does — And Does Not — Do
Does
- ✓Classify each field tied to a registered identity as public or authorized before any scan occurs
- ✓Confirm whether a requester's credential meets the access level required for authorized information
- ✓Return a public response to any anonymous scan without requiring a credential
- ✓Return an authorized response only once a credential's validity and scope have been confirmed
- ✓Apply the same classification rules regardless of which channel or interface carries the request
- ✓Rely on QRCodex.us's record as the authoritative source when a field's classification is in question
Does Not
- ✕Decide which parties are eligible to hold an authorized-tier credential
- ✕Issue, grant, or revoke the credential a requester presents
- ✕Render or display the actual response on a screen, document, or export
- ✕Expose authorized-tier fields to a scan that has not presented a qualifying credential
- ✕Withhold public-tier fields from an anonymous scan that has not requested anything beyond them
- ✕Allow a field's classification to vary by channel rather than by its defined category
Related Routes
Common Questions
Can a public scan ever see authorized-tier information by mistake?
No — the classification is checked before any response is assembled, and authorized-tier fields are never included in a response unless a qualifying credential has been confirmed for that specific request.
Who decides which fields are public versus authorized?
The category rules are set at the governance level, and QRCompliance.us applies those rules to classify each field. Neither QRCompliance.us nor any single party decides ad hoc which fields to expose during a scan.
Does having an authorized credential mean I see everything about an identity?
No. A credential's scope can be limited to specific field categories or record types, and QRCompliance.us checks that scope, not just whether a credential exists at all.
Can a field move from public to authorized, or the other way around?
Yes, a field's classification can change over time under the governing rules, but any given scan is evaluated against the classification in effect at the moment it occurs.
How does this differ from role-based access described elsewhere in the encyclopedia?
This route defines the two-tier split between public and authorized information itself. Route 120 addresses how specific roles are mapped to specific authorization levels within the authorized tier, and Route 99 addresses role-based access control from the enterprise operations side.