Skip to main content
D2 Group
ENVI

D2 Work · First-party evidence

Proof, with the evidence boundary attached.

D2 Work is the evidence layer behind Commerce Operations, Business Automation and Search & AI Visibility. Each case is meant to show the operating problem, the evidence available, the implementation or decision logic, and where the public claim stops.

3

Evidence lines

4

Commerce cases

11

Automation cases

1

Search cases

Direct answer

What does a D2 case study actually prove?

Only what the published evidence supports. Commerce cases can use source-backed operating data and commercial analysis. Automation cases may use workflow snapshots or architecture logic. Search cases can use repository, CI, runtime and measured visibility evidence. Those evidence types are labeled rather than presented as equivalent outcomes.

Marketplace operations

Can D2 own recurring marketplace execution and commercial review?

Start with Commerce cases covering TikTok Shop, Shopee, campaign execution, creator commerce and marketplace economics.

Commerce operating evidence
Profitability & reporting

Can D2 explain why GMV, payout and contribution disagree?

Review commerce cases where Orders, Ads, fees, COGS, settlement and SKU economics are reconciled before decisions are made.

Source-backed reconciliation evidence
Production automation

Can D2 design automation beyond the workflow canvas?

Review n8n, API, webhook, queue, state, retry and recovery cases with explicit architecture and evidence boundaries.

Architecture evidence
Data & AI workflows

Can D2 add data or AI without hiding control and failure modes?

Review data integration, reconciliation, RAG, document and routing cases where evidence status is kept separate from production outcome claims.

Workflow and architecture evidence
Search / AEO / GEO

Can D2 show how it applies Search & AI Visibility to its own site?

Review the first-party D2 implementation case from frozen baseline through canonical, entity, authority, citation-asset and release-quality controls, with ranking and AI-citation outcomes explicitly left unclaimed until measured.

Repository, CI and runtime evidence

Three evidence lines

Commerce, Automation and Search proof answer different questions.

Commerce Operations

Operating ownership, economics and marketplace decisions.

The Commerce branch contains all four canonical marketplace cases, including cross-border work. Read them for operating scope, commercial inputs, reconciliation logic and the decision that followed.

Mì Cay Dozin

GMV Max, P&L, reconciliation and SKU economics

Source-backed commerce operating analysis

Dozin U.S. Cross-Border

Cross-border marketplace execution through a U.S. distribution context

Source-backed operating case with explicit scope boundary

E.O Wins Coffee

Creative testing, KOC/creator and commerce growth loop

First-party creator and creative operating case

Wins Food

TikTok Shop, multi-SKU profitability and short-cycle reporting

Source-backed multi-SKU commerce analysis

Browse Commerce Work

Business Automation

Workflow evidence, architecture controls and production boundaries.

Automation cases explicitly carry an evidence type and status. A proof of concept, architecture prototype and production telemetry are not treated as the same claim.

n8n Infrastructure

Automation Infrastructure

Architecture evidence; deployment telemetry not claimed·Infrastructure architecture

Data Integration Hub

Data Integration

Architecture + workflow logic·Integration architecture

Finance Reconciliation

Finance Operations

Source-backed architecture; production outcomes not claimed·Architecture prototype

AI Email Routing

Email Operations

Proof-of-concept workflow·Proof of concept
Browse all 11 Automation cases

Search & AI Visibility

Technical implementation evidence before ranking storytelling.

Search Work documents baselines, canonical/entity/evidence controls, release state and measured visibility when available. Source-state proof is never extended into ranking, AI citation or revenue claims without the corresponding observation data.

Evidence standard

Evidence before storytelling.

A useful case study should help a buyer distinguish what happened, what was observed, what was designed and what remains unproven. D2 uses four public evidence checks across the Work library.

Operating problem

The case should state the business or system problem before presenting the solution, tools or implementation pattern.

Evidence type

Source-backed operating data, workflow snapshots, architecture logic, prototypes and production telemetry are not treated as interchangeable evidence.

Status label

Automation cases state whether the evidence is a proof of concept, architecture prototype, workflow-backed system or another documented status.

Claim boundary

A case does not imply uptime, scale, savings, revenue lift or client outcomes that are not supported by the evidence published with it.

How to read a case

Problem → evidence → logic → boundary → fit.

01

Operating problem

02

Evidence available

03

Decision / architecture

04

Claim boundary

05

Fit for your case

Work FAQ

Questions buyers should ask about case-study evidence.

What is the D2 Work library?

D2 Work is the first-party case-study and evidence library for D2 Group. Commerce cases document operating problems, economics and decisions. Automation cases document workflows and architecture. Search cases document technical Search/AEO/GEO implementation evidence and measured release state without extending those facts into unmeasured ranking or AI-citation outcomes.

Are all D2 case studies production client outcomes?

No. Each case should be read according to its evidence and status. Some automation cases are architecture prototypes, proofs of concept or workflow-backed designs rather than claims about live production performance.

How are Commerce and Automation case studies different?

Commerce cases focus on marketplace ownership, commercial inputs, economics and operating decisions. Automation cases focus on system design, workflow evidence, reliability controls, failure handling and architecture boundaries.

Why does D2 show an evidence or status boundary?

Because a workflow screenshot, architecture diagram, source-backed commercial analysis and measured production outcome prove different things. The boundary helps readers evaluate the case without extending the claim beyond the available evidence.

Do case studies guarantee the same result for another business?

No. A case study demonstrates how a specific problem was analyzed or implemented. Marketplace economics, products, traffic, data quality, systems, budgets and operating constraints differ between businesses.

Does D2 publish confidential client data?

Public cases use only information suitable for publication. Where implementation details or source material need protection, the public case can use sanitized workflow, architecture or operating descriptions instead of exposing credentials, private data or confidential system details.

How should I use these cases to evaluate D2?

Start with the problem closest to yours, then inspect the evidence type, operating or architecture logic, ownership boundary and what the case explicitly does not claim. Fit matters more than finding an identical brand or tool stack.

Where can I browse all D2 cases?

Use Commerce Work for marketplace cases, Automation Work for workflow/data/API/AI/infrastructure cases, and Search Work for technical SEO/AEO/GEO implementation evidence. The main Work page connects all three evidence lines.

Your operating problem

Use the nearest case as evidence, not as a promise.

Bring the business problem, current systems and source evidence. D2 can then scope whether the relevant path is Commerce Operations, Business Automation, Search & AI Visibility or a combination with explicit ownership boundaries.

Talk to D2