বেশিরভাগ সফটওয়্যার মনে রাখে কী বদলেছে। অনেক কম সফটওয়্যার মনে রাখে কেন একটি পরিবর্তন অনুমোদিত হয়েছিল, কে বা কী তা সিদ্ধান্ত নিয়েছিল, এবং সিদ্ধান্তটি কোন প্রমাণের উপর দাঁড়িয়ে ছিল। এই ফাঁকটিতেই আস্থা নিঃশব্দে ক্ষয়ে যায়। একটি অপারেশন টিম সাধারণত “এখন অবস্থা কী” উত্তর দিতে পারে; কিন্তু প্রায়ই “আমাকে দেখাও আমরা কীভাবে এখানে পৌঁছালাম, এবং প্রমাণ করো আমাদের তা করার অনুমতি ছিল” উত্তর দিতে পারে না।
Threada এমনভাবে নির্মিত যাতে দ্বিতীয় প্রশ্নটির উত্তর সবসময় দেওয়া যায়। প্রতিটি শাসিত ক্রিয়া একটি রসিদ রেখে যায়।
একটি রসিদে আসলে কী থাকে
রসিদ কোনো লগ লাইন নয়। একটি লগ লাইন বলে “কিছু একটা ঘটেছে।” একটি রসিদ এতটা বলে যে পরে একটি সিদ্ধান্ত পুনর্গঠন ও সমর্থন করা যায়। Threada-তে, একটি শাসিত ক্রিয়া লিপিবদ্ধ করে:
- কর্তা। একজন মানব অপারেটর বা একজন AI অংশগ্রহণকারী, আলাদা কর্তা-ঘটনা হিসেবে লিপিবদ্ধ। একজন এজেন্টের অনুমোদন কখনোই কোনো ব্যক্তির ছদ্মবেশ ধারণ করে না।
- ইনপুট। WorkItem, তার নিষ্কাশিত সত্তাগুলো, অনুরোধকারীর পরিচয়, এবং যে উৎস চ্যানেলে অনুরোধটি এসেছিল।
- প্রমাণ। উদ্ধৃতি, পুনরুদ্ধারের সূত্র, এবং — যখন প্রেক্ষাপট অপর্যাপ্ত ছিল — স্পষ্ট ফলব্যাক কারণ। উদ্ধৃতি কিংবা লিপিবদ্ধ ফলব্যাক কারণ ছাড়া Work তৈরি করা যায় না।
- নীতি। কোন নীতি-সেট সক্রিয় ছিল, কোন সংস্করণে, এবং তা পুরো টেন্যান্ট জুড়ে প্রযোজ্য ছিল নাকি কোনো সংকীর্ণ pack, ওয়ার্কফ্লো, চ্যানেল বা অনুরোধকারী গোষ্ঠীতে।
- ফলাফল। ক্রিয়াটি প্রস্তাবিত, অনুমোদিত, প্রত্যাখ্যাত, নির্বাহিত, সফল নাকি ব্যর্থ হয়েছিল — সেই বাহ্যিক নথির সঙ্গে ফিরতি সংযোগসহ যা এটি স্পর্শ করেছিল।
এই ক্ষেত্রগুলো একসঙ্গে পড়ুন, আর আপনি একটি একক ধাপের সমর্থনযোগ্য বিবরণ পাবেন। একটি WorkItem-এর সমগ্র জীবনচক্র জুড়ে পড়ুন, আর আপনি তার সম্পূর্ণ ইতিহাস পাবেন।
নিরীক্ষণযোগ্যতা একটি ডিফল্ট হিসেবে, পরে জুড়ে দেওয়া বৈশিষ্ট্য হিসেবে নয়
বেশিরভাগ ব্যবস্থায় প্রলোভনটি হলো নিরীক্ষা পরে যোগ করা: বৈশিষ্ট্যটি পাঠিয়ে দাও, তারপর যখন কোনো গ্রাহক SOC 2 প্রমাণ চায় বা কোনো নিয়ন্ত্রক হাজির হয়, তখন তাকে লগিং দিয়ে মুড়ে দাও। এই ক্রমটি উল্টো। পরে যোগ করা নিরীক্ষা সবসময় আংশিক, কারণ সিদ্ধান্ত নেওয়ার মুহূর্তে প্রেক্ষাপট বহন করতে ব্যবস্থাটিকে কখনো বলা হয়নি।
Threada ক্রমটিকে উল্টে দেয়। রানটাইম প্রতিটি অর্থবহ পরিবর্তনে কাঠামোবদ্ধ ঘটনা নিঃসরণ করে — work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered — কারণ কাজটি করার কাজই হলো সেই একই কাজ যা তা লিপিবদ্ধ করে। এখানে আলাদা কোনো “নিরীক্ষা চালু করো” ধাপ নেই, কারণ এমন কোনো মুহূর্তই নেই যেখানে কাজ নথির বাইরে ঘটে।
আমরা যখন বলি মডেলটি নথি-ও-রসিদের, তখন আমরা এটিই বোঝাই। নথি কোনো প্রতিবেদন নয় যা আপনি তৈরি করেন; এটি কাজটি সঠিকভাবে করার অবশিষ্টাংশ।
কেন রসিদ দলগুলোর কাজ করার ধরন বদলে দেয়
রসিদ প্রান্তিকের শেষে নিরীক্ষকের কাছে উপযোগী। কিন্তু তার আরও নীরব মূল্যটি কোনো সাধারণ মঙ্গলবারের মাঝখানে থাকা অপারেটরের জন্য।
যখন প্রতিটি ক্রিয়া তার প্রমাণ ও তার নীতি-ভিত্তি বহন করে, তখন তিনটি জিনিস সহজ হয়ে যায়:
- পর্যালোচনা দ্রুত ও সৎ হয়ে ওঠে। একজন অনুমোদনকারীকে স্মৃতি থেকে প্রেক্ষাপট পুনর্গঠন করতে হয় না কিংবা মূল অনুরোধের জন্য অনুরোধকারীর পিছনে ছুটতে হয় না। প্রমাণ ক্রিয়াটির পাশেই বসে থাকে। আস্থা, প্রত্যাবর্তনযোগ্যতা ও স্পষ্টতা সিদ্ধান্ত-বিন্দুতে দৃশ্যমান, তাই পর্যালোচকরা কেবল গতির বদলে পর্যালোচনাযোগ্যতার জন্য অনুকূলন করেন।
- প্রত্যাবর্তন নিরাপদ হয়ে ওঠে। যেহেতু রসিদ নীতি-সংস্করণ ও ইনপুটগুলোর নাম উল্লেখ করে, একটি ক্রিয়া ফিরিয়ে নেওয়া একটি সংজ্ঞায়িত কার্য, কোনো প্রত্নতাত্ত্বিক প্রকল্প নয়। আপনি জানেন আপনি কী পূর্বাবস্থায় ফেরাচ্ছেন এবং কেন তা করা হয়েছিল।
- জবাবদিহিতা বৈরী হওয়া বন্ধ করে। যখন নথি নিজে থেকে গঠিত হয়, “এটি কে অনুমোদন করেছে” কোনো অভিযোগ নয় — এটি কেবল একটি ক্ষেত্র। নির্মাতা, অনুমোদনকারী ও গভর্ন্যান্স ভূমিকার মধ্যে দায়িত্ব পৃথকীকরণ প্রয়োগকৃত ও দৃশ্যমান, তাই জবাবদিহিতার প্রশ্নটি কারও জিজ্ঞাসা করার আগেই উত্তরিত হয়ে যায়।
উচ্চ-ঝুঁকির কাজ মানবিক থাকে, নথিভুক্ত থাকে
রসিদ মানে এই নয় যে সবকিছু স্বয়ংক্রিয়। এর মানে সবকিছু জবাবদিহিযোগ্য। উচ্চ-ঝুঁকির স্বয়ংক্রিয়করণ একটি স্পষ্ট human-in-the-loop অগ্রগতি অনুসরণ করে — প্রস্তাবিত, তারপর অনুমোদিত, তারপর নির্বাহরত — এবং কেবল সেখানেই স্বয়ংক্রিয়ভাবে নির্বাহ হয় যেখানে কোনো নীতি স্পষ্টভাবে অনুমতি দেয়। রসিদ লিপিবদ্ধ করে একটি প্রদত্ত ক্রিয়া এই পথগুলোর কোনটি নিয়েছিল। স্বয়ংক্রিয়করণ ও অনুমোদন পরস্পরবিরোধী নয়; উভয়ই কেবল এমন ধাপ যা একটি চিহ্ন রেখে যায়।
ফলাফল এমন একটি ব্যবস্থা যা আপনি একজন নিরীক্ষক ও একজন নতুন অপারেটরের হাতে একই আস্থায় তুলে দিতে পারেন। নিরীক্ষক দেখেন নিয়ন্ত্রণগুলো টিকে ছিল। অপারেটর দেখেন আগের ব্যক্তি তার সামনের কেসটি কীভাবে সামলেছিলেন। দুজনেই একই রসিদ পড়ছেন।
এটিই Threada-র নিচে থাকা বাজি: একটি সিদ্ধান্ত কেন অনুমোদিত হয়েছিল তা ধরে রাখার সবচেয়ে সস্তা সময় হলো সেই মুহূর্ত যখন আপনি তা নেন, এবং যে দল কখনো নথির বাইরে কাজ করে না সেই দলই এমন একটি দল যা দ্বিতীয় প্রশ্নের উত্তর সবসময় দিতে পারে।