एजेंट साक्ष्य को जांचकर्ता के नोट्स से अलग कैसे रखें

एजेंट जांच उसी क्षण गलत दिशा में चली जाती है जब कोई विश्लेषक साक्ष्य फाइल को नोटबुक बना देता है। प्रलोभन समझ में आता है। आपके पास एन्क्रिप्टेड ऑडिट रिकॉर्ड, एक अजीब outbound request और समयसीमा होती है। आप उसे डिक्रिप्ट या export करते हैं, संदिग्ध कॉल के पास टिप्पणी जोड़ते हैं, timeline को बेहतर पढ़ने योग्य बनाने के लिए कुछ fields का क्रम बदलते हैं और परिणाम को case record के रूप में सहेज देते हैं। महीनों बाद कोई नहीं बता पाता कि एजेंट ने क्या किया था और जांचकर्ता ने उसका क्या अर्थ निकाला था।

मूल एन्क्रिप्टेड रिकॉर्ड को अक्षुण्ण रखें। हर निष्कर्ष, प्रश्न, परिकल्पना और सुधार अलग case file में रखें, जो स्थिर session और call identifiers की ओर इशारा करे। यह विभाजन बारीकी पर जरूरत से ज्यादा ध्यान देने जैसा लग सकता है, जब तक कोई निष्कर्ष को चुनौती न दे, दूसरा विश्लेषक काम न संभाले या कानूनी टीम यह न पूछे कि जांच शुरू होने से पहले कौन से bytes मौजूद थे। तब यह audit करने योग्य विवरण और ऐसी प्रभावशाली दिखने वाली फाइल के बीच का फर्क होता है जिसका इतिहास अज्ञात है।

साक्ष्य और विश्लेषण अलग प्रश्नों के जवाब देते हैं

साक्ष्य पूछता है, «सिस्टम ने कौन-सा रिकॉर्ड सुरक्षित रखा?» जांचकर्ता के नोट्स पूछते हैं, «मुझे लगता है इस रिकॉर्ड का क्या मतलब है?» ये जुड़े हुए प्रश्न हैं, लेकिन इनके साथ अलग ढंग से पेश आना चाहिए क्योंकि पहला स्थिर रहना चाहिए, जबकि दूसरा case आगे बढ़ने के साथ बदलना चाहिए।

एन्क्रिप्टेड ऑडिट रिकॉर्ड में असहज करने वाले तथ्य हो सकते हैं: एजेंट प्रोसेस ने credentials वाला HTTP action चलाया, किसी SSH command से अनपेक्षित परिणाम मिला, या किसी उपयोगकर्ता ने ऐसा run मंजूर किया जिसका व्यवहार बाद में अपेक्षा से अलग निकला। यह रिकॉर्ड मसौदा नहीं है। इसकी भाषा बेहतर न बनाएं, अप्रासंगिक लगने वाली entries न हटाएं और timestamp को सुविधाजनक format में दोबारा न लिखें। मामूली-सा बदलाव भी समीक्षा के एक बुनियादी प्रश्न का साफ जवाब खत्म कर देता है: क्या यह वही रिकॉर्ड है जो सिस्टम ने बनाया था?

नोट्स संपादन योग्य रहने चाहिए, क्योंकि अच्छी जांच खुद को संशोधित करती है। शुरुआती नोट कह सकता है, «Call c-204 ने शायद customer data भेजा है।» Request और response का संदर्भ पढ़ने के बाद विश्लेषक इसे सुधारकर लिख सकता है, «Call c-204 ने request header में एक internal identifier भेजा। रिकॉर्ड से यह साबित नहीं होता कि customer data environment से बाहर गया।» यह सुधार स्वस्थ है। इसे case file में होना चाहिए, जहां बदलाव तर्क में बदलाव बना रहे, साक्ष्य में परिवर्तन नहीं।

जिस अंतर को लोग अक्सर धुंधला कर देते हैं, वह है संरक्षण और पढ़ने की सुविधा का अंतर। डिक्रिप्ट करना, export करना, खोज करना, parse करना और render करना साक्ष्य को उपयोगी बनाते हैं। वे output को मूल नहीं बनाते। JSON export, spreadsheet, PDF printout या चिपकाया हुआ transcript derivative है। यह सटीक और उपयोगी हो सकता है, लेकिन उस पर यह label होना चाहिए कि इसे कैसे बनाया गया और यह किस सुरक्षित वस्तु से आया है।

इसे कार्यकारी नियम मानें: स्रोत रिकॉर्ड read-only है और हर व्याख्यात्मक वाक्य कहीं और रहेगा। यह नियम सहयोग को भी कम नाजुक बनाता है। दूसरा विश्लेषक स्रोत को छुए बिना आपके निष्कर्ष से असहमत हो सकता है, और समीक्षक आपकी citation को आपकी संपादन-इतिहास दोबारा बनाए बिना जांच सकता है।

स्थिर identifiers दावों को जांचने योग्य बनाते हैं

निष्कर्ष में उस सबसे छोटी स्थिर इकाई का संदर्भ होना चाहिए जो उसे समर्थन देती है। एजेंट गतिविधि में आमतौर पर इसका मतलब एजेंट run के लिए session identifier और अलग कार्रवाई के लिए call identifier होता है। जब दोनों का संबंध मायने रखता हो, तो दोनों का उपयोग करें।

Session identifier का जवाब है, «हम किस एजेंट प्रोसेस run की बात कर रहे हैं?» Call identifier का जवाब है, «उस run के अंदर कौन-सा खास HTTP या SSH action इस दावे को समर्थन देता है?» अपने आप में कोई identifier कुछ साबित नहीं करता। वे टिकाऊ पते हैं। प्रमाण उस पते पर मौजूद सुरक्षित रिकॉर्ड से आता है, साथ में आपकी यह व्याख्या कि उसमें क्या लिखा है।

जब सिस्टम पहले से identifier देता हो तो अपना सुविधाजनक identifier scheme न बनाएं। विश्लेषक कभी-कभी «approval के बाद तीसरी request» या «14:00 के आसपास वाली request» जैसे संदर्भ लिखते हैं। ये वाक्य पाठक की मदद कर सकते हैं, लेकिन citation के रूप में असफल होते हैं। View filter होने पर timeline बदल जाती है, घड़ियों में अंतर हो सकता है और बाद के records से «तीसरा» अस्पष्ट हो सकता है। दिए गए session और call IDs sorting, export और handoff में गद्य के शॉर्टकट से बेहतर टिकते हैं।

अलग case file में claim table इस्तेमाल करें। इसके लिए case-management product जरूरी नहीं है। साधारण structured document पर्याप्त है, अगर वह claim और citation के अंतर को बनाए रखे।

यह तालिका दो उपयोगी काम करती है। पहला, यह citation को explanation समझ लिए जाने से रोकती है। दूसरा, यह किसी आकर्षक कहानी को असमर्थित चिन्हित करने देती है, बिना उसे मिटाए। जब case तनावपूर्ण हो तो यह मायने रखता है। लोग अक्सर असफल सिद्धांत हटा देते हैं और बाद में यह नहीं बता पाते कि टीम ने उन्हें क्यों खारिज किया।

बिल्कुल वही identifiers इस्तेमाल करें जो स्रोत दिखाता है। उनके format, length या documented scope से परे global uniqueness की कल्पना न करें। अगर identifier सिर्फ एक collected journal में अर्थपूर्ण है, तो उसके साथ journal या evidence-package identifier भी लिखें। Stable का अर्थ जादुई नहीं है। इसका अर्थ है कि दूसरा जांचकर्ता उसी सुरक्षित स्रोत के सामने उस संदर्भ को resolve कर सके।

पढ़ने योग्य export derivative है, रिकॉर्ड नहीं

अधिकतर जांचों को पढ़ने योग्य view चाहिए। एन्क्रिप्टेड bytes को घूरकर उनकी जांच नहीं की जा सकती और किसी को ऐसा दिखावा नहीं करना चाहिए। समीक्षा के लिए derivative बनाएं, लेकिन उस पर टिप्पणी शुरू करने से पहले स्रोत से उसका संबंध साफ करें।

Evidence register entry से शुरू करें। Case reference, मूल file या package name, उसे कब और कहां से इकट्ठा किया, किसने इकट्ठा किया, अगर पता हो तो session scope और verification result दर्ज करें। Verification में इस्तेमाल command भी जोड़ें और उसका terminal output case materials के साथ सुरक्षित रखें। अनुमान लगाकर खाली जगह न भरें। अगर collector या collection time नहीं पता है, तो «unknown» लिखें और प्रश्न खोलें।

Sallyport अपने Sessions और Activity journals को एक write-blind, encrypted, hash-chained audit log से बनाता है। इसके offline verifier को vault key की जरूरत नहीं होती, इसलिए जांचकर्ता किसी से पढ़ने योग्य सामग्री दिखाने को कहने से पहले सुरक्षित एन्क्रिप्टेड material verify कर सकता है:

sp audit verify <preserved-audit-record>

Evidence register में वास्तविक command, उसके arguments, exit status और पूरा output दर्ज करें। किसी report में काल्पनिक success line न लिखें क्योंकि command «चल जानी चाहिए थी»। Output verification event का हिस्सा है। अगर verification विफल हो जाए तो बाद की व्याख्याओं को स्थापित साक्ष्य मानना बंद करें। विफल result सुरक्षित रखें, संभव हो तो अक्षुण्ण source फिर से इकट्ठा करें और बाद के export को चुपचाप रखने के बजाय टूटने का कारण बताएं।

फिर review derivative को ऐसे नाम से बनाएं जिससे पता चले कि वह क्या है। उदाहरण के लिए:

case-2026-041/
  original/
    audit-record.enc
  verification/
    verify-command.txt
    verify-output.txt
  derivatives/
    activity-readable-2026-07-24.json
  notes/
    findings.md
    claim-table.md

Folder names अपने आप में chain of custody नहीं हैं। वे उपयोगी आदत बनाते हैं: originals, verification material, readable derivatives और analysis एक ही वैचारिक bucket में नहीं रहते। Original directory पर write access सीमित रखें। अगर आपके storage controls ऐसा नहीं कर सकते, तो जहां आपकी evidence process अनुमति दे वहां digest की गणना कर दर्ज करें, फिर analysis के लिए नई working copy बनाएं। उद्देश्य है कि अनजाने edits साफ दिखें और recovery संभव रहे।

बदली हुई file को «raw» सिर्फ इसलिए न कहें कि आपने text को हाथ से नहीं बदला। जो tool decrypt, parse, filter, pretty print, time zones normalize या fields हटाता है, उसने representation बदल दिया है। यह transformation पूरी तरह वैध हो सकती है। उसका नाम लें।

Records को दोबारा serialize करने से ऐसे विवाद पैदा होते हैं जिन्हें आप नहीं जीत सकते

Reserialization का अर्थ structured content को decode करके फिर से लिखना है। जांचकर्ता ऐसा तब करते हैं जब वे JSON दोबारा format करते हैं, spreadsheet save करते हैं, report फिर से बनाते हैं या data को ऐसे parser से भेजते हैं जो अपने हिसाब से field order और escaping चुनता है। यह हानिरहित लगता है क्योंकि semantic content एक जैसा दिख सकता है। चुनौती दी गई जांच में «एक जैसा दिखता है» बेहद खराब मानक है।

मान लें कि कोई विश्लेषक activity को JSON में export करता है, calls को local display time से sort करता है, reviewed: true field जोड़ता है और file को audit-final.json के रूप में सहेज देता है। बाद में reviewer देखता है कि दो events का displayed second एक ही है, लेकिन उनका मूल क्रम महत्वपूर्ण है। अब export reviewer को यह नहीं बताता कि sorting ने source order बनाए रखा या नहीं। Parsing के दौरान त्रुटि हुई हो तो बदली हुई file उसे छिपा सकती है। अब विश्लेषक को सुरक्षित रिकॉर्ड की ओर इशारा करने के बजाय toolchain और workflow का बचाव करना पड़ता है।

एक और आम विफलता replacement के जरिए redaction है। कोई credential जैसा दिखने वाला value बदलकर REDACTED कर देता है और फिर edited record को evidence के रूप में फैलाता है। इससे दो समस्याएं पैदा होती हैं। Value शायद credential था ही नहीं, और जब तक टीम हर बदलाव का दस्तावेजीकरण न करे, review copy मूल से अज्ञात positions पर अलग है। Sharing के लिए copy redact करें, उसे redacted derivative का label दें और source को उचित access controls के तहत रखें।

मानवीय notes भी अनजाने में evidence को reserialize कर सकते हैं। Ticket में चिपकाया request body escaping, whitespace, order या nonprinting characters खो सकता है। Screenshot visible pane के बाहर की सामग्री छिपा सकता है। Report का quotation response छोड़ सकता है जो request का अर्थ बदल देता है। पहले call ID का संदर्भ दें। निष्कर्ष समझाने के लिए जितना जरूरी हो उतना ही text quote करें और बताएं कि quotation readable derivative से लिया गया है।

अच्छी case file transformations को ऐसे गद्य में दर्ज करती है जिसे दूसरा व्यक्ति जांच सके। उदाहरण: «D-03 को original O-01 से सफल offline verification के बाद बनाया गया। Export process ने समीक्षा के लिए record डिक्रिप्ट किया, view को session s-7f31 तक सीमित किया और O-01 को overwrite नहीं किया।» अगर filter किया है, तो बताएं। Time zones normalize किए हैं, तो बताएं। Tool ने fields हटाए हैं, तो बताएं। चुप्पी वहीं है जहां अनजाने evidence laundering छिपती है।

Approval records दावे को सीमित करते हैं, उसका अर्थ तय नहीं करते

Approval record लोगों की इच्छा से कहीं अधिक संकीर्ण बात साबित करता है। यह दिखा सकता है कि किसी व्यक्ति ने एक खास एजेंट प्रोसेस run मंजूर किया या per-call control के तहत credential use मंजूर किया। इससे यह साबित नहीं होता कि व्यक्ति ने हर proposed action पढ़ा, हर परिणाम समझा या हुए business change का इरादा रखा।

यह सीमा तब महत्वपूर्ण होती है जब जांच एक असहज प्रश्न तक पहुंचती है: «क्या user ने इसे authorize किया था?» इसका उत्तर एक शब्द में न दें। कथन को हिस्सों में बांटें। User ने उस session में process को काम करने की अनुमति दी हो सकती है। Process ने बाद में credential इस्तेमाल किया हो सकता है। Request सफल हुई हो सकती है। फिर भी हुई कार्रवाई उस दायरे से बाहर हो सकती है जिसे व्यक्ति अनुमति दे रहा समझ रहा था। Evidence इनमें से कुछ बातों को समर्थन दे सकता है और कुछ को खुला छोड़ सकता है।

Sallyport की decision ladder इन अंतरों को ठोस बनाती है। Locked vault हर action रोक देता है। Default रूप से enabled per-session authorization, नए दिखने वाले agent process run को उसके समाप्त होने तक मंजूर करती है। Per-call key setting उस credential के हर उपयोग के लिए approval मांगती है। जांच में पहचानें कि कौन-सा control लागू था, फिर केवल वही बताएं जो वह control स्थापित करता है।

निष्कर्ष ऐसे लिखें कि यह सीमा दिखे। «Evidence दिखाता है कि user ने session s-7f31 के लिए signed process मंजूर किया» session authorization के बारे में दावा है। «Evidence दिखाता है कि user ने call c-205 मंजूर किया» के लिए उस call का per-call approval record चाहिए। «User का इरादा payment record बदलने का था» के लिए intent संबंधी evidence चाहिए, जो शायद action journal के बाहर हो। सुविधा के लिए पहले वाक्य को तीसरे वाक्य में न बदलें।

यहीं पर विश्लेषक अक्सर एक ऐसी सलाह देते हैं जिसे मैं खारिज करता हूं: हर approval को informed consent का समान evidence मानें। यह इसलिए लोकप्रिय है क्योंकि इससे सरल verdict मिलता है। यह गलत है क्योंकि controls के scope अलग होते हैं। Run-level approval और action-level approval अलग प्रश्नों के जवाब देते हैं और इनमें से कोई भी किसी व्यक्ति का मन नहीं पढ़ता।

ऐसे notes बनाएं जो case को दूषित किए बिना बदल सकें

आपके notes में सुधार की गुंजाइश होनी चाहिए और लेखक व समय साफ दिखना चाहिए। अच्छे finding में claim, reason, citations, limits और disposition होते हैं। इसके लिए नाटकीय कहानी कहने की जरूरत नहीं।

इस तरह का format इस्तेमाल करें:

Finding: एजेंट ने session approval के बाद payment API को call किया।

Claim: Session s-7f31 में payment API के लिए credentialed HTTP call शामिल था।
Evidence: Session s-7f31; call c-205; derivative D-03.
Reasoning: Call record configured HTTP channel और record में दर्शाए गए destination की पहचान करता है।
Limits: यह record व्यक्ति के business intent या पूरे downstream effect को स्थापित नहीं करता।
Analyst: initials
Recorded: 2026-07-24T18:32:00Z
Status: supported

«Reasoning» शब्द का यहां अपना स्थान है। IDs की सूची finding नहीं होती। जो संबंध आप infer करते हैं, उसे बताएं और यह भी लिखें कि रिकॉर्ड क्या स्थापित नहीं कर सकता। जब finding की सीमा साफ लिखी होती है, तो पाठक उस पर अधिक भरोसा करते हैं।

Mutable personal annotations को evidence filenames या object metadata में न डालें। bad-call-confirmed.enc जैसा filename राय को source truth जैसा दिखाने लगता है। O-01-audit-record.enc जैसे neutral evidence names इस्तेमाल करें और राय को F-04-findings.md में रखें। जब दूसरी समीक्षा के बाद «confirmed», «not supported» हो जाए, तो इससे परेशानी बचती है।

Notes में observations और conclusions अलग रखें। Observation हो सकता है, «c-205 के activity record में successful response दर्ज है।» Conclusion हो सकता है, «एजेंट ने शायद मांगी गई कार्रवाई पूरी की।» पहला रिकॉर्ड की सामग्री पर निर्भर है। दूसरा इस बात पर निर्भर है कि उस API के लिए successful response का मतलब क्या है और इसके लिए API documentation या स्वतंत्र system record चाहिए हो सकता है। यह सीमा चिन्हित करने से विश्लेषक कथित तथ्य में व्याख्या छिपाकर नहीं डाल पाते।

अगर case पर कई लोग काम कर रहे हैं, तो उन्हें notes में असहमत होने दें। हर प्रतिस्पर्धी conclusion को claim ID और evidence references दें। असहमति को फीके consensus sentence में न मिलाएं। बाद के reviewer को दिखना चाहिए कि evidence ने विवाद सुलझाया या टीम ने बस उस पर चर्चा बंद कर दी।

असफल timeline अक्सर एक मामूली edit से शुरू होती है

ऐसी incident पर विचार करें जिसमें coding agent किसी internal deployment API तक पहुंचता है। Operator को अपरिचित बदलाव दिखता है और वह activity journal को spreadsheet में export करता है। पढ़ने में आसान बनाने के लिए operator rows को local time से sort करता है, दोहराव वाले दिखने वाले fields हटा देता है और कारण मानी जा रही row को रंग देता है। फिर वह टिप्पणी जोड़ता है, «Agent ने unapproved configuration deploy किया», और workbook response team को भेज देता है।

पहली समस्या तब आती है जब दूसरा विश्लेषक पूछता है कि call किस process ने की थी। Spreadsheet में call ID है, लेकिन session ID column हटाए गए «दोहराव वाले» fields में से एक था। Team जल्दी से एक run को दूसरे से अलग नहीं कर पाती। Operator को याद है कि सभी rows उसी run से थीं, लेकिन याद citation नहीं है।

दूसरी समस्या तब आती है जब team action की तुलना approval से करती है। Workbook में पास का approval time दिखता है, लेकिन उसमें इतना संदर्भ सुरक्षित नहीं है कि यह तय हो सके approval run पर लागू था या उस अलग credential use पर। टिप्पणी पहले ही चर्चा को प्रभावित कर चुकी है, इसलिए लोग पहले यह पूछने के बजाय कि evidence किस प्रकार का approval रिकॉर्ड करता है, इस पर बहस करने लगते हैं कि action unapproved था या नहीं।

तीसरी समस्या तब आती है जब deployment team कहती है कि API response का अर्थ «processing के लिए accepted» था, «configuration deployed» नहीं। रंगी हुई row वास्तविक थी। निष्कर्ष बहुत व्यापक था। Operator ने उसे दिखने में evidence artifact के भीतर रखा था, इसलिए पाठकों ने उसे रिकॉर्ड की विशेषता माना, एक त्रुटि-संभव व्याख्या नहीं।

साफ पुनर्निर्माण अलग दिखता है। एन्क्रिप्टेड audit record को O-01 के रूप में सुरक्षित रखें। O-01 पर sp audit verify चलाएं और command result सहेजें। D-01 को readable view के रूप में बनाएं। Case file में तीन अलग दावे लिखें: किस session ने कौन-सी call की, कौन-सा approval scope लागू होता है और response क्या स्थापित करता है। तीसरे दावे के लिए deployment-system record चाहिए हो सकता है। अगर वह अनसुलझा रहे, तो उसे अनसुलझा रहने दें। यह अधूरी जांच नहीं, ईमानदार जांच है।

इस case को बचाने वाला विवरण नीरस है: call c-205, call c-205 के बारे में लिखे वाक्य के समान नहीं है। पहला सुरक्षित activity का reference है। दूसरा ऐसा निष्कर्ष है जिसका लेखक, तारीख और गलत होने की संभावना है।

व्याख्या पक्की होने से पहले verification होना चाहिए

Team के उसके इर्द-गिर्द कहानी बनाने से पहले सुरक्षित audit material सत्यापित करें। कोई सिद्धांत chat, tickets और meetings में फैलने के बाद लोग records को उसका बचाव करने के लिए पढ़ने लगते हैं। तब verification उस निष्कर्ष के सामाजिक महत्व पा लेने के बाद किया जाने वाला अनुष्ठान बन जाता है।

क्रम सरल होना चाहिए। Source को बदले बिना इकट्ठा करें। लिखें कि वह कहां से आया और किसने संभाला। Supported offline command से एन्क्रिप्टेड material verify करें। Verification result सुरक्षित रखें। उसके बाद ही labeled readable derivative बनाएं। फिर claim table और notes शुरू करें।

Hash-chain verification खास तौर पर उपयोगी है क्योंकि वह vault key के बिना stored encrypted record की जांच करता है। इससे दो प्रश्न अलग होते हैं जिन्हें लोग अक्सर मिला देते हैं: «क्या रिकॉर्ड ने अपनी chain integrity बनाए रखी है?» और «संवेदनशील contents पढ़ने की अनुमति किसे है?» जांचकर्ता बुनियादी integrity check के लिए secrets तक पहुंच बढ़ाए बिना पहले प्रश्न का उत्तर दे सकता है।

सफल verification result source identity, collected range के बाहर की completeness या interpretation तय नहीं करता। इसका अर्थ बस इतना है कि verifier ने उसके सामने प्रस्तुत chain स्वीकार की। आपने वास्तव में जो scope इकट्ठा किया है, उसे दर्ज करें। अगर case पहले retained session से पहले suspected gap से जुड़ा है, तो «audit में पहले की कोई कार्रवाई नहीं दिखती» न लिखें, जब तक आपको पता न हो कि collection में प्रासंगिक पुराना history है। बचाव योग्य वाक्य अधिक संकीर्ण है: «इकट्ठे किए गए रिकॉर्ड में इस प्रकार की पहले की कोई कार्रवाई नहीं है।»

वही अनुशासन revocation पर भी लागू होता है। Journal में कोई session revoked हो सकता है, लेकिन वह record control event और उसके दर्ज scope का वर्णन करता है। यह अपने आप नहीं बताता कि revocation से पहले पूरी हुई actions, external service द्वारा पहले ही स्वीकार किया गया काम या channel response के बाहर के side effects क्या हुए। हर कथन को उस record से जोड़ें जो उसे समर्थन दे सकता है।

Case file को review में रखें, source को revision में नहीं

Evidence स्थिर रहना चाहिए। Findings की समीक्षा होनी चाहिए। Reviewers से हर conclusion और उसके cited session या call के बीच का संबंध चुनौती देने को कहें, न कि उनसे बदले हुए export के अनकहे versions की तुलना कराएं।

उपयोगी review pass चार सीधे प्रश्न पूछता है:

1. क्या मैं हर cited session और call को सुरक्षित रिकॉर्ड या documented derivative में ढूंढ सकता हूं?
2. क्या finding दर्ज event और विश्लेषक के inference में अंतर करती है?
3. क्या बताया गया approval scope निकाले जा रहे conclusion से मेल खाता है?
4. क्या लेखक ने उस transformation, filter, redaction या missing context का नाम लिया है जो इस claim को प्रभावित करता है?

अगर reviewer इनमें से किसी प्रश्न का उत्तर नहीं दे सकता, तो सुधार case file में होना चाहिए, सिवाय उस स्थिति के जब सुरक्षित source ही गलत ढंग से इकट्ठा किया गया हो। Derivative को तब तक patch न करें जब तक वह मनचाही कहानी जैसा न लगने लगे। Derivative process सही करें, नया labeled derivative बनाएं और अगर पुराने ने किसी महत्वपूर्ण finding को प्रभावित किया हो तो उसे बनाए रखें।

Sallyport इस्तेमाल करने वाली teams के लिए Sessions journal और Activity journal जांचकर्ताओं को दो स्वाभाविक citation levels देते हैं, जबकि instant session revocation एक अलग control event देता है जिसकी जांच की जा सकती है। इन records को anchor की तरह इस्तेमाल करें, analysis के विकल्प की तरह नहीं। Journal आपको बता सकता है कि उसने क्या दर्ज किया। Case file को बताना चाहिए कि team उससे जिम्मेदारी से क्या निष्कर्ष निकाल सकती है।

Collection के बाद पहली कार्रवाई साधारण और सटीक होनी चाहिए: original आरक्षित रखें, उसे verify करें और उसके पास खाली findings file खोलें। पहला conclusion तभी लिखें जब आप उसे समर्थन देने वाले session और call का संदर्भ दे सकें। अनुशासन की यह छोटी-सी आदत इस बात पर महीनों की बहस रोकती है कि जांच बदलने पर evidence बदला था या नहीं।