زیادہ تر software یاد رکھدا اے کیہ بدلیا۔ بہت گھٹ software یاد رکھدا اے کیوں change allowed سی، کس نے یا کس چیز نے decide کیتا، تے کیہ evidence تے decision کھڑا سی۔ ایہ gap trust نوں آہستہ آہستہ کمزور کردا اے۔ Operations team عموماً “state hun کیہ اے” دا جواب دے دیندی اے؛ پر “دکھاؤ اسی ایتھے کِویں پہنچے تے proof دو کہ allowed سی” اوکھا ہوندا اے۔
Threada ایس لئی built اے کہ دوجا سوال ہمیشہ answerable ہووے۔ ہر governed action receipt چھڈدی اے۔
Receipt وچ اصل کیہ ہوندا اے
Receipt log line نہیں۔ Log line کہندی اے “کجھ ہویا”۔ Receipt اتنا context دیندی اے کہ بعد وچ decision reconstruct تے defend ہو سکے۔ Threada وچ governed action record کردی اے:
- Actor. Human operator یا AI participant، distinct actor events دے طور تے۔ Agent approval کبھی person بن کے نہیں آندی۔
- Inputs. WorkItem، extracted entities، requester identity، تے source channel۔
- Evidence. Citations، retrieval trace، تے insufficient context ہووے تاں explicit fallback reason۔
- Policy. کونسا policy set active سی، کس version تے، tenant-wide یا narrowed pack/workflow/channel/requester group لئی۔
- Outcome. Action proposed، approved، rejected، executed، succeeded، یا failed — external record linkage سمیت۔
ایہ fields اک step دا defensible account بناندے نیں۔ WorkItem lifecycle وچ پڑھو تاں پوری history ملدی اے۔
Auditability default اے، bolt-on feature نہیں
اک temptation ایہ ہوندی اے کہ audit بعد وچ add کرو: feature ship کرو، پھر SOC 2 یا regulator آوے تاں logging wrap کرو۔ ایہ order غلط اے۔ بعد وچ add کیتا audit ہمیشہ partial ہوندا اے، کیونکہ decision دے moment تے system context carry نہیں کر رہیا سی۔
Threada order الٹ کردا اے۔ Runtime ہر meaningful transition تے structured events emit کردا اے — work_item_created، approval_requested، approval_decided، action_proposed، action_executed، fallback_triggered — کیونکہ work کرنا تے record کرنا اک ہی عمل اے۔ “Audit on” کرن دا separate step نہیں، کیونکہ work record توں باہر ہوندا ہی نہیں۔
ایہی records-and-receipts model اے۔ Record report نہیں جو بعد وچ generate ہووے؛ ایہ work صحیح طریقے نال کرن دا residue اے۔
Receipts teams دا کام کِویں بدل دیاں نیں
Receipt quarter دے آخر auditor لئی useful اے، پر Tuesday دوپہر operator لئی وی equally useful اے۔
- Review fast تے honest ہوندا اے۔ Approver نوں memory توں context reconstruct نہیں کرنا پیندا۔ Evidence action دے نال موجود ہوندی اے۔
- Reversal safe ہوندا اے۔ Receipt policy version تے inputs دسدی اے، اس لئی rollback archaeology project نہیں رہندا۔
- Accountability adversarial نہیں رہندی۔ Record خود assemble ہوندا اے؛ “کس نے approve کیتا” accusation نہیں، field اے۔ Builder، approver، تے governance roles دی separation visible رہندی اے۔
High-risk work human رہندا اے، record تے
Receipts دا مطلب ہر چیز automate کرنا نہیں۔ مطلب ہر چیز accountable اے۔ High-risk automations explicit human-in-the-loop progression follow کردیاں نیں — proposed، approved، executing — تے auto-execute صرف policy allow کرے تاں۔ Receipt record کردی اے action نے کونسا path لیا۔
نتیجہ اوہ system اے جو auditor تے new operator دونوں نوں confidence نال دکھایا جا سکدا اے۔ Auditor دیکھدا اے controls hold ہوئے۔ Operator دیکھدا اے پچھلے بندے نے سامنے والے case نوں کِویں handle کیتا۔ دونے اک ہی receipts پڑھ رہے نیں۔
Threada دی bet ایہ اے: decision allowed کیوں سی، ایہ capture کرن دا سب توں سستا وقت اوہی moment اے جدوں تسی decision کردے او؛ تے جو team record توں باہر کم نہیں کردی، اوہ ہمیشہ دوجا سوال answer کر سکدی اے۔