Products

Two kinds, and conflating them causes confusion.

	Service products	Platform products
What	A delivered engagement	Automation running on ABOS
Sold as	A project with a deliverable	A retainer
Runs on	People	Engines and the tenant stack
Example	Process Map, BOR	Email triage, invoicing

A service product usually sells a platform product. The Process Map produces the report that justifies the automation proposal.

Service products

Product	Deliverable	Docs
Process Map	A report saying what we think is required, ranked, with what each is worth	Requirements checklist
BOR	Light discovery, sells the Process Map	Portal only

Platform products

A platform product is a switch-on pattern over the shared engines. Not a codebase, not a fork, and never built "for" one client (ADR-0002).

flowchart TB
    subgraph P ["Platform products: switch-on patterns"]
        P1["Email triage"]
        P2["Invoicing"]
        P3["…"]
    end
    subgraph E ["Engines: shared machinery"]
        E1["Capture"]
        E2["Progress"]
        E3["Bill"]
        E4["Remember"]
    end
    P1 --> E1
    P1 --> E2
    P2 --> E2
    P2 --> E3
    P3 -.-> E4

Product	Status	Tenant
Email triage	In design	Client-zero, being Octopodia's own inbox
Invoicing	Not started

What a platform product actually consists of

Part	Where it lives	Code or config
Which engines it uses	Product definition	Code
Catalogue actions it can propose	The action catalogue	Code, since each needs an n8n branch
Which actions a given tenant may use	Registry, per tenant	Config
Rules, thresholds, taxonomy	Registry, per tenant	Config
The n8n workflow shape	Templated per tenant	Code, templated

The split is ADR-0003: behaviour is built once in code, and giving it to a client is config. If setting a client up means editing code, something has been designed wrong.

The work item

The unit of work. Every platform product produces them, and the Progress engine moves them through states.

Three things get confused, so they are worth separating:

	What it is	Whose
n8n workflow	The procedure. Identical for every item	Ours
work item	One piece of work we are handling, with a state and a history	Ours
job	The client's actual work, in their system	Theirs

flowchart LR
    J[("job<br/>Preston switchboard")] --> W1["work_item<br/>quote enquiry"]
    J --> W2["work_item<br/>reschedule request"]
    J --> W3["work_item<br/>CoC request"]

One job generates many work items over its life, weeks apart, each a separate conversation. A work item can also exist with no job at all, which is what a new enquiry is before anyone has agreed to anything.

A work item is a case file, not a flowchart. It records what was decided, not what should happen next: the brain re-derives the next action each turn from state plus config, so nothing is precomputed and nothing goes stale (ADR-0032).

A work item covers a conversation, not a single message. Something arrives, and it either joins an existing item or starts one.

flowchart LR
    E(["Something arrives"]) --> Q{"Do we already have<br/>an item for this?"}
    Q -->|"yes"| A(["Attach to it"])
    Q -->|"no"| N(["Create one"])

Look first, then decide. Creating an item and hunting for siblings to merge afterwards is the same operation backwards, and it leaves a window in which a duplicate exists.

What the lookup searches is our own records, not the source system. For email that means the Message-IDs already stored, because every message received and every reply sent was recorded (see email triage).

Adding a platform product

1. Define which engines it uses, and what a work item means for it.
2. Define its catalogue actions, with typed parameters (ADR-0032 §6b, §6e).
3. Implement an n8n branch per action.
4. Template the workflow.
5. Enable per tenant in the registry.
6. Add a Part B readiness section to the Process Map checklist, covering what must be true before the product can be quoted.

Steps 2 and 3 must stay in step. An action with no branch cannot be executed, and a branch with no catalogue entry cannot be proposed. That symmetry is what makes the catalogue closed.

Step 6 is the one that gets forgotten, and it is what stops a product being sold before anyone has asked whether the client can actually support it.