Why Identifold

Why Identifold?

Applications often ask one identifier to serve three audiences that have different needs:

Audience	Need	Identifold representation
Databases	Compact, canonical keys with useful insertion ordering	MID
APIs, events, and logs	A typed public value that identifies its resource kind	PID
Customers and staff	A short value that can be read, copied, and checked	REF

Raw UUIDs lose type context at public boundaries. Prefixed strings make poor canonical database keys. Truncated IDs are easy to mistype and cannot safely claim uniqueness without a collision strategy. Identifold gives each audience an appropriate representation while preserving one underlying identity.

Disputed-charge example

Bob disputes a charge for an employee order. His receipt displays the human reference:

ORD-7K4M-2P8Q-3D-9

Alice works in HR operations and opens the internal support tool:

1. Bob reads the REF to Alice.
2. Alice enters it. The application normalizes the text and verifies its check symbol.
3. Passing the checksum proves the text is well formed, not that the order exists.
4. Storage looks up (order, ORD-7K4M-2P8Q-3D-9) and returns the canonical MID.
5. The support service loads the order by MID.
6. When the order crosses an API, event, or log boundary, the service derives the typed PID order_01kn675j8gfa2b64tkrep638sf.
7. A receiving service deterministically converts that PID back to the same MID and loads its canonical row.

Bob                 Alice                  Application/API                  Database
REF  -------------> REF validation -----> REF lookup --------------------> MID
                                              |
                                              +---- derive/parse PID <----> MID

The REF does not encode the MID and does not mathematically convert into the PID. Its stored mapping resolves directly to the MID. The PID is a deterministic presentation of that MID with an order namespace.

This separation gives each participant what they need:

• Bob gets a readable reference with typo detection.
• Alice gets the same stable reference in the support interface.
• services get a typed public identifier for diagnostics and integration boundaries.
• the database keeps one canonical UUID primary key.

Authentication and authorization remain separate. Knowing the REF, PID, or MID must never grant Alice or Bob access by itself.

Why a shared specification?

Identity behavior drifts when every service independently implements TypeID encoding, REF normalization, checksums, and errors. Identifold freezes:

• one wire contract;
• one namespace model;
• one stable error taxonomy;
• one public vector corpus; and
• one conformance runner used by all ten language implementations.

That makes an identifier created in one supported language behave the same in every other supported language.