Sandbox scenarios

A scenario is a few synthetic events built to trip one built-in rule, so you can see a real alert without writing a payload. They only load into the sandbox: with a test key, or from the dashboard after switching to Sandbox. On live data both endpoints return 400.

A test key needs the events:write scope. Signed in, engineers and admins can load scenarios, because it sends events. The events go through the same path as any other, so the alerts, entities and decisions they make are real, just in the sandbox.

List scenarios

curl "$SENTINEL_URL/v1/sandbox/scenarios" \
  -H "Authorization: Bearer $SENTINEL_TEST_KEY"

{
  "scenarios": [
    {
      "key": "structuring",
      "title": "Structuring below the threshold",
      "detail": "Four transfers of GHS 4,950 in under an hour, each just under the 5,000 reporting line.",
      "expected_rule": "structuring_below_threshold"
    }
  ]
}

The list has six scenarios today: structuring, fan_in, fan_out, dormant, shared_device and round_tripping. The example shows the first.

Load a scenario

Sends the scenario's events one at a time, oldest first, as sync events, so each is decided as it arrives. Every load uses new wallets, so loading one twice adds a second pattern and never collides with the first.

curl -X POST "$SENTINEL_URL/v1/sandbox/scenarios/structuring" \
  -H "Authorization: Bearer $SENTINEL_TEST_KEY"

{
  "scenario": "structuring",
  "expected_rule": "structuring_below_threshold",
  "fired": true,
  "events": 4,
  "rules_fired": [
    "structuring_below_threshold"
  ],
  "alert_ids": [
    "a0edbe50-21e2-41b8-ade0-c80acfdd0a94"
  ]
}

fired is true when the expected rule fired on at least one event. rules_fired lists every rule that fired, once each, and alert_ids the alerts the events raised. Some scenarios trip a second rule as well, which is normal.

The sandbox scores with the built-in rules unless it has rules of its own. If it does, a scenario only fires when those rules cover its pattern.