ECZ-ID public infrastructure
Governance is published here. Verification happens in Resolver.ECZ-ID specification
ECZ-ID defines a stable parent identity spine that can be cited across contracts, systems, platforms, agents, APIs, marketplaces, insurers, auditors, regulators, and automated review flows without encoding changing state inside the identifier itself.
What the ECZ-ID is
What the ECZ-ID is not
Canonical form
The ECZ-ID should remain safe to cite in contracts, systems, manifests, logs, resolver URLs, procurement records, agent metadata, API documentation, badge links, and evidence references without changing when tier, authority, or state changes.
ECZ identifies the identifier family and separates ECZ-ID references from local customer names, domains, badges, and marketplace labels.
CC is the two-letter country code used in the parent identifier format. It must not be treated as a changing authority or state field.
XXXXXX is the stable six-character identifier body. It is not a tier, product, score, approval, or lifecycle signal.
The ID points to the current public answer in Resolver. Resolver output, not the ID string alone, determines public reliance posture.
Parent and child separation
ECZ-ID avoids identity explosion by keeping the parent identifier stable while child passports describe scoped accountability surfaces underneath that parent identity.
ECZ-GB-A93K7Q
ECZ-GB-A93K7Q::API-2Q7X9B
/p/ECZ-GB-A93K7Q/API/2Q7X9B
Interpretation rules
A copied page, badge image, marketplace listing, agent profile, API label, document, screenshot, or private message is not the authority plane. ECZ-ID interpretation must resolve through the correct public and operational surfaces.
Issuance, authority changes, lifecycle state, suspension, downgrade, revocation, and eligibility are backend-owned.
Resolver is the public read-only verification surface for current state, identifiers, public-safe receipts, and machine-readable outputs.
TrustOps handles acquisition, activation, setup, customer access, lifecycle control, payment, and repair workflows over backend truth.
Developer Gateway provides schemas, route indexes, examples, and implementation guidance. It does not issue proof or write truth.
Machine-readable public infrastructure
ECZ-ID references are designed for procurement teams, agents, platforms, APIs, auditors, insurers, marketplaces, and automated systems that need a repeatable way to resolve current public state without treating public copy as authority.
Use Resolver for current public state and machine-readable proof.
Use Developer Gateway for schemas, route indexes, manifests, examples, and safe integration patterns.
Use TrustOps for acquisition, setup, lifecycle action, binding repair, and customer operation.
Safe usage examples
Cite the parent ECZ-ID as a stable identity reference, then require Resolver checks for current state before reliance.
Include ECZ-ID references in agent metadata or manifests, but require Resolver output before automated reliance.
Use ECZ-ID references in API documentation, OpenAPI extensions, package metadata, or software supply-chain records.
Badges and public pages should route to Resolver. They must not become proof clones or independent authority surfaces.
Use the identifier to locate the relevant public proof surface, receipts, effective dates, and current state where available.
Use ECZ-ID as a reference key for review and routing, not as a platform endorsement or automatic approval signal.
Public reference path
Use this page to understand the parent identifier model. Use Resolver for current public proof. Use TrustOps for acquisition, setup, lifecycle, and repair. Use Developer Gateway for implementation guidance, schemas, and machine-readable integration.