ہر کارروائی کو رسید کیوں چھوڑنی چاہیے

زیادہ تر software یاد رکھتا ہے کہ کیا بدلا۔ بہت کم software یاد رکھتا ہے کہ کیوں change allowed تھا، کس نے یا کس چیز نے فیصلہ کیا، اور decision کس evidence پر کھڑا تھا۔ trust اسی gap میں خاموشی سے کم ہوتا ہے۔ operations team عموماً جواب دے سکتی ہے کہ “state اب کیا ہے”؛ اکثر وہ یہ نہیں بتا سکتی کہ “ہم یہاں کیسے پہنچے، اور prove کرو کہ ہمیں اجازت تھی۔”

Threada اس طرح built ہے کہ دوسرا سوال ہمیشہ 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 کے طور پر record ہوتے ہیں۔ agent کی approval کبھی کسی person کے طور پر masquerade نہیں کرتی۔
• inputs۔ WorkItem، اس کی extracted entities، requester identity، اور source channel جس سے request آئی۔
• evidence۔ citations، retrieval trace، اور جب context insufficient ہو تو explicit fallback reason۔ work یا تو citations کے ساتھ بنتا ہے یا recorded fallback reason کے ساتھ۔
• policy۔ کون سا policy set active تھا، کس version پر، اور کیا وہ tenant-wide apply ہوا یا narrowed pack، workflow، channel، یا requester group تک۔
• outcome۔ action proposed، approved، rejected، executed، succeeded، یا failed ہوا؛ اور جس external record کو touch کیا اس سے linkage۔

یہ fields together پڑھیں تو ایک step کا defensible account ملتا ہے۔ انہیں WorkItem lifecycle کے across پڑھیں تو پوری history ملتی ہے۔

Auditability default ہے، بعد میں لگایا جانے والا feature نہیں

اکثر systems میں temptation یہ ہوتی ہے کہ audit بعد میں add کریں: feature ship کریں، پھر جب customer SOC 2 evidence مانگے یا regulator آئے تو logging wrap کر دیں۔ یہ order الٹا ہے۔ بعد میں add ہونے والا audit ہمیشہ partial ہوتا ہے، کیونکہ system سے decision کے وقت context carry کرنے کو کہا ہی نہیں گیا تھا۔

Threada order invert کرتا ہے۔ runtime ہر meaningful transition پر structured events emit کرتا ہے: work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered، کیونکہ کام کرنا اور اسے record کرنا ایک ہی act ہے۔ کوئی separate “auditing on کریں” step نہیں، کیونکہ کوئی moment نہیں جہاں work off the record ہو۔

اسی کو ہم records-and-receipts model کہتے ہیں۔ record کوئی report نہیں جو آپ generate کرتے ہیں؛ یہ صحیح طریقے سے کام کرنے کا residue ہے۔

receipts teams کے operate کرنے کا طریقہ کیسے بدلتی ہیں

receipt quarter کے آخر میں auditor کے لیے useful ہے۔ مگر اس کی quieter value Tuesday کے درمیان operator کے لیے ہے۔

جب ہر action اپنی evidence اور policy basis carry کرتا ہے تو تین things آسان ہو جاتی ہیں:

1. review fast اور honest ہو جاتا ہے۔ approver کو memory سے context reconstruct نہیں کرنا پڑتا یا requester کے پیچھے original ask کے لیے نہیں بھاگنا پڑتا۔ evidence action کے ساتھ بیٹھتا ہے۔ confidence، reversibility، اور clarity decision point پر visible ہیں، اس لیے reviewers صرف speed نہیں بلکہ reviewability optimize کرتے ہیں۔
2. reversal safe ہو جاتی ہے۔ چونکہ receipt policy version اور inputs name کرتی ہے، action rollback defined operation ہے، archaeology project نہیں۔ آپ جانتے ہیں کیا undo کر رہے ہیں اور کیوں کیا گیا تھا۔
3. accountability adversarial نہیں رہتی۔ جب record خود assemble ہو، “یہ کس نے approve کیا” accusation نہیں، صرف field ہے۔ builder، approver، اور governance roles کے بیچ separation of duties enforced اور visible ہے، اس لیے accountability کا سوال پوچھنے سے پہلے answer ہو چکا ہوتا ہے۔

high-risk work انسان کے پاس رہتا ہے، record پر

receipts کا مطلب یہ نہیں کہ سب کچھ automated ہے۔ مطلب یہ ہے کہ سب کچھ accountable ہے۔ high-risk automations explicit human-in-the-loop progression follow کرتے ہیں: proposed، پھر approved، پھر executing؛ اور صرف وہاں auto-execute ہوتے ہیں جہاں policy explicitly allow کرے۔ receipt record کرتی ہے کہ given action نے کون سا path لیا۔ automation اور approval tension میں نہیں؛ دونوں steps ہیں جو trace چھوڑتے ہیں۔

نتیجہ ایسا system ہے جسے آپ auditor اور new operator دونوں کو اسی confidence کے ساتھ دے سکتے ہیں۔ auditor دیکھتا ہے controls held۔ operator دیکھتا ہے کہ پچھلے person نے سامنے کے case کو کیسے handle کیا۔ دونوں ایک ہی receipts پڑھ رہے ہیں۔

Threada کے نیچے یہی bet ہے: decision allowed کیوں تھا، اسے capture کرنے کا سب سے سستا وقت وہی moment ہے جب آپ decision کرتے ہیں، اور جو team کبھی off record کام نہیں کرتی وہ ہمیشہ دوسرے سوال کا جواب دے سکتی ہے۔