2.2. Quy trình điều tra truyền thống bị phân mảnh

Trong một quy trình AML điển hình, chuyên viên có thể phải chuyển qua nhiều nguồn để kiểm tra cảnh báo, lịch sử giao dịch, hồ sơ khách hàng, kết quả screening, quan hệ tài khoản, quy định nội bộ và các vụ việc liên quan. Cách làm này tạo ra bốn vấn đề chính:

1. Khó ưu tiên công việc: hàng đợi cảnh báo thiếu một góc nhìn thống nhất về rủi ro, nguyên nhân và thời hạn xử lý.
2. Khó nhìn thấy cấu trúc dòng tiền: bảng giao dịch phẳng không thể hiện rõ fan-in, fan-out, vòng tròn hoặc chuỗi chuyển tiếp.
3. Tốn thời gian xây dựng hồ sơ: chuyên viên phải thu thập lại dữ liệu và liên kết bằng chứng thủ công trước khi đưa ra nhận định.
4. Khó kiểm toán: nếu thiếu phiên bản luật, nguồn dữ liệu, dấu thời gian và lịch sử thao tác, người kiểm tra sau đó khó tái hiện lý do một cảnh báo hoặc bản nháp được tạo ra.

2.3. AI tạo sinh mang lại giá trị nhưng cũng tạo ra rủi ro mới

AI có thể hỗ trợ đọc, tổng hợp và soạn thảo nhanh, nhưng một chatbot tổng quát không phù hợp để tự quyết định trong nghiệp vụ AML. Những rủi ro cần kiểm soát gồm:

• tạo ra nhận định không có bằng chứng;
• trích dẫn sai hoặc sử dụng tài liệu chưa được phê duyệt;
• đưa dữ liệu định danh hoặc dữ liệu giao dịch thô ra ngoài ranh giới cho phép;
• bị prompt injection làm thay đổi phạm vi điều tra;
• biến khuyến nghị của mô hình thành hành động tuân thủ tự động;
• không thể tái hiện mô hình, công cụ và dữ liệu đã tạo ra câu trả lời.

Vì vậy, SENTRA không xem AI là nguồn sự thật hay người ra quyết định. AI chỉ là một lớp hỗ trợ nằm sau dữ liệu, luật, bằng chứng và các cổng quản trị.

3. Mục tiêu của SENTRA

SENTRA được xây dựng nhằm tạo ra một luồng AML thống nhất với năm mục tiêu:

1. Phát hiện có thể giải thích: mỗi cảnh báo phải chỉ ra dữ liệu, luật, kết quả screening, đặc trưng hoặc đường đi đồ thị liên quan.
2. Điều tra tập trung: chuyên viên có thể đi từ hàng đợi cảnh báo đến chi tiết bằng chứng, đồ thị, hồ sơ vụ việc và trợ lý điều tra trong cùng một không gian làm việc.
3. AI có căn cứ: mọi nội dung do Agent tạo ra phải được phân biệt rõ giữa sự thật, suy luận và phần thông tin còn thiếu.
4. Quyết định có kiểm soát: hệ thống hỗ trợ chuyên viên và reviewer nhưng không tự khóa tài khoản, tự đóng case hoặc tự nộp STR.
5. Sẵn sàng kiểm toán: sự kiện, bằng chứng, cấu hình, phiên bản và thao tác nghiệp vụ được lưu vết để có thể kiểm tra lại.

Đối tượng sử dụng chính

Customer Portal có code path riêng cho môi trường local/demo, nhưng bị loại khỏi shared environment và không thuộc phạm vi production được phê duyệt của release hiện tại.

4. Giải pháp tổng thể

SENTRA sử dụng kiến trúc Modular Monolith kết hợp Event-Driven Processing. PostgreSQL là nguồn sự thật; RabbitMQ chịu trách nhiệm giao việc bất đồng bộ; các worker tách biệt xử lý phát hiện, điều tra và xuất báo cáo. Frontend truy cập dữ liệu thông qua API có kiểm soát role, tenant và purpose.

flowchart LR
    Source[Wallet / Payment / KYC / Device] -->|Canonical Event V2| API[FastAPI Core API]
    API -->|Atomic transaction| DB[(PostgreSQL 16 + pgvector)]
    DB --> Outbox[Transactional Outbox]
    Outbox -->|Publisher confirm| MQ[RabbitMQ]
    MQ --> Detect[Detection Worker]
    Detect --> Rules[Rules T01–T11]
    Detect --> Graph[Bounded Graph]
    Detect --> Screening[Screening]
    Rules --> Risk[Risk Aggregation]
    Graph --> Risk
    Screening --> Risk
    Risk --> Evidence[Evidence + Alert]
    Evidence --> Case[Case Management]
    Evidence --> Agent[Bounded Investigation Agent]
    Agent --> Draft[FACT / INFERENCE / UNKNOWN Draft]
    Draft --> Review[Analyst / Reviewer]
    Case --> Review
    Review --> STR[Human-reviewed STR workflow]
    UI[React Web / AML Command Center] <--> API

Luồng này đặt bằng chứng trước phần diễn giải. Một alert không được tạo ra chỉ vì giao diện được mở, và một câu trả lời AI không thể trở thành nguồn dữ liệu đầu vào cho quyết định AML.

5. Giải pháp kỹ thuật chi tiết

5.1. Chuẩn hóa và tiếp nhận sự kiện

SENTRA định nghĩa Canonical Event Envelope V2 cho cả sự kiện tài chính và phi tài chính. API kiểm tra schema, xác thực caller, tenant, purpose, dữ liệu thời gian và khóa idempotency trước khi ghi nhận.

Các đặc điểm chính:

• hợp đồng JSON Schema và OpenAPI được sinh và kiểm tra trong CI;
• hỗ trợ sự kiện tài chính và phi tài chính;
• phân biệt thời điểm sự kiện với thời điểm ingestion;
• ghi nhận late/out-of-order event bằng watermark cấu hình;
• dùng Idempotency-Key để retry không tạo bản ghi trùng;
• xung đột nguồn được đưa vào trạng thái kiểm tra thay vì âm thầm ghi đè;
• payload chứa trường PII thô bị từ chối ở general event endpoint và phải đi qua protected PII ingress.

Trong một transaction cơ sở dữ liệu, hệ thống ghi canonical event, subtype, idempotency receipt và outbox intent. Cách làm này ngăn tình trạng dữ liệu đã ghi nhưng thông điệp xử lý bị mất, hoặc ngược lại.

Code liên quan: packages/contracts/events.py, apps/api/routes/events.py, packages/domain/ingestion.py, packages/messaging/outbox.py.

5.2. Xử lý bất đồng bộ và độ tin cậy

Transactional Outbox chuyển tham chiếu sự kiện sang RabbitMQ bằng publisher confirm. Broker sử dụng main queue, retry queue và dead-letter queue; consumer được thiết kế idempotent để chấp nhận cơ chế giao nhận at least once.

Giải pháp này giúp:

• tách thời gian phản hồi ingestion khỏi thời gian phát hiện;
• cho phép retry có giới hạn khi worker hoặc broker gặp lỗi tạm thời;
• cô lập thông điệp lỗi ở DLQ để redrive có kiểm soát;
• duy trì processing receipt và correlation/trace ID xuyên suốt luồng;
• tránh đặt payload nghiệp vụ lớn hoặc PII thô trong broker message; PostgreSQL vẫn là nguồn sự thật.

Code liên quan: packages/messaging/rabbitmq.py, workers/detection/outbox_publisher.py, workers/detection/consumer.py, workers/detection/redrive.py.

5.3. Detection Engine xác định và có phiên bản

Detection Worker tải sự kiện và các cấu hình được phép, tạo feature snapshot, chạy rule, graph, screening và risk, sau đó lưu evidence và alert. Các ngưỡng demo trong code được gắn nhãn synthetic; chúng không được diễn giải thành chính sách AML production.

Rule configuration hỗ trợ vòng đời tạo phiên bản, mô phỏng, phê duyệt, kích hoạt và rollback. Việc có code path không đồng nghĩa một rule bundle đã được AML phê duyệt; production phải dùng bundle có identity, checksum, hiệu lực và reviewer rõ ràng.

Code liên quan: packages/rules/evaluator.py, packages/rules/config.py, workers/detection/pipeline.py, governance/rule-manifests, apps/api/routes/rule_configurations.py.

5.4. Phân tích đồ thị có giới hạn

SENTRA lưu các node và edge cần thiết trong PostgreSQL rồi tải một vùng đồ thị giới hạn vào NetworkX để điều tra. Bounded traversal giới hạn số hop, số path, kích thước và timeout nhằm tránh truy vấn không kiểm soát trên toàn mạng lưới.

Graph Engine hỗ trợ:

• materialize quan hệ từ các sự kiện đã persist;
• phát hiện fan-in, fan-out và chu trình;
• trả đường đi kèm evidence ID thay vì chỉ trả một điểm số;
• fallback/degraded status khi truy vấn vượt giới hạn;
• hiển thị mạng lưới và timeline trên giao diện điều tra.

Cách tiếp cận hiện tại phù hợp với engineering candidate và điều tra có phạm vi. Nếu cần phân tích đồ thị cực lớn hoặc truy vấn toàn mạng theo thời gian thực, dự án phải benchmark và đánh giá kiến trúc lưu trữ/chia vùng bổ sung.

Code liên quan: packages/graph/bounded.py, packages/graph/detectors.py, packages/graph/materialize.py, apps/api/routes/graph.py.

5.5. Screening, Risk và Evidence

Screening được triển khai như một lifecycle có kiểm soát: snapshot danh sách phải được phê duyệt, kết quả ứng viên được che dữ liệu phù hợp, disposition do người có quyền thực hiện và hoạt động rescreen/redrive được lưu vết.

Risk Aggregator kết hợp các finding xác định theo policy/bundle đã chọn. Kết quả rủi ro giúp ưu tiên hàng đợi nhưng không tự động biến thành quyết định pháp lý.

Evidence Store lưu các bằng chứng gắn với nguồn, phiên bản, thời điểm và checksum. Alert, graph, case và Agent tham chiếu lại các evidence ID này để bảo đảm phần giải thích không tách rời dữ liệu gốc.

Code liên quan: packages/screening, packages/risk, packages/evidence/store.py, apps/api/routes/evidence.py, apps/api/routes/screening.py.

5.6. AI Agent và Governed RAG

Investigation Agent là một workflow read-only, bounded và non-authoritative. Agent chỉ được gọi các công cụ đọc nằm trong allowlist, có giới hạn tối đa 12 tool calls và 45 giây cho một lượt điều tra. Công cụ được giới hạn theo tenant và purpose, đồng thời giới hạn số alert, evidence và related case được lấy.

Luồng xử lý chính:

1. kiểm tra input và prompt injection;
2. thu thập alert, timeline, graph finding, screening và related case bằng read-only tools;
3. kiểm chứng evidence ID;
4. truy xuất tri thức đã được quản trị;
5. phân loại nội dung thành FACT, INFERENCE, UNKNOWN;
6. kiểm tra citation và giới hạn đầu ra;
7. persist một bản nháp có version và audit metadata;
8. yêu cầu con người tiếp tục kiểm tra.

Hai loại RAG cần phân biệt

Khi external AI không được bật hoặc thiếu điều kiện an toàn, hệ thống dùng deterministic fallback. Khi egress được cấu hình, dữ liệu gửi đi vẫn phải qua gate DPA/egress/model/registry và không được bao gồm raw CSV hay số tài khoản thô.

Đầu ra Agent luôn giữ nguyên các ranh giới:

• FACT: thông tin đã được liên kết với evidence hợp lệ;
• INFERENCE: suy luận có căn cứ nhưng cần người kiểm tra;
• UNKNOWN: dữ liệu còn thiếu hoặc không đủ để kết luận;
• citation được pin bằng định danh/hash;
• hành động nhạy cảm tạo yêu cầu human approval, không tự thực thi.

Code liên quan: src/agents/investigation.py, src/agents/grounded.py, src/agents/tools/investigation.py, packages/agent_core/guardrails.py, workers/investigation/runtime.py, packages/knowledge.

5.7. Case Management, Maker–Checker và STR

Alert có thể được chuyển thành case để analyst điều tra và cộng tác với reviewer. Vòng đời case hỗ trợ:

• tạo case từ alert đã tồn tại;
• phân công người xử lý;
• chuyển trạng thái kèm reason code;
• ghi chú và lịch sử thao tác;
• dùng ETag/If-Match để phát hiện stale update thay vì ghi đè;
• tạo decision proposal và reviewer decision riêng biệt;
• tạo, sửa và review bản nháp STR;
• chạy STR export qua worker có quản trị.

Đây là cơ chế hỗ trợ quy trình Maker–Checker. Việc xuất một artifact hoặc tạo bản nháp không đồng nghĩa báo cáo đã được nộp cho cơ quan quản lý.

Code liên quan: apps/api/routes/cases.py, packages/domain/case_decisions.py, packages/domain/str_drafts.py, workers/str_export/runtime.py.

5.8. Bảo mật, PII và phân quyền

SENTRA áp dụng mô hình deny-by-default dựa trên bốn thành phần: danh tính người dùng, role, tenant và purpose. Một role không tự động có mọi quyền; quyền thực tế phụ thuộc vào mục đích đang hoạt động trong phiên.

Các kiểm soát đã có trong code gồm:

• signed-token authentication và policy role–purpose–capability;
• tenant isolation ở API và domain service;
• tách admin capability khỏi business mutation;
• protected PII ingress riêng;
• AES-256-GCM cho giá trị PII được bảo vệ;
• HMAC token theo tenant và field để tra cứu mà không lưu giá trị thô;
• từ chối raw PII ở canonical event endpoint;
• masking/redaction trong search, audit và Agent context;
• correlation ID, trace ID và audit metadata;
• egress gate, deterministic fallback và human approval cho AI.

Các kiểm soát này là nền tảng kỹ thuật; production vẫn cần KMS/secret management, OIDC/service identity, security testing và phê duyệt vận hành trên đúng release artifact.

Code liên quan: packages/security/capabilities.py, packages/security/authorization.py, packages/security/pii.py, packages/security/vault.py, packages/security/redaction.py.

5.9. Trải nghiệm người dùng

Frontend React/TypeScript hiện cung cấp các không gian nghiệp vụ chính:

• AML Command Center: tổng quan alert đang mở, mức ưu tiên, SLA, case chờ duyệt và khối lượng phân công;
• Alert Queue và Alert Detail: lọc hàng đợi, xem lý do cảnh báo, risk, evidence và hành động được phép;
• Timeline & Graph: xem chuỗi sự kiện và mạng lưới quan hệ có giới hạn;
• Cases & Reviews: quản lý case, decision proposal, phê duyệt và STR draft;
• Search: tra cứu có giới hạn thời gian, tenant và masking;
• Agent: xem bản nháp FACT/INFERENCE/UNKNOWN, citation và fallback status;
• Governance: screening, rule configuration, audit và operations;
• Access Administration: quản lý tenant, người dùng và entitlement trong ranh giới được cấp.

Navigation và dữ liệu hiển thị được lọc theo session capability. Khi purpose hiện tại không có quyền đọc một khu vực, UI thể hiện trạng thái không khả dụng thay vì giả lập dữ liệu hoặc âm thầm nâng quyền.

Code liên quan: apps/web/src/app/routes.ts, apps/web/src/app/WorkspaceChrome.tsx, apps/web/src/features/workspace/CommandCenterPage.tsx, apps/web/src/features.

5.10. Triển khai và quan sát hệ thống

Môi trường local/demo dùng Docker Compose với PostgreSQL 16 + pgvector, RabbitMQ, API, Web và các worker Outbox, Detection, Investigation, STR Export. API có /healthz, /readyz và Prometheus metrics; correlation/trace ID được gắn vào request và processing flow.

Đường triển khai demo hiện tại dùng một EC2, build API/Web image, scan image, đẩy vào private ECR, resolve immutable digest rồi triển khai qua SSM. Web/Nginx là public listener; API, database và broker nằm trong private container network.

Topology này phù hợp để trình diễn kỹ thuật với dữ liệu synthetic, nhưng không có HA/Multi-AZ, trusted HTTPS/domain, managed PITR hay production identity. Vì thế mọi URL hiện tại phải được gắn nhãn PUBLIC_SYNTHETIC_DEMO_ONLY.

Code/tài liệu liên quan: docker-compose.yml, apps/api/main.py, deploy/aws-vps, overall_report.md.

6. Luồng sử dụng end-to-end

sequenceDiagram
    autonumber
    participant Source as Nguồn giao dịch
    participant API as Core API
    participant Worker as Detection Worker
    participant Analyst as AML Analyst
    participant Agent as Investigation Agent
    participant Reviewer as Compliance Reviewer

    Source->>API: Gửi Canonical Event V2 + Idempotency-Key
    API->>API: Xác thực, kiểm tra schema/PII, ghi event + outbox
    API-->>Source: 202 Accepted + trace_id
    API->>Worker: RabbitMQ delivery theo tham chiếu event
    Worker->>Worker: Feature → Rules → Graph → Screening → Risk
    Worker->>API: Persist evidence và alert
    Analyst->>API: Mở hàng đợi và chi tiết cảnh báo
    Analyst->>API: Xem evidence, timeline, graph và screening
    Analyst->>API: Tạo/nhận case điều tra
    Analyst->>Agent: Yêu cầu bản nháp điều tra
    Agent->>Agent: Read-only tools + RAG + citation verification
    Agent-->>Analyst: FACT / INFERENCE / UNKNOWN + manual-review warning
    Analyst->>API: Bổ sung nhận định và đề xuất quyết định
    Reviewer->>API: Duyệt, từ chối hoặc yêu cầu bổ sung
    Reviewer->>API: Review bản nháp/xuất STR theo quyền

Đầu ra mong muốn của luồng trên là một hồ sơ điều tra có thể kiểm tra và tiếp tục xử lý, không phải một lệnh tự động kết luận rửa tiền hoặc khóa tài khoản.

7. Giá trị mà sản phẩm hướng tới

Đối với AML Analyst

• tập trung alert, evidence, graph, case và Agent vào một luồng làm việc;
• nhìn thấy nguyên nhân cảnh báo thay vì chỉ nhận một risk score;
• giảm thao tác thu thập và định dạng thông tin lặp lại;
• xác định rõ phần nào là dữ kiện, phần nào là suy luận và phần nào còn thiếu;
• quản lý SLA, phân công và trạng thái case rõ ràng hơn.

Đối với Compliance Reviewer và Auditor

• kiểm tra được evidence ID, rule/config version, citation và lịch sử thao tác;
• tách vai trò người đề xuất và người phê duyệt;
• phát hiện ghi đè đồng thời bằng ETag;
• có audit trail và release/bundle identity để tái hiện quyết định.

Đối với tổ chức

• giảm phụ thuộc vào quy trình điều tra phân mảnh;
• tạo nền tảng quản trị rule, screening và AI theo cùng một nguyên tắc;
• hỗ trợ triển khai local/private khi dữ liệu cần nằm trong ranh giới kiểm soát;
• tạo điều kiện đo lường hiệu quả thật trong pilot thay vì dựa trên tuyên bố cảm tính.

SENTRA chưa đưa ra con số tiết kiệm chi phí, giảm false positive hay tăng năng suất production vì chưa có pilot trên dữ liệu đại diện và bộ tiêu chí đã được các bên nghiệp vụ phê duyệt.

8. Tính khả thi và bằng chứng kỹ thuật

8.1. Những gì đã được triển khai

8.2. Dữ liệu và AI engineering evidence

Bộ dữ liệu 100K_VIETQR là dữ liệu synthetic được pin bằng manifest/checksum:

• 124.516 tài khoản;
• 845.196 transaction/ground-truth rows;
• 236.979 giao dịch có nhãn synthetic;
• Case RAG tạo đúng 100.000 summary đã che định danh;
• local feature-hash embedding 512 chiều;
• GraphSAGE chạy offline trên 124.516 node và 845.196 edge.

Lần chạy GNN được ghi nhận trong báo cáo FIN07-916 có validation PR-AUC 0,7608 và Top-100 gồm 100/100 node positive. Kết quả này chỉ là shadow research evidence trên dữ liệu synthetic với random node split, không được dùng làm precision production. GNN có decision authority = NONE.

8.3. Kiểm thử đã được ghi nhận

Hồ sơ trạng thái hiện tại ghi nhận lần kiểm chứng gần nhất:

• backend non-contract regression: 857 passed, 5 skipped;
• frontend Vitest: 188 passed;
• frontend lint, typecheck và production build: pass;
• image build/scan thử: không có HIGH/CRITICAL tại thời điểm kiểm tra;
• contract, migration và CI gate baseline đã được thiết lập.

Các số liệu kiểm thử luôn phải đi kèm release/commit cụ thể khi dùng làm bằng chứng chính thức. Working tree thay đổi hoặc một release mới cần chạy lại toàn bộ gate tương ứng.

8.4. Kết luận về tính khả thi

Project đã chứng minh các thành phần có thể nối thành một luồng kỹ thuật hoàn chỉnh và có thể trình diễn lặp lại trên dữ liệu synthetic. Tính khả thi production vẫn là một giả thuyết cần được xác nhận bằng UAT có kiểm soát, dữ liệu đại diện, benchmark, security/resilience evidence và phê duyệt của con người.

9. Giới hạn và rủi ro còn lại

Những hành động sau không thuộc quyền tự động của SENTRA:

• đóng băng hoặc khóa tài khoản;
• kết luận một chủ thể thực hiện rửa tiền;
• tự động đóng case;
• tự động nộp STR cho cơ quan quản lý;
• tự nâng quyền hoặc bỏ qua tenant/purpose;
• đưa raw PII hoặc raw transaction rows ra external provider.

10. Hướng phát triển

Giai đoạn 1 — Hoàn thiện UAT evidence và governance

• chốt exact source SHA, API/Web image digest, SBOM, signature và release manifest;
• hoàn tất migration, rollback, restore và failure-drill receipt;
• benchmark p50/p95/p99, throughput, load/soak và resource saturation;
• hoàn thiện typology E2E evidence cho các rule được chọn;
• phê duyệt rule/list/risk/knowledge bundle;
• chạy source-to-alert reconciliation trên masked dataset;
• hoàn tất review AML, Security, Legal, Data Owner và Business UAT.

Giai đoạn 2 — Pilot trên dữ liệu masked có tính đại diện

• đo precision, recall và false-positive rate theo từng typology;
• đo alert-to-case conversion, thời gian xử lý case, SLA và reviewer rework;
• so sánh baseline trước/sau khi dùng graph và Agent;
• hiệu chỉnh threshold và risk calibration có version;
• đánh giá citation correctness, abstention và unsupported-claim rate;
• theo dõi phản hồi analyst/reviewer và cải tiến Unified Investigation experience.

Giai đoạn 3 — Mở rộng có kiểm soát

• tách hạ tầng theo yêu cầu HA, bảo mật và quy mô thực tế;
• bổ sung trusted HTTPS, production OIDC/service identity và secret/KMS boundary;
• nâng cấp retrieval đa ngôn ngữ chạy private/on-premise khi được phê duyệt;
• nghiên cứu TGN/HeteroGNN nhưng tiếp tục ở shadow mode đến khi vượt promotion gate;
• tăng cường realtime notification, observability, drift monitoring và model/rule registry;
• phát triển analytics cho typology, SLA, workload và chất lượng điều tra;
• chỉ mở Customer Portal sau khi xác định rõ phạm vi dữ liệu, consent, security và quy trình nghiệp vụ.

Roadmap tuân theo thứ tự PROVE → PILOT → SCALE. Dự án ưu tiên chứng minh dữ liệu, kiểm soát và hiệu quả trước khi tăng quyền cho AI hoặc mở rộng hạ tầng.

11. Bộ chỉ số đề xuất cho pilot

Mục tiêu định lượng chỉ nên được chốt sau khi xác định baseline, dataset, typology và cách đo cùng các bên AML, Data Owner và Business.

12. Ma trận trạng thái sản phẩm

13. Kết luận

SENTRA không chỉ là một mô hình AI hay một dashboard cảnh báo. Sản phẩm là một chuỗi giá trị AML theo hướng Evidence-first: chuẩn hóa sự kiện, phát hiện xác định, phân tích quan hệ, lưu bằng chứng, tổ chức vụ việc và sử dụng AI có giới hạn để hỗ trợ giải thích và soạn thảo.

Đóng góp nổi bật của giải pháp nằm ở ranh giới trách nhiệm rõ ràng:

• máy phát hiện, liên kết và hỗ trợ giải thích;
• con người kiểm chứng, phê duyệt và chịu trách nhiệm quyết định.

Phiên bản hiện tại đủ để chứng minh engineering feasibility và thực hiện Demo Day trên dữ liệu synthetic. Bước tiếp theo không phải là tuyên bố production-ready, mà là hoàn thiện UAT evidence, pilot trên dữ liệu masked đại diện và đo lường hiệu quả bằng các tiêu chí đã được thống nhất.

Thông điệp chốt: SENTRA dùng AI để tăng năng lực của điều tra viên — không thay thế trách nhiệm của điều tra viên.

14. Tài liệu và mã nguồn đã dùng để đối chiếu

Tài liệu trạng thái và kiến trúc

• README.md
• ARCHITECTURE.md
• overall_report.md
• FIN07_916_AI_COMPLETION_REPORT.md
• v1.3.0-rc.1 release candidate
• Production readiness
• AI Frontend–Backend Flow and Problem Statement
• Future Roadmap and Extensibility

Cấu trúc code chính

apps/api/                  FastAPI entrypoint, auth, schemas và API routes
apps/web/src/              React/TypeScript UI, repositories và feature pages
packages/contracts/        Canonical event, JSON Schema và contract manifest
packages/domain/           Domain services, persistence và workflow state
packages/rules/            Rule configuration, evaluator, simulation và replay
packages/graph/            Graph materialization, bounded traversal và detectors
packages/screening/        Screening snapshot, service, lifecycle và recovery
packages/risk/             Risk policy, aggregation và calibration
packages/evidence/         Evidence store
packages/knowledge/        Governed ingestion, retrieval, vector và reranking
packages/security/         Authorization, capabilities, PII protection và redaction
src/agents/                Bounded investigation, tools, grounded provider và STR draft
workers/                   Outbox, detection, investigation, screening và STR export
governance/                Rule/model/release manifests và readiness decisions
docs/                      Architecture, business, UAT, security và release evidence