Spool-driven generation

Consider this scenario. A job failed overnight, and the operator has the spool. The operator wants a recovery flow without having to summarize the failure by hand.

The pattern

Both steps run through the same provider path as any other AI node or DSL generation. There is no spool-specific model or command.

1. Interpret. Paste the spool into an ai node bound to a capable local LLM (or a cloud provider) and ask it to summarize the failure. The PII sanitizer redacts dataset names, hostnames, and credentials before the spool text reaches the model.

2. Generate. Feed that summary into the flow generator (the Generate screen’s prompt mode, or flow generate in the CLI) to produce a recovery flow, which parses into a reviewable canvas graph.

flow "spool-triage" v1

interpret[ai: "Summarise failure"] {
  modelId: "local-llm"
  system: "You are a mainframe operator. Summarise this job failure and its likely cause in three sentences."
  input: "{{input}}"
}

log[utility: "Log summary"] {
  actionId: "log"
  level: "info"
}

interpret --> log

Review the generated recovery flow before you run it. Like every generated flow, it goes through the review modal and pre-apply verification first.

History

An earlier design used dedicated task models, where a spool interpreter fed a flow-graph generator. That chain was retired with the move to the managed LLM sidecar. The pattern above achieves the same outcome with general models.

Related

• Agentic and monitor
• Mainframe orchestration covers failure recovery in the mainframe use case.
• Local runtime