Trace delegated work
Follow authority through a research-workflow study, inspect its allocations and treaty boundary, then check a signed record’s evidence.
On this page
Delegated work leaves a trail you can check: each worker’s narrower grant, its allocation from one shared pool, and the signed record of what the kernel decided. Trace one research run from the coordinator’s grant to a receipt, then break the receipt and watch verification say so.
Everything runs in your browser. No installation or account is required. The architecture is illustrative: the evidence inspector checks SHA-256 hashes and Ed25519 signatures under example keys over a four-record fixture. It dispatches no research task and produces no Chio protocol artifacts.
Start1. Follow the delegation tree
A coordinator assigns a research lead and an analysis worker. The lead delegates source reading and claim checking, and a partner operator admits a review through its own kernel.
Illustrative research swarm
Produce a research brief
Authority narrows with every generation
The research lead delegates source reading and claim checking to two more agents. Each child stays within its parent’s authority. The signed task graph bounds how deep delegation goes and how many children a task can create. Signed task graphs.
Under Delegate recursively, follow the lead’s two children, each inside its parent’s authority. Under Share a budget, read the five allocations: 80 of 100 units reserved, 20 left in the pool. Under Cross a boundary, find the receiving kernel; the treaty connects the operators while each keeps its own policy and keys.
Read more in Signed task graphs.
2. Follow one worker’s authority into its signed record
Select Read sources, Check claims, or Partner review. The highlighted grant leads to its decision record and then up the receipt’s Merkle inclusion path to the checkpoint; the partner’s record carries a different signing key.
The record set holds the coordinator and its three declared child receipts, a focused slice of the run above. A first checkpoint covers two records; the second covers all four.
Read sources
The research lead delegates source access. The reader’s decision record points back to that narrower grant.
- Scope
- Read the research sources
- Allocation
- 10 units
Inspect the example’s evidence
These illustrative records use real hashes and demo signatures, checked in your browser. They explain the relationships; they are not Chio protocol artifacts or a live execution.
Authority path Your grant / Research lead / Source reader
Checking the example…
Inclusion checks the selected record. Completeness accounts for the coordinator’s three declared child records. History is checked by rebuilding the earlier two-record tree and the complete four-record tree. Witness signatures are checked against the example’s pinned keys and two-of-three policy.
Delegation and receipt inclusion are different relationships. Authority narrows through signed grants; hashes converge into a Merkle commitment. The coordinator’s declared child set supplies the separate completeness check.
Your own kernel records the same relationships for the work you delegate. After Delegate Between Agents, walk forward from the fixer’s grant to the grant it handed the tester and every receipt the tester’s calls produced:
chio lineage query --live --seed cap-01d2…2a90 --direction forwardwalk forward from cap-01d2…2a90, depth limit 20 depth 0 cap-01d2…2a90 capability fixer depth 1 cap-01d2…6c13 capability tester delegated from cap-01d2…2a90 depth 2 rcpt-01d2…7a10 receipt allow run pytest, issued under cap-01d2…6c13 depth 2 rcpt-01d2…b3c2 receipt allow read /workspace/src/pricing.py, issued under cap-01d2…6c13 depth 2 rcpt-01d2…e48a receipt deny write /workspace/src/pricing.py, issued under cap-01d2…6c13 5 nodes, 4 edges, walk complete
You should see one delegated grant and three receipts under it, the refused write among them. The walk follows recorded edges only: a grant that never reached your kernel has no node to find.
3. Verify the original record
Open Inspect the example’s evidence with the original record selected.
You should see five checks report Matches: the receipt signature, its inclusion in the checkpoint, the retained checkpoint history, the coordinator’s three child records, and a witness quorum of two of three. Each runs in the page, over the fixture’s bytes, against the example’s pinned keys.
Read more in Verifiable evidence.
4. Change one receipt’s bytes, then restore it
Choose Change one receipt’s bytes. The inspector appends one byte to the selected record.
You should see the four record checks report Does not match, while the witness quorum still matches: the checkpoint and its witness signatures are unchanged, so only the record fails against them. Choose Restore original receipt and all five return to Matches.
The inspector needs SHA-256 and Ed25519 in the browser’s Web Crypto. Where either is missing, it reports verification as unavailable, disables byte alteration, and claims no successful check.