Viết Strategy Specification Document #25

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc hướng dẫn xây dựng, vận hành hay kiểm chứng hệ thống giao dịch.

Trả lời ngắn: Strategy Specification Document trong bài là tờ mô tả học tập giúp ghi rõ mục đích, phạm vi, giả định, quan sát và giới hạn của một ý. Nó không là strategy, quy tắc, tín hiệu, kiểm chứng, lời khuyên, hệ thống đang chạy hay chỉ dẫn để thực hiện bất kỳ hành động nào.

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

• Vì sao một tờ specification khác hẳn strategy hoặc rule để làm theo.
• Sáu field của Specification Card S-25 và điều từng field không chứng minh.
• Cách dùng ba card mock để nhìn phần rõ, phần thiếu scope và phần cần bàn giao.

1. Specification card ghi phạm vi, không tạo strategy

Từ “strategy specification document” nghe có vẻ rất lớn. Người mới dễ nghĩ đó là chỗ viết một công thức rồi chờ công thức tự làm việc. Trong bài này, specification chỉ là tờ mô tả: nó nói một ý đang được đọc là gì, đang nằm trong phần nào và phải dừng ở đâu.

Ta gọi tờ mock này là Specification Card S-25. Card có sáu ô: Purpose, Scope, Premise, Observation, Boundary và Review State. Tên các ô giúp người đọc không nhét nhiều ý vào một câu. Card càng rõ càng hữu ích cho việc hỏi lại, nhưng sự rõ ràng không làm nó trở thành một strategy. Nó không có dữ liệu thật, không đọc thị trường, không tạo tín hiệu và không nói ai phải làm gì.

Ví dụ ở quầy thư viện: bạn ghi “cần hỏi về nhãn kệ thiếu nhi”. Phiếu giúp cô trực quầy biết chủ đề đang được hỏi. Nó không chọn sách thay bạn, không đổi nhãn kệ và không chứng minh nhãn hiện tại có lỗi. Tương tự, S-25 mô tả câu hỏi để người khác hiểu, chứ không thay người có trách nhiệm kết luận hoặc hành động.

Hình 1 — Sáu ô của S-25 giữ ý học tập trong phạm vi đọc; footer CARD ≠ STRATEGY chặn nhầm card thành công thức.

2. Sáu field giữ một ý trong đúng khung

Purpose là câu hỏi card muốn làm rõ. “Tại sao nhãn kệ này khác?” là Purpose. Nó không phải mục tiêu phải đạt, càng không là yêu cầu thay đổi kệ. Khi Purpose ngắn và cụ thể, người đọc biết mình đang nhìn vào câu hỏi nào.

Scope là phần được phép mô tả. Nếu Scope là “kệ thiếu nhi ở thư viện mock”, card không tự nói tới mọi kệ, mọi thư viện hay mọi tình huống khác. Scope giống viền của một tấm ảnh: nó cho biết phần nào nằm trong khung, không trao permission — tức quyền được quyết định — cho bất kỳ ai.

Premise là giả định được viết ra để người đọc nhận biết. “Giả định hai nhãn thuộc cùng một nhóm sách” là Premise. Nó không phải fact, nghĩa là điều đã được chứng minh là đúng. Viết premise ra ngoài sáng giúp người khác có thể hỏi “nếu giả định này sai thì card còn nói được gì?”.

Observation là điều nhìn thấy trong ví dụ mock. “Có hai nhãn đặt cạnh nhau” là Observation. Nó chưa là proof, tức bằng chứng đủ để kết luận nguyên nhân, chất lượng hay kết quả. Mắt thấy một chi tiết không thay thế cho việc kiểm tra trong bối cảnh thật.

Boundary là câu khóa cho những điều card không được suy ra và không được làm. Với S-25, boundary có thể là “không đổi nhãn, không kết luận nguyên nhân, không tạo rule”. Boundary không làm card yếu; nó làm phạm vi của card thành thật hơn.

Cuối cùng, Review State ghi lượt đọc tiếp theo cùng lý do: READ — CARD CLEAR, HOLD — SCOPE MISSING hoặc HANDOFF — ROLE REQUIRED. State không phải dấu xanh xác nhận một ý đúng. Nó chỉ nhắc người đọc đang đủ field để đọc, đang thiếu field, hay phải chuyển reason cho role phù hợp.

NIST AI RMF Playbook nêu documentation, scope, assumptions, limitations, roles và review như các phần hữu ích cho accountability trong bối cảnh quản trị AI. Bài này chỉ mượn bối cảnh đó để tập viết rõ một card; NIST không cung cấp S-25, không xác thực premise và không biến card thành quy trình trading. NIST AI RMF Playbook — Govern

Hình 2 — Mỗi field trả lời một câu nhỏ: vì sao, ở đâu, giả định gì, thấy gì, không làm gì và đọc tiếp thế nào.

3. Ba S-25 mock cards: read, hold scope và handoff role

S-A là card về nhãn kệ sách. Purpose là hỏi sự khác nhau giữa hai nhãn; Scope ghi rõ “kệ thiếu nhi mock”. Premise nói hai nhãn có thể thuộc cùng một nhóm, Observation ghi thấy hai nhãn, Boundary cấm đổi nhãn hoặc gọi premise là fact. Vì các ô cần đọc đã có, state là READ — CARD CLEAR. “Read” chỉ là có thể đọc card trong phạm vi mock.

S-B là card về chuông lớp. Người viết ghi Purpose nhưng Scope là MISSING. Có thể họ nghe chuông ở thời điểm lạ, nhưng việc nghe chuông không bù được phạm vi thiếu. State là HOLD — SCOPE MISSING. Hold không phải thất bại hay cảnh báo nghiêm trọng; nó là cách để khoảng trống được nhìn thấy thay vì bị điền bừa.

S-C là card về thẻ mượn. Purpose, Scope, Premise và Observation đều đọc được, nhưng câu hỏi cần một role ngoài worksheet xem tiếp. State là HANDOFF — ROLE REQUIRED. Handoff chuyển card và reason, không chuyển authority — tức thẩm quyền quyết định — cho người đang cầm giấy.

Hình 3 — S-A/S-B/S-C giữ reason riêng: rõ để đọc, thiếu scope để giữ, thiếu role để bàn giao.

Ba card đứng cạnh nhau để nhắc một điều đơn giản: hàng trơn tru không phải hàng “tốt” hơn. S-B trung thực vì nó để Scope trống. S-C trung thực vì nó không giả vờ role đã xuất hiện. Khi reason nằm cạnh state, người sau không cần đoán tại sao card dừng ở đó.

4. Bốn nhầm lẫn biến tờ mô tả thành lời chỉ dẫn

Nhầm lẫn đầu tiên là gọi Premise là fact. Premise chỉ nói “đang giả định điều này”; nếu không gắn nhãn, người đọc dễ tưởng nó đã được chứng minh. Nhầm lẫn thứ hai là gọi Observation là proof hoặc forecast. Thấy hai nhãn không cho biết ngày mai nhãn sẽ đổi; ghi nhận không dự báo điều gì.

Nhầm lẫn thứ ba là dùng Scope như permission. Scope “quầy trả sách” chỉ khoanh vùng câu hỏi. Nó không tạo quyền sửa thẻ, sửa quy trình hay thay người khác quyết định. Nhầm lẫn thứ tư là gọi Review State là validation. Validation là một việc kiểm tra riêng, cần tiêu chí và evidence phù hợp; đọc một card không thay thế được việc đó.

NIST SP 800-218 nói về việc xác định và xử lý requirements trong phát triển phần mềm an toàn. Đây chỉ là bối cảnh để hiểu vì sao mô tả rõ trước khi làm có ích; bài không hướng dẫn software, không biến S-25 thành requirements thực và không đưa bất kỳ tool instruction nào. NIST SP 800-218 SSDF

Vì vậy, S-25 không phải trade plan, model card đầy đủ, test report, validation report, deployment brief hay bảng giới hạn rủi ro. Nó càng không là lời hứa rằng một ý sẽ hoạt động. Nếu câu hỏi đòi dữ liệu thật, tiêu chí thật, quyền thật hoặc hành động thật, card đã đi tới boundary và bài tập phải dừng.

5. Checklist: viết đủ rồi dừng đúng chỗ

Khi thử viết một S-25, hãy đọc theo bảy bước dưới đây. Đây là checklist cho độ rõ của record, không phải checklist để biến record thành action.

1. Viết Purpose bằng một câu hỏi học tập, không viết kết luận sẵn.
2. Khoanh Scope đủ hẹp để người sau biết phần nào đang được nói tới.
3. Gắn nhãn Premise là giả định và nói điều gì có thể làm giả định không đứng vững.
4. Ghi Observation là điều thấy trong mock; không gọi nó là proof hoặc forecast.
5. Viết Boundary bằng động từ rõ: không kết luận, không tạo rule, không thay đổi gì.
6. Chọn READ, HOLD hoặc HANDOFF kèm reason cụ thể, không dùng state như phán quyết chất lượng.
7. Nếu cần data thật, validation, role có quyền, platform, code hoặc tiền thật, hãy dừng bài tập và handoff record/reason cho bối cảnh phù hợp.

Checklist tốt khiến card bớt bóng bẩy nhưng đáng tin hơn. Một ô MISSING được ghi ra công khai hữu ích hơn nhiều một ô được đoán để làm bảng trông hoàn chỉnh.

6. Practice Bridge 15 phút: Specification Card trên giấy hoặc Sheets

Bạn chỉ cần giấy, Google Sheets hoặc LibreOffice Calc. Không dùng terminal, code, broker, API, platform, tài khoản, giá, chart, lệnh hay tiền thật. Mục tiêu duy nhất là tập tách field, không thử một ý nào ngoài bài học.

Năm phút đầu, kẻ năm cột: Card, Purpose/Scope, Premise/Observation, Boundary và State. Năm phút tiếp, chép ba hàng mẫu bên dưới. Năm phút cuối, đọc mỗi State cho một người khác và nói reason đi kèm. Nếu không có người nghe, tự đọc thành tiếng: câu nào biến assumption thành fact hoặc card thành action thì gạch lại.

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

Kết quả mong đợi rất nhỏ: bạn chỉ giải thích được vì sao S-B chưa đủ Scope và vì sao S-C cần role. Bạn không cần và không được tạo strategy, tín hiệu, kết quả, rule hay giao dịch thật từ bảng này.

Hình 4 — Worksheet giữ mỗi reason ở đúng hàng để người đọc không biến state thành kết luận hoặc hành động.

7. Tổng kết: rõ phạm vi trước, không biến card thành strategy

Một specification hữu ích thường bắt đầu bằng câu “đang nói về gì?” và kết thúc bằng “không được suy ra điều gì?”. S-25 giúp người mới tập hai đầu đó trước khi gặp các tài liệu khó hơn. Bài trước, Systematic Trading Operating System #24, đã đặt record mock vào năm lane đọc; bài sau, Xây Validation Report #26, sẽ tách report học tập khỏi chuyện chứng minh một strategy.

Năm ý chính

• Specification mô tả một ý học tập; nó không tạo strategy hay action.
• Purpose và Scope cho biết câu hỏi nào, trong phần nào, đang được đọc.
• Premise là giả định, còn Observation chưa phải proof.
• Boundary chặn card suy ra kết luận, permission hoặc kết quả.
• Review State giữ reason cho lượt đọc/handoff tiếp theo, không thay validation hay approval.

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

• Vì sao một Scope rõ vẫn không tạo permission?
• Premise và Observation khác fact/proof ở chỗ nào?
• Khi nào S-25 nên là HOLD thay vì READ?
• Handoff chuyển điều gì và không chuyển điều gì?

Gợi ý đáp án

Scope có phải quyền quyết định không?

Không. Scope chỉ khoanh phần card đang mô tả; nó không trao authority hoặc permission. → Xem lại mục 2 và mục 4.

Premise và Observation có chứng minh kết luận không?

Không. Premise là giả định, Observation là điều thấy trong mock; cả hai cần được tách khỏi fact và proof. → Xem lại mục 2 và mục 3.

Khi nào chọn HOLD?

Chọn HOLD khi một field cần để đọc card, như Scope, còn thiếu; hãy ghi reason thay vì tự điền. → Xem lại mục 3 và mục 5.

Handoff không làm được gì?

Handoff chuyển record và reason cho role phù hợp, nhưng không trao thẩm quyền, approval hay hành động tự động. → Xem lại mục 3 và mục 5.

Thuật ngữ cần nhớ

Nguồn tham khảo

• NIST AI RMF Playbook — Govern
• NIST SP 800-218, Secure Software Development Framework

Bài viết chỉ phục vụ giáo dục. Specification Card S-25 là ví dụ mock để học cách ghi phạm vi và rủi ro diễn giải; nó không phải strategy, khuyến nghị đầu tư hay hướng dẫn dùng tiền thật.