Incident Playbook: From Context ID to Fix

Fabra is built for one moment: an AI incident where everyone is guessing.

Your goal is to turn “the AI was wrong” into a reproducible ticket in minutes.

Step 0 — Ask for the receipt

In every incident, ask one question:

“What’s the context_id?”

That ID is the atomic unit of evidence.

Step 1 — Show what the AI saw

fabra context show <context_id>

Use this to answer:

• what data was included
• what got dropped (token budget)
• what features/retrievers were used (lineage)

Step 2 — Verify integrity (audits / disputes)

fabra context verify <context_id>

This checks cryptographic hashes so you can tell if the record was modified.

Step 3 — Diff drift between two incidents

Generate a second Context Record (same user, same request, or after a deploy), then:

fabra context diff <context_id_A> <context_id_B>

This is the fastest way to settle arguments:

• “what changed in features?”
• “what changed in retrieval?”
• “did the assembled context change?”

Step 4 — Export a ticket attachment

fabra context export <context_id> --bundle

Use this when you need evidence to live outside the running service (support, compliance, chargebacks).

Storage note (durability by default)

By default, dev installs store Context Records durably in DuckDB:

• ~/.fabra/fabra.duckdb

Override:

• FABRA_DUCKDB_PATH=/path/to/file.duckdb
• FABRA_DUCKDB_PATH=:memory: (ephemeral, not recommended for incident workflows)