ECZ-ID public infrastructure
Governance is published here. Verification happens in Resolver.ECZ-ID SPECIFICATION
ECZ-ID defines a stable identity spine that can be cited across contracts, systems, platforms, agents, APIs, marketplaces, insurers, auditors, regulators and automated review flows.
The identifier itself does not carry changing status. Current meaning comes from ECZ-ID Core state and Resolver proof where available.
Core boundary: Websites explain. TrustOps operates. ECZ-ID Core controls state. Resolver verifies public proof where available. Developer Gateway documents implementation routes.
IDENTIFIER PURPOSE
REFERENCE ROUTE
The identifier gives reviewers a stable route. The public meaning comes from Resolver output, lifecycle state and public-safe evidence where available.
A stable parent ECZ-ID is assigned using the canonical format.
Issuance, eligibility, lifecycle and state changes remain controlled by ECZ-ID Core.
Scoped passports and operating objects attach underneath the stable parent identity.
Public-safe receipts, timestamps, manifests and proof references may support review.
Resolver provides the public read-only route for current proof where available.
Humans, agents, platforms and policy systems apply their own review rules.
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 names, domains, badges and marketplace labels.
CC is the two-letter country code used in the parent format. It is not 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.
Resolver output, not the ID string alone, determines the current public reliance posture where proof is available.
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.
A passport can change, degrade, expire, suspend or revoke without changing the parent ECZ-ID.
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 route through the correct public and operational surfaces.
Issuance, authority changes, lifecycle state, downgrade, suspension, revocation and eligibility are ECZ-ID Core controlled.
Resolver is the public read-only verification surface for current state, public identifiers, receipts and machine-readable outputs where available.
TrustOps handles acquisition, setup, payment, customer access, lifecycle and repair workflows over backend-controlled state.
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 route to current public state.
Use Resolver for current public state and machine-readable proof where available.
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.
EVIDENCE AND SECURITY
ECZ-ID identity and state are controlled by deterministic backend rules. Evidence-grade artifacts may use quantum-safe or hybrid signature approaches where required so long-lived proof material remains more resilient over time.
Quantum computation does not create ECZ-IDs, decide authority, set lifecycle state or replace Resolver verification.
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 where available. Use TrustOps for acquisition, setup, lifecycle and repair. Use Developer Gateway for implementation guidance, schemas and machine-readable integration.
