Yes, that is very much in scope.
Right now Squid Mesh exposes the raw ingredients through inspect_run(..., include_history: true): run status, current step, step runs, attempts, errors, retry state, pause/approval audit events, etc. But that is still more of a structured runtime view than an explanation layer.
I do want something closer to Journey.Tools.introspect/1: a public function that can answer
questions like:
- why is this run stopped?
- why did this step fail?
- why did this run not resume?
- is it waiting on approval, retry delay, dependencies, cancellation, or a terminal state?
- what operator action is possible next?
I’d probably keep it separate from inspect_run/2, maybe something like
SquidMesh.explain_run/2 or SquidMesh.introspect_run/2, so inspect_run remains the factual
read model and the explanation API becomes the higher-level diagnostic layer.
This release moved a lot of the needed data into durable state, especially pause/approval resume metadata and manual audit history. So the next step is mostly shaping that data into a stable explanation contract rather than scraping logs or recomputing from current workflow code.
Appreciate any architectural feedback too. Originally, I was thinking on mostly building an “n8n” using Elixir macros/functions (it’s easier to QA and load test compared to drag and drop diagrams) but I think I am sliding into a more serious pit 
. I love the idea that people can run a re-usable workflow framework they can use for free but at the same time, I want this to be as reliable as possible even for mission critical things like payments.
