Verification Workflow និង Audit Trail
ការនិយាយថា “ខ្ញុំបានពិនិត្យរួច” មិនទាន់គ្រប់គ្រាន់ទេ។ ការផ្ទៀងផ្ទាត់ដែលអាចទុកចិត្តបាន ត្រូវបង្ហាញ Exact Claim, Evidence, វិធីតេស្ត, អ្នកសម្រេច, Version និងពេលត្រូវពិនិត្យឡើងវិញ។

- ពន្យល់ភាពខុសគ្នារវាង Activity log និង Audit trail ដែលអាចការពារសេចក្ដីសម្រេចបាន។
- Freeze Input/Output និងScope មុនចាប់ផ្តើមពិនិត្យ ដើម្បីកុំឱ្យVersion ផ្លាស់ទីស្ងាត់ៗ។
- បង្កើត Claim-Evidence Ledger ដែលមាន ID, Locator, Date, Test និងStatus។
- កត់ Decision, Rationale, Owner, Reviewer និងResidual uncertainty ដោយមិនលុបប្រវត្តិ។
- រៀប Verification Packet សម្រាប់ Handoff, Reproduction និងReview លើកក្រោយ។
១. Verification Workflow និង Audit Trail ជាអ្វី?
Verification Workflow គឺជាលំដាប់ការងារដែលកំណត់ថា ត្រូវទទួលចម្លើយ បំបែក Claims ស្វែងEvidence តេស្ត និងសម្រេចយ៉ាងដូចម្តេច។ Audit Trail គឺជាកំណត់ត្រាដែលរក្សាភស្តុតាងពីដំណើរនោះ ដើម្បីឱ្យអ្នកផ្សេងអាចតាមសំណួរ៖ “បានពិនិត្យអ្វី? ប្រើអ្វី? ពេលណា? ដោយអ្នកណា? ហេតុអ្វីបានសម្រេចបែបនេះ?”
ហេតុអ្វីសំខាន់៖ ប្រភពអាចកែ ឬលុប, AI output អាចខុសគ្នាពេលGenerate ថ្មី ហើយអ្នកសម្រេចអាចផ្លាស់ប្តូរ។ Audit trail រក្សាបរិបទមិនឱ្យពាក្យ “Verified” ក្លាយជាស្លាកគ្មានEvidence។

២. Freeze Intake និងScope មុនពិនិត្យ
Freeze មានន័យថារក្សាទុកសំណុំដែលកំពុងពិនិត្យ មិនមែនបិទការកែប្រែជារៀងរហូតទេ។ កត់សំណួរដើម, AI answer ទាំងមូល, ថ្ងៃ/ម៉ោង, Tool ឬModel/Version ប្រសិនបើដឹង, អ្នកស្នើ, សេចក្ដីសម្រេចដែលត្រូវធ្វើ, Stakes និងDeadline។ បើOutput ផ្លាស់ប្តូរ ត្រូវបង្កើត Version ថ្មី មិនត្រូវសរសេរជាន់ចាស់។
| Intake field | សំណួរត្រូវកត់ | ហេតុផល |
|---|---|---|
| Object | Prompt និងOutput មួយណាពិតប្រាកដ? | កុំឱ្យពិនិត្យចម្លើយមួយ តែប្រើចម្លើយថ្មីពេលសម្រេច |
| Decision | Accept, Publish, Act, Revise ឬReject? | កម្រិតEvidence ត្រូវស្របនឹងការប្រើ |
| Stakes | កំហុសអាចប៉ះពាល់ពេលវេលា លុយ សុខភាព ឬកេរ្តិ៍ឈ្មោះ? | កំណត់ជម្រៅពិនិត្យ និងReviewer |
| Scope | តើអ្វីនៅក្នុង/ក្រៅការពិនិត្យ? | កុំឱ្យស្លាក Verified លាតសន្ធឹងហួសអ្វីបានតេស្ត |
| Time/Version | ពេលណា និងVersion អ្វី? | ចំណេះដឹង និងទិន្នន័យអាចហួសសុពលភាព |
ឧទាហរណ៍ ៣ បរិបទ
៣. Claim-Evidence Ledger៖ បេះដូងនៃ Traceability
ផ្ដល់ ID ដល់Claim អាតូមិកនីមួយៗ ដូចជា C-01, C-02។ សម្រាប់Claim មួយ កត់ Type, Risk, Evidence, Exact locator, Date/Version, Test និងStatus។ Locator គឺទីតាំងជាក់លាក់—Section, page, paragraph, table cell, timecode ឬdataset field—not Homepage ទូទៅ។
| Field | ឧទាហរណ៍កំណត់ត្រា |
|---|---|
| Claim ID + Exact text | C-03 — “Policy នេះចាប់ផ្តើមថ្ងៃទី…” |
| Type + Risk | Date/Policy; High ព្រោះប៉ះDeadline |
| Source + Locator | ឯកសារផ្លូវការ, Section 4.2, page 7 |
| Date + Version | Published/updated date និងdocument version |
| Test | ឆ្លងពិនិត្យeffective date, exception និងsource authority |
| Status | Supported / Contradicted / Unclear / Not checked |

៤. Decision Log និងChange Control
Evidence មិនសម្រេចដោយខ្លួនឯងទេ។ Decision log ត្រូវកត់ Accept, Revise, Reject ឬHold, ហេតុផល, Claims សំខាន់, អ្នកទទួលខុសត្រូវ, Reviewer, Scope ដែលអនុញ្ញាតឱ្យប្រើ និងភាពមិនប្រាកដនៅសល់។ បើEvidence ថ្មីមកដល់ ត្រូវបង្កើតEntry ថ្មី ហើយសម្គាល់ចាស់ថា superseded មិនត្រូវលុបស្ងាត់ៗ។
Accept = Core claims supported និងRisk controls គ្រប់។ Revise = ចំណុចខ្វះអាចកែដោយEvidence/Context។ Reject = Core claim ខុស ឬបង្កហានិភ័យ។ Hold = Evidence សំខាន់មិនទាន់មាន ហើយមិនគួរស្មានបំពេញ។
Interactive Audit Record Builder
ប្រើClaim សាកល្បងដែលគ្មានទិន្នន័យផ្ទាល់ខ្លួន ឬSecret។ Lab នឹងបង្កើតកំណត់ត្រា និងFlag ផ្នែកដែលមិនទាន់គ្រប់។
៥. Reproducibility, Handoff និងIndependent Review
Minimum Reproducibility Packet គួរមាន frozen prompt/output, claim ledger, evidence copies/locators, calculations ឬtest steps, decision log, owner/reviewer, tool/model/version ប្រសិនបើស្គាល់ និងknown limits។ Handoff ល្អអនុញ្ញាតឱ្យមនុស្សថ្មីបន្តដោយមិនចាប់ផ្តើមពីសូន្យ និងមិនចាំបាច់ជឿតែអ្នកពិនិត្យដំបូង។
សម្រាប់High-risk decision គួរមាន Independent reviewer ដែលមិនមែនជាអ្នកបង្កើតចម្លើយ ឬអ្នកប្រមូលEvidence តែម្នាក់។ Reviewer ពិនិត្យCore claims, source fit, contradictions, decision rule និងថាScope “Verified” មិនធំជាងអ្វីបានតេស្ត។
កំហុសញឹកញាប់ និងវិធីកែ
៦. Workflow អនុវត្តបានភ្លាមៗ ៦ ជំហាន
លំហាត់អនុវត្ត
AI សរសេរSummary នៃPolicy ថ្មីមាន Claims ៤។ រៀប Audit packet ឱ្យមិត្តរួមការងារអាចពិនិត្យបន្តបាន។
គំរូចម្លើយ/ពិនិត្យខ្លួនឯង
Freeze memo និងsource version; C-01–C-04; សម្រាប់Claim នីមួយៗកត់section/page, effective date, exception និងstatus។ Decision “Revise” ប្រសិនបើC-03 ខ្វះexception; កត់owner, independent reviewer និងreview trigger ពេលPolicy version ផ្លាស់ប្តូរ។
AI ផ្ដល់Gold setup មានEntry, Target និងStop។ សរសេរអ្វីត្រូវកត់ មុនយកទៅសិក្សា ឬសម្រេចដោយខ្លួនឯង។
គំរូចម្លើយ/ពិនិត្យខ្លួនឯង
កត់XAU/USD, broker/feed, timeframe, timestamp, raw prices, formula, spread/fee, assumptions, scenario, downside/invalidation និងថាprediction មិនមែនfact។ Recompute numbers, ពិនិត្យsource time alignment និងDecision “Hold” បើdata timestamp មិនដឹង។ គ្មានAudit trail ណាធានាចំណេញទេ។
ពិនិត្យការយល់ដឹង
Key Takeaways
- Workflow កំណត់លំដាប់ការងារ; Audit trail រក្សាភស្តុតាងពីការងារនោះ។
- Freeze Prompt/Output, Scope, Decision និងVersion មុនពិនិត្យ ដើម្បីកុំឱ្យTarget ផ្លាស់ទី។
- Claim-Evidence Ledger ត្រូវមានID, source, locator, date/version, test និងstatus។
- Activity log មិនជំនួសEvidence-to-Claim traceability បានទេ។
- Decision ត្រូវមានRationale, owner, reviewer, scope និងភាពមិនប្រាកដនៅសល់។
- កុំលុបEntry ចាស់; version និងmark superseded ដើម្បីរក្សាប្រវត្តិ។
- Archive ជាមួយReview trigger ធ្វើឱ្យVerification នៅតែមានប្រយោជន៍ពេលព័ត៌មានផ្លាស់ប្តូរ។
ប្រភពសម្រាប់រៀនបន្ថែម
កំពុងបង្កើតជំនាញ Verification Operations
បន្តអានគ្រប់ Checkpoint និងឆ្លើយQuiz ដើម្បីបើកMission Complete។
មេរៀនបន្ទាប់៖ «Capstone: AI Truth Lab»។
by 
