Processing Network Module

Status: Designed, partly built. What exists in the runtime: a station type with an opaque identity that other modules store and copy forward — a demand item records the station it was released at this way. What does not exist: loops have no code referent at all (no type, no identifier, no reference anywhere in the runtime’s resource modules), and neither stations nor loops have any retirement — no retire act, no retired state, no latch. The concepts below are defined far enough to anchor the kanban and demand modules; the rest is design ahead of implementation, and the sections say which is which.

Purpose

The processing network is the map of where work happens and how material flows between those places. It has two concepts:

A station — a place within a facility that consumes input materials, applies a transformation, and produces output materials (a CNC machine turning a blank into a part, for example). A station is therefore both a consumption point for its inputs and a production point for its outputs — and the natural anchor for kanban card placement, bin organization, and shop-floor activity as those workflows are designed.
A loop — a configured, directed route between two stations that kanban cards circulate within. Loops are designed to eventually drive the routing of material between consumption and replenishment points; the canonical domain reference is RES::LOOP.

The module exists mainly to give the Kanban Cards and Demand modules something concrete to point at — the station a demand item is made at, and the loops cards travel around.

Context

Processing Network is a leaf of the domain map: it depends on no other domain module, and two modules point at it. Clients sit to the left of the servers they depend on; every arrow is a dependency the client calls, and together they form a DAG.

PlantUML diagram

What this module consumes:

Nothing — Processing Network sits at the bottom of the module dependency chain, alongside the reference-data modules.

What its clients consume from it:

Kanban Cards — a card is designed to be configured with the loop it travels: which station consumes and which supplies. No card carries a loop today, because the runtime has no loop type to carry.
Demand — a demand item is made at a station (part of its identity).

Station identity is the part that exists today, as an opaque stored identity: other modules store it and copy it forward, and nothing resolves it (a demand item’s station_eid, see Demand’s data model); there is no operation surface on top of it. Loop identity exists nowhere — there is no loop type in the runtime to resolve, so every statement above about loops describes the design (see Lifecycle).

Main entities

PlantUML diagram

Station — a node in the network. Two boundary varieties sit at the edge of the modeled system: a source station is a pure producer whose internal process is outside the network (Procurement, which sources from vendors), and a sink station is a pure consumer from which material leaves the system (Shipping).
Loop — a directed route from a source station to a sink station. A card’s full lap is one circuit of one loop; the number of cards circulating in a loop is what makes it single- or multi-card.

The network is directed and may be cyclic

The full system is a directed network of stations linked by loops. Because real manufacturing has re-entrant flows — a station’s output can feed back to an earlier station — this network can contain cycles. That is expected and unproblematic: it describes physical material flow, which is legitimately circular.

Lifecycle

Stations and loops aren’t state machines — they’re configuration. The processing network changes slowly and deliberately, when the physical network itself changes (a line is re-tooled, a new loop is set up between two work centers), not in response to day-to-day operational events. One piece of lifecycle exists for each entity: the retirement latch — a one-way mark taking it out of service. Deliberately, that is a structural mechanism of the network itself, not the versioned lifecycle the reference-data modules (Item, Business Affiliate, Staff) carry: the network’s shape and its members’ identities don’t version, they get marked.

Station

A station exists from the moment it is created, and a re-tooled line standing up again is a new station rather than an edit to the old one.

Retirement is designed and not built: the runtime carries no retire act, no retired state and no latch for a station. Read the one-way retirement below as the intended shape rather than as behaviour available today. References from other modules (a demand item’s station) stay lightweight and are not gated on a retired station for now; the full operation surface (create, edit, the gates) is deferred until the loop-management capability is built out.

Loop

A loop is the same in design: it exists from creation, a route that stops being used is superseded by a new loop rather than closed on the old one, and its retirement is likewise designed and not built. Loops go further than that — the runtime has no loop type at all, so everything this section says about them describes an intended design with no implementation behind it yet. A card configured with a retired loop is not re-gated today — the same deferral as the station’s.

One commitment does follow from that framing, and it reaches forward into how other modules must treat a station or loop reference: when something else in the system freezes a reference to one — a demand item recording where it was released, a kanban card recording which loop it travels — that reference has to survive a later edit to the network. What a document stores is the station’s opaque identity — never a resolved destination, seeded when the document is created and copied forward unchanged thereafter. Because nothing resolves it, a later edit to the network cannot ripple backward and change what the document meant when it was created.

This is not a version pin, and the page deliberately avoids that word. Elsewhere on this site a pin means a record plus a specific version, resolved as-of — see the reference-data module pattern. A station reference carries no version and is never resolved; its stability comes from being an identity that means one thing forever, not from selecting a version of something that changes.

Notifications

Processing Network doesn’t announce anything, and it doesn’t listen for anything either — see how modules stay in sync for the general mechanism this module simply isn’t plugged into. Nothing changes state here for another module to react to, and the module has nothing below it in the dependency map to listen to.

Scenarios

The design source has no end-to-end scenario material for this module yet: with no operations of its own on the API surface — stations are administered through the data-authority layer rather than through module endpoints, and loops have no runtime type at all — there’s no workflow to walk through here. Station and loop identities exist to be pointed at — by Kanban Cards (which loop a card travels) and Demand (which station a demand item is made at) — and it’s those modules’ own scenarios that show the reference in use.

Guarantees

Both of these are designed and not built, like the lifecycle above: the runtime has no loop type at all, and neither stations nor loops have any retirement — no retire act, no retired state, no latch. Read them as the rules the module is meant to hold, not as behaviour available today.

A loop connects two distinct stations in the same tenant — no loop points at itself, and a loop does not cross tenant boundaries.
Retirement is one-way. A retired station or loop never returns to service under the same identity; standing up the line again is a new station or loop.

How it relates to its neighbors

Kanban Cards — cards circulate within loops; a card’s lap is one circuit.
Demand — a demand item is made at a station (its source/production point).

Linear

Initiatives: Product / Resources / Stations · Product / Resources / Loops