Six kinds of signal. One decision to act.

Six lines of signal all land in one place.

Six kinds of signal feed into one place. When several related signals land at once (the same vendor, the same item) they are held briefly so Polymr can act on the combined result instead of each one separately. The signals that survive get two checks: are the facts they reference still current, and are the rules satisfied. Anything that clears both becomes a workflow run, handed to the workflow that owns the action. The board below is what those runs look like in the product: four columns for the four stages, active runs as cards, each one carrying the item it is driving and who is on it.

Wait for the related signals to settle, then act on the combined result.

We do not just put a uniform delay on everything. Instead, Polymr holds a signal open briefly, watches for related signals on the same item (the same vendor and item for a purchasing action, the same PO line for a write-back), and combines them in one of three ways: keep the latest, add the quantities, or merge field by field. The rule for which way to combine is part of the workflow itself, written in code and reviewed alongside it.

A vendor that sends three revised quotes in thirty seconds produces one action when the window closes, carrying the latest version. No race to the queue. No quiet last-one-wins. The audit row records each one that was folded in, so a buyer asking why a particular revision did not survive gets a clear answer.

Six kinds of signal. One wait. Two checks. One action.

The diagram below names every step. Signals on the left, the wait-and-check column in the middle, the action on the right. A signal that fails a check writes an audit row and stops; one held back by a rule sits in a holding slot and gets re-checked on the next pass.

Check the facts first. Check the rules second.

The check runs in two parts, not one. First, Polymr looks up the specific fields the workflow needs from the shared picture of the plant. If any of those fields are stale or missing, the signal is rejected and never even gets to the rules check. Second, the rules check compares the signal against the compute and write budgets. If Polymr is already at its limit for that destination system, the signal waits instead of racing in and tripping a rate limit.

Splitting the check in two is what lets every refusal come with a specific reason. A refusal tells you which check refused, which field it was looking at, and which limit was hit. Most "why did it not fire?" investigations end here, in one click from the debug screen.