The orchestration prototype, scoped before it is built

Part 1

1What the prototype is

One real journey, defined as data, executed by DBOS, sent through the gate, with events coming back and stopping the sequence for people who reply or unsubscribe. Not a framework. One journey, running.

# A journey, as a file. Shape now settled by the journey-as-data research
# rather than sketched: string ids, string-reference edges, no coordinates,
# content as a POINTER, conditions as expressions.

id: dormant-winback-2026
client: dockblocks                   # a parameter, not an assumption
published: 2026-10-01                # version by publish event, audience pinned per wave

entry:                               # FOUR separate controls, not one. Braze's own
                                     # entry screen splits these, and conflating them
                                     # is how "why did they get it twice" happens.
  audience: audiences/gate1_pilot    # WHO may enter. A pinned ref, not an inline list
  when: 'last_order_at < now - 365d' # WHAT fires. Suppression is not expressed here
  reentry: never                     # may someone who finished start again
  limit: 150                         # entrance VOLUME. Gate 1 is a pilot, so say so

suppression:                         # FIRST CLASS, not a branch condition.
  shared_with: [brevo, mailtrap]     # one truth or a person hears from the other
  stops: [replied, unsubscribed, converted, stop_status]

nodes:                               # edges are string references, like Braze next_paths
  - id: touch-1
    type: message
    content: blocks/winback/touch-1  # a pointer. Copy lives with the blocks, not here
    tag: winback-2026.touch-1        # PER NODE, not per campaign. Brevo reports by
                                     # campaign, so without a tag per step nobody can
                                     # say which STEP earned the open. An untagged
                                     # message is permanently unattributable.
    absent: abort                    # this person only, journey continues
    next: wait-5d

  - id: wait-5d
    type: wait
    for: 5d
    next: did-they-open

  - id: did-they-open
    type: decision                   # an EVENT inside a WINDOW, not a state read.
    event: opened                    # Mautic names the two outcomes yes and no and
    of: touch-1                      # records which path a person took (decisionPath).
    within: 5d                       # Without the window this silently means "ever".
    yes: touch-2a
    no:  touch-2b

  # A BRANCH is the other thing, and conflating them is the trap: a branch reads
  # STATE right now, first match wins, so the ORDER of its paths IS the rule.
  #   - id: which-tier
  #     type: branch
  #     paths: [{when: 'ltv > 5000', next: vip}, {default: standard}]

  - id: touch-2a  { type: message, content: blocks/winback/touch-2a, next: done }
  - id: touch-2b  { type: message, content: blocks/winback/touch-2b, next: done }
  - id: done      { type: exit }

# No holdout node: a holdout is a branch with an empty path, which is what every
# vendor checked actually does. Inventing a primitive for it would be our own idea.

The candidate is win-back. It is already a definition file rather than code, its audience exists, gate 1 is a 150-address pilot stratified across five owners, and it is deliberately plain text. That last part is why it is the right pilot: it proves orchestration without dragging composition in beside it.

Explicitly out of scope: a second journey, a composition surface, multi-tenancy, and any editor. The client stays a parameter rather than an assumption, which costs nothing now and is expensive to retrofit, but nothing is built FOR other clients yet.

Part 2

2What already exists, and is already in use

The CDP is delivered and in production. This prototype is not built on an empty foundation, and saying otherwise would misrepresent work that is already carrying the reports everyone reads each morning.

This also reframes what success looks like. A journey that reads person_lifecycle at send time, refuses on consent_state, and writes its outcome back where the next send can read it, is the whole point. Nothing about that requires new infrastructure.

Part 3

3Where it lives, and who owns which half

This is the decision the prototype actually forces. Today the boundary is implicit and both sides are quietly assuming different things.

Part 4

4How we use it

If adding a journey is not write one file, open a pull request, then watch it run, the prototype has not worked.

1. Write the definition. A file in the campaigns directory: entry, audience, steps, waits, branches, exits, sender. The format comes out of the journey-as-data research, not from this document.
2. Review it. A human reads the definition, not the code. That is the test of whether the format is legible: Alecia should be able to tell what a person will receive without opening a renderer.
3. It runs. DBOS executes per person. A deploy does not silently strand anyone, because the version-mismatch sensor says when workflows are stuck on an old application version.
4. Events return. Mailtrap webhooks land, are persisted, then fire a run that updates state. A reply or an unsubscribe stops the sequence for that person.
5. State is reportable. The catalogue row for that journey moves up its own ladder, and the five checks are answered rather than assumed.

Part 5

5How we know it worked

Not invented here. The catalogue already defines the bar, and nothing in 62 rows has ever reached it.

The prototype is done when ONE journey is VERIFIED: all five true and monitoring closed. That is a definition we did not choose, cannot argue with, and have never met.

Part 6

6What we are not building

Written down so it does not get built by accident, and so a later session does not read the gaps as an oversight.

• A composition surface. That is the next problem, not this one, and the editor research priced it: nothing self-hostable has both block locking and MJML round trip, and the real candidates run $3,000 to $14,400 a year.
• Multi-tenancy. The client is a parameter. Nothing is built for a second client until a second client exists.
• A replacement for Brevo. Lifecycle keeps leaving from Brevo. Mailtrap carries volume so the Brevo reputation is not the thing at risk.
• A canvas UI. A journey is a file a person can read. If the file is not legible, a diagram over the top of it will not fix that.
• Anything that moves live programs. Thirty-six are running and none of them is waiting for this.

Part 7

7Open, and who holds each one

Nothing here is a research question. Each is a decision somebody has to make.