# DSCons Policy Operations Playbook

Tài liệu này mô tả cách DSCons hiện đang vận hành policy/guardrail cho workflow dossier review, bám trực tiếp theo code ở:

- `app/services/workflow_policy_service.py`
- `app/services/workflow_persistence_service.py`
- `docs/dossier-review-full-flow-audit.md`
- `docs/operations-case-management-upgrade-proposal.md`

Mục tiêu của playbook là giúp team vận hành hiểu rõ:
- policy đang kiểm soát cái gì
- automation được phép đi đến đâu
- lúc nào phải chặn hoặc chuyển sang manual follow-up
- dữ liệu audit nào bắt buộc phải nhìn được trong `WorkflowReviewRunSummary`
- cách thay đổi rule an toàn mà không làm vỡ flow hiện tại

---

## 1. Bối cảnh hiện tại trong DSCons

Trong codebase hiện tại, policy không phải là một engine tách biệt hoàn toàn. Policy đang được triển khai như một lớp guardrail thực dụng nằm ngay trong workflow dossier review:

- `WorkflowPolicyService` đánh giá request ở mức session và từng finding
- `WorkflowPersistenceService.start_review_run()` dùng kết quả policy để quyết định:
  - có cho phép auto-assign không
  - có cho phép auto-submit không
  - có cho phép auto-verify không
  - có cho phép auto-close không
  - có phải tạo escalation next actions không
  - có phải phát sinh employee log cho policy/escalation không
  - có phải trả workflow ở trạng thái `manual_follow_up_required` không

Nói ngắn gọn:

- `WorkflowPolicyService` = nơi chấm guardrail
- `WorkflowPersistenceService` = nơi thực thi hậu quả vận hành của guardrail

Policy hiện tại đang đóng vai trò **safety gate cho end-to-end automation**, không chỉ là validator hình thức.

---

## 2. Policy model overview

## 2.1. Hai tầng policy hiện có

### Tầng 1: Session-level policy
Được đánh giá bởi `_evaluate_session_policy()`.

Phạm vi:
- toàn bộ `WorkflowReviewStartRequest`
- mối quan hệ giữa workflow, findings, departments, metadata flags

Các rule session-level hiện đang được khai báo trong `applied_rules`:

- `lead_agent_must_exist`
- `workflow_should_include_findings`
- `blocking_workflow_requires_departments`
- `high_risk_workflow_requires_manual_review`
- `conflicting_metadata_triggers_circuit_breaker`

Các tín hiệu chính:
- không có findings
- có finding blocking nhưng không có `assigned_departments`
- `metadata.flags.data_conflict`
- `metadata.flags.critical_data_missing`
- workflow chạy từ `integration_test`

### Tầng 2: Finding-level policy
Được đánh giá bởi `_evaluate_finding_policy()`.

Phạm vi:
- từng `WorkflowReviewFindingRequest`
- owner, department, severity, blocking, metadata flags

Các rule finding-level hiện có:

- `finding_requires_responsible_department`
- `blocking_finding_requires_owner`
- `critical_finance_legal_findings_escalate`
- `high_risk_findings_require_manual_review`
- `conflicting_finding_metadata_triggers_circuit_breaker`

Các tín hiệu chính:
- thiếu `responsible_department_code`
- finding blocking nhưng không có owner suy ra được
- finding thuộc `finance`, `legal`, `contracts`
- severity `high` hoặc `critical`
- `finding.metadata.flags.data_conflict`
- `finding.metadata.flags.critical_data_missing`

---

## 2.2. Các output policy chuẩn trong code hiện tại

Mỗi check trả về `WorkflowReviewPolicyCheckResult` với các trường quan trọng:

- `scope`
- `allowed`
- `risk_level`
- `risk_score`
- `requires_escalation`
- `requires_manual_review`
- `circuit_breaker_triggered`
- `violations`
- `warnings`
- `escalation_targets`
- `applied_rules`
- `metadata`

Sau đó policy được tổng hợp thêm thành `WorkflowReviewPolicySummary` trong response workflow.

Điều này có nghĩa là policy hiện tại đã là **machine-readable contract**, không chỉ là text log.

---

## 3. Actor roles trong policy operations

## 3.1. Lead agent
Nguồn: `request.lead_agent_code`, resolve qua `get_persona()`.

Vai trò:
- là actor chính khởi động workflow
- mang theo `display_name`, `role_title`, `escalation_targets`
- quyết định escalation route ở session-level

Trong persistence, lead agent còn được ghi vào:
- review metadata
- action trail của review session
- employee log actions do policy phát sinh

## 3.2. Lead reviewer employee
Nguồn:
- `request.lead_reviewer_employee_code`
- fallback sang `request.initiated_by_employee_code`

Vai trò:
- human/employee đại diện cho AI workflow trong audit trail
- được dùng làm `actor_employee_code`
- được dùng làm employee nhận log policy/escalation mặc định

## 3.3. Responsible department
Nguồn:
- `finding.responsible_department_code`
- `request.assigned_departments`

Vai trò:
- là neo tổ chức tối thiểu để workflow tiếp tục
- nếu thiếu ở finding-level thì bị coi là violation
- nếu có finding blocking nhưng workflow không khai báo department-level coverage thì sinh warning ở session-level

## 3.4. Assigned owner / employee
Nguồn suy ra theo thứ tự:
- `finding.assignment.assigned_employee_code`
- employee đầu tiên có trong `finding.employee_actions`

Vai trò:
- là owner để automation có thể auto-assign tiếp
- bắt buộc với finding blocking
- nếu không có owner ở finding blocking thì thành vi phạm critical

## 3.5. Escalation agents
Nguồn:
- persona escalation targets của lead agent
- rule cứng theo department `finance`, `legal`, `contracts`

Vai trò:
- nhận next action kiểu `policy_escalation`
- xuất hiện trong employee logs như action escalation
- là đối tượng follow-up ở command/operations layer sau này

Mapping hiện tại trong code:
- `finance` -> `nam`
- `legal` -> `thao`
- `contracts` -> `thao`

---

## 4. Action classes: auto-allow / require-verification / block

Để vận hành nhất quán, nên hiểu policy hiện tại của DSCons theo 3 lớp hành động sau.

## 4.1. Auto-allow

### Định nghĩa thực tế
Workflow hoặc finding được coi là auto-allow khi:
- `allowed=True`
- không `requires_manual_review`
- không `circuit_breaker_triggered`

Trong `WorkflowPersistenceService.start_review_run()`, chỉ khi không bị block ở session-level và không bị constrained ở finding-level thì hệ thống mới đi tiếp sang:
- `_ensure_assignment()`
- auto submission
- auto verification

### Hệ quả vận hành
Hệ thống có thể:
- tạo assignment
- submit supplement
- verify finding
- nếu toàn bộ findings ổn thì auto-close review

### Ví dụ thực tế
Một finding có:
- `responsible_department_code` hợp lệ
- có owner suy ra được
- không blocking hoặc blocking nhưng có owner rõ
- không có metadata conflict
- severity thấp/trung bình

=> đi theo flow auto hoàn chỉnh.

---

## 4.2. Require-verification

### Định nghĩa thực tế
Trong code hiện tại, lớp này tương ứng với các trường hợp:
- `requires_manual_review=True`
- hoặc có warnings/escalation nhưng chưa nhất thiết cấm hoàn toàn toàn bộ workflow
- hoặc finding hợp lệ nhưng cần theo dõi/hậu kiểm

Khái niệm "require-verification" ở DSCons nên được hiểu là:
- hệ thống có thể ghi nhận, tổng hợp, và tạo next actions
- nhưng không nên tự tin tiếp tục automation full chain mà không có người/agent chuyên trách xác nhận

### Dấu hiệu thường gặp
- risk score cao
- severity `critical`
- finding `high`/`critical`
- department nhạy cảm (`finance`, `legal`, `contracts`)
- warning ở session-level về departments
- policy yêu cầu escalation

### Hệ quả vận hành
Hệ thống sẽ:
- tạo `policy_checks`
- có thể tạo `policy_escalation`
- tạo `blocked_reasons` nếu cần manual review
- để `automation_status=manual_follow_up_required` nếu không còn đủ điều kiện auto-close

### Ý nghĩa thực dụng
Đây là lớp "cho phép machine handoff, không cho phép machine closure".

---

## 4.3. Block

### Định nghĩa thực tế
Lớp block tương ứng với:
- `allowed=False`
- hoặc `circuit_breaker_triggered=True`
- hoặc session-level blocking policy khiến toàn bộ findings không được auto-assign

### Dấu hiệu block trong code hiện tại
Session-level:
- `SESSION_NO_FINDINGS`
- `SESSION_DATA_CONFLICT`

Finding-level:
- `FINDING_NO_DEPARTMENT`
- `BLOCKING_FINDING_NO_OWNER`
- `FINDING_DATA_CONFLICT`

### Hệ quả vận hành
Khi block:
- workflow vẫn có thể tạo review session và persist finding
- nhưng không tiếp tục auto-assign/submit/verify cho finding bị chặn
- tạo `manual_assignment_required` hoặc escalation next actions
- thêm `WorkflowReviewStepOutcome` bị `blocked=True`
- review không được auto-close
- `resumable_from_step` thường về `assign` hoặc `close`
- `automation_status=manual_follow_up_required`

### Ý nghĩa vận hành
Block trong DSCons hiện không có nghĩa "không lưu gì cả".
Nó có nghĩa:
- vẫn persist để audit và follow-up
- dừng automation ở điểm an toàn
- chuyển quyền xử lý cho con người hoặc escalation path

---

## 5. Risk / confidence / escalation thresholds

## 5.1. Risk thresholds đang được code hóa

### Session-level
Điểm rủi ro được cộng như sau:

- có violations: `+80`
- có finding blocking: `+15`
- có warnings: cộng tối đa `+15`

Suy ra:
- `risk_score >= 60` -> `requires_manual_review=True`
- có violation lớn gần như luôn đẩy session sang high risk
- có metadata conflict -> circuit breaker + high risk

### Finding-level
Điểm rủi ro được cộng như sau:

- có violations: `+85`
- finding blocking: `+20`
- severity `critical`: `+10`
- severity `high`: `+5`

Suy ra mapping:
- `risk_score >= 80` -> `risk_level=high`
- `risk_score >= 20` -> `risk_level=medium`
- `risk_score >= 60` hoặc severity `critical` -> `requires_manual_review=True`

## 5.2. Escalation thresholds hiện tại

Escalation phát sinh khi:
- `requires_escalation=True`
- hoặc finding thuộc `finance`, `legal`, `contracts`
- hoặc session có lead persona escalation targets và có finding blocking / violation đủ điều kiện

Escalation priority hiện tại:
- `high` cho agent `thao`, `nam` ở một số session escalation
- `high` nếu finding blocking ở escalation theo department
- ngược lại thường là `medium`

## 5.3. Confidence thresholds: khuyến nghị diễn giải vận hành

Code hiện tại chưa có field `confidence_score` riêng trong policy result. Vì vậy team vận hành nên dùng quy ước sau để suy diễn confidence từ policy outcome:

- **High confidence automation**
  - `allowed=True`
  - `risk_level=low`
  - không escalation
  - không manual review
  - không circuit breaker

- **Medium confidence / require verification**
  - `allowed=True`
  - nhưng `risk_level=medium` hoặc có escalation/warnings

- **Low confidence / no autonomous continuation**
  - `allowed=False`
  - hoặc `requires_manual_review=True`
  - hoặc `circuit_breaker_triggered=True`

Khuyến nghị governance tiếp theo:
- thêm explicit `confidence_level` hoặc `confidence_score` vào `WorkflowReviewPolicyCheckResult`
- không suy luận ngầm mãi từ risk state

---

## 6. Circuit breaker behavior

## 6.1. Điều kiện kích hoạt
Circuit breaker hiện được kích hoạt khi metadata cho biết dữ liệu mâu thuẫn hoặc thiếu nghiêm trọng.

Session-level:
- `request.metadata.flags.data_conflict`
- `request.metadata.flags.critical_data_missing`

Finding-level:
- `finding.metadata.flags.data_conflict`
- `finding.metadata.flags.critical_data_missing`

## 6.2. Hành vi khi circuit breaker bật
Khi circuit breaker xảy ra:

- policy result đặt `circuit_breaker_triggered=True`
- thường kèm violation critical
- `blocked_reasons` sẽ có mục `...: circuit breaker đã kích hoạt`
- finding/session bị đẩy vào manual review
- automation chain dừng trước bước assign cho scope bị ảnh hưởng
- review vẫn được tạo để bảo toàn audit trail
- review thường không auto-close

## 6.3. Nguyên tắc vận hành
Circuit breaker trong DSCons nên được coi là:
- **stop-the-line safety control**
- không override bằng cách sửa tay response
- chỉ resume sau khi đã sửa nguồn dữ liệu hoặc metadata flags

## 6.4. Thao tác vận hành đúng
Khi thấy circuit breaker:
1. xác định scope bị ảnh hưởng trong `policy_checks`
2. kiểm tra `metadata.flags` của session/finding
3. xác minh nguồn upstream có conflict thật hay do mapping sai
4. chỉ re-trigger workflow sau khi dữ liệu đã sạch
5. giữ nguyên review cũ làm chứng cứ audit, không xoá

---

## 7. Audit trail requirements

DSCons hiện đã có nền audit khá tốt, nhưng cần vận hành theo checklist rõ ràng.

## 7.1. Các lớp audit hiện có

### A. Dossier review session
Được persist qua `create_dossier_review_session()` với:
- review metadata
- lead persona info
- trigger summary
- policy summary payload
- baseline snapshot nếu có
- actor metadata

### B. Findings / assignments / submissions / verifications / close
Toàn bộ lifecycle đều được persist qua PostgreSQL service:
- finding created
- assignment created
- submission persisted
- verification persisted
- session closed

### C. Employee work logs
`_persist_employee_logs()` ghi:
- policy check actions
- escalation actions
- automation actions assign/submit/verify
- metadata gắn review_id, review_code, project_code, finding_code

### D. Workflow response audit surface
`WorkflowReviewRunSummary` là lớp audit đọc nhanh cho API consumer.

## 7.2. Audit tối thiểu bắt buộc cho mỗi run
Mỗi workflow run production nên nhìn được tối thiểu:

- `review.review_id`
- `review.review_code`
- `correlation_id`
- `policy_checks`
- `policy_summary`
- `lifecycle_outcomes`
- `blocked_reasons`
- `next_actions`
- `post_close_actions`
- `employee_log_summaries`
- `trigger_summary`
- `operational_state_snapshot`

## 7.3. Audit yêu cầu riêng cho policy changes
Khi thay rule policy, cần lưu rõ:
- rule nào được thêm/sửa/xóa
- tại sao đổi
- scope bị ảnh hưởng: session, finding, escalation
- expected change về:
  - blocked checks
  - manual review count
  - escalation count
  - auto-close rate
- thời điểm rollout
- người phê duyệt

Hiện code chưa có policy version field riêng, nên tài liệu vận hành phải bù phần này bằng change log ngoài repo hoặc release note nội bộ.

---

## 8. Cách policy checks được surfacing trong `WorkflowReviewRunSummary`

Đây là hợp đồng quan trọng nhất cho layer API/command center.

## 8.1. `policy_checks`
Nguồn: `WorkflowPolicyService.evaluate_start_request()`.

Ý nghĩa:
- danh sách đầy đủ các check theo thứ tự:
  - 1 record session-level
  - N record finding-level

Cần dùng để:
- biết scope nào allowed / blocked
- biết violations/warnings cụ thể
- xác định escalation targets
- xác định có circuit breaker không

## 8.2. `policy_summary`
Nguồn:
- `WorkflowPolicyService.summarize_policy_outcome()`
- và `_build_policy_summary()` trong persistence service

Thông tin chính:
- `total_checks`
- `allowed_checks`
- `blocked_checks`
- `escalation_count`
- `manual_review_count`
- `circuit_breaker_count`
- `highest_risk_level`
- `scopes_requiring_attention`
- `warnings`
- `applied_rules`
- `metadata`

Đây là lớp summary nên dùng cho:
- command center KPI
- response compact view
- release comparison trước/sau thay rule

## 8.3. `blocked_reasons`
Nguồn: `_collect_policy_blocked_reasons()`.

Bao gồm:
- từng violation theo định dạng `scope: message`
- yêu cầu manual review theo định dạng `scope: yêu cầu manual review do risk level ...`
- thông báo circuit breaker theo định dạng `scope: circuit breaker đã kích hoạt`

Dùng để:
- hiển thị nhanh lý do automation bị chặn
- phục vụ escalations / incident handling
- hỗ trợ resumable executor sau này

## 8.4. `lifecycle_outcomes`
Nguồn: `start_review_run()`.

Các step đang được ghi:
- `start`
- `assign`
- `submit`
- `verify`
- `close`

Khi policy chặn, `lifecycle_outcomes` sẽ phản ánh:
- `executed=False` hoặc `succeeded=False`
- `requires_manual_intervention=True`
- `blocked=True`
- `reason` mô tả vì sao
- metadata như `policy_scope`, `blocking_policy`

Đây là nguồn tốt nhất để trả lời câu hỏi:
- workflow dừng ở bước nào
- dừng vì policy hay vì dữ liệu vận hành
- resume từ đâu

## 8.5. `post_close_actions`
Nguồn: `_build_post_close_actions()`.

Chỉ xuất hiện khi:
- review đủ điều kiện auto-close thành công

Hiện các action hậu đóng có thể gồm:
- `post_close_monitoring`
- `post_close_backlog_projection`

Dùng để:
- nối review lifecycle với operations backlog
- làm đầu vào cho operational state / command center nâng cấp

### Lưu ý quan trọng
`post_close_actions` hiện mới là response-level object, chưa phải queue bền vững có state machine riêng.
Vì vậy nếu muốn vận hành production nghiêm túc:
- cần persist sau này
- trước mắt phải xem đây là "deterministic projected actions", chưa phải "guaranteed executed tasks"

---

## 9. Quy trình thay đổi rule an toàn

Policy của DSCons đang ảnh hưởng trực tiếp đến automation chain. Vì vậy thay đổi rule phải xem như thay đổi production control plane.

## 9.1. Nguyên tắc
Không sửa rule trực tiếp mà không đánh giá tác động tới:
- auto-assign rate
- manual follow-up count
- escalation count
- auto-close rate
- blocked reasons distribution

## 9.2. Quy trình đề xuất

### Bước 1: Mô tả thay đổi bằng ngôn ngữ nghiệp vụ
Ví dụ:
- thêm rule bắt finding severity high luôn cần manual review
- đổi mapping escalation department contracts từ `thao` sang persona khác
- coi `critical_data_missing` là hard block ở mọi scope

### Bước 2: Mapping sang code path bị ảnh hưởng
Xác định rõ hàm nào đổi:
- `_evaluate_session_policy()`
- `_evaluate_finding_policy()`
- `_build_policy_summary()`
- `_collect_policy_blocked_reasons()`
- `_build_escalation_next_actions()`

### Bước 3: Chạy replay / diagnostic
Dùng các workflow payload pilot hoặc diagnostic script hiện có để kiểm:
- `policy_checks`
- `policy_summary`
- `blocked_reasons`
- `lifecycle_outcomes`
- `post_close_actions`

### Bước 4: So sánh trước/sau
Bắt buộc so:
- số check blocked
- số scope manual review
- số escalation target
- số finding không còn auto-assign
- số review không còn auto-close

### Bước 5: Rollout giới hạn
Ưu tiên:
- `integration_test`
- pilot project code
- trigger manual trước
- quan sát 1-2 ngày trước khi áp rộng

### Bước 6: Theo dõi sau rollout
Theo dõi tối thiểu:
- tỷ lệ `automation_status=manual_follow_up_required`
- số lượng `blocked_reasons`
- số workflow có `circuit_breaker_triggered`
- số escalation next actions tăng bất thường

---

## 10. Rollout checklist cho policy operations

Trước khi áp một thay đổi policy hoặc mở rộng automation, checklist tối thiểu nên là:

- [ ] Đã xác định rõ rule mới là auto-allow, require-verification hay block
- [ ] Đã xác định scope bị ảnh hưởng: session / finding / escalation / close
- [ ] Đã có ví dụ request thật hoặc pilot payload để kiểm thử
- [ ] Đã review output `policy_checks`
- [ ] Đã review output `policy_summary`
- [ ] Đã review `blocked_reasons` có còn dễ hiểu cho operator không
- [ ] Đã review `lifecycle_outcomes` có phản ánh đúng step bị dừng không
- [ ] Đã review `post_close_actions` nếu thay đổi chạm tới close logic
- [ ] Đã xác minh employee logs vẫn được ghi đủ
- [ ] Đã xác minh review session metadata vẫn chứa trigger/policy summary cần thiết
- [ ] Đã giới hạn rollout ban đầu cho pilot/integration path
- [ ] Đã có người chịu trách nhiệm rollback logic

---

## 11. Incident handling cho policy-related failures

## 11.1. Nhóm sự cố cần phân loại

### Loại A: False block
Triệu chứng:
- workflow bị chặn dù dữ liệu hợp lệ
- `blocked_reasons` không phản ánh đúng thực tế
- manual follow-up tăng đột biến sau khi đổi rule

Cách xử lý:
1. lấy `WorkflowReviewRunSummary`
2. xem `policy_checks` scope nào block
3. so với payload request thật
4. rollback rule hoặc hạ mức từ block xuống require-verification nếu phù hợp
5. re-trigger bằng review snapshot nếu cần

### Loại B: False allow
Triệu chứng:
- workflow tự động đi tiếp dù đáng lẽ phải dừng
- finding nhạy cảm vẫn auto-close
- không tạo escalation khi lẽ ra phải có

Cách xử lý:
1. xem `policy_summary` và `lifecycle_outcomes`
2. xác định rule thiếu ở session hay finding
3. vá policy và chạy diagnostic replay
4. rà soát các review gần nhất có pattern tương tự
5. nếu cần, tạo review follow-up thủ công cho các run đã lọt

### Loại C: Circuit breaker storm
Triệu chứng:
- hàng loạt workflow trả `circuit_breaker_triggered`
- auto-close về 0
- blocked reasons tập trung vào data conflict / critical missing

Cách xử lý:
1. kiểm tra upstream metadata mapping
2. xác định có thay đổi ingestion/integration nào mới không
3. không tắt circuit breaker hàng loạt để “cho chạy tiếp”
4. xử lý sạch dữ liệu nguồn trước
5. re-trigger có kiểm soát

### Loại D: Escalation flood
Triệu chứng:
- số `policy_escalation` tăng bất thường
- command center/backlog đầy action escalation
- lead reviewer logs bị spam

Cách xử lý:
1. xem rule nào đang auto-escalate quá rộng
2. kiểm tra mapping department -> agent
3. giảm escalation cho warning-only case nếu phù hợp
4. giữ escalation cho block/critical case

---

## 11.2. Nguồn dữ liệu cần lấy khi điều tra
Khi xử lý incident, nên thu thập tối thiểu:

- request payload đã gửi vào `POST /v1/workflows/dossier-review/start`
- response `WorkflowReviewRunSummary`
- review detail từ `GET /v1/dossiers/reviews/{review_id}`
- employee logs liên quan
- company operational state snapshot nếu issue lan sang operations board

---

## 12. Recommended operating conventions

## 12.1. Chuẩn hoá cách diễn giải severity và block
Team nên thống nhất:
- `severity=critical` gần như luôn là require-verification hoặc block
- finding blocking mà thiếu owner là hard block
- thiếu department là hard block
- data conflict / critical data missing là circuit breaker, không override tay

## 12.2. Không dùng warning như block ngầm
Nếu muốn một warning thực sự chặn automation, hãy nâng nó thành:
- violation
- hoặc `requires_manual_review`
- hoặc circuit breaker rule

Không nên để operator đoán.

## 12.3. Ưu tiên policy có thể giải thích
Mọi rule mới nên trả được:
- `code`
- `message`
- `field_name`
- `metadata` nếu cần

Để `blocked_reasons` và `policy_checks` vẫn đọc được từ API.

---

## 13. Recommended next governance steps

Bám theo hiện trạng code và các tài liệu audit/operations hiện có, các bước governance nên làm tiếp là:

## 13.1. Thêm policy versioning
Nên thêm vào metadata hoặc schema:
- `policy_version`
- `policy_bundle`
- `policy_change_ticket`

Để biết một review run đã được chấm dưới bộ rule nào.

## 13.2. Thêm confidence field chính thức
Hiện confidence mới suy diễn từ risk state.
Nên bổ sung:
- `confidence_level`
- hoặc `confidence_score`

vào `WorkflowReviewPolicyCheckResult` và `WorkflowReviewPolicySummary`.

## 13.3. Persist next actions hậu policy
Hiện:
- `next_actions`
- `post_close_actions`

mới là projected response objects.
Nên nâng lên queue bền vững để:
- track pending / claimed / completed
- đo SLA
- surfacing tốt hơn trên company operational state

## 13.4. Tách policy analytics dashboard
Tối thiểu nên đo:
- blocked_checks theo rule code
- manual_review_count theo project/department
- escalation_count theo agent
- circuit_breaker_count theo source/trigger

## 13.5. Xây change approval process
Mọi thay đổi policy nên có:
- owner
- reviewer
- pilot scope
- rollback plan
- acceptance criteria

## 13.6. Chuẩn hóa replay pack cho incident/debug
Nên có bộ payload mẫu:
- happy path auto-close
- blocking without owner
- missing department
- finance/legal escalation
- session data conflict
- finding data conflict

để mỗi lần sửa rule có thể replay nhanh.

---

## 14. Kết luận vận hành

Trong DSCons hiện tại, policy không chỉ là “validation trước khi lưu”.
Policy đang là lớp quyết định:
- automation có được đi tiếp không
- escalation có được tạo không
- review có được auto-close không
- workflow có phải chuyển sang manual follow-up không
- audit trail có ghi được lý do chặn hay không

Vì vậy, policy operations cần được quản trị như một phần của production workflow control plane.

Nguyên tắc vận hành nên giữ là:

- **persist trước, chặn an toàn sau**
- **có explainability trong response**
- **mọi block đều phải truy vết được qua `policy_checks` và `blocked_reasons`**
- **mọi thay đổi rule đều phải replay và rollout có kiểm soát**
- **circuit breaker chỉ được giải quyết bằng sửa dữ liệu/rule đúng cách, không by-pass thủ công**

Tài liệu này là playbook nền để team tiếp tục nâng DSCons từ workflow pilot sang command center và governance-ready operations.