Watch Drift Detection Example

This example shows how to use the watch feature to detect when a corpus change causes a query's answer to drift. The scenario: you ask a question about your data retention policy, register a watch, update the policy document, and observe the drift alert.

Requires Pro.

Setup

export VAULTCRUX_API_URL="https://api.vaultcrux.com"
export VAULTCRUX_API_KEY="vcrx_your-api-key"
export VAULTCRUX_TENANT_ID="your-tenant-id"

Step 1: Upload the initial policy document

curl -sS -X POST "$VAULTCRUX_API_URL/v1/ingest" \
  -H "content-type: application/json" \
  -H "x-tenant-id: $VAULTCRUX_TENANT_ID" \
  -H "x-api-key: $VAULTCRUX_API_KEY" \
  -d '{
    "doc_id": "data-retention-policy",
    "content": "Customer data is retained for 90 days after account closure.",
    "mime_type": "text/plain",
    "metadata": {"type": "policy", "version": "1.0"}
  }'

Step 2: Ask the question to establish the baseline answer

curl -sS -X POST "$VAULTCRUX_API_URL/rpc" \
  -H "content-type: application/json" \
  -H "x-tenant-id: $VAULTCRUX_TENANT_ID" \
  -H "x-api-key: $VAULTCRUX_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": "q-baseline",
    "method": "query_vault",
    "params": {
      "query": "How long is customer data retained after account closure?",
      "agent_id": "agent-1"
    }
  }'

The answer at this point: data is retained for 90 days.

Step 3: Register a watch on the same query

curl -sS -X POST "$VAULTCRUX_API_URL/rpc" \
  -H "content-type: application/json" \
  -H "x-tenant-id: $VAULTCRUX_TENANT_ID" \
  -H "x-api-key: $VAULTCRUX_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": "watch-1",
    "method": "watch_answer",
    "params": {
      "agent_id": "agent-1",
      "query": "How long is customer data retained after account closure?",
      "label": "retention-policy-watch"
    }
  }'

Expected response:

{"watch_id": "watch_ghi012", "status": "active", "snapshot_hash": "sha256:a1b2..."}

Save watch_id:

export WATCH_ID="watch_ghi012"

Step 4: Update the corpus — simulate a policy change

curl -sS -X POST "$VAULTCRUX_API_URL/v1/ingest" \
  -H "content-type: application/json" \
  -H "x-tenant-id: $VAULTCRUX_TENANT_ID" \
  -H "x-api-key: $VAULTCRUX_API_KEY" \
  -d '{
    "doc_id": "data-retention-policy",
    "content": "Customer data is retained for 30 days after account closure, in compliance with updated GDPR guidance.",
    "mime_type": "text/plain",
    "metadata": {"type": "policy", "version": "2.0"}
  }'

The policy now says 30 days instead of 90.

Step 5: Read the drift alert

After the corpus update cycle runs, poll for alerts:

curl -sS "$VAULTCRUX_API_URL/v1/watches/$WATCH_ID/alerts" \
  -H "x-tenant-id: $VAULTCRUX_TENANT_ID" \
  -H "x-api-key: $VAULTCRUX_API_KEY"

Expected response:

{
  "alerts": [{
    "alert_id": "alert_jkl345",
    "watch_id": "watch_ghi012",
    "detected_at": "2026-03-29T11:02:17Z",
    "prior_hash": "sha256:a1b2...",
    "new_hash": "sha256:c3d4...",
    "changed_evidence": ["data-retention-policy"]
  }]
}

Step 6: Interpret the alert

The changed_evidence array identifies which document(s) shifted the answer. In this case data-retention-policy was re-ingested with new content, causing the ranked evidence set — and therefore the answer hash — to change.

Key signals to act on:

  • prior_hash vs new_hash: answer-level drift confirmed
  • changed_evidence: pinpoints which corpus documents drove the drift
  • detected_at: timestamp for your audit log

Any prior agent decisions that relied on the 90-day retention figure should be flagged for re-evaluation. If you use agent residency, check stale pins referencing data-retention-policy.

Step 7: Unwatch when no longer needed

curl -sS -X DELETE "$VAULTCRUX_API_URL/v1/watches/$WATCH_ID" \
  -H "x-tenant-id: $VAULTCRUX_TENANT_ID" \
  -H "x-api-key: $VAULTCRUX_API_KEY"