Governance

Governance Overview

ECZ-ID governance describes the public rules, authority boundaries and lifecycle principles that keep identity, authority, state, time and evidence independently resolvable. This page explains how that material is organised and what it can and cannot establish.

INFORMATIVE DRAFT Informative governance overview

Document ID
Not yet established
Classification
INFORMATIVE
Lifecycle status
DRAFT
Version
Not yet established
Published / revised
Not yet established
Effective date
Not yet established
Scope
The ECZ-ID public governance corpus published on ecocitizenz.org and the documentary authority model that applies to it.
Authority source
Not yet established
Approved by / authority record
Not yet established
Supersedes
None
Superseded by
None
Machine-readable counterpart
None published

The governance boundary Link to section: The governance boundary

Ecocitizenz.org publishes governance and specification documents. It does not issue ECZ-IDs, activate capability, process payment, change state or act as the verification surface.

Websites publish documentation. Backend state is canonical. Resolver verifies public proof. Each surface in the ECZ-ID estate has one job and a strict authority boundary, described in full on the Public Architecture page.

Where each kind of question is answered
QuestionAnswered byWhy there
What do ECZ-ID rules and specifications say?ecocitizenz.orgDocumentary publication for governance and specifications.
Is this ECZ-ID or Passport current right now?ResolverRead-only public projection of backend-controlled state.
How do I acquire, activate or manage one?TrustOpsAcquisition, payment, entitlement and lifecycle operations.
How do I implement or integrate?Developer GatewaySchemas, SDKs and implementation guidance.

The accountability chain Link to section: The accountability chain

Governance material on this site is organised around the ECZ-ID canonical accountability chain. Each stage is distinct; none can be inferred from another.

ECZ-ID canonical accountability chain, ten stages.
  1. IDENTITY
  2. AUTHORITY
  3. DELEGATION
  4. INTENT
  5. CURRENT STATE
  6. DECISION
  7. ACTION
  8. RECEIPT
  9. EVIDENCE
  10. RE-VERIFY

The semantics of each stage, and the equivalences that are explicitly rejected, are set out in Trust Principles and Public Architecture.

Governance documents Link to section: Governance documents

Governance documents and their current status
DocumentCoversClassificationLifecycle
Authority ModelIdentity, authority and delegation semantics; scoped and time-bound authority.InformativeDraft
Issuance PolicyHow an ECZ-ID or Passport state becomes available for public reference.InformativeDraft
Revocation PolicyRevocation, suspension, expiry and other states that end present reliance.InformativeDraft
Trust PrinciplesPublic trust principles and prohibited semantic equivalences.InformativeDraft
System RationaleWhy resolver-first reciprocal trust infrastructure exists.Informative—

Documentary authority Link to section: Documentary authority

Publishing a document on ecocitizenz.org does not, by itself, make it normative or current. A document can carry NORMATIVE classification or CURRENT lifecycle status only when it identifies a designated ECZ-ID documentary authority and an approval or publication record.

No such authority record has yet been published for the governance corpus. Every governance and specification document on this site is therefore presented as Informative and, where it is a controlled document, as a Draft. Its metadata shows fields such as document ID, version and approving authority as “Not yet established” rather than inventing values.

Classifications
Normative (mandatory requirements under an identified authority); Informative (explanation, no requirement); Advisory (recommended practice); Historical (retained context, no longer current).
Lifecycle states
Draft; Proposed; Current; Superseded (replaced by a named successor and kept for history); Withdrawn.
Normative vocabulary
In a properly authorised normative document, MUST and SHALL state mandatory requirements, SHOULD states a recommendation that admits exceptions, and MAY states a permission. These words are never used for emphasis.

How versions and supersession will be recorded is described on the Version History page.

What ECZ-ID provides and does not provide Link to section: What ECZ-ID provides and does not provide

ECZ-ID provides

  • A stable, non-semantic ECZ-ID that can be cited across contracts, platforms, systems and official processes.
  • A parent-and-Passport model for structured state about businesses, machines, products and operating surfaces.
  • A time-bound record of authority and state transitions such as issuance, activation, suspension and revocation.
  • Machine-readable public surfaces for resolution and integration.
  • Receipt references that record ECZ-ID system events, so that history can be reconstructed where the underlying records support it.

ECZ-ID does not

  • Rank, score, endorse or certify business quality.
  • Provide opinions, recommendations or reputational ratings.
  • Replace regulators, auditors, insurers, courts or institutional decision-makers.
  • Guarantee outcomes, performance, safety, compliance or commercial suitability.
  • Publish pricing, promotions or commercial offers on this site.

Four questions governance keeps answerable Link to section: Four questions governance keeps answerable

Economic, regulatory and machine-operated systems repeatedly depend on four questions being answerable at the moment of reference.

Who is the entity?
The subject being relied on remains identifiable across systems, contracts, platforms and time.
Who held authority?
Authority is scoped, time-bound, attributable and reconstructable later.
What state existed?
State is distinguishable at the relevant moment, not inferred from stale pages or documents.
Was reliance justified?
Relying parties check current public output in Resolver rather than reconstruct a narrative afterwards.

Where to go next Link to section: Where to go next

Verify — Resolver

Why leave this site
This page explains rules. It cannot show whether a particular ECZ-ID, Passport or binding is current.
Where you go
Resolver (resolver.ecocitizenz.org)
Authority there
Current public proof: a read-only projection of backend-controlled state.
What happens next
Open the ECZ-ID or Passport record and re-check its current public status before you rely on it.

Implement — Developer Gateway

Why leave this site
You need schemas, SDKs, route indexes or integration patterns rather than governance text.
Where you go
Developer Gateway (developers.ecocitizenz.com)
Authority there
Implementation, interoperability, SDK and schema guidance. It is not live proof.
What happens next
Use the implementation guides and reference material. Live proof still comes from Resolver.

Acquire, activate, manage or pay — TrustOps

Why leave this site
You want to acquire, activate, manage or pay for an ECZ-ID or Passport.
Where you go
TrustOps (trustops.ecocitizenz.com)
Authority there
Acquisition, payment, entitlement, activation and lifecycle operations.
What happens next
Start or manage the operational acquisition and lifecycle flow. Payment or activation is not itself proof.

Revision history Link to section: Revision history

Controlled revisions of Governance Overview
DateVersionStatusChange summary
No controlled revision of this document has been published. Earlier versions of this page on the Shopify-hosted site were not issued under a documentary authority record, so no history is backfilled.

Recommended citation Link to section: Recommended citation

EcoCitizenz Ltd, Governance Overview, DRAFT, https://www.ecocitizenz.org/pages/governance-overview.

Fields that do not yet exist for this document, such as a document ID or version, are omitted rather than invented.