Your identity should travel with the entity.

• The share page

  The human record on the public Resolver: the page a person lands on when they follow the identifier. Free to read, with no account and no key.

  https://resolver.ecocitizenz.org/p/{ecz_id}

  Open EcoCitizenz Ltd's record↗(opens in a new tab — resolver.ecocitizenz.org)

• The machine record

  The same record as JSON, for policy engines, gateways and agents. Public reads are never metered and never authenticated.

  https://api.ecocitizenz.com/api/p/{ecz_id}.json

  Open the same record as JSON↗(opens in a new tab — api.ecocitizenz.com)

• A badge plate, drawn by Core

  Core renders the Business Passport plate for an organisation from the record's current state, and the plate links back to the Resolver. A site never draws badge artwork or badge states itself — the plate at the foot of this page is this address, loaded live.

  https://api.ecocitizenz.com/api/badge/{operator_ecz_id}/BP.svg

• A QR code and a share link

  Included with every free Passport, alongside the badge, and reached from your ECZ-ID console. A QR code is what carries an identity onto a label, a carton, a rack card or a slide.

• Bindings on the record itself

  The record can name the public places where your service or workload already appears, and basic bindings are included with every free Passport. Where a live proof method reaches a place and you complete it, the record shows that binding as verified, with when it was last verified. That is the record pointing outwards; everything in the next group is the artefact pointing back.

Nothing on the estate crawls these artefacts. A reference pattern is for the person or the system that finds your artefact, and the Resolver record stays the only authority on what is true. Where a pattern is also a live proof method, ECZ-ID reads only the artefact you named, and only when you complete a binding's proof; the Resolver shows when that binding was last verified, and a fresh proof is a new binding.

• A documentation page

  One line in the documentation that already describes it — a docs site, a product page or the front page of its repository — linking the identifier to the record anyone can re-check.

  Illustrative

  [ECZ-ID {ecz_id}](https://resolver.ecocitizenz.org/p/{ecz_id})

  Markdown for your own documentation. A text link, not a rendered badge: the plate above is drawn for an organisation, not for this identifier.

• A file under /.well-known/ on a domain you control

  A static file declaring the identifier, on a domain you control. No library, no dependency, and nothing new in the execution path. This is also a live proof method. ECZ-ID reads it only when you complete a binding's proof, and the Resolver shows when that binding was last verified; a bound binding is not renewed, so a fresh proof is a new binding. Your ECZ-ID console gives you the exact value to publish.

• A field in the descriptor it already publishes

  Whatever your service or workload already hands out to the systems around it can carry the identifier as one more field. Your artefact, your field name. No live proof method reads a field like this, so nothing on the estate reads it, and adding it changes no behaviour.

• A deployment or release annotation

  A label, an annotation or a release tag on what you already ship, so the identifier travels with the artefact into whatever runs it.

• A procurement or inventory record

  A supplier questionnaire, an asset register or an inventory row. The identifier gives a reviewer somewhere to look, instead of a name to take on faith.

Illustrative. These are shapes to copy into your own files with your own identifier — not artefacts we host, publish, check or keep in step with you.

Planned connectors are listed as Planned only; none verifies a binding today. Each is a place no live proof method reaches yet, recorded as a declared binding, and no date is published for any of them.