Skip to main content
D2 Group

D2 Evidence & Measurement Methodology

Evidence first. Formulas and rules second. Execution third. Claims only after measurement.

D2 separates what the source says, what a formula calculates, what a deterministic rule decides, what a workflow executes and what was actually measured. That boundary is used across Commerce Operations, n8n Automation, case studies and free tools.

Direct answer

How does D2 decide whether an operating recommendation is reliable?

The recommendation must be traceable through five layers: a named source of truth, an inspectable formula when calculation is required, deterministic decision rules where consistency matters, an execution model with failure ownership, and a measured outcome when a performance claim is made. Unknowns remain visible instead of being converted into assumed facts.

Operating model

Truth → Formula → Rule → Workflow → Outcome.

The layers are deliberately separate. That makes it easier to identify whether a bad result came from the source data, the calculation, the decision rule, the execution path or the underlying business condition.

01

Truth

Start from a named source of truth.

Identify the system, export, event, identifier or approved cost source that answers the question. Missing or unmatched evidence remains visible instead of being silently guessed.

02

Formula

Make the calculation inspectable.

When a decision depends on economics or measurement, the formula and period logic should be explicit enough to reproduce from the same inputs.

03

Rule

Separate deterministic decisions from interpretation.

Thresholds, mappings, validation, state transitions and side-effect controls are deterministic wherever reliability requires the same input to produce the same decision.

04

Workflow

Execution needs ownership and failure behavior.

A workflow is not complete because a node turns green. Inputs, state, retries, duplicate handling, recovery paths and the owner of failed work must be defined.

05

Outcome

Only measured outcomes become performance claims.

Architecture, implementation and validation evidence are kept distinct from measured commercial or production outcomes. A case result is not extrapolated into a future guarantee.

Commerce evidence model

GMV, contribution and payout are different operating questions.

D2 does not collapse marketplace activity, operating economics and financial realization into one number. Orders and Settlement are also kept distinct because they answer different questions and often use different time bases.

GMV

Marketplace activity or gross merchandise value. It is not automatically retained revenue, contribution profit or cash received.

Orders

Used for sales-period activity, order status, SKU identity, quantity and commercial-event analysis.

Settlement / Income

Used for recorded platform deductions, refunds, adjustments, payable amounts and cash-reconciliation questions.

Ads

Spend and reporting-period evidence used to evaluate media cost against the same commercial scope.

COGS

A controlled SKU or bundle cost source with a stable key and effective date. Missing costs remain an exception.

Contribution

A modeled operating result after the variable costs included in scope. It remains separate from accounting profit and payout timing.

See the GMV-to-profit model

Automation evidence model

A successful execution is not automatically a successful business outcome.

Production automation requires durable state, explicit side-effect controls and recovery ownership. AI interpretation can be useful, but deterministic validation and high-impact side effects need a stable control layer.

Business event

What happened, which identifier represents it and whether duplicate delivery is possible.

Source of truth

The durable state or authoritative system that decides whether work should proceed, retry, stop or be recovered.

Execution

The workflow, API calls and side effects that transform or move work between systems.

Reliability controls

Authentication, validation, idempotency, bounded retries, rate-limit handling, concurrency and recovery behavior.

Observability

Execution evidence, failure context and downstream verification needed to distinguish technical success from business success.

Production outcome

Measured reliability or business impact only when production evidence exists; architecture alone is not treated as an outcome.

See the production-readiness controls

Claim boundary

What D2 deliberately does not infer from incomplete evidence.

No generic platform fee or ROAS benchmark is presented as seller truth when the value should come from the seller's own evidence.

No missing SKU cost, settlement join or financial deduction is filled with an AI-generated guess.

A validated MVP or workflow is not described as production adoption, uptime, scale capacity or product-market fit without that evidence.

A case-study result describes the documented case and is not a guarantee that another business will produce the same result.

AI may assist interpretation, extraction, classification or drafting, while deterministic validation and high-impact side effects remain bounded by explicit controls.

How this appears across D2

One evidence standard, different content intent.

Insights

Explain the decision model, definitions, failure modes and implementation logic before a commercial recommendation.

Tools

Expose formulas or scoring rules so users can see how the result is derived. Tool output is decision support, not a guarantee.

Work

Show first-party implementation or operating evidence with a clear line between what was built, validated and actually measured.

Services

Define what D2 owns, what the client owns, the operating scope, deliverables and the evidence required to make decisions.

Technology

Describe system architecture, source-of-truth boundaries, reconciliation, observability and recovery without turning architecture into an unsupported performance claim.

Tool citation contracts

Eight deterministic tools with stable formulas, boundaries and citation anchors.

Each tool publishes its model version, last-reviewed date, formula or scoring rules, input/output contract, limitations and worked example at a stable #methodology anchor. The same contract is exposed in structured data so human readers and machine systems receive the same semantics.

Release checklist

Before D2 treats a recommendation or system output as decision-ready.

The source that answers the question is named and the reporting period is explicit.

Identifiers and joins are stable enough to reproduce the result.

Formula inputs and cost scope are visible where economics are calculated.

Missing, unmatched or unknown evidence is surfaced as an exception.

Deterministic rules own validation, mappings and high-impact side-effect controls.

Retries, duplicate handling and recovery behavior match the semantics of the failure.

A downstream business outcome is verified when technical success alone is insufficient.

Any public performance claim is no stronger than the measured evidence available.

FAQ

Evidence, formulas, AI and claim boundaries.

What is D2 Group's operating methodology?

D2 uses a five-layer model: Truth → Formula → Rule → Workflow → Outcome. The purpose is to keep source evidence, calculations, deterministic controls, execution and measured results separate enough to audit and improve.

Why does D2 separate GMV, profit and payout?

They answer different questions. GMV describes marketplace activity, contribution models the operating economics included in scope, and settlement or payout describes financial realization and timing. Combining them into one number hides important differences.

Does D2 use AI to decide financial values or production readiness scores?

Not where the result should be deterministic. Financial joins, formulas, validation rules and readiness scoring are rule-based. AI can be added as an interpretation layer when useful, but it does not replace the authoritative calculation or control logic.

What counts as evidence in a D2 case study?

Evidence can include source files, architecture, implemented workflow behavior, validation records or measured operating outcomes. The page should state which kind of evidence exists and avoid claiming a stronger outcome than the evidence supports.

How does D2 handle missing or unmatched data?

It remains visible as an exception. Examples include unmapped SKUs, missing effective costs, unmatched settlements, duplicate joins or unknown deductions. The system should not silently convert uncertainty into a confident number.

Does this methodology guarantee a business outcome?

No. It is a control and decision framework designed to make assumptions, evidence and execution more inspectable. Business outcomes still depend on the underlying market, offer, operations, data quality and implementation context.

Apply the methodology

Need a commerce or automation system whose assumptions can be inspected?

Bring the source data, workflow or operating problem. D2 can help define the evidence, formulas, controls and ownership needed to turn it into a decision-ready system.

Start a conversation