Context Rescue

• 

  Start state: one messy dashboard question and one clear Run rescue action.

• 

  CR-0001 complete: lineage-aware rescue card with owner, action, NEXT decision, and receipt.

• 

  Mobile proof: the complete decision card stays readable on a narrow viewport.

Inspiration

A dashboard incident almost never arrives as a neat technical ticket. It arrives as a worried message: "Revenue dropped after yesterday's customer/orders change. What broke, who owns it, and what should we do next?"

The slow part is not reading the message. It is reconstructing context across schemas, lineage, ownership, runbooks, and old queries before anyone can make a responsible decision.

We built Context Rescue to do that first pass without guessing.

What it does

Context Rescue turns one messy data-team question into a compact decision artifact:

• what the incident probably means
• which upstream and downstream assets may be involved
• what context is still missing
• who should take the next step
• a suggested action
• a clear NEXT or HOLD decision
• a receipt that preserves the evidence used

The result is a Context Rescue Card, not another chat transcript.

Why DataHub matters

DataHub is the foundation of the proof. For CR-0001, Context Rescue reads the showcase-ecommerce graph through DataHub MCP: search results, entity metadata, schema fields, upstream and downstream lineage, documents, ownership, and query history.

That grounding is what turns a vague question into a useful answer. The app shows the evidence counts and the exact receipt so a judge can see where the decision came from.

How we built it

We ran DataHub locally with the showcase-ecommerce sample graph and queried it through the open-source MCP server. A small evidence pipeline captured the verified CR-0001 context. The public React and TypeScript demo replays that proof so judges can test the complete experience without installing a data stack.

The repository includes the evidence, sample input and output, receipt, setup instructions, contract tests, and the Apache 2.0 license.

Challenges

The main design challenge was restraint. A data incident can produce a wall of metadata, but an operator needs a decision. We had to preserve lineage and ownership evidence while keeping the card readable in one pass.

The second challenge was making the public demo honest. The hosted app clearly labels its verified replay mode; it does not pretend a browser-only showcase is making live catalog calls.

What we learned

Lineage becomes much more useful when it is paired with ownership, documents, and an explicit missing-context check. Metadata is not the final product. A grounded next action is.

What is next

The next engineering step is a live authenticated run that generates the same card directly from a user's DataHub environment and writes the receipt back to the graph where appropriate.

Built With

• datahub
• github
• mcp
• pages
• playwright
• python
• react
• typescript
• vite
• vitest