Agency and consultancy deliveries: handing clients an evidence report with every release — proof of process as part of the product

Last reviewed 2026-08-21 · 8 min read

Agencies and consultancies are asked by clients how the software they deliver was built — increasingly, how much an AI agent wrote and who reviewed it. A recorded development chain lets you hand over an evidence report with every release: authorship, review, tests, components. It proves the process; contract terms and acceptance remain between you and the client.

What it is

Agencies, consultancies and system integrators build software for other people — and increasingly build it with AI coding agents. Their clients notice. Procurement asks how much of the delivery an agent wrote; security teams ask who reviewed it; legal asks who owns it and whether the licences are clean; and, if the client places the software on the market, the client inherits the Product Liability Directive’s disclosure risk and the Cyber Resilience Act’s documentation duties for something they did not write.

The agency that answers those questions with a document written for the occasion is at a disadvantage against the agency that answers with a record. Proof of process as part of the product is the idea: every release handed to the client comes with an evidence report — who or what authored each change, what human review approved it, what tests ran, what components and licences it contains — generated from a record the client can verify independently. The code is the deliverable; the report is the reason the client can trust it, defend it and audit it.

It is also a commercial differentiator that costs little to produce if the process already leaves the evidence as a by-product, and a great deal to assemble by hand if it does not.

Who it applies to and when

Software agencies and consultancies, system integrators, freelancers delivering code under contract, and the clients who receive it — especially regulated clients and those placing the delivered software on the market under their own name. The need appears at three moments: when a tender or vendor assessment asks about development practices (before the engagement), at each release or sprint hand-over (during), and at the end of the engagement, when the client takes over the codebase and its obligations.

No statute sets a date, but the client’s obligations do: from 9 December 2026 the Product Liability Directive makes software a product under strict liability for whoever places it on the market — often the client — with development records subject to disclosure; the CRA’s documentation duties apply fully from 11 December 2027, with reporting clocks from 11 September 2026. A client who knows that will write evidence requirements into the next statement of work.

This topic is not part of our regulatory mapping — it is a delivery and contracting use of development evidence. The support section below uses the mapping’s vocabulary and marks where evidence stops and contract begins.

What it asks of your development process

What a client-grade evidence report needs from the agency’s process is the same short list every other use case on this site comes back to — with a delivery twist:

Authorship per change, human or agent. Clients ask “how much of this did an AI write?” — and whether you choose to disclose the number or not, you want it to be accurate. That requires recording agent authorship (tool, model, session) at the source; git alone shows the developer whose session the agent ran in.
Review linkage. For agent-authored changes especially: which person approved the change before it went into a release. This is the “quality-assured” half of every client question.
Tests per change and per release. Not “we have CI” but evidence that tests ran against the changes in this release.
Release scope with components and licences. Each hand-over is a release; its SBOM and licence snapshot are what the client’s legal and security teams will ask for, and what protects both sides from a licence surprise later.
Portability. At the end of the engagement, the evidence has to travel with the code — exportable in a form the client can keep and verify without the agency’s tools.

The delivery twist is that the report is read by people who did not watch the work: the client’s engineers, auditors, insurers, sometimes their customers. Its value is therefore in its verifiability. A PDF the agency wrote is a statement; an export the client’s own team can verify against the open-source verifier is evidence. Agencies that understand that difference sell it.

There is also a commercial argument that is easy to miss. Agencies compete on trust as much as on rate, and the trust question has changed shape: clients no longer ask only “can you build it” but “can you show me how you built it, and what a machine did”. A proposal that promises an evidence report with every release — and can show one from a previous engagement, verified — answers a question the client did not yet know how to ask. Over time the report becomes part of the agency’s product: the code, the documentation, and the record of how the two came to be. Agencies that already run disciplined reviews and CI pay almost nothing for it; the recorder observes what they do. Agencies that do not will discover, in the report, exactly where their process leaks — which is useful before a client discovers it for them.

What OLOBOLO evidence supports

OLOBOLO records each change with its author (human or agent, with tool and model), the review that approved it, the test evidence and the sealed release with SBOM and licence snapshot — append-only, time-anchored, and exportable as a canonical file the client verifies with the open-source verifier. Release evidence reports summarise AI share, review coverage and test evidence per release. The table uses our mapping vocabulary; this is not a regulatory mapping — acceptance, warranties and IP terms live in your contract.

Client question	What you need to show	Chain evidence	Support
How was this release built — who or what wrote it, who reviewed it, what was tested?	Per-change authorship, review and test linkage, summarised per release	`change.authored` / `change.reviewed` / `test.evidenced` → `release.sealed`; release evidence report	Supports
What share of the delivery is AI-authored?	A measured figure with method	AI-share figure per release from actor-typed `change.authored`	Supports
What components and licences are in it?	SBOM and licence snapshot per release	Sealed release with SBOM + licence snapshot	Supports
Can we keep and verify the evidence after the engagement?	Portable, independently verifiable record	Canonical export (free, always available) + open-source verifier; RFC 3161 anchors	Supports
Acceptance criteria, warranties, IP assignment, SLAs, fees	Contract terms	—	Out of scope

The caveat, again: the record covers what was recorded — repositories and events inside the engagement’s recording scope. Put the scope in the statement of work so both sides know what the report will and will not cover.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your contract decides what the delivery requires.

How to start

Record every client repository from day one of the engagement. A report that starts mid-project covers half the delivery; make the recorder part of project setup.
Make agent authorship and human review explicit. Agents carry tool, model and session in commit trailers; your reviewers’ approvals land as change.reviewed. The “how much AI, who checked it” question answers itself.
Seal each hand-over as a release. The sealed release with its evidence report and SBOM is the document you attach to the delivery note.
Hand over the export with the code. Give the client the canonical export and point them at the verifier; an agency whose work can be checked is easier to hire again.

Evidence can't be reconstructed after the fact — it has to be recorded while you build. Start recording now, free, and every change from this moment is on the record.

Start recording

Frequently asked questions

Why would a client want an evidence report rather than just the code?

Because the client inherits the questions: their auditors, insurers and — if they place the software on the market — the Product Liability Directive and the CRA ask how it was built. A report that shows authorship, review and test evidence per release answers those questions for them, and differentiates the agency that can produce it.

Do we have to disclose how much of the work an AI agent did?

That is a contractual and commercial decision between you and the client. The record makes the number accurate if you choose to disclose it — and many clients now ask outright; an agency with a measured answer is in a stronger position than one with an estimate.

Who owns the evidence chain for a client project?

The chain is recorded per repository and organisation; export is free and always available, so the evidence can be handed over with the code at the end of an engagement. The arrangement — who records, who holds the export — belongs in the contract.

Does the report replace our QA or acceptance process?

No. It evidences that your process ran — reviews, tests, releases — release by release. Acceptance criteria, SLAs and warranties stay in the contract.

Sources

Last reviewed 2026-08-21. Dates are cross-checked against our regulatory mapping and radar.

A necessary honesty: OLOBOLO is evidence, not a legal opinion. This guide describes what our chain supports as documentation — Supports / Partially supports / Out of scope — and your counsel decides what compliance requires. No tool can promise the latter.