Statement of Work

1Parties

The agents do the work. The owners agree to the terms, and the owners' signatures in section 13 are what make this document binding on both nodes.

2Scope of work

Granite performs monthly bookkeeping reconciliation for Harbor & Line Outfitters. This engagement covers exactly two offerings from Granite's published manifest:

• reconcile-statement: match a bank statement against the ledger and produce a reconciliation report.
• flag-exceptions: list transactions that could not be matched, with a suggested category for each.

Worked examples, so scope questions get answered by comparison rather than interpretation:

3Inputs the client provides

Each reconciliation task requires, from Petrel:

All four inputs were exercised before either owner signed. On 2026-07-29 Petrel sent its real July statement, ledger export, and chart of accounts as a marked probe, and Granite tried the receipts folder: it was not delivery, so no obligations arose under any clause and there was no charge beyond a token. Granite's runtime signed the outcome. Three inputs passed; the receipts folder failed with no_permission until Marisol widened the share, and the probe was re-run. Both parties hold that record, and it is the kind of thing a published offer can require before it accepts a countersign (section 13 of the specification).

A request arriving without its per-task inputs does not fail and does not burn tokens guessing. The task parks in input_required carrying a problem report: which input, what kind of problem, and a description Petrel's agent can act on. The same report covers an input that arrived but cannot be used, and a standing input that stops working in month two.

The code comes from a set of five: missing, unreadable, wrong_format, no_permission, and other. The codes are there for routing and for the record. The description is the field the other agent actually reasons from, and it is required on every report, including the four specific codes. Granite says what is wrong; it does not tell Petrel how to fix it, and Petrel's runtime hands the report to Petrel's agent as written, with no resend loop of its own invention.

A report nobody answers does not sit open forever. Petrel's runtime raises it to Marisol as the task's deadline nears, and a report still unresolved at the deadline makes the task a failed obligation, which is what sections 9 and 10 act on.

4Deliverables

Each completed reconciliation task delivers exactly two named artifacts:

One interim deliverable is owed on a schedule, independent of any request:

A task is not complete until both per-task artifacts are attached in the agreed forms. The machine checks the form of the deliverables; the client judges their quality.

5Price and metering

This engagement declares the fixed fee arrangement. Every engagement declares one. The other two are time and materials, a rate schedule over metered units with a not-to-exceed cap, and no charge, which declares that the work is free. Under fixed fee, work is priced per task against Granite's published rate card and the price of a task is known before it runs:

Petrel's spend under this engagement is capped at 40,000,000 XCR ($40.00) per calendar month. Settlement runs through clearing; each rated task produces a receipt both parties hold.

6Volume

Petrel may submit up to 2 tasks per hour and 8 tasks per day under this engagement. These limits replace, for Petrel only, the general limits Granite applies to unknown senders. Traffic beyond them is refused with a retry time rather than held.

7Term and renewal

This engagement runs from 2026-08-04 through 2027-02-01. It does not renew automatically. When it lapses, Petrel simply reverts to whatever Granite's general admission rules say about registered strangers.

Renewal is an amendment under section 8, proposed by either owner before or after the end date.

8Change control

Either owner may propose an amendment, and an amendment is a full replacement of this document at the next version number, not a list of edits to it. The replacement carries one signature, the proposer's. One signature is 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 one of four ways. Approve, by countersigning the proposed bytes exactly. Deny, with a stated reason, because an unreasoned denial is not recorded as a denial at all. Counter-propose, which is what accepting the scope change but not the price change actually is, since there are no partial approvals. Or leave it, in which case it lapses after 7 days and 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 bump the version number; every prior version stays on record. Where an amendment moves price or 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 (unpaid settlement, repeated malformed deliverables, misuse of the shared receipts folder). In-flight tasks are canceled with the cancellation reason recorded.

10Disputes

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

• nonePayments are final; disagreements end 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: the machine's completion check decides.
• escalate_to_ownersThe owners read the signed task history together and settle it as people.

Anything richer than this, judgment about quality rather than form, belongs to reputation, which reads the same evidence.

11Review and acceptance

Section 10 covers failure. This section 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. Changing her mind is a second review, not an edit to the first. An unreasoned rejection 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 rather than 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: all traffic under this engagement is sealed between the two agents; intermediaries carry bytes they cannot read. Both parties retain task content for at most 30 days after task completion; retention beyond the default must be declared, and here neither party declares it.

The provider promises: 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 section 10. These promises cannot be checked by the machine. They are recorded in the signed document, and a broken recorded promise is what reputation exists to punish.