ECZ-ID Agent Passport Operations, Lifecycle and Troubleshooting Guide

• Control plane

  Dashboard - authenticated customer actions

• Proof plane

  Resolver - public read-only re-check

• Find the canonical Agent Passport in Dashboard.
• Confirm the intended organisation / Parent context where supported.
• Review current published state.
• Review the bindings relevant to the agent now.
• Review evidence and freshness where operationally important.
• Open Resolver and confirm the public proof matches the intended context.
• If a required authority/delegation context matters for an action, inspect it separately.

• Good starting evidence

  Correct ECZ-ID, expected Parent/organisation relationship, current state and relevant binding.

• Escalate when

  The record is missing, stale, duplicated, unexpectedly related or shows a state/binding that does not match the intended object.

• DASHBOARD

  Authenticated customer experience for permitted estate actions. Use it to find the Passport, inspect available lifecycle controls, manage supported context and access operational views permitted to your role.

• RESOLVER

  Public, read-only proof surface. Use it to confirm the bounded public record after changes and to let counterparties independently re-check identity/context.

• Public

  ECZ-ID, Passport family/object, published relationship/state/bindings/evidence according to the record.

• Private

  Account controls, internal recovery, secrets and customer-private data that are not intended for public proof.

• Binding change

  Update the supported endpoint, manifest, MCP/API surface, repository/package reference or other binding while retaining the same Agent ECZ-ID where appropriate.

• Evidence update

  Refresh or add supported evidence when old evidence is stale, out of scope or a stronger source becomes available.

• Responsibility change

  Use the supported control path for legitimate organisation / Parent context change, then re-check Resolver proof.

• Authority / delegation change

  Treat action-specific authority as mutable context. Re-evaluate it independently of persistent identity.

• CURRENT / ACTIVE WHERE PUBLISHED

  Operate according to current published state and applicable policy. Re-check before higher-consequence actions when freshness matters.

• SUSPENSION / REVOCATION / DEGRADATION WHERE SUPPORTED

  Treat these as signals requiring re-check and potentially challenge or denial according to policy.

• RETIREMENT / END OF USE

  Preserve the integrity of the historical identity/evidence context according to supported lifecycle behaviour rather than repurposing the identity.

• REACTIVATION / CHANGE

  Re-evaluate state, bindings and evidence before relying on a previously inactive or materially changed Agent Passport.

• Before creating

  Search for and reuse the relevant account, Parent and Agent Passport where supported.

• During migration

  Keep the same Agent ECZ-ID for the same logical object and update provider-native bindings/evidence.

• If a duplicate appears

  Treat it as an identity-governance/support issue. Do not silently operate both records as if they were equivalent.

• If a binding is wrong

  Correct/escalate the binding; do not mint a new Agent ECZ-ID merely to escape an incorrect association.

• LOWER CONSEQUENCE

  Use the freshness policy appropriate to your application and evidence needs.

• CHANGING CONTEXT

  Re-resolve when endpoint, operator, state, evidence or authority may have changed.

• HIGHER CONSEQUENCE

  Re-check immediately before consequence when policy requires current proof.

• SIGN-IN / RECOVERY

  Use the supported account recovery or sign-in method. Preserve the existing organisation / Parent and Passport relationships whenever the intended identity already exists.

• AFTER RECOVERY

  Confirm Dashboard shows the intended estate, then re-check Resolver proof for the affected Agent ECZ-ID before resuming consequential operations.

• Support context to include

  Failed step, occurrence time, visible error, ECZ-ID or Passport ID if available, and appropriate AWS/account context. Do not send passwords, API keys, registration tokens, certificates or other secrets.

• Passport not found

  Confirm ECZ-ID and acquisition/issuance status; distinguish not-found from access or copied-ID error.

• Stale data

  Re-resolve; update supported binding/evidence if the underlying context legitimately changed.

• Incorrect binding

  Correct/escalate the binding rather than minting a second identity.

• Missing evidence

  Treat it as absent and obtain/publish appropriate supported evidence.

• Unexpected responsibility

  Challenge the record/use and investigate the Parent/organisation context.

• Authority mismatch

  Evaluate action-specific authority separately; identity alone does not override the mismatch.

• INCLUDE

  • ECZ-ID / Passport ID if available
  • Failed stage or operational action
  • Visible error
  • Occurrence time
  • Relevant AWS/account context where appropriate
  • What changed immediately before the issue

• NEVER INCLUDE

  • Passwords
  • API keys
  • AWS Marketplace registration tokens
  • Private keys/certificates
  • Unrelated customer-private data
  • Secrets copied from runtime logs

• Escalation principle

  Preserve the canonical identity first. If the issue is a state, binding, evidence, access or acquisition problem, fix that problem rather than creating a parallel identity record.

• Find the canonical Agent Passport.
• Confirm expected Parent / organisation context.
• Read current published state.
• Inspect current bindings.
• Review evidence and freshness.
• Evaluate authority/delegation separately if the action requires it.
• Re-resolve in Resolver.
• Challenge or escalate anomalies; do not mint duplicates.
• Use supported account recovery for access problems.
• Send support context - never secrets.

MACHINE-READABLE RESOLVER

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