Escape Trend Watch
Defects found after release are recorded against their component — and when one component starts letting too many through, somebody is asked about it once.
What it does
Records every defect the tracker labels as an escape against its component and release, then watches its OWN record. For each new escape it counts that component's escapes, all time and in the recent window, and marks the component bending or steady. Only for a bending component does it ask a person anything: open a prevention item, accept the rate, or say the count is misleading.
How it works
Defects found after release are the ones that got past everything. This mission records each of them against its component, then watches its own record: when a component's escapes cross the line you set, it asks one person whether to open a prevention item. It reads nothing but its own memory to do it.
How it's wired
TWO watchers. The first polls the tracker and does nothing but store. The second is native — its source is the mission's `escapes` table — and it computes the counts, marks the standing, and raises a gate guarded by `when standing = bending`. The Escape desk shows escapes by component and by release, then what is over the line and what was decided.
The team
Reads a component's escape record and says what a prevention effort should target — not that quality should improve, but which specific gap let these through.
Connects to
You supply
- Escapes in the window before a component is flagged
What it watches
Polls the tracker every five minutes for defects labelled as escapes, oldest first, and records each against its component and release.
Watches the mission's OWN escapes table for rows nothing has assessed yet, and counts that component's record. No external system is involved.
Human approval
One consequential step waits for a person's approval before it acts.
What it already knows (3)
Data it carries
1 table
What it shows a human
Ask it
“Five escapes in one component were all found in the same release. What does that suggest, and what would you check?”
“A component has five escapes but they are completely unrelated to each other. Is that the same problem as five of the same kind?”
“What would make an escape count misleading rather than informative?”
“We keep saying we need more testing. What would you say instead, given a component with repeated escapes at the integration boundary?”
“Why is escapes-per-component a weaker measure than escapes-per-release, and what would you need to compute the better one?”
Before it runs, you'll
- 1Confirm the Issue Tracker server at import. It is credential-free and works as-is; replace the URL with your own tracker and nothing else changes. If your convention for a post-release defect is not the label `escape`, edit the first watcher's JQL.
- 2Set the flag threshold in Configure if 4 in the window is wrong for how much you ship — it is the only number this mission asks for.
- 3Enable BOTH observations. The native one has nothing to read until the first has recorded something, so the tracker watcher goes first.
Import into StudioX
- Download the
.sxmfile. - In StudioX → Missions → Import, drop the file.
- Review, finalize, and it's live — chat to it or enable the observation.
Reviews
No reviews yet. If you’ve run this mission, yours will be the first — what it handled well, and what you had to wire up, is what the next person needs to know.
More in Engineering
Bug Intake Gate
Every bug report is read before it reaches the backlog — and the ones that can't be worked are named, not silently queued.
Triage Analyst
Close-Out Gate
A fix isn't finished until somebody can say what went wrong — and the answer is written down where it can be found again.
RCA Analyst
Defect Twin Finder
Before anyone starts work, the mission says whether this fault has been seen before — and what was learned the last time it was.
Signature Analyst