Architecture evidence
System boundary, component, trách nhiệm và failure path được mô tả rõ. Mức này chứng minh design reasoning, không đồng nghĩa đã deploy.
D2 Evidence Methodology
Automation rất dễ bị overclaim. D2 dùng evidence ladder rõ ràng để khách hàng, search engine và technical reviewer phân biệt phần nào là design, implementation, validation và phần nào thật sự được quan sát trong production.
Evidence ladder
System boundary, component, trách nhiệm và failure path được mô tả rõ. Mức này chứng minh design reasoning, không đồng nghĩa đã deploy.
Có workflow snapshot, configuration hoặc source implementation để hỗ trợ các claim kỹ thuật cụ thể về node, routing, field hoặc system behavior.
Hệ thống có implementation artifact với input, output, deterministic boundary và failure/recovery logic có thể quan sát.
Implementation được chạy qua test case, expected outcome hoặc recovery scenario đã khai báo. Validation chỉ được claim trong đúng phạm vi đã test.
Deployment, runtime telemetry, execution history hoặc operational record hỗ trợ claim về production behavior thực tế. Architecture đơn thuần không được nâng lên mức này.
Operating hoặc commercial outcome được đo với period, metric definition và attribution boundary rõ ràng trước khi gắn kết quả đó với hệ thống.
Evidence boundary · không claim
Cách đọc một D2 case study
Vì sao chọn boundary, source of truth hoặc failure-control này và trade-off đi kèm.
Source, workflow hoặc artifact nào hỗ trợ claim, gồm input, output và recovery behavior khi có.
Những gì không được claim vì chưa có production telemetry, evaluation hoặc business outcome đã đo.
Xem methodology được áp dụng
Áp dụng tiêu chuẩn