From incoming signals to comparable facts and connected cases.
A supplier confirms an order on Monday. A dispatch update follows on Wednesday. A delivery notice comes on Friday. Three messages, one purchase. Software needs to understand that relationship before it can do useful work.
I have spent this summer building and working with Signal Flow. Here I follow the architecture from an arrival to an identifiable piece of work. The supplier example is illustrative; the mechanisms come from the system I have been developing.
The role symbols return from the model-routing article. Each badge names a job. Different models can do that job.
An arrival is an input received by the system. A case is a concern it can work on. The Splitter proposes what belongs together: several products in one order may be one concern; two independent requests may need separate cases.
For work that continues from an arrival with content, the split proposal is followed by a saved source record before cases are created. Depending on the input, that record preserves the text or uses an Extractor digest. This first question is about retaining the arrival's information; later extraction asks for business-specific fields.
A single concern can proceed automatically when its gate is satisfied. A proposed division into several cases can wait for review while a provisional case carries the whole arrival forward. Each case remains linked to its source. Splitting too aggressively can still lose shared context.
The Router first chooses a workflow, the business process responsible for the case. It receives the applicable workflow choices, their interests and routing guidance, alongside the case material. In our example, the answer is Purchasing.
The workflow can supply a field contract. The Extractor uses it, extraction guidance and the case content to produce structured facts. Where extraction is unnecessary or no usable contract exists, the source record can pass through to the next question.
The Router now chooses among the selected workflow's lanes. Case facts, lane descriptions and guidance for this question help it choose. A particular supplier is one possible lane; another company might divide work by product family or contract category.
A lane can bring its own extraction contract. When that contract needs applying, the Extractor reads the case content again before Intent. The new fields answer the lane's question. This is a conditional step, not an extra model call required for every case.
The Router chooses an intent using the lane, case facts, candidate meanings and Intent guidance. Order confirmation, dispatch update and delivery notice are different meanings within the purchase example. Routing makes the same case more specific; it does not split it three times.
Workflows contain lanes. Lanes can select their candidate Intents from a shared vocabulary. The same Intent may be relevant to several lanes. If a lane has no active scoped choices, my implementation falls back to the active Intent vocabulary.
Domain memory is guidance retained from earlier work and corrections. My routing guidance describes each workflow; separate memory for Extraction, Lane, Intent and Normalization serves those questions within it. More specific work needs relevant guidance, not necessarily a larger pile of text.
I distinguish the role's instructions, selected domain memory, reference context and the case data. A field definition says what to look for; the case supplies a possible value. These concerns are composed differently for different jobs. They help me ask whether a bad answer came from the question, its guidance or its evidence.
For normalization, a lane's field contract can replace the workflow's base contract. The applicable Intent fields are then added. A dispatch update and a delivery notice can therefore share an order reference while asking for different event details.
The Normalizer proposes structured fields with source support. Code checks grounding and puts values into comparable forms. A dispatch date is not an expected delivery date; an absent value should stay absent. Even a value found in the source may belong to the wrong event. Deterministic processing can carry a bad assumption forward.
Declared recipes let code compose strong keys from grounded fields. The lane's key recipes take precedence when present; otherwise the workflow's apply. This is the hinge I care about: a model interprets the source, then ordinary comparisons can operate on an explicit identity.
A matter connects cases about one continuing concern. Correlation first tries declared strong keys against open matters in the same workflow, including keys contributed by their member cases. The search can cross lanes: a carrier update and a supplier confirmation may share a meaningful identity.
Two matching matters are an ambiguity; missing keys need another route. The deterministic tier declines to choose when the evidence cannot settle it. Correlation can also abstain while the case continues to DECIDE. A successful matter match is useful context, not a prerequisite for every decision.
Even a verified key match is saved as a proposal. Acceptance writes the matter membership. A person can inspect, accept or redirect the proposed connection. The cases retain their own histories while the matter explains why they belong together.
I built the Signal Flow board to make the work inspectable. If an identity looks wrong, I want to follow it back through normalization, Intent, Lane and Workflow, then check the source. Corrections need a place in that history too.
A company supplies its vocabulary and contracts. Signal Flow gives those declarations a path from incoming information to structured, connected work. Part B follows the next boundary: turning that understanding into application records and actions.
