What Is a Proof Package? Making Agent Deliveries Verifiable

1. Why “the Agent says it is done” is not enough

A fluent answer can look complete while hiding missing sources, scope drift, tool failures, or unvalidated inference. If the buyer must rerun the whole task to check it, automation has not truly reduced acceptance cost.

A verifiable delivery does not promise zero errors. It makes errors discoverable, locatable, and actionable. A reviewer should quickly answer: Does the result match the frozen scope? What supports each key claim? Which steps ran? What remains unknown?

2. Six parts of a minimum Proof Package

Different tasks need different evidence, but the minimum structure should remain stable. A stable structure prevents buyers and providers from reinventing acceptance every time and makes similar services easier to compare.

3. Link results and evidence in both directions

A pile of source links is not traceability. Every key item in the result manifest should point to supporting evidence, and every evidence item should identify the result or acceptance rule it supports. A reviewer can then move down from a conclusion or up from raw evidence to see its impact.

An evidence item should contain at least a type, location, acquisition time, related result, and integrity state. For an external page, keep access conditions. For a generated file, preserve an identifier, size, digest, or integrity information when appropriate.

• Stable evidence_id values instead of relying on file order.
• Explicit relationships between result_id and evidence_id.
• Evidence type, source, time, and acquisition method.
• Completeness, conflict state, and need for human review.

4. Give facts, inferences, and unknowns different places

A source may prove what a page says without directly proving a business recommendation. A Proof Package should separate original facts, inferences based on those facts, and unresolved unknowns. An inference cites its basis and states assumptions; an unknown explains why it cannot be confirmed and how to validate it next.

This is not timid writing. It tells the user where they can act directly and where internal data or human judgment is still required. A delivery that labels an unknown honestly is usually more valuable than one that fills every blank with false certainty.

5. Validation goes beyond “the file exists”

Validation should move from low-cost deterministic checks toward checks that need judgment. Confirm files and field structure first, then rules and evidence coverage, and only then semantic quality and business usability. Preserve the reason for failure at each layer.

A web data pack might check: the file opens, required columns exist, type and uniqueness rules pass, key fields have sources, sampled values match pages, and the business owner confirms the dataset can enter its next workflow. One generic “pass” cannot replace those layers.

6. How a buyer can review it in five minutes

A good Proof Package puts the most important information first instead of requiring the buyer to read every execution log. Show contract scope, result summary, failed items, and recommendation, then allow evidence to expand by layer.

• Confirm which frozen contract version the delivery belongs to.
• Check that required results are complete and usable.
• Sample whether key claims return to a source or execution evidence.
• Inspect whether failures, missing data, conflicts, and unknowns are fully disclosed.
• Confirm validation rules, pass states, and areas still needing human judgment.
• When accepting, requesting revision, or disputing, cite specific result and evidence IDs.