Incident & remediation workflow
When a check fails, the first question is who is exposed. Incidents here open with the impact already mapped from the lineage graph, covering affected reports, consumers, and CDEs, and they route to the accountable owner. Closure is verified: the failed check has to re-run green, and nobody hand-closes a failed issue.
Incidents are created automatically from rule failures, monitoring misses, and confirmed anomalies, so everything lands in one queue on one record.
Impact is mapped at open. Affected reports, downstream consumers, and CDEs are pulled from the lineage graph, so severity comes from evidence rather than a guess on a call.
Each incident routes to the named owner of the dataset or CDE, with second line watching the same queue instead of emailing for status.
Downstream visibility is built in. Report owners see the open incident on the report record itself, so nobody unknowingly consumes a number that is known to be bad.
Closure is verified. The incident closes only when the original check re-runs green, and the verification is done by someone other than the fixer.
A sealed timeline of detection, triage, remediation, and the closing re-check lives on the hash-chained ledger, ready to drop into an evidence pack.
Open
A failed check or confirmed anomaly opens the incident with its impact pre-mapped from the graph.
Route
It lands with the accountable owner, and second line sees the same record at the same time.
Fix
Remediation happens in the source system, with each step logged against the incident.
Verify
The original check re-runs, and only a green re-check closes the incident. The closure is sealed on the ledger.
“Which reports did this break touch, and who was told?”
The incident opens with affected reports, consumers, and CDEs already mapped from the lineage graph, and report owners see it on the report record itself. Nobody unknowingly consumes a number that is known to be bad.
“How do I know the fix actually worked, rather than someone marking it done?”
Closure is verified, not asserted. The incident closes only when the original check re-runs green, the verification is done by someone other than the fixer, and the closing re-check is sealed on the ledger.
“Can anyone on your team quietly close an issue without fixing it?”
Nobody can. There is no hand-close path for a failed issue. The only route to closure is a green re-run of the original check, verified by someone other than the fixer and sealed on the hash-chained ledger.
Start with proof, not a promise.
There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.
A 60-minute working session
Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.
A two-week guided sandbox
Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.
A six-week proof on your systems
We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.