How AI receipts make work checkable

An AI assistant says it published your article. The publishing service accepted its request. But can a reader actually open the page?

Those are three different facts. A useful work record should tell you which have been established.

Grex coordinates AI teams and uses receipts to preserve that distinction. A receipt is a structured record of an action or mission result that can be inspected after execution ends.

Four questions an action receipt should answer

This early design uses four core fields. They are an explanation of the action record, not the complete schema for every later mission receipt.

Field	Question it answers
Action identifier	Which action and related output does this record describe?
Cost incurred	What model usage or service charges were measured?
Outcome assertion	What result does the evidence support?
Approval state	What permission applied when the action ran?

The outcome assertion needs particular care. “The request succeeded” describes a request. “The page is publicly visible” describes the result the operator wanted.

A publishing example

Imagine an agent asked to draft and publish a product note. The following sequence is illustrative, not a report of a real Grex publication.

First, it saves a draft as revision 184. That receipt identifies the revision and records the drafting usage.

Next, a spell-check records its result against the same revision. A human then approves publication, and the publishing action records that approval alongside its measured API cost.

Finally, a separate check opens the public URL. Only this last step establishes whether a reader can reach the intended page.

When the service says yes but nothing appears

Suppose the publishing service accepts the request, then a moderation rule withholds the article. The HTTP request can succeed while the article remains invisible.

The receipt should say that the request was accepted but visibility is unverified. If a follow-up check confirms the page is absent, the outcome should record that failure.

Returning a plausible URL cannot upgrade the result to published. The existence of the requested page is what needs checking.

Receipts organize evidence; they do not create truth

A transcript can explain what the agent intended. A tool log can show what the service returned. Screenshots can show a page at a particular moment.

A receipt links such evidence to an action, its cost, and its authority. That makes review easier than reconstructing the whole conversation.

But a receipt with a weak outcome assertion remains weak evidence. A signature can authenticate a record without proving that its underlying claim is correct.

The practical benefit is a clearer audit trail. You can ask which actions incurred charges, which needed approval, and which results remain unverified. For examples of what this approach still missed, read Four jobs looked healthy and delivered nothing.