बहुतेक software काय बदलले ते आठवते. खूप कमी software का allowed होते, कोणी किंवा कशाने decide केले, आणि decision कोणत्या evidence वर उभा होता ते आठवते. हाच gap trust शांतपणे कमी करतो. Operations team “state आता काय आहे” हे बहुतेक सांगू शकते; पण “इथे कसे पोचलो ते दाखवा, आणि आम्हाला परवानगी होती हे prove करा” हे नेहमी सांगता येत नाही.
Threada मध्ये दुसरा प्रश्न नेहमी answerable असावा म्हणून बांधणी आहे. प्रत्येक governed action receipt ठेवते.
Receipt मध्ये प्रत्यक्ष काय असते
Receipt ही log line नाही. Log line म्हणते “काहीतरी झाले.” Receipt नंतर decision reconstruct आणि defend करण्याइतके सांगते. Threada मध्ये governed action record करते:
- Actor. Human operator किंवा AI participant, distinct actor events म्हणून. Agent approval कधीही person चे रूप घेत नाही.
- Inputs. WorkItem, त्याची extracted entities, requester identity, आणि request ज्या source channel वरून आली ते.
- Evidence. Citations, retrieval trace, आणि context insufficient असेल तर explicit fallback reason. Citations किंवा recorded fallback reason शिवाय work तयार होत नाही.
- Policy. कोणता policy set active होता, कोणत्या version वर, आणि तो tenant-wide होता की pack, workflow, channel, requester group पर्यंत narrow होता.
- Outcome. Action proposed, approved, rejected, executed, succeeded, किंवा failed झाले का - touched external record शी linkage सहित.
ही fields एकत्र वाचा आणि single step चे defensible account मिळते. WorkItem lifecycle भर वाचा आणि त्याचा full history मिळतो.
Auditability default म्हणून, नंतर जोडलेले feature नाही
बहुतेक systems मध्ये temptation म्हणजे audit नंतर add करणे: feature ship करा, मग customer SOC 2 evidence मागतो किंवा regulator येतो तेव्हा logging wrap करा. हा क्रम उलटा आहे. नंतर जोडलेला audit नेहमी partial असतो, कारण decision होत असताना context carry करायला system ला सांगितलेलेच नसते.
Threada order invert करते. Runtime प्रत्येक meaningful transition वर structured events emit करते - work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered - कारण work करणे आणि ते record करणे हेच एकच act आहे. “turn on auditing” असा वेगळा step नाही, कारण work off the record होण्याचा क्षणच नाही.
Records-and-receipts model म्हणताना आमचा अर्थ हा आहे. Record generate करायचा report नाही; work योग्यरीत्या केल्याचा residue आहे.
Receipts teams चे काम कसे बदलतात
Quarter शेवटी auditor साठी receipt उपयोगी आहे. पण Tuesday च्या मध्यभागी operator साठी त्याची शांत value अधिक असते.
प्रत्येक action evidence आणि policy basis घेऊन येते तेव्हा तीन गोष्टी सोप्या होतात:
- Review fast आणि honest होते. Approver ला context memory मधून reconstruct करावा लागत नाही किंवा original ask साठी requester मागे धावावे लागत नाही. Evidence action च्या बाजूला बसते.
- Reversal safe होते. Receipt policy version आणि inputs चे नावे देते, त्यामुळे rollback archaeology project नसून defined operation असते. काय undo करत आहात आणि का केले गेले हे माहीत असते.
- Accountability adversarial राहत नाही. Record स्वतः assemble होत असल्याने “हे कोणी approve केले” हा accusation नसतो - तो field असतो. Builder, approver, governance roles मधील separation enforced आणि visible असते.
High-risk work human राहते, record वर
Receipts म्हणजे सगळे automate झाले असे नाही. त्याचा अर्थ सगळे accountable आहे. High-risk automations explicit human-in-the-loop progression follow करतात - proposed, मग approved, मग executing - आणि policy स्पष्टपणे परवानगी देईल तेथेच auto-execute होतात. Receipt त्या action ने कोणता path घेतला ते record करते. Automation आणि approval tension मध्ये नाहीत; दोन्ही trace ठेवणारे steps आहेत.
परिणाम असा system जो auditor आणि new operator दोघांनाही समान confidence ने देता येतो. Auditor पाहतो की controls टिकले. Operator पाहतो की मागच्या person ने समोरील case कसा हाताळला. दोघेही तेच receipts वाचतात.
Threada खालील bet हा आहे: decision का allowed होता हे capture करण्याचा सर्वात स्वस्त क्षण म्हणजे decision घेतानाच; आणि जी team कधी off the record काम करत नाही ती दुसऱ्या प्रश्नाचे उत्तर नेहमी देऊ शकते.