A tool that acts for you has to answer one question at any moment: why did you do that? If the answer is “the model decided”, the tool is not ready.
Explanations are a design constraint, not a feature
We treat explainability as a constraint on the whole system. Every step in a workflow has to declare its inputs, its action and its output. Every run stores them. This costs us flexibility. Some things that would be easy to do invisibly are hard to do visibly. We accept that cost.
What gets recorded
For each run we keep:
- What started it, such as a schedule or an event.
- The steps in order, with the time each began and ended.
- What each step read, summarised and linked back to the source.
- What each step wrote, and where.
- Which approvals were requested, and who answered.
Why summaries link back to sources
When a generated summary says “three tasks closed in the billing project”, you should be able to click through to those three tasks. Otherwise you are being asked to trust prose. Linking keeps the summary honest and makes errors visible.
Mistakes are the real test
An explanation system proves its value when something goes wrong. A good one lets you find the failing step in under a minute, see what it was given, and fix the instruction. A weak one leaves you guessing.
Trade-offs
Detailed logs mean more data stored. We keep logs to what is needed to explain a run, and you can delete a run history at any time. We cover how we handle data on the privacy page.
What we want next
We would like a plain-language “why” on every step, written for a non-technical reader. That is harder than it sounds, because a short explanation is easy to get subtly wrong. We would rather ship a precise one that is a little dry.
Leave a Reply