Most software remember wetin change. Far fewer remember why di change dey allowed, who or wetin decide am, and which evidence di decision stand on. Na inside dat gap trust dey quietly reduce. Operations team fit usually answer “wetin be di state now”; many times dem no fit answer “show me how we reach here, and prove say we get permission.”
Threada dey built so di second question always get answer. Every governed action leave receipt.
Wetin receipt actually contain
Receipt no be log line. Log line talk say “something happened.” Receipt say enough to reconstruct and defend decision later. For Threada, governed action record:
- Di actor. Human operator or AI participant, recorded as distinct actor events. Agent approval never disguise as person own.
- Di inputs. Di WorkItem, extracted entities, requester identity, and source channel where request arrive.
- Di evidence. Citations, retrieval trace, and, when context no enough, explicit fallback reason. Work no fit be created without either citations or recorded fallback reason.
- Di policy. Which policy set dey active, at which version, and whether e apply tenant-wide or to narrowed pack, workflow, channel, or requester group.
- Di outcome. Whether action dey proposed, approved, rejected, executed, succeeded, or failed, with linkage back to external record wey e touch.
Read those fields together and you get defensible account of one step. Read dem across WorkItem lifecycle and you get im full history.
Auditability as default, no be feature wey you bolt on
Temptation for most systems na to add audit later: ship di feature, then wrap am with logging when customer ask for SOC 2 evidence or regulator come. Dat order backwards. Audit wey dem add after dey always partial, because system no carry di context at di moment decision happen.
Threada invert di order. Di runtime emit structured events for every meaningful transition: work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered, because doing di work and recording am na di same act. No separate “turn on auditing” step dey, because no moment dey where work happen off record.
Na this we mean when we say di model na records-and-receipts. Di record no be report wey you generate; na residue of doing di work correctly.
Why receipts change how teams operate
Receipt useful to auditor at quarter end. But im quieter value dey for operator in di middle of Tuesday.
When every action carry im evidence and policy basis, three things become easier:
- Review become fast and honest. Approver no need reconstruct context from memory or chase requester for original ask. Di evidence sit beside di action. Confidence, reversibility, and clarity dey visible at decision point, so reviewers optimize for reviewability, no be speed alone.
- Reversal become safe. Because receipt name policy version and inputs, rolling action back become defined operation, no be archaeology project. You know wetin you dey undo and why dem do am.
- Accountability stop to be fight. When record assemble itself, “who approved this” no be accusation; na just field. Separation of duties between builder, approver, and governance roles dey enforced and visible, so accountability question get answer before anybody ask.
High-risk work stay human, on record
Receipts no mean everything automated. Dem mean everything accountable. High-risk automations follow explicit human-in-the-loop progression: proposed, then approved, then executing; and only auto-execute where policy explicitly allow am. Di receipt record which path dat action take. Automation and approval no dey fight; both na steps wey leave trace.
Result na system wey you fit hand to auditor and to new operator with di same confidence. Auditor see say controls held. Operator see how di last person handle di case in front of dem. Both dey read di same receipts.
Dat na di bet under Threada: di cheapest time to capture why decision dey allowed na di moment you make am, and team wey never work off record fit always answer di second question.