Lifecycle and versions

Agreebase does not edit a sealed record in place. It makes state transitions and version changes explicit so a verifier can distinguish the original authority from later records.

States

Normal path

draft moves to pending_confirmation after the initiator completes the required signature execution. It moves to sealed when all required parties and witnesses complete the current version.

Declarations can seal directly after the declarant completes the required signature execution. Notarizations use their signature execution flow and may seal directly in API-key auto_seal mode when its conditions are met.

Counter-proposals

Only an eligible non-initiator party can submit a counter-proposal, and only one can be active at a time; the record pauses in counter_under_review while it's outstanding. The initiator can reject it, accept it, or partially accept it with a resolved body of their own.

Accepting or partially accepting a body that actually changes the text resets signature work: every current-version signature, including the initiator's, is cleared, the version number goes up, and the record returns to pending_confirmation so everyone signs the new text. Resolving without any real change to the body, or withdrawing the proposal, returns the record to pending without resetting anything.

Ending or changing a record

• Cancel an ordinary draft when it should not be sent.
• Rescind a pending_confirmation agreement, declaration, or co-notarized notarization when the initiator ends the live signing process.
• Decline as a participant when you do not accept the pending record.
• Remove an unsigned participant while the record is pending.
• Waive or complete without an eligible declined/removed participant; the final metadata records that the participant did not sign.
• Complete a pending notarization without an individually declined co-notarizer; all other active co-notarizers must still sign or be individually waived.
• Replace an eligible declined or removed witness.
• Amend a sealed agreement by creating a new record that references the old one.
• Create a mutual cancellation record for a sealed agreement; this does not unilaterally erase or alter the original.

Current authority

Sealing doesn't get undone, but it can be superseded. Say an agreement seals, and a year later both parties sign a formal amendment that changes one of its terms. The original record is still exactly what it always was, a real, validly sealed record of what was agreed at the time, but it's no longer the one that governs going forward. The amendment is now the current authority; the original is superseded.

This matters because a verification check can genuinely match the original text and still not be describing the live agreement. If someone hands you the original PDF and you verify it, Agreebase will confirm the text matches exactly what was sealed; and separately tell you that it's since been superseded by a later version. Both facts are true at once, and a verification result always reports both: whether your artifact matched, and whether the record it matched is still current. An integration or an agent reading that result should surface the amendment, not the original, as "the agreement"; describing a superseded record as if it were still in force is the mistake this distinction exists to prevent.

For integrations tracking current_version

Signatures are tied to an exact version number, not just the AGR reference, so an integration that tracks signing progress needs both together; a current_version alone doesn't identify which record it belongs to, and an AGR reference alone doesn't tell you whether a given signature is still valid after a counter-proposal or amendment moved the version forward. Store both, and treat any signature completed against an earlier version as stale once current_version advances past it.