چرا هر action باید receipt بگذارد

بیشتر نرم‌افزارها یادشان می‌ماند چه چیزی تغییر کرده است. بسیار کمتر یادشان می‌ماند چرا change مجاز بوده، چه کسی یا چه چیزی آن را تصمیم گرفته و decision بر چه evidenceیی ایستاده است. اعتماد دقیقاً در همین gap آرام آرام فرسوده می‌شود. operations team معمولاً می‌تواند پاسخ دهد «state الان چیست»؛ اما اغلب نمی‌تواند پاسخ دهد «نشانم بده چگونه به اینجا رسیدیم و ثابت کن اجازه داشتیم.»

Threada طوری ساخته شده که پرسش دوم همیشه پاسخ‌دادنی باشد. هر action govern شده receipt می‌گذارد.

receipt واقعاً شامل چه چیزی است

receipt یک log line نیست. log line می‌گوید «چیزی رخ داد». receipt آن‌قدر می‌گوید که بتوان بعداً decision را reconstruct و defend کرد. در Threada، action govern شده اینها را record می‌کند:

• Actor. operator انسانی یا AI participant، که به‌صورت actor eventهای distinct record می‌شوند. approval یک agent هرگز شبیه approval یک انسان masquerade نمی‌کند.
• Inputها. WorkItem، entityهای extracted، identity requester و source channelی که request از آن رسیده است.
• Evidence. citationها، retrieval trace و، وقتی context کافی نبوده، fallback reason صریح. work نمی‌تواند بدون citation یا fallback reason recorded ایجاد شود.
• Policy. کدام policy set active بوده، با چه versionی، و آیا tenant-wide اعمال شده یا به pack، workflow، channel یا requester group محدودتر.
• Outcome. اینکه action proposed، approved، rejected، executed، succeeded یا failed بوده، با linkage به external recordی که touched کرده است.

این fieldها را با هم بخوانید و accountی defensible از یک step دارید. آنها را در lifecycle یک WorkItem بخوانید و history کامل آن را دارید.

Auditability به‌عنوان default، نه featureی که بعداً bolt-on شود

وسوسه در بیشتر systemها این است که audit را بعداً اضافه کنند: feature را ship کنید، سپس وقتی مشتری evidence SOC 2 خواست یا regulator آمد، logging دور آن بپیچید. این ordering وارونه است. auditی که بعداً اضافه می‌شود همیشه partial است، چون هنگام ساخته شدن decision از system خواسته نشده context را حمل کند.

Threada ترتیب را برعکس می‌کند. runtime در هر transition معنادار event ساختاریافته emit می‌کند: work_item_created، approval_requested، approval_decided، action_proposed، action_executed، fallback_triggered. چون act انجام دادن work همان act record کردن آن است. step جداگانه‌ای به نام turn on auditing وجود ندارد، چون لحظه‌ای وجود ندارد که work off the record رخ دهد.

این همان چیزی است که وقتی می‌گوییم مدل records-and-receipts است منظور داریم. record گزارشی نیست که generate می‌کنید؛ residue درست انجام دادن کار است.

چرا receiptها نحوه کار teamها را عوض می‌کنند

receipt برای auditor در پایان quarter مفید است. اما ارزش آرام‌تر آن برای operator در میانه یک سه‌شنبه است.

وقتی هر action evidence و policy basis خود را دارد، سه چیز آسان‌تر می‌شود:

1. Review سریع و صادقانه می‌شود. approver لازم نیست context را از حافظه reconstruct کند یا برای ask اصلی دنبال requester برود. evidence کنار action قرار دارد. confidence، reversibility و clarity در نقطه decision visible است، پس reviewerها برای reviewability optimize می‌کنند، نه فقط speed.
2. Reversal امن می‌شود. چون receipt policy version و inputها را نام می‌برد، rollback کردن action یک operation defined است، نه پروژه archaeology. می‌دانید چه چیزی را undo می‌کنید و چرا انجام شده بوده.
3. Accountability از حالت adversarial خارج می‌شود. وقتی record خودش assemble می‌شود، «چه کسی این را approve کرد» accusation نیست؛ فقط یک field است. separation of duties میان builder، approver و governance roleها enforce و visible است، پس پرسش accountability پیش از آنکه کسی مجبور شود بپرسد پاسخ داده شده است.

کار high-risk انسانی و on the record می‌ماند

receipt به این معنی نیست که همه چیز automate می‌شود. یعنی همه چیز accountable است. automationهای high-risk progression صریح human-in-the-loop را دنبال می‌کنند: proposed، سپس approved، سپس executing؛ و فقط جایی auto-execute می‌شوند که policy صریحاً اجازه دهد. receipt record می‌کند action مورد نظر کدام مسیر را رفت. automation و approval در tension نیستند؛ هر دو stepهایی هستند که trace می‌گذارند.

نتیجه سامانه‌ای است که می‌توانید با confidence یکسان به auditor و operator جدید بدهید. auditor می‌بیند controlها برقرار مانده‌اند. operator می‌بیند نفر قبلی case پیش روی او را چگونه handle کرده است. هر دو همان receiptها را می‌خوانند.

شرط زیر Threada این است: ارزان‌ترین لحظه برای capture کردن اینکه چرا یک decision مجاز بوده همان لحظه گرفتن آن decision است، و teamی که هرگز off the record کار نمی‌کند همیشه می‌تواند به پرسش دوم پاسخ دهد.