A date in the wrong field
Suppose an update says, “Dispatched Tuesday.” The system puts Tuesday in the expected-delivery field. The source described a departure; the recorded fact now claims something about arrival.
What should change after a correction?
How Signal Flow carries experience into later work.
I have spent much of my work on Signal Flow connecting human review to future behaviour. Its LEARN layer has several ways to make that connection. A corrected field is a useful place to see how it works.
01 / Keep the evidence
Keep the reason
I correct expected delivery to “not stated” and explain why: a dispatch date does not establish a delivery date. The corrected field repairs this case. The explanation gives us something to examine for later work.
Find the answer behind the mistake
Signal Flow records corrections, changed fields and reasons supplied with review decisions. Links to the relevant model executions let me inspect the request and answer behind the mistake, alongside what was subsequently changed.
Decide what should carry forward
An accepted decision can contribute evidence too. I still need to decide what applies beyond this case. Ambiguous wording may call for a one-off judgement; applying a default is not proof that it was right.
02 / Choose what should change
Teach the next interpretation
Domain memory is guidance supplied to a particular question. A person's explanation can be added directly to active memory, such as “A dispatch date does not establish a delivery date.” This teaching path does not wait for a dream.
Keep the exception when shortening
When active guidance grows too long, a consolidator compresses it to fit. Repetition can disappear usefully; a small exception can disappear dangerously. I want the shortened guidance inspected for what it loses as well as what it saves.
Ask for the right information
The extraction question itself may be wrong. A workflow specification says what information interests the workflow and what extraction should return. Correcting that contract addresses a different cause from adding another explanation to memory.
Test the specification separately
Specification candidates are compared with the current version on reviewed examples while memory stays fixed. A promising candidate still needs its own activation decision. New specification prose waits for a person even when unattended adoption is enabled.
Add a missing choice
Sometimes the available vocabulary is incomplete. A person can accept a proposed lane or add an intent. Later routing questions then have another possible answer, rather than having to fit every case into the existing choices.
03 / Learn a default within scope
Fill an empty field
Repeated corrections can suggest an existing reference for a particular lane and field. It can fill a declared blank only when that reference is available for the new case. The result remains a correctable default, not an extracted fact.
Check a rule against later decisions
A separate learner proposes which cases need attention or only a record. It compares that relevance rule with later review decisions. The candidate can collect agreement and disagreement before it takes over the choice.
Require human approval
Eligible relevance defaults can become active under their configured conditions. Rules that would close cases as noise, and proposals for filtering later arrivals, require human approval. Their consequences set a different approval boundary.
Respond to disagreement
Later disagreement can withdraw an adopted relevance rule. Another path can weaken text associated with a mistaken noise decision. One changes a structured default; the other changes guidance that only affects work when a later prompt reads it.
04 / Try the lesson on earlier cases
Prepare a candidate memory
Dreaming gathers active guidance and recorded experience into candidate memory. It can consolidate and shorten the proposed text while keeping that candidate separate during evaluation. The change is to supplied guidance; the model's weights stay unchanged.
Compare with today’s memory
The original live answer is history. The replay baseline is the active memory when the experiment is prepared. Direct corrections may already have changed that memory, so the original execution and today's baseline need separate identities.
Compare on the same cases
Each version gets the same selected reviewed cases and the same model. Fixed grading rules compare their outputs with reviewed answers, such as an expected field value. That gives me a comparison I can inspect.
Look for the new mistake
In this synthetic example, “Leave expected delivery blank in dispatch updates” repairs the “Dispatched Tuesday” case. But when another update explicitly says “Expected delivery Thursday,” the candidate still leaves the field blank. I would revise the lesson: it has discarded a fact we wanted to preserve.
Measure ordinary variation
Even with unchanged memory, a new model call can return a different answer. Repeating the unchanged version provides a control: how much variation should I expect before attributing an improvement to the lesson?
Decide from enough evidence
These two examples explain a failure; they cannot qualify a real candidate. Adoption needs trustworthy references, adequate evidence, controls and the applicable version checks. A candidate can remain held when that evidence is insufficient.
05 / Follow the change into later work
Make sure the next step uses it
Each active change needs a reader: guidance in a later prompt, a specification in the step it configures, or a default in the field or policy that applies it. I inspect that connection before claiming a stored lesson changes behaviour.
Use the right undo
Withdrawing a relevance rule changes future handling. Undoing automatic memory weakening can restore the saved earlier text, subject to its version check. Neither reverses an application action that already happened; recovering from that effect belongs to ACT.
Keep permission explicit
An answer grade measures an answer against a reference. An automation grade defines permission. Reviewed routing behaviour can support more automation, but a person must approve the increase. That evidence does not establish that every decision or outward action is safe.
For me, this series describes one connected architecture: understand what arrived, decide what should happen, and learn from the result. I want routine work to move with less intervention, while people focus on exceptions and improving the workflow. That is what I am exploring with Signal Flow.