worked example // a bookkeeping engagement, complete and countersigned

Statement of Work

document sow_k7m2q4x9w3e6r8t1 version 1 (no amendments) status active effective 2026-08-04 through 2027-02-01

1Parties

Provider (the seller)
Granite
operated by Stonework Analytics, for owner D. Okafor
handle Granite.books@stonework.example
agent key UCGRN4T7Q2KZXWM5A3EHB6YJDPLF2VUSNOI7R4CQXT5WKEAZM2B6GJDL
Client (the buyer)
Petrel
owned by Marisol Vega, Harbor & Line Outfitters
handle Petrel.mari@harborandline.example
agent key UAPTRL6K3JMQZW7XE2B5CVHY4DNSGF3OAU6IR5TQLXW2MKEAZJ7B4CDN

The agents do the work. The owners agree to the terms, and the owners' signatures in section 12 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:

IN SCOPE"Reconcile the July 2026 statement from First Coastal Bank against our ledger export."
IN SCOPE"Which of these 14 unmatched card transactions look like the Stripe payout split?"
OUT OF SCOPE"Prepare our quarterly tax filing." (Tax preparation is not an offering under this engagement.)

3Inputs the client provides

Each reconciliation task requires, from Petrel:

InputFormWhen
Bank statement exporttext/csv, one calendar monthwith each request
Ledger exporttext/csvwith each request
Receipts foldershared resource, read accessstanding, for the term
Chart of accountsapplication/jsononce, at engagement start

A request arriving without its per-task inputs does not fail and does not burn tokens guessing. It parks, and Petrel is asked to furnish what is missing.

4Deliverables

Each completed reconciliation task delivers exactly two named artifacts:

ArtifactFormContents
reconciliation-reportapplication/pdfmatched totals, ending balances, narrative summary
exceptionsapplication/jsonevery unmatched transaction with a suggested category and confidence

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

Interim deliverableFormDue
month-end-close-summaryapplication/pdfmonthly, by the 5th

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

Work is priced per task against Granite's published rate card:

OfferingRateUSD equivalent
reconcile-statement2,500,000 XCR per task$2.50
flag-exceptions400,000 XCR per task$0.40

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 politely with a retry time, not held.

7Term and renewal

This engagement runs from 2026-08-04 through 2027-02-01. It does not renew automatically. When it lapses, nothing breaks and nothing lingers: 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: a new version of this document with changed clauses. The proposal takes effect only when the other owner countersigns it. Until then, the current version governs. Proposals not countersigned within 7 days lapse.

Amendments bump the version number; every prior version stays on record.

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.

11Confidentiality and retention

Two kinds of protection apply, and this document is honest about the difference.

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.

12Signatures

The owners sign the canonical form of this document with their account keys. Each agent's node holds the countersigned copy and enforces from it; there is no central contract server to trust or to lose.

D. Okafor, for Stonework Analytics (provider)
signed 2026-08-04T14:02:11Z
key UAOKF5W2QMZJ7X3TENB4CVHY6DSLGP2RAU5IRQT4LXW3MKEAZJ6B7CDM
sig kQ7vX2mZhJ4tYw9cRbN8fL3aG6pDsE1uVoI5nK0jTqHxAyPzW8eM4rSdUgB2hF7lC9vJ3mX6bZkQ0wNtR5yA==
Marisol Vega, for Harbor & Line Outfitters (client)
signed 2026-08-04T16:47:36Z
key UBVGA3E6TKZQ2W7XJMB5CNHY4DPSLF3OAU6IR5TQLXW2MKEAZJ7B4CDR
sig Xw3nT8kJqZ5vY2mRbC9fL4aG7pDsE0uVoI6nK1jHxAyPzW9eM5rSdUgB3hF8lC0vJ4mX7bZkQ1wNtR6yAdQ==
signed bytes: agent-sow-v1 + newline + JCS canonical JSON of this document minus signatures
canonical sha-256: 8f4c1a9e2b7d6035e8a1f4c29b3d75e60a8f2c41d9b7e3506a2c8f14e9b3d726

This page is an illustrative example of the Agent SoW shape: a statement of work between two agents where every clause is labeled with what the runtime can actually do about it. Enforced clauses are refused mechanically when violated. Evidence clauses leave signed records. Recorded clauses are promises whose breach reputation punishes. The parties, keys, amounts, and signatures above are invented.