The system
How the system worksThe DirectoryDispatchThe LedgerAI modelsAI agentsYour installationThe appThe research libraryWhat changes for your businessUse it from your softwareEverything it can do
Messaging
iMessageWhatsApp
Ads and leads
AdsCreativeLeads
Devices
Devices
Industries
RealtorsRestaurantsHome services
Explore
How it worksPermissions and limitsCompareSet upQuestionsText me

Task provenance: every payload of a piece of work, on one page the worker could not have written

When an agent says "done", the only witness is usually the agent. This system binds a scoped token to a task, so every call made for that task is filed under it by the runtime, with its exact request and answer. The task's page is assembled from those records, not from the worker's report. This article walks the mechanism, a recorded run, a full lead-to-inbox example, and the specified projection from a task to a shareable article with hashed sources.

"Done" is a claim. The calls are the evidence.

You assign a task. An agent works it: it searches, filters, drafts, sends. Then it says "done" and writes a paragraph about what it did. The paragraph may be accurate. But the paragraph is the agent's testimony about itself, written after the fact, by the one party with a reason to round up. When a client, a reviewer or a regulator asks show me how you got here, a paragraph is not an answer.

This system gives a different answer. Every call an agent makes for a task is filed under that task by the runtime, with the exact request and the exact answer, at the moment it happens. The task's page is then assembled from those records. The worker could not leave a call out, because it could not act without the token, and it could not add one, because the build writes the record.

That is task provenance: a recorded connection between an assignment and every action taken for it, produced by the infrastructure rather than reported by the agent. It is the third piece of a design whose other two parts are the Directory and Ledger (what could run, and what was recorded) and unified dispatch with scoped tokens (one runner, and limits that can be lent out). This article is about the one caveat that ties them to a piece of work.

The task becomes part of the permission

A scoped token can carry the line task = T-0207, where T-0207 names an assignment. The line is a caveat like any other: it is signed into the token's chain, so a holder can add restrictions beneath it but can never remove it. Three things follow.

  1. Every call is grouped under the task. When the token is minted, it is added to the task's index. On every use the checker writes the call to the token's log and submits the Ledger events under the session task:T-0207. A single filter on that session recovers every byte the task ever touched.
  2. Closing the task closes its permission. The checker reads the task's state on every use. Once the task is marked done, any further execution is refused with the reason "its task is done". The proof door stays open, within the token's other limits, so the record remains readable after the work stops.
  3. Delegating never detaches the work. A helper handed a narrower copy still carries task = T-0207. Its calls land on the same page. There is no way to do work for a task off the task's record while using the task's authority.

The binding is small and the consequence is large: the same string that identifies the work being authorised identifies the record that will be inspected afterwards.

What a reviewer sees at /w/<TASK>

The proof page is a plain, read-only document generated from the records:

  • The task, as it was written. Not a summary; the text of the assignment, with its state.
  • What was done, counted. "3 tool runs (2 answered, 0 failed, 1 refused by a limit), 0 chat messages, under 2 tokens."
  • The tokens it was worked with, each with its limits in plain words.
  • Every call, in order. Time, tool, door, duration, and the result: answered, failed, or refused and by which caveat. Each call expands to its arguments and the exact request and answer, with credential values shown by name only.
  • Every chat turn, if the task was worked through the chat door.

The owner opens the page with the build key. Anyone else needs a token for that task with ways = proof: a credential that opens the page read-only and runs nothing, with its own expiry, and which can be turned off. Showing a task to a client is minting one line and sending a link. Opening the page is not a use.

A recorded run

On 3 October 2026, while the token system was being built, a task was created to check it on the live build. Its completion condition was written into the task: two runs on the proof page, a refused run refused, and the token stopping when the task is done.

T-0229, as its proof page records it
JSONT-0229, as its proof page records it
8 keys
"task""T-0229"
"as_written""WHAT: prove a task-bound scoped token end to end on the live build. DONE WHEN: two runs are on this task's proof page, a refused run is refused, and the token stops when this task is done."
"state""done"
"summary_on_page""3 tool runs (2 answered, 0 failed, 1 refused by a limit), 0 chat messages, under 2 tokens"
"tokens" 2 items
2 keys
"label""Live check: work token for T-0229"
"caveats" 5 items
"tools = WIKIPEDIA_SUMMARY,HTTP_ECHO_HEADERS"
"ways = rest,mcp"
"expires < 2026-10-03T22:41:13.648Z"
"uses <= 10"
"task = T-0229"
2 keys
"label""Live check: proof link for T-0229"
"caveats" 3 items
"ways = proof"
"expires < 2026-10-03T22:41:15.872Z"
"task = T-0229"
"calls" 3 items
7 keys
"at""2026-10-03T21:41:18.679Z"
"tool""WIKIPEDIA_SUMMARY"
"door""rest"
"args" 1 key
"title""Macaroon"
"result""answered"
"status"200
"ms"2321
7 keys
"at""2026-10-03T21:41:23.646Z"
"tool""HTTP_ECHO_HEADERS"
"door""rest"
"args" 1 key
"title""Macaroon"
"result""answered"
"status"200
"ms"1351
7 keys
"at""2026-10-03T22:02:42.146Z"
"tool""WIKIPEDIA_SUMMARY"
"door""rest"
"args"
"result""refused before it ran: nothing was sent anywhere"
"caveat""task = T-0229"
"reason""its task T-0229 is done"
"gap_between_second_call_and_refusal""21 min 18.5 s"
"read_from""the proof page /w/T-0229, opened with the owner key on 9 October 2026"

Two calls answered within five seconds of each other. The task was marked done. Twenty-one minutes and eighteen seconds after the second call, a third was attempted. It never left the build. The checker refused it on task = T-0229 with the reason "its task T-0229 is done", and the page shows the refusal with that caveat beside it. The tokens have since expired and been turned off; the page preserves the calls.

This proves what it proves: that the task condition is enforced before execution, and that the page is drawn from the checker's records. It does not prove that an agent completed an arbitrary assignment well. It is one hand-made task with three calls. What it demonstrates is the mechanism, which is what it was written to demonstrate.

The example this was built for: a cold lead, start to finish

The sentence that motivated the design, from the owner on 3 October 2026: if I assign a task to the models I can now have all of the associated payloads from the ledger show up from that task onto an article. The example below shows what that means for the person at the far end of the work: someone who just received an outreach letter and wants to know how they were chosen. The names and figures are illustrative; this is the mechanism, not a recorded run.

The task. Find three plumbers in Marin County with forty or more reviews and a working website. Draft one personalised note each. Queue the sends. Record the provider receipts. Budget: twenty tool uses, one week.

The token. Minted with task = T-XXXX, tools = LEADS_,OUTREACH_,EMAIL_*, ways = rest,mcp, uses <= 20, and an expiry one week out. The mint response carries the address of the task's proof page. The page is empty. The work will fill it.

Step 1: search. LEADS_SEARCH_GOOGLE_PLACES with a query and a limit. The request and the whole answer, eight candidates with names, addresses, ratings and review counts, are recorded as one exchange under one call id. The call log entry names the tool, the door, the arguments and the receipt.

Step 2: filter. LEADS_LIST with the task's rules. Three remain. The answer is recorded whole.

Step 3: draft. OUTREACH_DRAFT once per lead. The draft as first emitted is the receipt. A person may edit it before sending; the record keeps both the model's version and the sent version, each as its own event.

Step 4: send. EMAIL_SEND once per draft. The outbound bytes and the provider's answer (message id, accepted, or the bounce reason) are recorded.

Step 5: delivery. The tracking sweep records delivered, opened, clicked, replied, each as an event with the bytes exactly as they arrived.

At that point the proof page shows the task as written, the token's limits, and five calls in order, each one tap from its exact exchange. The recipient of the letter can be given a proof link and see: the criteria they were selected by, the search that found them, the filter that kept them, the draft that became their letter, and the receipt that it was sent. No screenshot. No deck. No retelling.

From a task to an article: the specified projection

The proof page is private until a proof token exists for it, and it lives on this system's domain. The next step is to turn a task into something that travels: an article, one JSON object with facts, a body and hashed sources, published at one address. The projection below is specified and not built; it is about one module and one route, and its write path is the one the ARTICLE tool already uses.

shell
POST /api/articles/from-task   {"task": "T-0207", "publish_when": "all_quotes_found"}

1. read the task as written
2. read the task's token index and every token's call log
3. read the Ledger rows for each call id
4. write one article:
     facts.task       the task as written
     facts.tokens     each token's limits
     facts.events     one entry per call: tool, door, time, call id, result
     facts.payloads   the structured answers (candidates, filtered list, drafts, receipts)
     sources          one per event, pointing at the record, with its quote hashed
     body             the narrative, plus a JSON widget over facts.events
5. verify every source, and publish only if every quote was found
Line 13, Column 1Shell Script

Two properties make this a projection rather than a second store:

  • Each event points back to its record. An entry in facts.events names a call id that resolves on the Ledger. An agent that fabricated an event would have invented a call id that resolves to nothing, which is detectable by anyone with access to compare.
  • Deleting the article loses nothing. The task, the call logs and the Ledger rows stay where they are. The article is for readability and sharing; the Ledger is for durability.

Three audiences get three views of one substrate. The operator already uses the proof page and the Ledger. The recipient of a letter gets the article: why me, why now, with receipts rather than assertions. A reviewer doing diligence gets the answer to whether "provenance" is a feature or a system property: every task can be shown this way, because the records exist whether or not anyone asks.

What a hashed source actually proves

An article's sources are part of its stored object. Each carries a URL, the exact words it supports, and hashes the build adds:

  • quote_sha256 is computed when the article is saved, from the quote with its whitespace collapsed.
  • On verify, the build fetches each URL with no credentials, keeps snapshot_sha256 of the bytes it got back (the hash of the page as fetched), reduces the page to text, and sets quote_found only if the quote is in it.
  • With the default setting, the article stays a draft while any quote was not found.

The verifier sends no authentication, which is a deliberate constraint: an article that claims a task's record has to cite a page a stranger can open. For a task, that is its proof page opened by a proof token. A hash detects whether messages have been changed since the digests were generated; it does not certify that the source is correct or that the task succeeded. It narrows the question a reader has to trust anyone on, which is the most a document can do.

Every source on this page was fetched and its quote found before it was published. The hashes are in /a/task-payload-provenance-article.json.

Why this matters for training and evaluation

Take the mechanism out of the business setting and put it in an evaluation harness. Each rollout runs under its own task-bound token: the tools, arguments, paths, uses and lifetime it may spend are fixed before it starts. The checker then produces, independently of the policy's own transcript, a record of what the rollout actually did and every point where it tried to exceed its grant, each refusal naming the caveat that stopped it.

That gives a grader three signals that do not depend on the model's account of itself: whether the required calls happened; whether any attempt crossed the grant, counted directly as refusals; and whether work continued after the task closed, as the third T-0229 call did. A policy cannot improve any of those by narrating better, because none of them is read from the narration. The record is also replayable: event sourcing means the event log can be used to reconstruct past states, so a grader can rebuild the rollout's world at any step.

This has not been run on a training job. T-0229 shows the mechanism on one hand-made task. The claim is that the mechanism is the right shape for that use, and Authority outside the model sets out what making it fully true would require.

Where this stops today

  • The task-to-article projection is a specification, not code.
  • A proof page is private until a proof token is minted for it and shared.
  • The checker reads tasks from the document the task list was kept in before it moved to a database table. A token bound to a task created since the move is refused as "does not exist" until the checker is pointed at the table.
  • Calls made outside the task-bound path, with another credential or in another system, are not on the task's page. Today the build's own agents still hold the build key, so their work is recorded on the Ledger but not filed under tasks by this mechanism.
  • Recording is bounded by the Ledger's stated limits: deferred writes can be lost if a Worker dies first; bodies over 8 MiB are recorded as missing.
  • The page is generated by this system and controlled by its operator. It is an inspectable execution record, not a proof against operator tampering.

The rest of the series

  • The Directory and the Ledger: where the contracts live and where the bytes go.
  • Unified dispatch: the runner every call crosses, and the token construction the task caveat belongs to.
  • Atomic tooling: the tools whose answers these records hold, and why each stores its whole result before returning a slice.
Related pages
References (11)
  1. Scoped access: the proof page — miscsubjects“The worker could not leave a call out, because it could not act without the token, and it could not add one, because the build writes the record.”
  2. Scoped access: the task limit — miscsubjects“Binds the token to one task: every run is recorded under that task, shows on its proof page, and the token stops working when the task is done.”
  3. Scoped access: showing a task to someone else — miscsubjects“it opens that page read-only and runs nothing.”
  4. Scoped access: what a use is — miscsubjects“A use is one tool run or one chat message; opening a page is not a use”
  5. Scoped access: turning a token off — miscsubjects“Turning off a token turns off every copy narrowed from it; turning off one copy leaves the token it came from working.”
  6. The jarticle/1 schema — miscsubjects“set by verify: the hash of the page as fetched”
  7. Articles as JSON: how every page here is built — miscsubjects“hashes the page that came back”
  8. FIPS 180-4, Secure Hash Standard — NIST“The digests are used to detect whether messages have been changed since the digests were generated.”
  9. Event Sourcing: rebuilding state — Martin Fowler“we can also use the event log to reconstruct past states”
  10. Authority outside the model — miscsubjects“In this build a model does not set its own authority”
  11. Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud (NDSS 2014) — Google Research“macaroons embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests”