Projects and evidence packs

Closing a quarter is one job that may contain three requests and a publish. Afterwards the question is not "which approvals were there in October" but "what happened on the Q3 close". A project answers that question, and an evidence pack is the answer written down.

What a project is#

A project groups the approvals, reviews, requests for information and reports that belong to one piece of work. Usually an agent starts one when a job will take more than one request, and adds each request to it as it makes it. Nothing is added to a project from its page.

Objectives started with the project's flowId, and the gates an agent checked under it, belong to it too. They are not steps — nothing waits on them — but the project page lists them and its history includes what happened to them.

A project groups; it does not drive. It has no order of its own and no step waits on another: each request inside it is decided exactly as it would be on its own. An agent that wants to do one thing after another simply does them in that order.

Reading a project#

Projects lists the pieces of work in progress and those finished. Each shows who started it, how many steps it has, and how many are waiting on somebody.

A project's own page lists its steps — each approval, review, request or report, with its status, linking to where it is read — its tasks, as a tree under each objective, the gates checked under it, and a timeline of everything that happened across all of them in the order it happened: who asked, who approved or rejected, who asked for changes, who answered, what was published, what was commented on, the gate's checks, and each task's findings, decisions and governance evidence. A report that belongs to a project links to it as well. You see the tasks of workspaces you belong to.

Who worked on this project lists the people, the API keys, the OAuth connectors and the registered agents that did something in it, from its history. A request can also say which agent made it and which model that agent was running on; those are listed separately, as the request declared them. Nothing checks a declared name or model, and the page says so.

Finishing or calling off a project#

Only whoever started a project can close it, and only while it is open. If a project was started as you — by an AI tool connected under your name, for instance — its page offers you two buttons. A project started by an agent identity is closed by that agent.

Mark it done

The job is finished. The history records it as completed.

Call it off

The job was abandoned. The history records it as called off, which is not the same thing.

Evidence packs#

An evidence pack is everything recorded about one piece of work, for an auditor, a client or a colleague who was not there. There are two kinds of subject: a project, and a report — the approvals, reviews and requests that point at it, and its own history of versions.

What a pack contains

• The subject: what it is, its status, who started it and when, and the organisation.
• Every step: who asked, whether an agent asked, the agent and model the request declared, who was asked, and what each of them said with their note, in order.
• For an approval: the description, the risk, the key factors and links, the questions and answers, and the concerns your organisation's ethics rules raised, beside the approver's reason for going ahead.
• For a review: the instructions, the verdicts and notes, and how many comment threads were opened.
• For a question: the questions and every submitted answer. Drafts are not included.
• For a project: the task tree under it, every finding and decision recorded on those tasks, the gates checked, and for a governed objective its controls — how many are satisfied, waived and outstanding — and the evidence submitted against them.
• The timeline: every recorded event, with who did it and when.
• Legal holds in force over the subject when the pack was taken. See Security, audit and legal holds.
• An integrity block: a SHA-256 digest of the pack itself, the head of the organisation's audit chain when the pack was taken, and an Ed25519 signature over the digest.

The digest and the signature show that a pack has not been altered since it left Deliverd: check one with deliverd verify pack.json (CLI 0.17.0 and later), which needs no account, or with POST /api/v1/evidence/verify. They say nothing about the records themselves; what stands behind those is that the audit log refuses updates and deletions at the database level, and that each organisation's entries are hash-chained, so an entry changed afterwards is detected when the chain is checked — tamper-evident history, not cryptographic immutability. The chain head in the pack is what makes a filed pack useful later: a chain rebuilt after that date would not reach the same hash at the same position. The pack says all of this in its own words, and a pack from a deployment with no signing key says it is unsigned.

Downloading one

Organisation owners, administrators, compliance admins and auditors see an evidence pack panel on a project's page and on a report's page, and every pack in one list under Records → Evidence packs. Anyone else can read the project but not export it: a pack is a portable copy of the notes, verdicts and answers, and once downloaded it has left the product.

A pack is a file: share it the way you would share any other. Your organisation's audit log records the same events by date rather than by piece of work.