D2 Automation Knowledge

Design Automation from the Source of Truth, Not from Workflow Nodes

A systems-thinking method for mapping events, state, deterministic decisions, failure modes and evidence before drawing an n8n workflow.

Written by: D2 Automation SystemsReviewed by: D2 Systems EngineeringPublished: 2026-08-21Updated: 2026-08-21

Direct answer

The practical answer

Before drawing nodes, define five things: the business event that starts the process, the system that owns each piece of state, the deterministic decisions that must remain explicit, the side effects that need idempotency, and the failure/recovery evidence operators require. The workflow should then implement those responsibilities. Starting from nodes often produces automation that works on the happy path but has no clear answer to 'what is true now?' when something fails.

Engineering model

Event → source of truth → deterministic rules → side effects → evidence/recovery → workflow implementation

01 / Design rule

Name the event precisely

'New lead' is more useful than 'webhook trigger'; 'order refund confirmed' is more useful than 'HTTP request'. Business-event language makes ownership and expected outcomes easier to reason about across tools.

02 / Design rule

One state needs one authoritative owner

A workflow can copy and synchronize data, but it should know which system is authoritative for customer identity, order status, ticket ownership or delivery state. Conflicts cannot be reconciled safely if every copy is treated as equally true.

03 / Design rule

Keep decision boundaries deterministic where possible

AI can classify ambiguous language, extract fields or draft content, but application routing, SLA clocks, financial thresholds and permission checks should normally remain deterministic unless there is a documented reason otherwise.

04 / Design rule

Design the operator experience for failure

Ask what an operator needs when processing stops: event ID, current state, last successful transition, error category, retry status and replay action. If the workflow cannot answer those questions, observability is incomplete even if logs exist.

Implementation checklist

Questions to resolve before calling the workflow production-ready.

Write the business event in one sentence
Name the source of truth for every important state
List deterministic rules separately from AI decisions
Identify irreversible/duplicate-sensitive side effects
Define failure evidence and operator recovery before implementation

FAQ

Why not design directly in n8n?

You can prototype there, but node-first design tends to merge business state, routing and integration mechanics into one canvas. A short system map first makes later workflow choices more deliberate and reviewable.

What is a source of truth in automation?

The authoritative system or record that owns a state when copies disagree. A workflow may maintain projections or caches, but conflict resolution should defer to the declared owner unless an explicit reconciliation rule says otherwise.

Evidence standard

Architecture knowledge, implementation evidence and production outcomes are different claims.

D2 publishes these boundaries explicitly. The methodology page explains what evidence is required before a system is described as implemented, validated or production-backed.

Read D2 evidence methodology

Related system evidence