mycelium_triage
Triage data incidents by computing cause, severity, blast radius, and owner from your data catalogue. Returns a report with next actions and identified gaps.
Instructions
Triage a data incident end to end: cause, severity, blast radius, owner, next actions.
Use this instead of mycelium_ask whenever something is broken. ask answers a question;
this does the on-call job, and returns a report rather than a paragraph.
What comes back is computed from DataHub, not inferred: the severity (P1-P4) with the inputs
that produced it and the rule that combined them, the assets downstream and how many of them a
person actually watches, the cause with its lineage path and evidence, the owner or the
escalation path when there is no owner, a timeline, ranked next actions, and -- importantly --
a gaps list of what could not be determined.
Three things worth knowing before you act on it:
You may not overrule the severity. It is arithmetic over the catalogue and the rule is in the response. If you disagree, say which input you think is wrong.
statusmatters as much asseverity.resolved_itselfmeans the alert already cleared;ambiguousmeans several unrelated assets match and you should ask the user which fired, not guess;no_cause_foundmeans the metadata genuinely does not explain the symptom, which is a finding and tells you to look outside the catalogue.Read
gapsbefore summarising. Reporting a cause while omitting that the suspect has no SLA recorded is how a confident wrong answer gets made.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| alert | Yes | The alert, in the monitor's words or the user's. e.g. 'freshness SLA missed on ORDER_DETAILS' or 'the exec dashboard is showing last week's numbers'. | |
| subject | No | URN of the asset that fired, if known. Skip the name resolution and its ambiguity by passing this whenever the monitor tells you which asset it was. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||