I am working on a setup where Docs tables act as the control surface for real work: rows define tasks, owners, approval state, payload fields and links to the result.
The outside execution layer then runs the work and returns proof: final URL, changed record, file, run id, cost, reviewer notes or a failed check. In our case that outside layer is Crankflo, but the question is really about Docs/Superhuman Community patterns.
What I am trying to avoid:
- a row saying done while the external proof failed
- circular automations that keep updating each other
- manually pasted proof links with no stable structure
- a doc that looks current but is no longer the source of truth
The shape I am considering:
1. Docs table row is the human-facing request and approval surface.
2. External system owns execution and immutable proof.
3. Docs gets a compact status update plus proof URL back.
4. A separate audit log keeps the full event history.
5. Automations only move rows between explicit states, not infer success from a webhook alone.
Has anyone here built something like this with Docs tables, Pack/API calls, buttons or automations?
I would especially like to know where you keep the durable proof reference and how you prevent a table update from being mistaken for verified completion.
