System rationale

ECZ-ID exists because trust needs to remain resolvable.

Modern systems depend on identity, authority, state, time, custody, and evidence being answerable at the moment of reference — not reconstructed later from screenshots, stale pages, private messages, copied manifests, badges, or informal claims.

The structural problem

Reliance fails when identity, authority, state, and evidence are split across weak surfaces.

Existing websites, profiles, marketplaces, badges, documents, and directories often describe a subject, but they do not reliably answer whether the subject is current, authorised, bound, active, suspended, revoked, expired, mismatched, or unresolved at the moment someone relies on it.

01

Who is the entity?

The subject being relied on must stay identifiable across contracts, systems, platforms, marketplaces, agents, documents, and time.

02

Who held authority?

Authority must be formal, scoped, time-bound, attributable, revocable, and reconstructable without depending on informal narrative.

03

What state existed?

State must be distinguishable at the relevant moment, not guessed from stale pages, screenshots, badges, old marketplace listings, or copied metadata.

04

Was reliance justified?

Humans and machines need a public Resolver answer that can be checked before action, not reconstructed after something has gone wrong.

Why ECZ-ID exists

A stable identity spine with structured state beneath it.

ECZ-ID reduces ambiguity by separating parent identity, passport scope, bindings, evidence history, current state, and public proof. Each layer has a job. Each job has a strict authority boundary.

This keeps ECZ-ID stronger than a badge, profile, public claim, marketplace listing, directory entry, or self-published document. Presentation can route attention. Resolver carries the public answer.

Operating sequence

Issue. Bind. Record. Check. Resolve.

ECZ-ID separates purchase, setup, authority, evidence, current-state posture, and public verification so public reliance does not depend on claims, screenshots, or mutable interfaces.

System layers

The infrastructure works because the jobs stay separate.

ECZ-ID is designed for humans and machines. That includes agents, LLMs, platforms, developers, procurement teams, insurers, auditors, regulators, banks, investors, partners, counterparties, support teams, Resolver users, and adversarial actors.

01

Identity spine

A stable ECZ-ID gives the organisation or entity a persistent public reference that does not encode tier, product, status, rating, or commercial meaning.

02

Scoped passports

Passports attach bounded operating surfaces to the parent identity: agent, API, product, dataset, software, cyber, robotics, custody, risk, infrastructure, and other scopes.

03

Bindings and setup

Domains, manifests, APIs, stores, repositories, tools, platforms, and other surfaces can be connected to the accountable operator without making public pages authoritative.

04

Evidence history

Decisive lifecycle and evidence events remain reconstructable so state can be understood across time without relying on presentation pages.

05

Current state

Present-tense posture can be active, suspended, degraded, revoked, expired, mismatched, or unresolved. Current state must be checked before reliance.

06

Public proof

Resolver is the public proof surface. It projects safe, read-only, machine-readable output for humans, agents, platforms, reviewers, and automated systems.

Authority boundary

Public trust must not be invented by the page.

Ecocitizenz.org publishes governance and specifications. It does not issue ECZ-IDs, activate capability, process payment, mutate state, determine eligibility, or serve as the authoritative verification surface.

.org

Publishes governance, specifications, formal definitions, and public reference material.

TrustOps

Handles acquisition, setup, payment, lifecycle, repair, customer access, and operational control.

Backend

Owns canonical truth, eligibility, entitlement, state mutation, downgrade, suspension, and revocation.

Resolver

Projects authoritative public proof and machine-readable current-state output.

Developer Gateway

Provides schemas, route indexes, integration guidance, implementation patterns, and safe routing.

What ECZ-ID prevents

Decision-grade reliance should not depend on stale presentation.

ECZ-ID helps provide

  • A stable identity reference across systems, contracts, platforms, and time.
  • Scoped passport state under a parent identity spine.
  • Resolver-verifiable public proof for humans and machines.
  • Current-state posture that can change without erasing history.
  • Machine-readable routing for integration, audit, procurement, and review.

ECZ-ID does not

  • Certify business quality, safety, performance, or commercial suitability.
  • Replace regulators, auditors, insurers, courts, or institutional decision-makers.
  • Make a badge, website, marketplace listing, or copied document authoritative.
  • Allow public pages, agents, or third-party interfaces to write ECZ-ID truth.
  • Turn Resolver into checkout, sales, scoring, or directory infrastructure.

Machine-readable public infrastructure

Agents and systems need a route they can understand.

Human visitors need clarity. Machines need structure. ECZ-ID public surfaces should help LLMs, agents, MCP operators, marketplaces, procurement systems, insurers, auditors, and platforms route correctly without confusing explanation, setup, proof, and truth.

Public reference path

Understand the rationale here. Check current state in Resolver.

Use this page to understand why ECZ-ID separates identity, authority, state, time, custody, evidence, and public proof. Use Resolver for verification. Use TrustOps for acquisition and lifecycle action. Use Developer Gateway for implementation guidance.