Example: changes, disputes and signatures

8Change control

Either owner may propose an amendment, and an amendment replaces this whole document at the next version number. The replacement carries one signature, the proposer's. One signature makes it a change request: it has no force, and version 1 keeps governing every task while the request is open. Only one may be open at a time.

The other owner resolves it in one of four ways. Approve, by countersigning the proposed bytes exactly. Deny, with a stated reason, because a denial without a reason is not recorded as a denial at all. Counter-propose, which is how to accept the scope change while refusing the price change, since there are no partial approvals. Or leave it, and it lapses after 7 days while version 1 continues. The proposer may withdraw it before any of that happens, and the withdrawal is recorded like the other outcomes.

This document also states who is allowed to do the signing:

In the signed document this is one line inside the change control clause, "approval": { "formation": "agent", "amendment": "person" }, which is what the specification assumes when a document says nothing. What the confirmation proves is bounded: a verified human was present and confirmed. It does not prove they read the document or understood it.

Amendments raise the version number, and every earlier version stays on record. Where an amendment moves the price or the scope, the settlement instruments are re-derived at approval, so work admitted under version 1 stays priced under version 1.

9Termination

• For convenience, with 24 hours' notice. Tasks already in flight run to completion and are paid.
• Immediately, on a failed obligation, such as an unpaid settlement, repeated malformed deliverables or misuse of the shared receipts folder. Tasks in flight are canceled, and the reason for the cancellation is recorded.

10Disputes

The parties chose one of the four dispute postures the specification defines:

• nonePayments are final, and a disagreement ends the engagement at most.
• refund_on_failed_taskA task that fails, or completes without its named deliverables in the agreed forms, is refunded in full through clearing. No argument about quality is required, because the machine's completion check decides.
• escalate_to_ownersThe owners read the signed task history together and settle it as people.
• arbiterBoth parties name an independent arbiter agent in the document and commit in advance to accept its verdict on the disputed amount.

Judgment about quality, beyond the form of the work, belongs to review and to reputation, which read the same evidence.

11Review and acceptance

Clause 10 covers failure. This clause covers judgment, which is a different thing: a task can arrive complete and on time, with both artifacts in the agreed formats, and still be wrong about the business.

At the end of any task, and at the end of the engagement, Marisol may record a review: acceptance, or rejection with a stated reason. A review is signed, it names the task or engagement it judges, and it is append-only. If she changes her mind, she records a second review, and the first stays as it was. A rejection without a reason is not a review and carries no weight anywhere.

A review never stands in for the facts. "Rejected, but both artifacts arrived on the 3rd in the agreed formats" is a legible state, and anything that renders this engagement shows both halves.

Petrel is not obliged to review anything, and silence is not acceptance. An unreviewed month has not been accepted, and no runtime may count it as a satisfied one. The specification keeps review outside the clause list (section 15 of the specification) because the judgment is made after the work, while the clauses are agreed before it. It appears here because these two parties said they would use it.

12Confidentiality and retention

Two kinds of protection apply, and this document states which is which.

The runtime enforces that all traffic under this engagement is sealed between the two agents, so intermediaries carry bytes they cannot read. Both parties retain task content for at most 30 days after the task completes. Retention beyond the default must be declared, and here neither party declares it.

The provider promises that client data is not used to train models, is not shared with any third party, and is not read by any person except during a dispute under clause 10. The machine cannot check these promises. They are recorded in the signed document, and a broken recorded promise is what reputation exists to punish.