பெரும்பாலான software என்ன மாறியது என்பதை நினைவில் வைத்திருக்கும். ஆனால் change ஏன் allowed, யார் அல்லது என்ன decide செய்தது, decision எதன் evidence மீது நின்றது என்பதைக் குறைவான software மட்டுமே நினைவில் வைத்திருக்கும். அந்த gap-ல்தான் trust மெதுவாக குலைகிறது. Operations team “state இப்போது என்ன” என்பதற்கு பதில் சொல்ல முடியும்; ஆனால் “நாம் இங்கே எப்படி வந்தோம், அதை செய்ய allowed என்பதை நிரூபியுங்கள்” என்பது கடினம்.
Threada அந்த இரண்டாவது கேள்வி எப்போதும் answerable ஆக இருக்க built செய்யப்பட்டுள்ளது. ஒவ்வொரு governed action-மும் receipt விடுகிறது.
Receipt உண்மையில் என்ன கொண்டது
Receipt log line அல்ல. Log line “ஏதோ நடந்தது” என்று சொல்கிறது. Receipt ஒரு decision-ஐ பின்னர் reconstruct செய்து defend செய்யப் போதுமான context தருகிறது. Threada-வில் governed action record செய்வது:
- Actor. Human operator அல்லது AI participant, distinct actor events ஆக. Agent approval ஒருபோதும் மனிதராக masquerade ஆகாது.
- Inputs. WorkItem, extracted entities, requester identity, source channel.
- Evidence. Citations, retrieval trace, 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 அல்ல
பல systems-ல் temptation: முதலில் feature ship செய்ய, பிறகு SOC 2 evidence அல்லது regulator கேட்டால் logging சேர்க்க. அந்த order தவறு. பின்னர் சேர்க்கும் audit partial ஆகும், ஏனெனில் decision செய்யும் நேரத்தில் system context carry செய்யவில்லை.
Threada இதை उल்டாக்குகிறது. Runtime ஒவ்வொரு meaningful transition-லுமே structured events emit செய்கிறது — work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered — ஏனெனில் work செய்வதே record செய்வதுமாகும். “Auditing on” என்ற separate step இல்லை; record-க்கு வெளியே work நடக்கும் தருணமே இல்லை.
இதையே records-and-receipts model என்று சொல்கிறோம். Record பின்னர் generate செய்யும் report அல்ல; work சரியாக செய்ததால் உருவாகும் residue.
Receipts teams செயல்பாட்டை மாற்றுவது
Receipt quarter முடிவில் auditor-க்கு பயனுள்ளது. ஆனால் Tuesday நடுவில் operator-க்கும் அது equally பயனுள்ளது.
- Review வேகமாகவும் 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 என்றால் எல்லாம் automated என்பதல்ல; எல்லாம் accountable என்பதே. High-risk automations explicit human-in-the-loop progression பின்பற்றும் — proposed, approved, executing — policy explicit-ஆக அனுமதித்தால் மட்டுமே auto-execute. Action எந்த path எடுத்தது receipt-ல் record ஆகும்.
இதன் முடிவு auditor-க்கும் new operator-க்கும் ஒரே confidence-ஐ தரும் system. Auditor controls held என்பதைப் பார்க்கிறார். Operator முன்னர் ஒருவர் அந்த case-ஐ எப்படி handle செய்தார் என்பதைப் பார்க்கிறார். இருவரும் அதே receipts-ஐப் படிக்கிறார்கள்.
Threada-வின் அடிப்படை நம்பிக்கை இதுதான்: decision ஏன் allowed என்பது capture செய்ய மிகச் சுலபமான நேரம் decision எடுக்கும் அதே தருணம்; record-க்கு வெளியே வேலை செய்யாத team எப்போதும் இரண்டாவது கேள்விக்கு பதில் சொல்ல முடியும்.