iii — the ledger
Two people ask the same question. They get different answers.
Permissions are not a filter an agent is asked politely to respect. Every resource call goes through a proxy holding the credentials, checked against the grants minted for that run, and the container never sees a secret at all. An automation can only ever touch what the person who asked for it could have touched themselves.
Summarise this week’s admissions on ward 3.
grants at the proxy
patients · query
row filter: ward = 3
scans · get
key prefix: scans/ward-3/
patients in report
36
scans rendered
12
The full ward, because the grant covers the full ward.
grants at the proxy
patients · query
row filter: ward = 3 and consent = 'research'
scans · get
no grant
patients in report
12
scans rendered
0
Twenty-four patients withheld, and the report never hints at them.
every scope decision, written down
[09:12:01]grant u_ellis patients query row filter: ward = 3
[09:12:01]scope patients -> 36 rows in scope
[09:12:02]grant u_ellis scans get key prefix: scans/ward-3/
[09:12:04]grant u_rhodes patients query + consent = 'research'
[09:12:04]scope patients -> 12 rows in scope, 24 withheld
[09:12:05]deny u_rhodes scans get no grant for this resource
█
One table, folded four ways.
Status, the audit trail, approval, and crash recovery all read this one table, so none of them can drift from each other.
Kill the executor mid-run and it rebuilds every run by folding the log, then finishes the work.
A task can gate on human approval. The pending decision persists, so the run survives a restart and continues when someone signs off.