Inside Signal Flow: declared records, explicit authority and accountable execution.
A case has found a workflow, lane and intent. Its facts have been normalized, and related cases may share a matter. What should that understanding change?
This is where I have spent much of my time on Signal Flow: connecting interpreted information to application records and actions. During the summer, I ran work through DECIDE, ACT and LEARN and kept refining those connections.
A decision needs a precise destination. An action needs authority and an observable result. Those boundaries also give a person somewhere to intervene.
A decision bucket says where information belongs and what saving it means. The application declares its meaning, save effect, symbol and colour. The same declaration helps DECIDE choose a destination and helps a person recognise it on the board.
A bucket binds to an action kind, the operation that writes its records. The record schema belongs to that action kind: fields, types, required values and permitted references. Several buckets can share a write tool. An application plugs into Signal Flow by registering these declarations.
A record can refer to other entities, including the legal entity that owns it. These references can appear as facets beside the record. The application can also derive extra facets that enrich the view while leaving the stored payload unchanged.
In a simple, synthetic purchase example, confirmation, dispatch and payment information contribute to the same purchase record. One case can also contribute several records: a purchase update, a follow-up and an appointment. A case and a business record have different lifetimes.
Selected normalized facts help prepare the decision's context. In my implementation, a cited counterpart name and the case's lane help find candidate application references. The Decision proposer receives those identifiers when proposing a record.
The Decision proposer reads the source, interpreted context and application vocabulary to propose a package of records. Several models can offer competing proposals for the same job.
The proposals are merged, then checked in code: does the record fit its schema, do its references exist, and are its values supported? A well-formed record can still describe the wrong event or belong in the wrong bucket.
When records are proposed, a Critic checks the package against the source. The model serving the Critic must be separate from the models that proposed it. An unreadable or missing independent verdict leaves the package held. I treat that independent judgement as another piece of evidence.
Holding findings can trigger one Repairer attempt. A replacement must pass the checks and a fresh independent critique before it is adopted. Otherwise the original package remains held. I want a bounded attempt to improve the proposal, with the unresolved question visible.
I use application tools exposed through MCP at this boundary. For internal writes, declared mappings connect record fields to the tool's actual parameters, including different names or allowed values. Outward calls keep their approved arguments. Application code supplies the validation, identity and authority rules around the call.
An upsert creates or updates the record identified by its business key. Normalization and matter identity now have practical consequences: the write must address the right record. Calling it an upsert does not make every retry safe.
Materialization turns the package into concrete calls. It can derive associated records and order dependencies, such as writing a parent before a record that refers to it. The core works with declarations; the application owns the business meaning and implementation.
A person can edit eligible proposed records without another model call. The change is retained in the history. Editing a field does not silently approve a pending decision; saving a human-authored replacement package is a separate operation.
Another path is to explain the misunderstanding and ask the Decision proposer to produce a fresh package. A new machine proposal after a human ruling returns for review. The retained correction and its reason also become evidence for LEARN to examine.
The distinction remains useful in ACT. Re-decide opens eligible manual package correction. Rerun DECIDE sends the case back for a new model proposal. Retry requests another execution attempt. A wrong interpretation and a failed call need different interventions; earlier effects still matter.
Signal Flow has automation grades and a maturity calculation based on reviewed routing behaviour over time. That evidence informs promotion, which requires human approval. Confidence from one answer cannot grant authority, and good routing evidence cannot establish that every action is safe.
The unattended execution gate checks the particular action: its kind is declared and bound to a tool, its decisions are settled, and its grade and action guards permit it. A configured permission level is only one part of that decision.
In my implementation, declared reversible internal writes can qualify for unattended execution. An outward effect requires a person's explicit release, even at the highest automation grade. Where an effect happens and whether it can be reversed are separate policy facts.
ACT carries the authorized operation into the application and retains the execution outcome. A successful tool call is useful evidence. It is not universal independent confirmation that the intended business result occurred. That stronger confirmation needs an appropriate application contract.
A package of calls can succeed only partly. A parent record may be written before a later call fails. Recovery must account for what already happened. Dependency order is useful, but it does not turn the package into one transaction.
Consider a timeout after an outward call. The effect is uncertain: the target may have acted before the response was lost. Sending the call again could repeat it. The next step is to establish what happened, then decide whether to retry, correct or stop.
Reversing a ruling records that it no longer stands. Restoring application state may require a compensating tool operation. An external consequence may need another response entirely. I want the history to distinguish what was requested, what ran, what came back and what remains unresolved.
The Signal Flow board gives these questions a place: a record awaiting review, an action awaiting release, an execution needing recovery. The sketch uses synthetic cases to show those different needs.
I want routine updates to proceed within their authority while people examine exceptions, correct interpretations and decide how to recover. Keeping those interventions and their reasons opens the next question: what should change before similar work arrives again? That is the responsibility of LEARN.
