Trading Journal cho Setup #14

Trả lời ngắn: Trading Journal là hồ sơ có cấu trúc để tái dựng điều đã quan sát, rule được dùng và lý do setup kết thúc ở một trạng thái. Ba sheet liên kết giữ riêng dữ liệu gốc, kết quả suy ra và lịch sử chỉnh sửa, thay cho screenshot hoặc ghi chú rời.

Đọc xong, bạn sẽ hiểu:

• Vì sao journal cần một hợp đồng ghi dữ liệu cố định.
• Cách nối một candidate F02 với ba completed bar và một correction.
• Cách kiểm tra orphan, ID trùng, ô bắt buộc trống và evidence thiếu.

Lưu ý giáo dục: Toàn bộ timestamp, giá, mã và record trong bài là dữ liệu hư cấu. Bài chỉ hướng dẫn ghi bằng chứng nghiên cứu setup; không có lệnh, tài khoản, vốn hoặc đánh giá lợi nhuận.

1. Trading Journal không phải album screenshot

Hãy hình dung kho nhận ba kiện đồ. Nếu nhân viên chỉ chụp ảnh, tuần sau khó biết ảnh thuộc phiếu nào, nhận lúc mấy giờ và lỗi ở đâu. Phiếu nhập kho có mã cố định giải quyết việc đó: ảnh vẫn hữu ích, nhưng phải nối với hồ sơ.

Trading Journal trong bài cũng vậy. Nó là bộ record cho phép người khác — hoặc chính bạn sau vài tuần — tái dựng:

• candidate nào đang được xét;
• setup version nào áp dụng;
• từng completed bar có timestamp và close bao nhiêu;
• state được suy ra sau mỗi bar;
• evidence nằm ở đâu;
• lỗi nhập liệu nào đã được sửa, khi nào và vì sao.

CME Group gợi ý trade log nên giữ thời gian, lý do và chi tiết để xem lại. Bài này thu hẹp mục tiêu sang nghiên cứu setup-state, không biến journal thành bảng thành tích. CME Group — Keep a Trade Log

Ta tách ba loại thông tin:

• Raw field là dữ liệu quan sát trực tiếp, như event_time và close_raw.
• Derived field là kết quả suy ra bằng rule, như state_after = INVALID.
• Review note là nhận xét chủ quan, ví dụ “lúc đó tôi hơi vội”.

Nhận xét không được ghi đè close hoặc state. Câu chắc chắn đúng là: “Ba completed close của F02 có thể được kiểm lại từ record.” Câu chỉ đúng có điều kiện là: “Journal phản ánh đúng protocol”, vì còn phụ thuộc rule, nguồn và độ đầy đủ.

Suy luận sai thường gặp là: “Record rất đầy đủ nên setup chắc tốt.” Đầy đủ chỉ nói rằng quá trình có thể kiểm tra. Nó không chứng minh rule hợp lý hay kết quả tương lai.

2. Ba sheet liên kết thành Journal Record Contract

Hình 1 — Hợp đồng journal đi từ identity tới raw evidence, derived state và review mà không xóa lịch sử gốc.

Schema là danh sách cố định các cột, kiểu dữ liệu, giá trị được phép và ý nghĩa. Bản giải thích đi kèm gọi là data dictionary. Demo dùng schema TA-JOURNAL-v1 với ba sheet.

sample_log: một hàng cho mỗi candidate

Sheet này giữ identity và kết luận cuối. Một sample giống đầu hóa đơn: có mã riêng và sở hữu nhiều dòng chi tiết.

Stable ID là mã không đổi khi sort hoặc chèn hàng. S-FTV1-F02 vẫn là F02 dù nó chuyển từ dòng 2 xuống dòng 20. Không dùng row number làm ID.

bar_log: một hàng cho mỗi completed observation

Mỗi bar row là một dòng con của sample. Quan hệ này gọi là parent/child: parent S-FTV1-F02 có ba child B-F02-01, B-F02-02, B-F02-03.

Enum là danh sách nhãn được phép. State chỉ được là WAITING, VALID, INVALID, EXPIRED, UNAVAILABLE hoặc SKIP. Viết tự do như “invalid-ish” sẽ trả INVALID_ENUM, vì máy và người khác không thể diễn giải nhất quán.

change_log: một hàng cho mỗi thay đổi

Sheet này giữ version, deviation hoặc correction. Append-only correction nghĩa là thêm một hàng sửa đổi thay vì xóa giá trị cũ. Nó giống bút toán điều chỉnh: lịch sử vẫn còn, người đọc biết cái gì đổi và lý do.

Hình 2 — Một stable sample ID làm khóa nối ba quan sát và một correction thành cùng hồ sơ F02.

evidence_ref là mã trỏ tới bằng chứng gốc, cũng gọi là provenance — dấu vết cho biết giá trị đến từ đâu. Screenshot không timestamp, source và mã liên kết chưa đủ.

Mọi timestamp dùng YYYY-MM-DD HH:mm UTC. Giá trị thiếu phải ghi NA nếu schema cho phép; không để trống rồi bắt người sau đoán. Không đưa account ID, email, API key, token hoặc dữ liệu nhận diện cá nhân vào journal giáo dục.

3. Điền trọn hồ sơ F02

Journal này dùng batch FT-DEMO-M15-v1, setup INV-DEMO-M15-v1 và candidate F02 từ bài Forward Test. Hàng sample_log chính xác là:

Ba hàng bar_log:

Tái tính từ raw data: bar 1 close 101.4 chưa dưới 100 nên WAITING; bar 2 close 100.8 vẫn WAITING; bar 3 close 99.7 <100 nên terminal state là INVALID. Sau terminal bar 3 không được thêm bar mới cho sample này.

Giả sử logged_at của B2 được gõ 13:31 UTC, nhưng thời điểm capture đúng là 13:32 UTC. Không sửa event_time, close_raw hoặc giá trị cũ. Thêm vào change_log:

Hình 3 — Raw closes tái tạo được terminal state; correction C-0001 giữ nguyên dấu vết trước và sau.

Kết quả integrity là: một sample, ba linked bars, terminal bar 3, last state INVALID, orphan bars 0, duplicate IDs 0, blank required fields 0 và một append-only correction.

4. Sai lầm, giới hạn và rủi ro dữ liệu

Dùng số dòng làm ID

Sort sheet làm “sample dòng 7” chuyển chỗ, khiến child trỏ nhầm. Stable ID phải nằm trong chính record.

Để ô trống mơ hồ

Ô trống có thể là chưa nhập, không có dữ liệu hoặc không áp dụng. Dùng NA đúng policy; field bắt buộc trống trả MISSING_REQUIRED.

Có child nhưng không có parent

Nếu bar_log.sample_record_id không tồn tại trong sample_log, đó là ORPHAN_BAR. Dừng kiểm tra; không tự tạo parent giả.

Trùng ID rồi tự thêm hậu tố

Duplicate ID phải chặn import. Tự đổi B-F02-02 thành B-F02-02-copy che mất nguyên nhân trùng và có thể nối sai evidence.

Trộn timezone, đơn vị hoặc open bar

13:30 không ghi UTC có thể bị hiểu theo máy người mở file. Open bar còn thay đổi không được thay completed close.

Chỉ lưu screenshot

Ảnh có thể mất tên, bị crop hoặc hỏng đường dẫn. Nếu evidence thiếu hoặc hash/path không khớp, giữ record và gắn EVIDENCE_MISSING; không xóa row để bảng trông sạch.

Sửa đè lịch sử

Correction thiếu target, reason hoặc timestamp phải bị từ chối. Một journal không có change trail rất khó phân biệt dữ liệu ban đầu với dữ liệu đã sửa.

Ghi cảm nhận vào cột raw

“Nến nhìn yếu” không phải close_raw. Để nó trong review_note riêng, không dùng thay bằng chứng định lượng.

FINRA nhấn mạnh việc giữ hồ sơ quan trọng và lịch sử liên quan. Ta chỉ lấy nguyên tắc giữ record, không áp dụng hướng dẫn tài khoản hay thuế. FINRA — Importance of Investment Recordkeeping

Giới hạn lớn nhất: journal không sửa được protocol tệ, nguồn sai hoặc sample bị chọn thiên lệch. Nhập tay còn có rủi ro gõ nhầm; file đính kèm có thể mục theo thời gian. Vì vậy journal cần validation và backup, không chỉ cần nhiều cột.

5. Checklist kiểm tra trước khi khóa hồ sơ

1. Ghi schema_version = TA-JOURNAL-v1 và data dictionary.
2. Xác nhận mọi record_id, bar_record_id, change_id là duy nhất.
3. Kiểm tra mọi bar child có parent sample tồn tại.
4. Kiểm tra timestamp có ngày, giờ và UTC.
5. Đối chiếu close_raw với evidence_ref.
6. Chỉ dùng state trong enum đã khóa.
7. Tái tính state_after theo rule version, không theo trí nhớ.
8. Đối chiếu terminal_state, terminal_bar và bar cuối.
9. Không thêm observation sau terminal state.
10. Kiểm tra field bắt buộc; chỉ dùng NA nơi schema cho phép.
11. Ghi correction bằng hàng mới, đủ target, old/new, reason và changed_at.
12. Lưu export và backup không chứa secret hoặc thông tin tài khoản.

Referential integrity là điều kiện mọi child trỏ tới parent có thật. Reconciliation là phép đối chiếu tổng và trạng thái giữa các sheet. Với F02:

sample 1 = linked sample 1
terminal_bar 3 = linked bars 3 = last bar_no 3
terminal_state INVALID = last state_after INVALID

Dừng và review ngay khi gặp ORPHAN_BAR, duplicate ID, MISSING_REQUIRED, INVALID_ENUM hoặc correction thiếu lý do. Không “sửa cho chạy” nếu chưa biết nguyên nhân.

Schwab cũng đề cập notebook hoặc spreadsheet và việc xem lại journal định kỳ. Đây là gợi ý về phương tiện lưu và review, không phải chứng thực cho schema hư cấu của bài. Charles Schwab — 5 Elements of a Smart Trade Plan

6. Bài tập 15 phút với ba tab

Dùng Google Sheets hoặc LibreOffice Calc. Tạo ba tab sample_log, bar_log, change_log; không cần broker, order hoặc tiền.

1. Dán header và một hàng sample F02.
2. Dán ba bar rows theo đúng thứ tự.
3. Dán correction C-0001.
4. Sort bar_log ngược rồi xuôi để thấy stable ID vẫn nối đúng.
5. Dùng tìm kiếm hoặc lookup kiểm tra mọi sample_record_id có parent.
6. Lọc state ngoài enum và ô bắt buộc trống.
7. Đối chiếu terminal bar/state với bar cuối.
8. Export một bản CSV hoặc XLSX làm backup.

Mẫu đối chiếu đã điền

Nếu cố ý đổi parent của B3 thành S-MISSING, kết quả phải là ORPHAN_BAR, không phải tự tạo sample mới. Sau đó hoàn tác lỗi thử nghiệm và chạy reconciliation lần cuối.

7. Tổng kết: journal tốt phải tái dựng được

Năm ý chính

• Trading Journal là record contract, không chỉ là album screenshot.
• Ba sheet tách sample identity, bar evidence và change history.
• Stable ID nối parent/child dù sheet được sort hoặc chèn hàng.
• Raw data, derived state và subjective note phải nằm đúng lớp.
• Correction được append; lỗi integrity phải fail closed.

Câu hỏi tự kiểm tra

• Vì sao row number không phải stable ID?
• Từ ba close của F02, terminal state xuất hiện ở bar nào?
• Khi evidence file bị mất, có nên xóa record không?
• logged_at nhập sai được sửa như thế nào?

Gợi ý đáp án

Xem gợi ý câu 1

Row number đổi khi sort hoặc chèn hàng; stable ID nằm trong record và không đổi vị trí logic. → Xem mục 2.

Xem gợi ý câu 2

Bar 3, vì completed close 99.7 nhỏ hơn 100 nên state chuyển sang INVALID và sample kết thúc. → Xem mục 3.

Xem gợi ý câu 3

Không. Giữ row, gắn EVIDENCE_MISSING và dừng review để bảo toàn lịch sử. → Xem mục 4.

Xem gợi ý câu 4

Thêm correction C-0001 với target, old/new value, reason và changed_at; không sửa đè raw history. → Xem mục 3.

Thuật ngữ cần nhớ

Nguồn tham khảo

• CME Group — Keep a Trade Log
• CME Group — Building a Trade Plan
• FINRA — Importance of Investment Recordkeeping
• Charles Schwab — 5 Elements of a Smart Trade Plan

Bài trước và bài tiếp theo

Quay lại Forward Test một Setup #13 để ôn batch F01–F04 và rule no-backfill. Tiếp tục với Đánh giá kết quả Backtest #15 để học cách đọc kết quả sau khi hồ sơ đã đạt integrity.

Nhắc lại: Bài chỉ phục vụ giáo dục và quản trị bằng chứng. Journal đầy đủ không chứng minh setup có lợi thế, không bảo đảm kết quả tương lai và không thay thế đánh giá rủi ro độc lập.