D2 Evidence & Measurement Methodology
D2 Group tách điều source thực sự nói, điều formula tính ra, điều deterministic rule quyết định, điều workflow thực thi và outcome đã được xác minh. Cùng một boundary được dùng cho Commerce Operations, Automation Systems, Work, Insights và các công cụ miễn phí.
Trả lời trực tiếp
Recommendation phải truy ngược được qua năm lớp: source of truth được gọi tên, formula có thể kiểm tra khi cần tính toán, deterministic rule ở nơi consistency quan trọng, execution model có failure ownership và measured outcome khi phát biểu performance claim. Unknowns vẫn là unknowns cho đến khi có evidence phù hợp.
Operating model
Tách layer giúp biết một kết quả yếu đến từ data, calculation, decision rule, execution path hay underlying business condition. Debug đúng layer thường quan trọng hơn thêm dashboard hoặc thêm automation.
Truth
Xác định system, export, event, identifier, cost master hoặc nguồn đã được phê duyệt thực sự trả lời câu hỏi. Dữ liệu thiếu, unmatched hoặc chưa biết phải còn visible thay vì được điền bằng giả định.
Formula
Khi quyết định phụ thuộc economics hoặc measurement, input, period logic và formula phải đủ rõ để một người khác có thể tái tạo cùng kết quả từ cùng dữ liệu.
Rule
Mapping, validation, threshold, state transition, duplicate control và high-impact side effect dùng rule xác định khi reliability yêu cầu cùng input phải dẫn tới cùng control decision.
Workflow
Workflow không hoàn tất chỉ vì node chạy xanh. Input, state, retry, idempotency, duplicate handling, downstream verification, recovery path và owner của failed work phải được xác định.
Outcome
Architecture, implementation và validation evidence được giữ riêng với commercial hoặc production outcome đã đo. Kết quả của một case không được suy rộng thành guarantee cho business khác.
Evidence hierarchy
Architecture evidence có thể chứng minh architecture đã được thiết kế. Execution evidence có thể chứng minh một action đã chạy. Chỉ measured downstream evidence mới hỗ trợ outcome claim tương ứng.
Raw file, API response, event, configuration, database state, marketplace export hoặc approved business input trả lời trực tiếp điều gì đã xảy ra.
Một giá trị được tính từ source evidence bằng formula, join, mapping hoặc aggregation có definition và time basis rõ.
Rule hoặc threshold quyết định proceed, hold, retry, reject, escalate, scale, fix hoặc một state transition khác dựa trên evidence đã có.
Workflow, API call hoặc operator action đã thực hiện một bước cụ thể; execution evidence chưa tự chứng minh downstream business state đã đúng.
Kết quả downstream được xác minh bằng nguồn phù hợp, ví dụ contribution đã reconcile hoặc business state sau automation; đây mới là lớp đủ mạnh cho outcome claim tương ứng.
Commerce evidence model
D2 không gộp marketplace activity, operating economics và financial realization thành một số. Orders và Settlement cũng được giữ riêng vì thường khác population, status và time basis.
Marketplace activity hoặc gross merchandise value trong một scope cụ thể; không mặc định bằng retained revenue, contribution hoặc cash received.
Dùng cho sales-period activity, order status, SKU identity, quantity và commercial-event analysis theo definition đã chọn.
Dùng cho recorded platform deductions, refunds, adjustments, payable amount và cash-reconciliation questions theo settlement timing.
Spend và reporting-period evidence được đặt cạnh cùng commercial scope; attribution metric không tự trở thành accounting profit.
SKU/bundle cost source có stable key và effective period khi cần. Missing cost là exception, không phải zero mặc định.
Operating-management result sau các variable costs đã được đưa vào formula; tách riêng khỏi statutory accounting profit và payout timing.
Automation evidence model
Production automation cần durable state, explicit side-effect controls, observability và recovery ownership. AI interpretation có thể hữu ích nhưng không thay deterministic validation hoặc authoritative state.
Điều gì đã xảy ra, identifier nào đại diện cho event và event có khả năng được delivery lại hoặc đến out-of-order hay không.
Durable state hoặc authoritative system quyết định work nên proceed, retry, stop, reconcile hay recover.
Workflow, API calls và side effects di chuyển hoặc biến đổi work giữa systems; HTTP 2xx hoặc node success chỉ nói đúng phần contract tương ứng.
Authentication, validation, idempotency, bounded retries, rate-limit handling, concurrency và recovery behavior theo semantics của failure.
Execution evidence, failure context, logs/alerts và downstream verification giúp tách technical success khỏi business success.
Reliability hoặc business impact chỉ được claim khi production evidence tương ứng thực sự tồn tại; architecture tốt không tự biến thành outcome.
Claim boundaries
Platform fee, ROAS target hoặc margin benchmark không được coi là con số đúng cho mọi seller khi value cần đến từ evidence của chính business.
Missing SKU cost, unmatched settlement, unknown deduction hoặc incomplete join phải giữ thành exception thay vì làm dashboard trông hoàn chỉnh hơn.
Execution thành công chỉ chứng minh phần technical contract tương ứng; business outcome có thể cần destination verification, reconciliation hoặc async status check.
Prototype, validated workflow hoặc staging pass không được mô tả thành uptime, scale capacity, user adoption hoặc product-market fit nếu chưa có evidence đó.
First-party result chỉ mô tả documented scope, period và constraints của case đó; không suy rộng thành kết quả chắc chắn cho brand hoặc market khác.
AI có thể hỗ trợ extraction, classification, retrieval hoặc drafting; financial values, validation, state ownership và consequential side effects vẫn cần control phù hợp risk.
Một evidence standard, nhiều content intent
Decision-ready checklist
Nguồn trả lời câu hỏi và reporting/event period được gọi tên rõ.
Identifiers, joins hoặc event keys đủ ổn định để kết quả có thể được tái tạo và deduplicate khi cần.
Formula inputs, denominator, period basis và cost scope được công khai khi economics được tính.
Missing, unmatched, duplicate hoặc unknown evidence không bị silently dropped hay converted thành assumed fact.
Validation, mappings, thresholds và high-impact side-effect controls dùng rule xác định khi consistency cần thiết.
Retry, rate limit, duplicate handling và recovery behavior phù hợp với failure type và reversibility của action.
Downstream business state được kiểm tra khi technical success một mình chưa đủ trả lời câu hỏi.
Client, D2, system owner và escalation path được xác định cho cả normal flow lẫn exception flow.
Public claim không mạnh hơn evidence thực sự có; architecture, validation và measured outcome không bị gộp thành một lớp.
FAQ
D2 dùng mô hình năm lớp Truth → Formula → Rule → Workflow → Outcome. Mục đích là giữ source evidence, phép tính, deterministic controls, execution và measured result tách đủ rõ để audit, debug và cải thiện.
Vì một kết quả sai có thể đến từ source data, formula, decision rule, execution path hoặc business condition. Nếu các lớp bị gộp, team khó biết phải sửa dữ liệu, công thức, workflow hay quyết định thương mại.
Không. Source of truth phụ thuộc câu hỏi. Orders có thể sở hữu sales activity, Settlement sở hữu payout/deduction events, cost master sở hữu COGS effective theo SKU, còn CRM hoặc database khác có thể sở hữu customer/workflow state. Quan trọng là authority của từng field được khai báo.
Chúng trả lời ba câu hỏi khác nhau. GMV mô tả marketplace activity, contribution mô hình hóa economics trong cost scope đã chọn, còn payout/settlement mô tả financial realization và timing. Gộp chúng thành một con số doanh thu sẽ che mất khác biệt quan trọng.
Dữ liệu đó trở thành exception có reason để điều tra. Ví dụ unmapped SKU, missing effective cost, unmatched settlement, duplicate join hoặc unknown deduction không được tự động đổi thành zero hay AI-generated guess.
Chỉ ở execution layer tương ứng. Nếu business outcome nằm ở downstream system hoặc asynchronous state thì cần verification/reconciliation riêng. Execution success và business success là hai evidence layers khác nhau.
Không ở nơi kết quả cần deterministic. Financial joins, formulas, validation rules và readiness scoring phải dựa trên explicit rule/input. AI có thể hỗ trợ interpretation khi hữu ích nhưng không thay authoritative calculation hoặc control logic.
Evidence có thể là source files, implemented behavior, architecture, validation records hoặc measured operating outcomes. Page phải nói rõ loại evidence đang có và không claim lớp mạnh hơn, ví dụ không biến implementation evidence thành revenue lift nếu chưa đo được lift.
Không. Case result mô tả period, scope, source và constraints đã công khai của case đó. Market, offer, inventory, operations, data quality và execution context khác có thể tạo outcome khác.
Không. Đây là control và decision framework giúp assumption, evidence, execution và claim dễ kiểm tra hơn. Outcome vẫn phụ thuộc market, offer, operations, implementation quality và các constraint của doanh nghiệp.
Áp dụng methodology
