Preparing a workflow with historical work, AI-assisted analysis and Signal Flow's Time Machine.
I have used historical work extensively while developing Signal Flow. Its Time Machine brings earlier inputs into the same processing path as new arrivals. Around it, I use AI-assisted analysis and human review to work out what the system should understand and what its decisions should produce.
The useful starting question is what the work should accomplish. Categories, memory and model calls become easier to judge once that is clear.
Consider a fictional operations team reading order updates. Someone identifies the order, checks whether a delivery date has changed, and updates the business system. That small piece of work already contains several architectural decisions: what the message means, which order it concerns, and which record should change.
I would choose a period that reveals the work's variations. A few weeks might show the routine; a longer period might expose seasonal changes. Include awkward cases as well as frequent ones. The question is whether the collection helps challenge the proposed workflow, rather than how many years it contains.
AI can help group examples, propose names and describe recurring distinctions. I examine those suggestions with the people who understand the work. Two messages that look similar may demand different outcomes; two different phrasings may belong together. The proposal needs to survive those examples before it becomes configuration.
A workflow describes an area of work the system should recognise. In the example, “Order operations” gives us a useful starting scope. Its description should explain what belongs there and what information matters, so later questions have a purpose beyond choosing a label.
A lane narrows the context, while an intent identifies what the case is telling us. Within a supplier-updates lane, an order confirmation and a delivery update ask different questions. The vocabulary and extraction requirements need to make those differences clear.
A matter connects cases about the same ongoing concern. An order confirmation and a later delivery update can belong to the same order matter. I need to establish which identifiers support that relationship and how ambiguous matches should be reviewed. The matter represents the continuing concern; each case keeps its own classification.
A decision bucket describes where a proposed fact belongs. A dispatch event and a changed delivery date have different meanings, even though both may contain dates. Defining the boundary between neighbouring buckets gives the decision step something more useful than a list of names.
The bucket also needs a clear save effect: which record will be created or updated, and what it attaches to. In the example, a proposed delivery-date change needs a destination associated with the correct order. Agreement about the meaning of the message is only part of that contract.
I compare the desired result with the application that owns the business record. Which order identifier does it use? Which fields can be changed, and through which operation? In Signal Flow, bucket declarations and registered tool schemas provide concrete places to express those contracts.
An existing API may already provide the operation. It may need an MCP adapter, or the application may lack the record or capability we want. That discovery can change the proposed workflow. I want to find it while designing the destination, before a stream of convincing decisions starts looking for somewhere to go.
The integration also needs a decision about effects. Reading a record, updating an internal record and sending something outside the application carry different responsibilities. Signal Flow keeps outward actions behind human release. Historical input still enters ordinary processing, so I decide what it may change before walking it through.
With the distinctions agreed, AI can help draft a glossary, domain descriptions and initial guidance. People review the terms, exceptions and assumptions before that material becomes active context. Signal Flow can seed authored context and keep later versions; the drafting and the approval remain separate work.
A glossary explains terms. Scoped domain memory supplies guidance relevant to a particular question. The prompt needs the appropriate pieces, alongside the case being examined. This preparation changes configuration and supplied context; it does not train the model's weights.
An adjudication runbook makes review repeatable. It says which evidence to inspect, how to distinguish nearby answers and when to leave a question for a person. I would include a clear example and an exception: a dispatch date tells us when something left; it does not establish when it will arrive.
In my historical walks, an AI assistant reviewed sensing and interpretation, while I handled decisions and actions. The ruling's author and the reason for a correction matter. An AI ruling is useful review work, but it must remain identifiable as such. Disagreement gives us another case to examine.
Time Machine advances through selected date windows, bringing earlier arrivals into intake and routing. I can then inspect the cases they produce. This is historical input processed with the configured workflow and available business context. It does not reconstruct every surrounding system as it was on that date.
A wrong result may expose a weak category boundary, a missing field, an unsuitable destination or incomplete guidance. Those call for different changes. I want the review to identify which contract needs attention, so the next attempt tests a deliberate revision rather than another broadly worded instruction.
I would reserve other examples for a later check, including cases that challenge the common pattern. If the same examples define the vocabulary and judge it, the result can look more convincing than it is. A useful revision should cope with work beyond the examples that suggested it.
Time Machine can move from historical intake to live input once its catch-up condition is met. That tells me where intake and routing have reached. I still need to judge the reviewed behaviour, the application connections and the permitted effects. Reaching today on the timeline does not answer those questions for me.
The result I want is a first operating definition: recognisable work, meaningful destinations, usable connections and examples people know how to review. Historical work gives me something concrete to test those decisions against before new work depends on them.