The agreement anchors the lifecycle
Before a verifier can judge work or a rail can settle payment, the system needs a stable description of what was promised. The Accord Agreement Object provides that anchor.
It can be canonicalized and hashed so payment proof, receipts and registry entries refer to the same terms.
What it should contain
A useful agreement describes the buyer, seller, task, price, asset, deadline, verification rules, rail assumptions and acceptance criteria. Implementations may add references to outputs, policies or metadata, but the core purpose remains the same: make the work terms inspectable.
Ambiguous agreements produce ambiguous verification. Clear agreements reduce downstream disputes.
Why canonicalization matters
Agents need deterministic references. If two systems serialize the same terms differently, hashes and signatures can drift. Accord's canonical JSON and hashing rules are designed to make agreement references stable.
That stability is what lets receipts and settlement records bind back to the original promise.
FAQ
Is the Agreement Object the same as a payment request?
No. It describes work terms; payment authority or proof is part of the broader lifecycle.
Why hash the agreement?
Hashing gives receipts and rails a stable reference to the same canonical terms.
Open the Agreement schema
Use the schema as the source of truth for implementation shape.