Answer Who Had Access

Start from the instance

Access is always some instance's access, and the instance's own trail says which License it ran under, and when.

1. Open Customers → Instances, then sakura-tokyo-prod, then its Audit Trail tab. The Event Log lists the instance's latest 200 entries, newest first.
2. Narrow the list with the search box, or filter by entitlement group, by event, or by status. The tab has no time range: bound one on the organization's page, below, or over the API.
3. Click View details, the eye at the end of a row. The dialog shows the entry's Full Payload: on an Instance created or Instance updated entry, licenseSlug is the License version the instance was given at that moment.

✕

✕

Narrow by event and time

Three query parameters do the work on an Instance's trail: event_name (exact catalog name), after and before (RFC 3339, inclusive). Every change made to sakura-tokyo-prod over the last thirty days — a change of License among them:

AFTER=$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)   # macOS: date -u -v-30d +%Y-%m-%dT%H:%M:%SZ

curl "$KAITEN_API/instances/sakura-tokyo-prod/audit-trails?event_name=INSTANCE_UPDATED&after=$AFTER" \
  -H "Authorization: Bearer $KAITEN_TOKEN"

One event name per query. To answer a question that spans several events — a report and the cap it hit — run one query per event, or read the unfiltered trail for the time window and sort by eventName locally.

Walk the pages

A page holds up to 200 entries (limit, default 50). hasMore says whether older entries exist; nextCursor fetches them. To hand a complete window to an auditor, walk the cursor to the end and keep every entry — here, the last ninety days:

AFTER=$(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)   # macOS: date -u -v-90d +%Y-%m-%dT%H:%M:%SZ

url="$KAITEN_API/instances/sakura-tokyo-prod/audit-trails?after=$AFTER&limit=200"
cursor=""
while :; do
  page=$(curl -s "$url${cursor:+&cursor=$cursor}" -H "Authorization: Bearer $KAITEN_TOKEN")
  echo "$page" | jq -c '.items[]' >> sakura-tokyo-prod-audit.jsonl
  [ "$(echo "$page" | jq -r '.hasMore')" = "true" ] || break
  cursor=$(echo "$page" | jq -r '.nextCursor')
done

The file is one JSON entry per line, newest first, exactly as recorded. The CLI follows the cursor for you and returns the window as one JSON array; its --event-name filter takes the same exact catalog name:

kaiten instances audit-trails sakura-tokyo-prod --event-name INSTANCE_UPDATED --after "$AFTER" --output json

Read the organization's trail

Grants, flag changes and flag evaluations carry no Instance, so an Instance's trail does not return them. They are read on the organization's trail, which holds every entry of the organization — the instances' included.

1. Open Audit trail, at the bottom of the sidebar: the feed of the whole organization, newest first, grouped by day.
2. Narrow it with the search box, the status filter, the time range — 24h, 7 days, 30 days or All time — and the Event type, Instance and Customer filters. An entry recorded without an Instance shows a dash in both columns.
3. Click a row to expand it: Full payload is the event's data. Export downloads the filtered entries as a CSV file.

✕

✕

The page reads the latest 500 entries, and Load older events widens the window to 1,000. To go further back, or to automate the read, use the API.

Worked question 1 — "Why could a Sakura Tokyo user see delivery tracking?"

Support asks this. An evaluation entry does not answer it alone — it names the flag and the decision, not the customer. The contract does, in three hops:

1. The License the instance ran under. On the trail of sakura-tokyo-prod, the INSTANCE_CREATED entry carries its licenseSlug — premium-v2, the second version of Premium — and no later INSTANCE_UPDATED entry changes it.
2. What that License granted. On the organization's trail, the LICENSE_ENTITLEMENT_ASSIGNED entry for premium-v2: entitlementSlug delivery-tracking, value true, recorded when the License was configured.
3. What the flag's rule said. On the organization's trail, the newest FEATURE_FLAG_CREATED or FEATURE_FLAG_UPDATED entry for delivery-tracking-enabled before the date in question: one rule, serving on where __kaiten.entitlements['delivery-tracking'] == true.

Three dated entries, and the answer is complete: from the moment all three held, an evaluation for Sakura Tokyo resolved to on, because its License grants the entitlement the rule reads. Where the flag was evaluated in the period, its FEATURE_FLAG_EVALUATED entries confirm that it served on with reason TARGETING_MATCH, and name the rule that matched.

The mirror question — why a Ninja Osaka user did not see it — is the same three hops from ninja-osaka-prod: a licenseSlug of starter, and a Starter grant of false. Gate a feature by License builds this chain and reads both evaluations back.

Worked question 2 — "Ninja Osaka says an order was blocked. Was it, and rightly?"

This is a dispute, from the customer or from finance. On your stack, ninja-osaka-prod holds such a refusal once you have run Meter usage and enforce limits, which takes its monthly orders to the cap and past it. Filter ninja-osaka-prod to ENTITLEMENT_USAGE_REPORT_REJECTED over the window in question — here, the last seven days:

AFTER=$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)   # macOS: date -u -v-7d +%Y-%m-%dT%H:%M:%SZ

curl "$KAITEN_API/instances/ninja-osaka-prod/audit-trails?event_name=ENTITLEMENT_USAGE_REPORT_REJECTED&after=$AFTER" \
  -H "Authorization: Bearer $KAITEN_TOKEN"

{
  "items": [
    {
      "id": "…",
      "instanceSlug": "ninja-osaka-prod",
      "eventName": "ENTITLEMENT_USAGE_REPORT_REJECTED",
      "eventType": "com.kaiten.instance.entitlement.v1.usage_report_rejected",
      "timestamp": "…",
      "payload": {"entitlement_slug": "monthly-orders", "value": 1, "behavior": "append", "status": "REJECTED", "…": "…"}
    }
  ],
  "hasMore": false
}

Yes, it was blocked: one report of 1 against monthly-orders, refused. Was it rightly blocked? The INSTANCE_ENTITLEMENT_USAGE_REACHED entry just before it, on the same trail, carries the usage record at the moment the cap was hit — value 20, limit 20. The grant that applied is Starter's: a value of 20 with limitCapExceededOveragePercent 0, a hard cap with no allowance past it. Where a grant was made through the console or the API, its LICENSE_ENTITLEMENT_ASSIGNED entry is on the organization's trail — the demo profile's grants included, recorded at the moment the seeder ran — and GET /licenses/starter/entitlements/monthly-orders reads the grant itself. Refusal, cap, contract: the receipt is three records long, each one dated, and no entry of the trail can be edited.