— <Module / area>

Written for the business. No field IDs, no script names, no system jargon.

The six prompts below are required, in this order, and npm run check warns when one is missing. They are the questions every reader arrives with; answering them in a fixed order means nobody has to hunt.

What it does. One paragraph. The decision this makes and the value it writes back.

Why it exists. The commercial or operational reason, and what it costs when it goes wrong — the cost is usually the real reason the rule exists.

Who it affects. Teams, customers, carriers, suppliers. Name who notices first.

When it runs. Trigger, timing, frequency, and what makes a record eligible.

How it decides. The whole logic at a high level, in five or six bullets — enough that a reader can predict the outcome for a normal case without opening a rule below.

• <first thing it looks at, and what that settles>
• <the next decision, and the usual answer>

Outcomes. The full list of ways this can end, including the ones that write nothing.

LI-BL-XXX-000

Field registry

Every field this automation reads or writes, by the name it carries in the system — what it means, and what changes when it changes. Field ids are in the developer reading.

Every h3 below becomes a collapsible section on the site, so this layer can be as long as it needs to be. A developer should be able to rebuild the behaviour from this alone — and prove it still works. npm run check warns for any of these that is missing, and for any that sit out of the order below.

Keep the order. It is the reading: what it reads · what it does · how it decides · what it writes · that it works · where it bends · what is wrong · where the truth is. Proof comes before problems, because limitations, defects and open questions each have their own generated page now — the entry's job is to establish the behaviour and show it works, then say what is wrong with it.

Do not write a description under a heading. The one-line gloss the site prints under each of these is generated from SKELETON in build.mjs, so it reads the same on every entry. CONVENTIONS.md §15.

Sections of your own are fine — module 5 carries four — and they belong between Processing and Decision tree, or as #### inside Processing. Anything that sets the scene before the mechanism (which version is deployed, say) goes above Inputs. Only the skeleton headings have a fixed order.

on <trigger>:
  if <condition>        -> <outcome>
  else                  -> <outcome>

<subject>
 ├─ <condition> ?  ──► <outcome>                      LI-BL-XXX-000
 └─ otherwise      ──► <outcome>

Diagrams are hand-written HTML. There is no diagram library — the boxes are plain elements the theme styles, so they print, search and copy like text.

The vocabulary is small: .tree wraps a diagram, .row lays boxes out horizontally, .col vertically, .split draws a branch under a decision, and every box is a .node with a data-kind. Connectors are .edge-v (down) and .edge-h (across); .edge-label is a Yes/No label.

data-kind values: start, decision, step (the default), ok (an approved / written outcome), stop (held, rejected, waiting), watch (a step that is known to misbehave).

Every node carries three attributes that feed the hover helper — data-kicker (the rule ID or a short label), data-title, and data-detail (one or two sentences in plain language). Write them for every box: the helper is how a reader who has never seen the system gets through the diagram. Hovering draws the note beside the box being hovered, so it stays readable however far down the diagram you are; clicking pins it into the panel below the legend.

Copy the block below and edit it.