What you hand over when the automation is finished.

What it does, in one sentence they would use

Not the workflow name. The outcome the client is buying, written the way they would describe it to their own colleague — because that sentence is what they will judge it against a year from now.

What it can reach, and what it can never touch

Every system it reads, every system it writes to, and the actions it must never take on its own. Stated as can, cannot and needs approval, so there is nothing to interpret.

What it does not handle

The cases it was never built for, written down by you before anybody hits one. A limitation a client reads in advance is a scope boundary. The same limitation discovered in production is a complaint.

Who owns the accounts and the credentials

Whose API keys these are, whose account the model is billed to, and what happens to each if you and the client stop working together. This is the question that turns into a dispute, and it is almost never written down.

What happens when it breaks

Who to contact, what counts as broken, and what the client should do in the meantime. A named route to a person beats a promise about response times you cannot keep.

What is covered, and what is a new job

The line between fixing what you built and building something new. Agree it before the first change request, because the first change request is when both of you find out you disagreed.

How the work is counted

What one run is, what it costs, and where the number comes from. A client who cannot see the count has no way to sanity-check an invoice, and you have no way to defend one.

The capability statement, versioned

A System Passport — one page stating what the system can do, cannot do, and needs approval for. You write it. Every version is kept, with the fields each correction changed and who changed it. Your client does not see the passport itself: what it may touch and what it will not do are in the proposal they open.

What they agreed, frozen

The scope and the figures, the price per extra run included, are fixed when your client first opens the proposal link, and what they accept is exactly that, recorded with who agreed and when. Changing your price afterwards changes what you offer next, never terms a client has already opened.

The run record

Every production run on a client’s installation is counted once, against that client. Runs you start from Tolavo are recorded there as tests and not counted as the client’s usage, unless you mark work sent through the API as production. A retried request is the same run only when it repeats its Idempotency-Key. Runs above the included number are priced at the rate the client accepted; usage with no accepted agreement is priced from the plan’s terms. A later price change does not reprice an accepted agreement.

A trail that cannot be quietly edited

Each entry seals the one before it. Alter a record and the chain breaks, and the screen says so rather than printing “verified” over an empty trail.

Everything, as one file

Your whole workspace exports on request — records, subscriptions, run history — with credential columns dropped and named, and secret-shaped values removed and counted before a byte is written. One thing is kept byte for byte: the agreement text a buyer opened or accepted, because its fingerprint is their proof. A secret somebody typed into that text stays in it, and the file names each one and says how many there are.