# Agent Transaction Passport™ Governance — Draft v0.1

## Mission

Agent Transaction Passport™ (ATP) is intended to become a neutral, portable transaction-record format for autonomous economic actors.

The specification should remain independent of any single payment rail, agent protocol, cloud provider, model vendor, blockchain, identity system, or jurisdiction.

## Roles

**Publisher:** AgentProof publishes canonical ATP specifications and schemas.

**Implementers:** Any organization or developer may implement the public specification.

**Contributors:** Public feedback and proposed extensions may be evaluated for inclusion in future versions.

**Verifiers:** Any party may independently validate conformance to the published schema and integrity rules.

## Compatibility

An implementation may describe itself as "ATP-compatible" when it produces or consumes records conforming to a published ATP specification.

Compatibility does not imply endorsement, certification, partnership, or security review by AgentProof.

## Extension rules

- New fields should be namespaced when they are not part of the base specification.
- Existing required fields must not change meaning within a major version.
- Breaking semantic or structural changes require a new major version.
- Payment-specific, identity-specific, and jurisdiction-specific extensions should remain modular.

## Neutrality principles

ATP should not require:
- one payment provider;
- one blockchain;
- one model vendor;
- one wallet;
- one identity system;
- one agent protocol;
- or one cloud.

## Trademark boundary

The technical format is intended for broad implementation. The source-identifying name **Agent Transaction Passport™** remains a claimed trademark associated with the AgentProof-published standard.

Implementers may make truthful compatibility references but may not imply official AgentProof certification unless expressly authorized.

## Change process

Draft versions may evolve quickly. Stable major versions should prioritize backward compatibility and migration guidance. Proposed changes should include:
1. problem statement;
2. interoperability impact;
3. privacy/security impact;
4. migration impact;
5. example payloads;
6. validation changes.

## Long-term direction

Future work may cover delegated authority, verifiable credentials, multi-party transactions, dispute events, revocation, selective disclosure, zero-knowledge proofs, cross-border compliance metadata, insurance attestations, and machine reputation signals.