Turning workflow events into explicit write plans.

THE WORK

The project.

I'm building Retail Workflow Prototype as reusable n8n steps that turn a supplied purchase event into proposed order, inventory and workflow records. Each module adds its output to a shared record bundle, and a planner checks where those records should go. External writers aren't connected yet, making this a record-planning implementation rather than a running business automation.

IMPLEMENTATION

Design choices.

1. Processing modules build records while one planner decides their destinations. This keeps runtime history and durable business data separate without embedding live storage clients throughout the workflows.
2. recordBundles stays beside the run context as a top-level array. Appending lets later modules preserve earlier proposed records instead of replacing them or hiding them inside context metadata.
3. External tasks are described before their executors are connected. That makes the intended requests visible, but budget results and permission flags still need enforcement before any dispatch can be treated as authorized.
4. Record keys distinguish business identity from workflow identity: order-derived keys describe the supplied purchase, while trace and stage identify runtime history. Retries depend on preserving that context, and line-position keys need care when input lines are reordered.
5. A persistence plan needs execution results before it can support recovery. Future writers must validate each destination's fields and return individual receipts, so one successful write doesn't conceal another that failed.

HOW IT FITS TOGETHER

Architecture.

• A parent workflow normalizes its trigger and creates or preserves the run context before calling JavaScript subworkflows. The processors use the supplied event to prepare records and follow-up tasks, appending to the top-level recordBundles array without discarding earlier output.
• Each bundle names its store, table, action, idempotency key and fields. The shared persistence planner rejects missing routing fields and unsupported stores, then separates the proposed operations by destination. An unspecified action defaults to upsert; the planner itself performs no write.
• Order, item and inventory records target the business store. Runtime records use trace and stage identity in a separate store, so the plan can express both the business event and the workflow's progress without giving every processing module a storage client.
• Approval, browser, language-model and messaging work is also prepared as task payloads. The corresponding external executors aren't connected, and payload flags don't yet provide enforced dispatch permissions.
• Parent workflows reference local subworkflow exports. Deployment still needs those references mapped to the destination runtime. The related ledger and research builds are separate implementations, not demonstrated integrations with this prototype.

ACCESS & INPUT

Security controls.

• Browser task payloads prohibit payment, final checkout, irreversible actions and financial-record edits. These are instructions for a future executor, not permissions enforced by the current exports.
• Approval creation includes an expiry, but decision intake doesn't yet authenticate the actor, load the pending request or enforce its expiry. A supplied approval field isn't sufficient authority for dispatch.
• The budget calculation can report that a task exceeds what remains without stopping the parent path. A later payload may still be marked ready, so dispatch needs an explicit enforced refusal.
• The persistence planner checks routing fields and supported stores. Table-specific field validation and independent verification of the supplied event remain outside that check.

SELECTED DEVELOPMENT RECORD

Engineering changes.

Implementation dates come from project records. “Recorded” is the date this portfolio entry was written.

1. Replacing placeholder steps with reusable record planningaddedRecorded 11 September 2026

   JavaScript modules now prepare context, records and external-task payloads, then assemble proposed writes by destination. Storage writers and external workers remain unconnected.

   Source observedChanged 19 March 2026

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app