Comparison matrix
Primary-source review queue vs Verified history record
One-sentence distinction
Primary-source review queue and Verified history record answer different evidentiary or operational questions and must remain separate.
Side-by-side matrix
| Dimension | Primary-source review queue | Verified history record |
|---|---|---|
| Primary question | What evidence establishes the first property for a named purpose? | What separate evidence or authority establishes the second property? |
| Evidence | Purpose-specific technical, factual, or institutional records. | Independent records appropriate to the second category. |
| Authority | May be descriptive or technical and may not require legal authority. | May require a competent legal, constitutional, organizational, or operational decision-maker. |
| Currentness | Can be current, stale, disputed, unknown, or unavailable. | Must be assessed separately; the first status does not transfer. |
| Failure condition | Evidence may be authentic but incomplete or unsuitable. | Authority may exist but rely on wrong or stale facts. |
Why the distinction matters
Primary-source review queue and Verified history record answer different evidentiary or operational questions and must remain separate. Systems and institutions fail when one side is used as a shortcut for the other. The distinction determines what evidence is collected, who may decide, what can be appealed, and which failure modes must be controlled.
Common failure caused by conflation
Conflation can manufacture readiness, erase uncertainty, bypass accountable review, or expose protected information.
This error can create false confidence, unauthorized status, misattributed liability, silent loss of correction rights, or an operational claim based only on descriptive material.
Implementation consequences
- Use different fields, identifiers, and claim-status records for each side.
- Require separate evidence and currentness checks.
- Do not let a user-interface label silently merge the categories.
- Preserve correction and supersession history for both.
- Route decisions to the ecosystem authority that owns the relevant function.
Legal consequences
Registry policy, trademark, consumer-protection, accessibility, security, and service obligations remain jurisdictional and operational questions beyond Unicode or IDNA conformance.
Technical evidence can inform a legal decision but cannot replace jurisdiction, legal basis, procedural authority, due process, or remedy. Conversely, a lawful decision does not make the underlying technical record accurate if the evidence is stale or defective.
Examples
- A valid signature demonstrates control over a key and payload integrity; it does not establish the truth of every signed statement.
- A registry can record a citizenship decision; the registry operator does not thereby acquire constitutional power to create citizenship.
- A static release can show that software exists; it does not prove the service is currently operating.
Sources
- Unicode 17.0 Runic Code Chart — Unicode Consortium; Unicode 17.0; OFFICIAL CHARACTER CODE CHART. Exact claim-support entries: 1. Revalidated 2026-08-15T23:55:00Z.
- Unicode Standard Annex #15 — Unicode Normalization Forms — Unicode Consortium; Unicode 17.0.0, Revision 57; UNICODE STANDARD ANNEX. Exact claim-support entries: 1. Revalidated 2026-08-15T23:55:00Z.
- RFC 3492 — Punycode: A Bootstring Encoding of Unicode for IDNA — IETF / RFC Editor; RFC 3492; PROPOSED STANDARD; UPDATED BY RFC 5891. Exact claim-support entries: 1. Revalidated 2026-08-15T23:55:00Z.
- RFC 5890 — IDNA Definitions and Document Framework — IETF / RFC Editor; RFC 5890; PROPOSED STANDARD. Exact claim-support entries: 1. Revalidated 2026-08-15T23:55:00Z.
- RFC 5891 — Internationalized Domain Names in Applications: Protocol — IETF / RFC Editor; RFC 5891; PROPOSED STANDARD. Exact claim-support entries: 1. Revalidated 2026-08-15T23:55:00Z.
Comparison claim record
Each proposition has a stable ID, status, scope, owning route, evidence relationship, currentness qualification, correction state, and synchronized JSON record. Record completeness does not make the proposition true.
Primary-source review queue versus Verified history record
Primary-source review queue and Verified history record answer different evidentiary or operational questions and must remain separate.
Support relationship
SRC-UNICODE-RUNIC-17· Runic range and character names · DIRECT OR QUALIFYING SOURCE SUPPORTSRC-UNICODE-UAX15-17· Normalization forms and conformance · DIRECT OR QUALIFYING SOURCE SUPPORTSRC-RFC-3492· Abstract and encoding algorithm · DIRECT OR QUALIFYING SOURCE SUPPORT