Memory không phải source of truth

Có một kiểu lỗi tôi gặp lặp đi lặp lại: mọi người trong cuộc đều nhớ rằng task đã xong. Chat nói đã deploy, handoff ghi production xanh, người vận hành cũng nhớ đã bấm nút. Nhưng edge vẫn trả artifact cũ.

Một lỗi thật: đúng trong chat, sai ở production

Trong lần gom GreenJade về monorepo, code mới đã build, commit đã push lên main và mọi người đều có lý do để nghĩ bước tiếp theo là Cloudflare tự deploy. Đó là flow từng hoạt động trước đây.

Nhưng Cloudflare Pages vẫn kết nối với repository Astro cũ. Push vào monorepo mới không thể làm production thay đổi. Intention đúng, code đúng và ký ức về pipeline cũng từng đúng. Chỉ có trạng thái hiện tại là khác.

Nếu hỏi “chúng ta định deploy từ đâu?”, câu trả lời nằm trong plan. Nếu hỏi “code mới đang ở đâu?”, câu trả lời nằm trong Git. Nếu hỏi “production đang lấy source nào?”, chỉ cấu hình Cloudflare hiện tại mới trả lời được.

- memory: push main sẽ tự deploy
+ repo: commit mới đã có trên main
+ Cloudflare: vẫn nối repository cũ
+ edge: vẫn phục vụ artifact cũ

Memory không vô dụng. Nó giúp tôi biết nên kiểm tra Git integration. Nhưng nếu biến memory thành bằng chứng, chính kinh nghiệm cũ sẽ che mất sự thật mới.

Ký ức là tái tạo, không phải playback

Trong thí nghiệm kinh điển của Elizabeth Loftus và John Palmer, cách đặt câu hỏi sau khi người tham gia xem cảnh va chạm có thể ảnh hưởng đến ước lượng tốc độ và báo cáo ký ức sau đó. Nghiên cứu này không chứng minh mọi ký ức đều sai. Nó cho thấy thông tin đến sau sự kiện có thể tham gia vào cách ký ức được báo cáo lại.

Điều này quan trọng với operation vì handoff, issue title và lời giải thích của người trước đều là thông tin đến sau. Một câu “đã deploy xong” có thể trở thành frame cho lần kiểm tra tiếp theo. Ta bắt đầu tìm bằng chứng rằng deploy đã xong thay vì hỏi trạng thái hiện tại là gì.

Đây là lúc confidence trở nên nguy hiểm. Nhớ rõ không đồng nghĩa với nhớ đúng. Một narrative mạch lạc cũng không đồng nghĩa với một causal chain đã được kiểm chứng.

Ta suy nghĩ bằng thứ nằm ngoài đầu

Jiajie Zhang và Donald Norman mô tả distributed cognitive task như một hệ gồm internal representation và external representation cùng tham gia biểu diễn cấu trúc của công việc. David Kirsh đi xa hơn: external representation không chỉ giảm gánh nặng ghi nhớ, nó còn tạo persistent referent, giúp chia sẻ object of thought, tái biểu diễn vấn đề và thay đổi chi phí của suy luận.

Trong software operation, repo, diff, deployment ID, dashboard, config và runbook không chỉ là nơi “ghi chép lại”. Chúng là một phần của hệ nhận thức đang vận hành task.

External representation	Nó giúp ta nghĩ gì	Nó không tự chứng minh gì
Git diff	Thay đổi dự kiến và phạm vi patch	Binary đó đã chạy ở production
Deployment record	Commit nào được platform nhận	Custom domain đã phục vụ đúng content
Runbook	Flow chuẩn và điểm kiểm tra	Flow hiện tại chưa drift
Log	Sự kiện được ghi tại một thời điểm	Không có lỗi ngoài vùng log
Handoff	Nơi nên bắt đầu điều tra	Mọi claim bên trong đều còn đúng

Thiết kế external representation tốt không phải viết nhiều tài liệu hơn. Nó là làm cho trạng thái quan trọng có nơi tồn tại bền, có timestamp, có identity và có thể đối chiếu.

AI memory cũng không phải runtime

Không nên nói AI “nhớ sai” theo đúng nghĩa con người nhớ sai. Cơ chế khác nhau. Một model tạo output từ context nó đang nhận; một lớp memory hoặc summary chỉ đưa thêm representation vào context đó. Nó không tự trở thành sensor nối với process, database hay CDN.

Vì vậy một summary có thể hoàn toàn trung thực ở thời điểm được viết nhưng stale sau một deploy. Nó cũng có thể nén mất điều kiện, biến “local build pass” thành “đã xong” hoặc giữ conclusion mà bỏ evidence.

Tôi dùng memory của agent như một index:

Nó chỉ ra repo, file, command hoặc incident cần xem.
Nó giữ vocabulary và decision từng được chốt.
Nó giảm thời gian tìm lại context.

Tôi không dùng nó như attestation rằng production đang đúng. Attestation phải đến từ probe hiện tại.

$ resume-task --from memory
INDEX expected repo and deployment path found
VERIFY worktree, remote HEAD, runtime and edge
UPDATE external record after evidence agrees

Source of truth phụ thuộc câu hỏi

Không có một thứ luôn đứng đầu cho mọi câu hỏi. Repo là source of truth của code được version. Nó không phải source of truth của process đang chạy. Runtime cho biết process hiện tại, nhưng không nói đầy đủ intention ban đầu. Decision log giữ lý do, không giữ live state.

Câu hỏi	Nguồn ưu tiên	Nguồn chỉ dùng làm chỉ dẫn
Code nào đã được commit?	Git object và remote ref	Chat, handoff
Config nào đang active?	Live config hoặc platform setting	Config mẫu trong repo
Process nào đang chạy?	Process manager, health endpoint, service state	Deploy script
Người dùng đang nhận gì?	Edge response, API result, asset hash	Dashboard success
Vì sao quyết định này được chọn?	Decision record kèm evidence	Hồi tưởng của người tham gia

Source-of-truth thinking bắt đầu bằng việc viết đúng câu hỏi. Nếu không, ta thường lấy nguồn dễ đọc nhất thay cho nguồn có authority đúng nhất.

Từ nhớ lại sang verification loop

Roediger và Karpicke cho thấy retrieval practice có thể cải thiện long-term retention tốt hơn việc chỉ đọc lại trong điều kiện thí nghiệm của họ. Tôi không dùng kết quả này để nói một lệnh health check sẽ cải thiện trí nhớ. Phép nối thực dụng là: đừng chỉ đọc lại narrative, hãy buộc claim đi qua một lần retrieval và test.

Verification loop của tôi có năm bước:

Recall: viết claim hiện tại bằng một câu, không mở tài liệu.
Locate: xác định external representation có authority cho câu hỏi.
Probe: chạy kiểm tra read-only rẻ nhất có thể phủ định claim.
Compare: tách expected, observed và inference.
Update: chỉ cập nhật memory hoặc handoff sau khi evidence khớp.

claim: production đang chạy commit mới
expected: deployment source = current HEAD
observed: edge marker = old artifact
inference: pipeline hoặc alias chưa cập nhật
next probe: deployment source + custom-domain alias

Cấu trúc này ngăn một lỗi phổ biến: đổi claim ngay khi thấy một evidence thuận chiều. Ta giữ observation riêng cho đến khi causal chain đủ rõ.

Brainstorm mà không tự lừa mình

Brainstorm cần quyền được sai. Operation cần biết cái gì đang đúng. Trộn hai mode này vào cùng một tài liệu sẽ khiến giả thuyết dần biến thành “quyết định đã chốt” chỉ vì nó được đọc lại nhiều lần.

Tôi chia note thành ba nhãn:

Hypothesis: một giải thích có thể đúng, chưa có authority.
Observation: thứ đã thấy, kèm nguồn và thời điểm.
Decision: lựa chọn của owner, kèm lý do và điều kiện xem lại.

Nội dung	Nhãn đúng	Lỗi nếu ghi sai nhãn
“Có thể webhook chưa chạy”	Hypothesis	Bắt đầu sửa webhook khi lỗi nằm ở repository connection
“Edge trả hash cũ lúc 10:42”	Observation	Biến một sample thành kết luận về toàn CDN
“Chuyển source sang monorepo”	Decision	Agent tự coi suggestion là authority

Meta-thinking có ích ở đây vì nó giúp ta nhìn cách một ý nghĩ đổi status trong hệ thống, không chỉ nhìn nội dung của ý nghĩ.

Playbook phục hồi execution truth

Khi mở lại một task cũ, nhận handoff từ người khác hoặc cho AI resume qua session, tôi dùng checklist này:

Đọc summary để lập bản đồ, không để kết luận của summary khóa hướng điều tra.
Xác định câu hỏi đang cần current state, intention hay history.
Kiểm tra worktree, remote ref và artifact trước khi sửa gì.
Kiểm tra runtime hoặc edge nếu claim liên quan production.
Giữ hypothesis, observation và decision thành ba lớp riêng.
Đặt timestamp cho evidence dễ stale.
Cập nhật handoff bằng claim có thể tái kiểm tra, không dùng “looks good”.

Tài liệu tham khảo

Đây là các nguồn cho phần cognitive science. Source-of-truth ladder và verification loop là framework vận hành tôi rút ra từ trải nghiệm làm việc với repo, runtime và agent, không phải kết luận trực tiếp của bốn nghiên cứu trên.