Governance and specifications are published here. Authoritative public verification happens in Resolver.
Resolver surface ↗
ECZ-ID
Governance & specifications
ECZ-ID public infrastructure
Governance is published here. Verification happens in Resolver.Authority Model
ECZ-ID authority does not arise from reputation, branding, visibility, consensus, interface behaviour, market expectation, or informal assertion. Authority exists only where recognised through canonical backend pathways and projected for public checking through Resolver.
The authority rule
A claim, page, badge, directory entry, agent profile, marketplace listing, interface label, or copied manifest is not authority. Authority must be formally scoped, valid at the relevant moment, backend-owned in effect, and capable of being checked through Resolver.
Authority Boundary
ECZ-ID becomes institutionally useful because public pages, operating surfaces, proof surfaces, developer documentation, and backend truth do not collapse into one another.
Public specification surface
This site publishes governance, specifications, formal public definitions, and reference material. It does not issue ECZ-IDs, activate capability, mutate state, process payment, or verify live public proof.
Operational control surface
TrustOps handles acquisition, setup, activation, lifecycle control, payment, and customer operational action over backend truth. It is not an independent truth source.
Authority plane
Issuance, eligibility, authority change, lifecycle mutation, downgrade, suspension, and revocation are controlled through deterministic backend-owned authority pathways.
Public verification surface
Resolver is the public read-only verification surface. Humans, agents, platforms, auditors, insurers, and automated systems should check Resolver for current public state before reliance.
Implementation guidance surface
Developer Gateway supports schemas, route indexes, manifests, verifier guidance, and implementation patterns. It helps systems integrate safely, but it is not itself public proof.
Authority Principles
The authority model governs whether canonical state may be created, changed, constrained, suspended, revoked, or projected. It underpins issuance policy, revocation policy, lifecycle state, Resolver output, and machine-readable public verification.
Formal
Time-bound
Scope-limited
Revocable
Authority Hierarchy
Root authority defines system parameters, authority conditions, and top-level issuance constraints. Delegated authority nodes may act only within defined permissions, time bounds, and state-control functions. Delegation never expands beyond the rights formally granted.
Defines top-level authority conditions, system parameters, issuance constraints, and canonical control rules.
May act only within granted functions, defined scope, relevant time bounds, and applicable lifecycle constraints.
Valid changes are reflected through backend-owned state and projected through Resolver for public checking.
Authority Constraints
Authority must remain reconstructable, attributable, bounded, and machine-checkable. These constraints protect ECZ-ID from copied trust, interface drift, marketplace overreach, and non-canonical authority claims.
An authority node may not act outside the rights formally granted to it.
An authority node may not modify its own assignment retroactively.
Credentials, assertions, screenshots, badges, directories, or copied manifests outside Resolver authority are non-canonical for ECZ-ID reliance.
Ecocitizenz.org publishes governance and specifications. It does not issue identifiers, mutate state, activate capability, or revoke proof.
An agent, tool, MCP server, API, bot, or automated workflow cannot become authoritative by declaring itself trusted.
Marketplace presence can support discovery, but it does not create ECZ-ID validity. Public reliance should defer to Resolver output.
Machines, Agents, Platforms, and Reviewers
Agents, MCP servers, platforms, procurement tools, insurers, auditors, reviewers, and integration systems should treat Resolver as the public proof surface. Developer Gateway can support schemas, route indexes, manifests, verifier guidance, and implementation patterns, but it is not public proof.
Re-check Resolver before relying on an ECZ-ID, passport, tool, provider, API, credential, MCP server, package, or proof surface.
Use current Resolver state as an input to your own review, routing, gating, hold, escalation, or fail-closed policy.
Use Developer Gateway for schemas, route indexes, manifests, verifier guidance, and safe implementation patterns.
Canonical Effect
Authoritative issuance, revocation, delegation, lifecycle mutation, downgrade, suspension, expiry, and public proof projection must remain inside canonical pathways. Backend truth decides. Ledger-linked records support reconstruction where relevant. Resolver projects the public answer that relying parties should check.
Read Together
Public Reference Path
Ecocitizenz.org publishes the authority model. TrustOps handles acquisition, activation, lifecycle, and payment. Backend truth controls authoritative state. Resolver verifies public proof. Developer Gateway supports implementation, schemas, route indexes, and machine-readable guidance.
Quick routes
Use this utility dock to move quickly between governance, verification, operational, and implementation surfaces.
For humans, agents, and machine-routed visitors. Use the correct surface for the correct job.