# 150 Play ideas

These research-backed starting points connect APIs, browsers, and local commands. Each idea includes the systems, access rules, safety boundary, and an operational exploration brief.

## Give this list to an agent

Ask your agent to read this catalog and shortlist three ideas that match the systems you can access. Have it explain the useful result, required access, and safety boundary before it runs anything. Then copy the selected `$play explore [...]` prompt into your harness.

Full structured feed: [play-ideas.v1.json](/feeds/play-ideas.v1.json)

## Software and cloud operations

### CLOUD-001 · Release causality window

For every production release, align the deploy, flag changes, error onset, and monitor movement on one clock. Produce the smallest evidence-backed change set that could explain the regression.

- **Systems:** GitHub Deployments · Sentry Releases · LaunchDarkly · Datadog
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Read-only; never roll back or change a flag automatically.
- **Evidence:** [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Sentry Releases](https://docs.sentry.io/api/releases/list-an-organizations-releases/) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log) · [Datadog](https://docs.datadoghq.com/api/latest/using-the-api/)

```text
$play explore [
Outcome: Release causality window.
Tools: Work only with GitHub Deployments, Sentry Releases, LaunchDarkly, and Datadog. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Build a release causality window for the latest production regression from GitHub Deployments, Sentry, LaunchDarkly, and Datadog. Align all evidence by time and propose the smallest plausible change set. Do not modify production.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Read-only; never roll back or change a flag automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-002 · Feature-flag ghost town

Find flags with no recent evaluations, no live code references, and no owner activity. Separate safe retirement candidates from dormant emergency controls.

- **Systems:** LaunchDarkly · GitHub · Linear
- **Reach:** api · shell
- **Access:** required
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Produce a review queue; never delete flags.
- **Evidence:** [LaunchDarkly](https://launchdarkly.com/docs/api) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Feature-flag ghost town.
Tools: Work only with LaunchDarkly, GitHub, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Find feature flags with no recent evaluations and no live code references. Use LaunchDarkly, repository search, and Linear ownership to produce a review-only retirement queue, preserving emergency controls.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Produce a review queue; never delete flags.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-003 · Unowned public endpoint

Join public DNS, cloud accounts, repository ownership, and current worker records to find internet-facing names whose responsible team no longer exists.

- **Systems:** Cloudflare DNS · AWS Organizations · GitHub · Rippling
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Inventory only; do not alter DNS or cloud resources.
- **Evidence:** [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/) · [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/APIReference/Welcome.html) · [Git](https://git-scm.com/docs) · [Rippling](https://developer.rippling.com/documentation/rest-api)

```text
$play explore [
Outcome: Unowned public endpoint.
Tools: Work only with Cloudflare DNS, AWS Organizations, GitHub, and Rippling. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Map every public DNS name to its AWS account, repository owner, and current team in Rippling. Flag endpoints whose owning team or maintainer no longer exists. Make no changes.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Inventory only; do not alter DNS or cloud resources.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-004 · Infrastructure reality split

Compare declared Terraform, saved state, recent CloudTrail changes, and the current pull request. Explain each unmanaged or out-of-band difference and identify its likely author and purpose.

- **Systems:** Terraform · AWS CloudTrail · GitHub
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** either
- **Complexity:** 5 / 5
- **Safety boundary:** Plan and inspect only; never apply Terraform.
- **Evidence:** [Terraform CLI](https://developer.hashicorp.com/terraform/cli/commands) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Infrastructure reality split.
Tools: Work only with Terraform, AWS CloudTrail, and GitHub. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare Terraform configuration and state with recent AWS CloudTrail changes and the open pull request. Explain every reality split, identify likely ownership, and stop before apply.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Plan and inspect only; never apply Terraform.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-005 · Shadow scheduler map

Discover recurring work hidden across CI schedules, pipeline schedules, cloud event rules, and machine crontabs. Group jobs by effect instead of by scheduler name to expose duplicates.

- **Systems:** GitHub Actions · GitLab CI · AWS · local crontab
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Read-only; do not disable schedules.
- **Evidence:** [GitHub Actions](https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10) · [GitLab CI](https://docs.gitlab.com/api/pipelines/) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html)

```text
$play explore [
Outcome: Shadow scheduler map.
Tools: Work only with GitHub Actions, GitLab CI, AWS, and local crontab. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Inventory recurring jobs across GitHub Actions, GitLab pipelines, AWS scheduling configuration, and local crontabs. Group jobs by actual effect and flag duplicates or conflicting schedules. Do not disable anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Read-only; do not disable schedules.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-006 · Rollback route rehearsal

Trace the exact reversible path from a bad deploy through the previous artifact, feature flags, aliases, and health checks. Rehearse commands against dry-run or read-only endpoints.

- **Systems:** GitHub Deployments · Vercel · LaunchDarkly · Sentry
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Rehearsal only; require explicit approval for any production write.
- **Evidence:** [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Vercel](https://vercel.com/docs/rest-api) · [LaunchDarkly](https://launchdarkly.com/docs/api) · [Sentry Releases](https://docs.sentry.io/api/releases/list-an-organizations-releases/)

```text
$play explore [
Outcome: Rollback route rehearsal.
Tools: Work only with GitHub Deployments, Vercel, LaunchDarkly, and Sentry. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Rehearse the rollback route for the current production release using GitHub Deployments, Vercel, LaunchDarkly, and Sentry. Resolve the last known good state and verify commands without executing production writes.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Rehearsal only; require explicit approval for any production write.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-007 · Error budget by change batch

Attribute reliability loss to change batches rather than individuals by joining deploy windows, monitor state, and incident timing. Reveal risky combinations of changes that look harmless in isolation.

- **Systems:** GitHub Deployments · Datadog · PagerDuty
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not rank employees; analyze change batches and system conditions.
- **Evidence:** [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Datadog](https://docs.datadoghq.com/api/latest/using-the-api/) · [PagerDuty](https://github.com/PagerDuty/api-schema)

```text
$play explore [
Outcome: Error budget by change batch.
Tools: Work only with GitHub Deployments, Datadog, and PagerDuty. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Explain error-budget loss by deploy batch using GitHub Deployments, Datadog monitors, and PagerDuty incidents. Find combinations of changes and conditions, not people to blame.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not rank employees; analyze change batches and system conditions.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-008 · Support-to-release regression graph

Connect first customer symptom, error fingerprint, affected release, and fixing commit. Preserve cases where support noticed a regression before observability did.

- **Systems:** Zendesk · Sentry · GitHub · Linear
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Redact customer content from any shared output.
- **Evidence:** [Zendesk Ticket Audits](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_audits/) · [Sentry](https://docs.sentry.io/api/events/list-an-organizations-issues/) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Support-to-release regression graph.
Tools: Work only with Zendesk, Sentry, GitHub, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Connect recent Zendesk symptom reports to Sentry fingerprints, GitHub releases, and Linear fixes. Show which regressions customers detected before monitors and keep customer text private.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Redact customer content from any shared output.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-009 · Green pipeline, broken data

Detect pipelines that pass while their promised output is stale, empty, or statistically implausible. Compare job artifacts with downstream dashboards and prior successful output.

- **Systems:** GitLab CI · GitHub Actions artifacts · Grafana · shell
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Read-only; label statistical anomalies as evidence to inspect, not proof of failure.
- **Evidence:** [GitLab CI](https://docs.gitlab.com/api/pipelines/) · [GitHub Actions artifacts](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts) · [Grafana](https://grafana.com/docs/grafana/latest/developer-resources/api-reference/http-api/)

```text
$play explore [
Outcome: Green pipeline, broken data.
Tools: Work only with GitLab CI, GitHub Actions artifacts, Grafana, and shell. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Find pipelines that report success while their output is stale, empty, or implausible. Compare CI artifacts, shell-level output checks, and Grafana downstream signals against prior good runs.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Read-only; label statistical anomalies as evidence to inspect, not proof of failure.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-010 · Runbook command truth test

Extract commands from operational docs, compare them with current CLI help and repository paths, then execute only harmless discovery forms. Report stale flags, renamed services, and missing prerequisites.

- **Systems:** Notion or Google Drive · local CLIs · GitHub
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Allow-list read-only commands; never execute copied destructive commands.
- **Evidence:** [Notion](https://developers.notion.com/reference/intro) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Runbook command truth test.
Tools: Work only with Notion or Google Drive, local CLIs, and GitHub. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Verify our operational runbooks against current CLI help, repository paths, and read-only discovery commands. Report stale syntax and missing prerequisites without executing destructive steps.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Allow-list read-only commands; never execute copied destructive commands.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-011 · Certificate renewal dependency chain

Map every certificate-bearing hostname to its DNS validation records, Terraform ownership, secret references, and renewal calendar. Find renewals that depend on a person or vanished repo.

- **Systems:** Cloudflare DNS · Terraform · 1Password · Google Calendar
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never expose secret values; inspect references and metadata only.
- **Evidence:** [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/) · [Terraform CLI](https://developer.hashicorp.com/terraform/cli/commands) · [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Certificate renewal dependency chain.
Tools: Work only with Cloudflare DNS, Terraform, 1Password, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Map certificate hostnames to Cloudflare validation records, Terraform ownership, 1Password references, and renewal events. Flag any renewal dependent on a person, missing repo, or inaccessible vault. Never reveal secrets.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never expose secret values; inspect references and metadata only.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-012 · Region asymmetry finder

Compare infrastructure shape, cost mix, and telemetry coverage across nominally identical regions. Explain whether each asymmetry is intentional, drift, or a hidden capacity risk.

- **Systems:** AWS Cost Explorer · Terraform · Datadog
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Read-only; do not rebalance capacity.
- **Evidence:** [AWS Cost Explorer](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html) · [Terraform CLI](https://developer.hashicorp.com/terraform/cli/commands) · [Datadog](https://docs.datadoghq.com/api/latest/using-the-api/)

```text
$play explore [
Outcome: Region asymmetry finder.
Tools: Work only with AWS Cost Explorer, Terraform, and Datadog. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare supposedly identical regions using Terraform, AWS cost and usage, and Datadog coverage. Classify asymmetries as intentional, unexplained drift, or capacity risk with evidence.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Read-only; do not rebalance capacity.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-013 · Orphan preview environment

Find preview deployments whose branch, pull request, owner, or DNS alias no longer exists, then estimate ongoing cost and exposure.

- **Systems:** Vercel · GitHub · Cloudflare DNS · AWS Cost Explorer
- **Reach:** api · shell
- **Access:** required
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Produce candidates only; require approval before deletion.
- **Evidence:** [Vercel](https://vercel.com/docs/rest-api) · [Git](https://git-scm.com/docs) · [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/) · [AWS Cost Explorer](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html)

```text
$play explore [
Outcome: Orphan preview environment.
Tools: Work only with Vercel, GitHub, Cloudflare DNS, and AWS Cost Explorer. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Find preview environments with no live branch, pull request, owner, or expected DNS alias. Estimate cost and exposure, then produce a review-only cleanup list.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Produce candidates only; require approval before deletion.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-014 · Shipped but unobservable

For each deployable service, prove the existence of traffic telemetry, a meaningful monitor, an on-call route, and an owner. Surface services that can fail silently.

- **Systems:** GitHub · Datadog · PagerDuty · Rippling
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not create monitors or schedules automatically.
- **Evidence:** [Git](https://git-scm.com/docs) · [Datadog](https://docs.datadoghq.com/api/latest/using-the-api/) · [PagerDuty](https://github.com/PagerDuty/api-schema) · [Rippling](https://developer.rippling.com/documentation/rest-api)

```text
$play explore [
Outcome: Shipped but unobservable.
Tools: Work only with GitHub, Datadog, PagerDuty, and Rippling. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For every deployable service, prove there is telemetry, a meaningful monitor, a PagerDuty route, and a current owner. List services that can fail silently and the missing proof.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not create monitors or schedules automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-015 · Change-freeze contradiction

Cross-check declared freeze windows against deployments, flag edits, and emergency approvals. Distinguish documented exceptions from unnoticed policy drift.

- **Systems:** Google Calendar · GitHub Deployments · LaunchDarkly audit log · Linear
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Evidence only; do not infer misconduct from timing alone.
- **Evidence:** [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Change-freeze contradiction.
Tools: Work only with Google Calendar, GitHub Deployments, LaunchDarkly audit log, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare declared change-freeze windows with GitHub deploys, LaunchDarkly audit events, and Linear exception records. Separate approved exceptions from unexplained contradictions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Evidence only; do not infer misconduct from timing alone.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-016 · Hotfix knowledge gap

Identify production hotfixes whose incident context, rationale, or follow-up never reached the issue tracker or durable docs. Build the missing evidence packet from commits and incident timelines.

- **Systems:** GitHub · PagerDuty · Linear · Notion
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 3 / 5
- **Safety boundary:** Draft documentation only; preserve incident privacy.
- **Evidence:** [Git](https://git-scm.com/docs) · [PagerDuty](https://github.com/PagerDuty/api-schema) · [Linear](https://linear.app/developers/graphql) · [Notion](https://developers.notion.com/reference/intro)

```text
$play explore [
Outcome: Hotfix knowledge gap.
Tools: Work only with GitHub, PagerDuty, Linear, and Notion. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find recent production hotfixes whose rationale or follow-up never reached Linear or Notion. Reconstruct a draft evidence packet from Git history and PagerDuty timelines for human review.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Draft documentation only; preserve incident privacy.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-017 · Dependency-change blast radius

For a package upgrade, trace direct and transitive consumers, CI artifacts, deploy targets, and observed errors. Show which services actually exercised the changed path.

- **Systems:** npm · GitHub · GitHub Actions artifacts · Sentry
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Do not upgrade packages; analyze the proposed or completed change.
- **Evidence:** [npm](https://docs.npmjs.com/cli/v11/commands/) · [Git](https://git-scm.com/docs) · [GitHub Actions artifacts](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts) · [Sentry](https://docs.sentry.io/api/events/list-an-organizations-issues/)

```text
$play explore [
Outcome: Dependency-change blast radius.
Tools: Work only with npm, GitHub, GitHub Actions artifacts, and Sentry. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Map the real blast radius of a package change across dependency trees, repository consumers, CI artifacts, deploy targets, and Sentry errors. Show exercised paths, not just declared dependencies.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not upgrade packages; analyze the proposed or completed change.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-018 · Schema-consumer impact map

Diff an API schema, locate generated and handwritten consumers, identify tests covering changed fields, and open a review list by owning team.

- **Systems:** OpenAPI or GraphQL schema · GitHub · Linear · shell
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Do not regenerate clients or create tickets without approval.
- **Evidence:** [Git](https://git-scm.com/docs) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Schema-consumer impact map.
Tools: Work only with OpenAPI or GraphQL schema, GitHub, Linear, and shell. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Diff the current and proposed API schema, find generated and handwritten consumers, locate tests for changed fields, and produce an owner-grouped impact review. Make no code or ticket changes.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not regenerate clients or create tickets without approval.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-019 · Drift owner resolver

For each out-of-band cloud change, connect the CloudTrail actor to the Terraform resource, repository owner, and reason recorded in work tracking. Mark changes with no durable explanation.

- **Systems:** AWS CloudTrail · Terraform · GitHub · Linear
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not revert drift automatically.
- **Evidence:** [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html) · [Terraform CLI](https://developer.hashicorp.com/terraform/cli/commands) · [Git](https://git-scm.com/docs) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Drift owner resolver.
Tools: Work only with AWS CloudTrail, Terraform, GitHub, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Resolve every recent out-of-band AWS change to its Terraform resource, repository owner, and Linear rationale. Flag changes with no durable explanation and do not revert anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not revert drift automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-020 · Cost spike as product event

Explain cloud-cost anomalies through product releases, feature rollouts, and traffic or error changes instead of cost categories alone.

- **Systems:** AWS Cost Explorer · GitHub Deployments · LaunchDarkly · Datadog
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Treat correlation as a lead, not proof of causation.
- **Evidence:** [AWS Cost Explorer](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log) · [Datadog](https://docs.datadoghq.com/api/latest/using-the-api/)

```text
$play explore [
Outcome: Cost spike as product event.
Tools: Work only with AWS Cost Explorer, GitHub Deployments, LaunchDarkly, and Datadog. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Explain the latest AWS cost spike using deploys, feature rollouts, and Datadog traffic or error movement. Rank evidence-backed product causes and label uncertainty explicitly.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Treat correlation as a lead, not proof of causation.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-021 · Data-residency route proof

Trace a representative request from DNS through deployment region and configured data services. Compare the actual route with declared residency policy and repository configuration.

- **Systems:** Cloudflare DNS · AWS Organizations · Terraform · GitHub
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Proof only; do not move data or change routing.
- **Evidence:** [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/) · [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/APIReference/Welcome.html) · [Terraform CLI](https://developer.hashicorp.com/terraform/cli/commands) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Data-residency route proof.
Tools: Work only with Cloudflare DNS, AWS Organizations, Terraform, and GitHub. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Trace a representative customer request from Cloudflare DNS through AWS accounts, regions, and Terraform-managed data services. Compare the actual route with declared residency policy and report contradictions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Proof only; do not move data or change routing.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-022 · Secret-expiry launch risk

Before a launch, map referenced secrets to CI jobs, deploy targets, owners, and upcoming expiry or rotation events without retrieving secret values.

- **Systems:** 1Password · GitHub Actions · Vercel · Google Calendar
- **Reach:** shell · api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Never print secret values; inspect references and metadata only.
- **Evidence:** [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts) · [GitHub Actions](https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10) · [Vercel](https://vercel.com/docs/rest-api) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Secret-expiry launch risk.
Tools: Work only with 1Password, GitHub Actions, Vercel, and Google Calendar. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Before launch, map 1Password secret references to GitHub Actions jobs, Vercel targets, owners, and expiry events. Identify launch risks without retrieving or printing secret values.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never print secret values; inspect references and metadata only.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-023 · Dead-service retirement proof

Prove a service is unused by joining DNS, request telemetry, deploy history, repository activity, and residual cost. Preserve counterevidence that blocks retirement.

- **Systems:** Cloudflare DNS · Datadog · GitHub Deployments · AWS Cost Explorer
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never delete the service; produce evidence and blockers.
- **Evidence:** [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/) · [Datadog](https://docs.datadoghq.com/api/latest/using-the-api/) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [AWS Cost Explorer](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html)

```text
$play explore [
Outcome: Dead-service retirement proof.
Tools: Work only with Cloudflare DNS, Datadog, GitHub Deployments, and AWS Cost Explorer. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Build retirement proof for a suspected dead service from DNS, traffic, deploy history, repository activity, and residual cost. Preserve counterevidence and make no destructive changes.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never delete the service; produce evidence and blockers.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-024 · Monorepo test-gap cartography

Map changed files to ownership, historical failures, workflow selection, and produced artifacts. Find code paths that changed but never reached a relevant test job.

- **Systems:** GitHub · GitHub Actions · GitHub Actions artifacts · Git
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Report missing coverage; do not claim untested code is defective.
- **Evidence:** [GitHub Actions](https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10) · [GitHub Actions artifacts](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Monorepo test-gap cartography.
Tools: Work only with GitHub, GitHub Actions, GitHub Actions artifacts, and Git. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Map this monorepo change to owners, selected workflows, historical failures, and produced test artifacts. Identify changed paths that never reached a relevant test job.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Report missing coverage; do not claim untested code is defective.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### CLOUD-025 · License-change release gate

Detect when a dependency or transitive dependency changes license between the locked and proposed versions, then locate the binaries and deployables that absorb it.

- **Systems:** npm · GitHub · shell
- **Reach:** shell · api
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Flag for legal review; do not render legal conclusions.
- **Evidence:** [npm](https://docs.npmjs.com/cli/v11/commands/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: License-change release gate.
Tools: Work only with npm, GitHub, and shell. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare licenses across the locked and proposed dependency trees, including transitive packages. Map changed licenses to shipped binaries and produce a legal-review queue without making legal conclusions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Flag for legal review; do not render legal conclusions.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

## Agent operations

### AGENT-001 · Instruction collision map

Resolve every instruction file that can affect a task, apply directory precedence, and show contradictory commands before an agent starts work.

- **Systems:** AGENTS.md · Copilot instructions · repository files
- **Reach:** shell
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Read-only; do not rewrite instructions automatically.
- **Evidence:** [GitHub Copilot instructions](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Instruction collision map.
Tools: Work only with AGENTS.md, Copilot instructions, and repository files. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Resolve all repository and path-specific agent instructions for this task, apply precedence, and show contradictions or unreachable guidance before any work begins.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Read-only; do not rewrite instructions automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-002 · Tool-permission shadow diff

Compare tools advertised to an agent with tools it actually invoked, their read/write annotations, and the permissions used. Reveal broad grants that never contributed to the result.

- **Systems:** MCP schemas · agent trace · local policy files
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Recommend least privilege; do not revoke access automatically.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Tool-permission shadow diff.
Tools: Work only with MCP schemas, agent trace, and local policy files. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare advertised agent tools, MCP annotations, actual calls, and permissions used in this run. Identify unnecessary write or open-world access and propose a review-only least-privilege profile.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Recommend least privilege; do not revoke access automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-003 · Tool-schema drift impact

Diff MCP or OpenAPI tool schemas across versions, then search prompts, skills, and saved Plays for arguments or outputs that became invalid.

- **Systems:** MCP servers · OpenAPI specs · GitHub · local Play catalog
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Do not update published Plays automatically.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Tool-schema drift impact.
Tools: Work only with MCP servers, OpenAPI specs, GitHub, and local Play catalog. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Diff current and previous tool schemas, then find prompts, skills, and Plays that depend on removed arguments, changed enums, or output fields. Produce an owner-grouped repair list.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not update published Plays automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-004 · Replay nondeterminism microscope

Replay the same task against frozen inputs, then compare tool-call order and outputs. Isolate divergence from the model, changing external state, or an unstable command.

- **Systems:** agent traces · Git worktrees · local processes
- **Reach:** shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Use fixtures or read-only calls; never replay destructive writes.
- **Evidence:** [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Replay nondeterminism microscope.
Tools: Work only with agent traces, Git worktrees, and local processes. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Replay this agent task against frozen inputs three times. Compare tool order, arguments, outputs, and file diffs to isolate model, external-state, and command nondeterminism.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use fixtures or read-only calls; never replay destructive writes.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-005 · Retry-loop fingerprint miner

Cluster repeated failed calls by unchanged error, mutated argument, and eventual recovery. Turn productive recovery sequences into candidate Plays and flag blind retries.

- **Systems:** agent traces · MCP tool results · shell history
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Analyze recorded runs; do not rerun failed writes.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema)

```text
$play explore [
Outcome: Retry-loop fingerprint miner.
Tools: Work only with agent traces, MCP tool results, and shell history. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Cluster retries in recent agent traces by error, argument change, and eventual recovery. Separate productive diagnosis from blind repetition and propose reusable recovery candidates.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Analyze recorded runs; do not rerun failed writes.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-006 · Context payload bloat locator

Measure which files, tool outputs, and repeated excerpts enter context but never influence a citation, decision, command, or diff. Preserve required safety instructions even when unused.

- **Systems:** agent trace · repository files · MCP resources
- **Reach:** shell
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Never recommend removing safety or policy instructions solely because they were unused.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Context payload bloat locator.
Tools: Work only with agent trace, repository files, and MCP resources. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Measure context inputs against later citations, decisions, commands, and diffs. Find repeated or inert payload while preserving safety and policy instructions regardless of apparent use.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never recommend removing safety or policy instructions solely because they were unused.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-007 · Expert-correction hotspot

Find where experts repeatedly correct the same field, assumption, or tool choice across runs. Rank the corrections whose reuse would prevent the most rework.

- **Systems:** agent traces · Git diffs · issue comments
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Treat corrections as candidate knowledge, not universal policy.
- **Evidence:** [Git](https://git-scm.com/docs) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Expert-correction hotspot.
Tools: Work only with agent traces, Git diffs, and issue comments. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find repeated expert corrections across agent traces, Git diffs, and issue comments. Rank the corrections most likely to prevent future rework and show the evidence for each.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Treat corrections as candidate knowledge, not universal policy.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-008 · Fallback-model divergence

Run a frozen task through the configured primary and fallback paths. Compare tool selection, policy adherence, evidence use, and final diffs rather than prose style.

- **Systems:** agent harness · Git worktrees · test runner
- **Reach:** shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Use isolated worktrees and non-production fixtures.
- **Evidence:** [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Fallback-model divergence.
Tools: Work only with agent harness, Git worktrees, and test runner. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Run this frozen task through the configured primary and fallback model paths in isolated worktrees. Compare tool choice, policy adherence, evidence, tests, and diffs rather than writing style.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use isolated worktrees and non-production fixtures.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-009 · Claimed-test verifier

Compare an agent's test claims with shell history, workflow artifacts, exit codes, and changed files. Detect tests that were named but never run or ran before the relevant change.

- **Systems:** agent trace · shell history · GitHub Actions artifacts · Git
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Report evidence gaps without inferring intent.
- **Evidence:** [GitHub Actions artifacts](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Claimed-test verifier.
Tools: Work only with agent trace, shell history, GitHub Actions artifacts, and Git. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Verify every test claim in this agent run against command history, timestamps, exit codes, artifacts, and the final diff. Flag tests never run or run before the relevant change.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Report evidence gaps without inferring intent.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-010 · Invisible side-effect census

Snapshot filesystem, processes, network listeners, package locks, and Git status before and after a run to reveal side effects absent from the final answer.

- **Systems:** local filesystem · process table · Git · package manager
- **Reach:** shell
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Observe only; do not terminate processes or clean files automatically.
- **Evidence:** [Git](https://git-scm.com/docs) · [npm](https://docs.npmjs.com/cli/v11/commands/)

```text
$play explore [
Outcome: Invisible side-effect census.
Tools: Work only with local filesystem, process table, Git, and package manager. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare pre-run and post-run filesystem, process, listener, package-lock, and Git state. Report side effects that were not disclosed, without cleaning or terminating anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Observe only; do not terminate processes or clean files automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-011 · Credential reach versus task need

Map each credential available to a run to the exact endpoint or command that used it. Show credentials whose scope exceeded the task's demonstrated need.

- **Systems:** 1Password references · MCP servers · agent trace · cloud APIs
- **Reach:** shell · api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never read or emit credential values.
- **Evidence:** [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts) · [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema)

```text
$play explore [
Outcome: Credential reach versus task need.
Tools: Work only with 1Password references, MCP servers, agent trace, and cloud APIs. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Map available credential references to actual endpoints and commands used in this run. Identify scope beyond demonstrated need without reading, printing, revoking, or rotating any secret.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never read or emit credential values.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-012 · Stale skill versus live CLI

Compare commands embedded in agent skills with current CLI grammar, help, and harmless dry runs. Pinpoint instructions that would fail today.

- **Systems:** skill files · local CLIs · Git
- **Reach:** shell
- **Access:** none
- **Best home:** public
- **Complexity:** 2 / 5
- **Safety boundary:** Run help and dry-run forms only.
- **Evidence:** [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Stale skill versus live CLI.
Tools: Work only with skill files, local CLIs, and Git. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Audit agent skill commands against installed CLI versions, grammar, help, and harmless dry runs. List stale flags, missing subcommands, and unsafe assumptions without executing writes.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Run help and dry-run forms only.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-013 · Prompt-to-write provenance

For each external write, connect the user instruction, intermediate evidence, approval state, tool call, and resulting remote object. Surface writes with no clear authority chain.

- **Systems:** agent trace · MCP tool results · Git history · external audit logs
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Audit only; never repeat or undo remote writes automatically.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Git](https://git-scm.com/docs) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log)

```text
$play explore [
Outcome: Prompt-to-write provenance.
Tools: Work only with agent trace, MCP tool results, Git history, and external audit logs. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Build a provenance chain for every external write in this run: user authority, evidence, approval, tool call, and resulting object. Flag any write with a missing link.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Audit only; never repeat or undo remote writes automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-014 · Cross-harness result parity

Run the same Play in two supported harnesses with frozen inputs and compare artifacts, writes proposed, citations, and policy outcomes.

- **Systems:** two agent harnesses · Git worktrees · test runner
- **Reach:** shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Use isolated fixtures and block external writes.
- **Evidence:** [GitHub Copilot instructions](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Cross-harness result parity.
Tools: Work only with two agent harnesses, Git worktrees, and test runner. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Run this Play in two supported harnesses against the same frozen fixture. Compare artifacts, proposed writes, citations, policy outcomes, and final tests in isolated worktrees.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use isolated fixtures and block external writes.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-015 · Missing stop-condition detector

Examine long runs for loops without a measurable completion state. Infer a verifiable stop condition from the requested outcome and successful prior runs.

- **Systems:** agent traces · test results · issue state
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Propose stop conditions; do not truncate active work automatically.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Missing stop-condition detector.
Tools: Work only with agent traces, test results, and issue state. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Find agent runs that continued without a measurable completion state. Infer evidence-based stop conditions from the requested outcome, tests, and comparable successful runs.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Propose stop conditions; do not truncate active work automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-016 · Tool-argument instability map

Compare repeated calls to the same tool and identify arguments the agent guesses inconsistently, especially IDs, time windows, pagination, and destructive flags.

- **Systems:** agent traces · MCP schemas · API logs
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Analyze recorded arguments; do not replay destructive calls.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema)

```text
$play explore [
Outcome: Tool-argument instability map.
Tools: Work only with agent traces, MCP schemas, and API logs. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare repeated calls to the same tools and identify unstable guessed arguments, especially identifiers, time windows, pagination, and write flags. Suggest parameters that should be resolved once and referenced.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Analyze recorded arguments; do not replay destructive calls.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-017 · Shared-state contamination test

Run a task in a clean profile and the normal profile. Identify outputs caused by stale browser state, cached files, environment variables, or prior tool state.

- **Systems:** agent harness · browser profile · local filesystem · Git
- **Reach:** browser · shell
- **Access:** mixed
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Use isolated copies; never expose browser tokens or environment values.
- **Evidence:** [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Shared-state contamination test.
Tools: Work only with agent harness, browser profile, local filesystem, and Git. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Run this task once in a clean profile and once in the normal profile. Compare outcomes to locate stale browser, cache, file, environment, or tool state without revealing secrets.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use isolated copies; never expose browser tokens or environment values.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-018 · Public canary for tool honesty

Use stable no-auth public endpoints to test whether a harness actually performs calls, preserves citations, handles pagination, and reports rate limits rather than fabricating results.

- **Systems:** OSV · World Bank Indicators · USGS · agent harness
- **Reach:** api
- **Access:** none
- **Best home:** public
- **Complexity:** 2 / 5
- **Safety boundary:** Use documented rate limits and small result sets.
- **Evidence:** [OSV](https://google.github.io/osv.dev/api/) · [World Bank Indicators](https://datahelpdesk.worldbank.org/knowledgebase/articles/889392) · [USGS Earthquake Catalog](https://earthquake.usgs.gov/fdsnws/event/1/swagger.json)

```text
$play explore [
Outcome: Public canary for tool honesty.
Tools: Work only with OSV, World Bank Indicators, USGS, and agent harness. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Build a no-auth harness canary using OSV, World Bank, and USGS. Verify real calls, pagination, citations, error handling, and rate-limit reporting with small read-only queries.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use documented rate limits and small result sets.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-019 · Approval-boundary proof

Inject representative read, reversible-write, and irreversible-write requests into a sandbox and prove where the harness pauses, asks, or proceeds.

- **Systems:** agent harness · sandbox API · Git worktree
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 5 / 5
- **Safety boundary:** Use fake endpoints and disposable fixtures only.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Approval-boundary proof.
Tools: Work only with agent harness, sandbox API, and Git worktree. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Prove this harness's approval boundaries with sandboxed read, reversible-write, and irreversible-write cases. Record where it pauses, asks, or proceeds; never target real systems.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use fake endpoints and disposable fixtures only.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-020 · Self-modifying instruction watch

Detect when a run changes an instruction, skill, hook, or policy file that will govern its own later behavior. Explain the before-and-after authority implications.

- **Systems:** Git · agent instruction files · skill files · hooks
- **Reach:** shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Observe and require human review; do not accept self-modification as authority.
- **Evidence:** [GitHub Copilot instructions](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Self-modifying instruction watch.
Tools: Work only with Git, agent instruction files, skill files, and hooks. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Detect any changes this run makes to instructions, skills, hooks, or policy files that will govern later behavior. Explain the authority change and require human review.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Observe and require human review; do not accept self-modification as authority.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-021 · Agent dependency expansion audit

Compare requested work with every package, binary, browser extension, and MCP server added or activated. Find expansions that were unnecessary or persisted beyond the task.

- **Systems:** npm · local package manager · MCP configuration · Git
- **Reach:** shell
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Do not uninstall or disable dependencies automatically.
- **Evidence:** [npm](https://docs.npmjs.com/cli/v11/commands/) · [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Agent dependency expansion audit.
Tools: Work only with npm, local package manager, MCP configuration, and Git. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare the requested task with packages, binaries, extensions, and MCP servers added or activated during the run. Flag unnecessary or persistent expansion without removing anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not uninstall or disable dependencies automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-022 · Ungrounded identifier detector

Collect every repository, ticket, deployment, user, and incident identifier asserted by the agent and prove it came from a tool result or user input.

- **Systems:** agent trace · GitHub · Linear · PagerDuty
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Mark unverified identifiers; do not infer the object exists.
- **Evidence:** [Git](https://git-scm.com/docs) · [Linear](https://linear.app/developers/graphql) · [PagerDuty](https://github.com/PagerDuty/api-schema)

```text
$play explore [
Outcome: Ungrounded identifier detector.
Tools: Work only with agent trace, GitHub, Linear, and PagerDuty. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Audit every repository, issue, deploy, user, and incident identifier in this run. Prove each came from user input or a tool result and mark every ungrounded identifier.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Mark unverified identifiers; do not infer the object exists.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-023 · Rate-limit recovery rehearsal

Simulate throttling against fixtures and verify that the agent respects retry headers, preserves pagination state, and avoids duplicate writes after recovery.

- **Systems:** mock API · agent harness · MCP tool schema
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Use mocks or public read-only endpoints; never provoke a production limit intentionally.
- **Evidence:** [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/schema) · [Crossref](https://www.crossref.org/documentation/retrieve-metadata/rest-api/)

```text
$play explore [
Outcome: Rate-limit recovery rehearsal.
Tools: Work only with mock API, agent harness, and MCP tool schema. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Rehearse API throttling with fixtures. Verify retry headers, backoff, pagination continuity, and duplicate-write prevention without intentionally rate-limiting a production service.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use mocks or public read-only endpoints; never provoke a production limit intentionally.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-024 · Judgment per compute cycle

Measure useful verified outcomes per model call by linking each reasoning segment to evidence gathered, corrections avoided, tests passed, and durable artifacts produced.

- **Systems:** agent traces · test runner · Git · issue tracker
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not use the metric to rank individuals; use it to improve task and Play design.
- **Evidence:** [Git](https://git-scm.com/docs) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Judgment per compute cycle.
Tools: Work only with agent traces, test runner, Git, and issue tracker. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Measure useful verified outcomes per model call for recent runs using evidence gathered, corrections avoided, tests passed, and durable artifacts. Diagnose workflow waste without ranking people.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not use the metric to rank individuals; use it to improve task and Play design.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### AGENT-025 · Repeated-trace Play candidate ranker

Find recurring successful trace shapes across different tasks, quantify shared steps and expert corrections, and rank the highest-value methods to crystallize as Plays.

- **Systems:** agent traces · Git · issue tracker
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Propose candidates; do not publish a Play without expert review.
- **Evidence:** [Git](https://git-scm.com/docs) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Repeated-trace Play candidate ranker.
Tools: Work only with agent traces, Git, and issue tracker. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find recurring successful trace shapes across recent work. Rank methods to crystallize as Plays by repeated steps, expert corrections avoided, frequency, and outcome value.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Propose candidates; do not publish a Play without expert review.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

## Security and compliance

### SECURITY-001 · Dormant admin, live token

Find administrators with no recent interactive use but active API tokens or automation attributed to them. Separate legitimate service ownership from forgotten human credentials.

- **Systems:** Okta · Okta System Log · GitHub · 1Password
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never revoke access automatically; require identity-owner confirmation.
- **Evidence:** [Okta](https://developer.okta.com/docs/api/) · [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Git](https://git-scm.com/docs) · [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts)

```text
$play explore [
Outcome: Dormant admin, live token.
Tools: Work only with Okta, Okta System Log, GitHub, and 1Password. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find dormant administrator accounts that still have active tokens or automation. Separate legitimate service ownership from forgotten human credentials using Okta events, repository evidence, and secret references. Make no access changes.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never revoke access automatically; require identity-owner confirmation.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-002 · Former-employee deploy lineage

Trace deploy keys, signed commits, CI jobs, and recent production changes back to workers who have left or changed roles. Identify durable machine ownership before proposing cleanup.

- **Systems:** Rippling · GitHub Actions · Git · AWS CloudTrail
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Preserve forensic evidence and require approval before key rotation.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [GitHub Actions](https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10) · [Git](https://git-scm.com/docs) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html)

```text
$play explore [
Outcome: Former-employee deploy lineage.
Tools: Work only with Rippling, GitHub Actions, Git, and AWS CloudTrail. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Trace deploy keys, CI jobs, signed commits, and production changes to workers who left or changed roles. Resolve current machine ownership and produce a review-only cleanup plan.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Preserve forensic evidence and require approval before key rotation.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-003 · SSO-bypass path graph

Compare the intended identity provider path with direct passwords, API tokens, break-glass accounts, and local application users. Show every route that reaches a protected system without the expected SSO policy.

- **Systems:** Okta · Google Admin · SaaS user directories · audit logs
- **Reach:** api · browser
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Read-only; do not test bypasses by attempting unauthorized access.
- **Evidence:** [Okta](https://developer.okta.com/docs/api/) · [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Google Admin Directory](https://developers.google.com/workspace/admin/directory/reference/rest) · [Google Admin Reports](https://developers.google.com/workspace/admin/reports/reference/rest)

```text
$play explore [
Outcome: SSO-bypass path graph.
Tools: Work only with Okta, Google Admin, SaaS user directories, and audit logs. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Map every documented route into protected SaaS systems and identify accounts, tokens, or local users that do not traverse the intended SSO policy. Use directory and audit evidence only; do not attempt access.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Read-only; do not test bypasses by attempting unauthorized access.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-004 · Ownerless machine identity

Link service accounts, bot users, API tokens, and scheduled jobs to a current team, repository, and business purpose. Surface identities whose last human owner has vanished.

- **Systems:** Okta · Google Admin · GitHub Actions · Rippling
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Never disable machine identities automatically.
- **Evidence:** [Okta](https://developer.okta.com/docs/api/) · [Google Admin Directory](https://developers.google.com/workspace/admin/directory/reference/rest) · [GitHub Actions](https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10) · [Rippling](https://developer.rippling.com/documentation/rest-api)

```text
$play explore [
Outcome: Ownerless machine identity.
Tools: Work only with Okta, Google Admin, GitHub Actions, and Rippling. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Map service accounts, bot users, tokens, and scheduled jobs to current teams, repositories, and business purpose. Flag machine identities whose human owner or purpose can no longer be proven.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never disable machine identities automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-005 · Secret-rotation blast radius

Before rotating a secret, enumerate every reference, CI job, deployment target, fallback credential, and known owner. Prove which consumers can be tested independently.

- **Systems:** 1Password · GitHub Actions · Vercel · Terraform
- **Reach:** shell · api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Inspect references only; never print or rotate the secret.
- **Evidence:** [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts) · [GitHub Actions](https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10) · [Vercel](https://vercel.com/docs/rest-api) · [Terraform CLI](https://developer.hashicorp.com/terraform/cli/commands)

```text
$play explore [
Outcome: Secret-rotation blast radius.
Tools: Work only with 1Password, GitHub Actions, Vercel, and Terraform. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Map the blast radius of rotating a named secret across 1Password references, CI jobs, Vercel targets, and Terraform. Identify independently testable consumers without reading or changing the secret.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Inspect references only; never print or rotate the secret.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-006 · Role entropy after job changes

Compare recent promotions, transfers, and manager changes with current group membership and actual application use. Find additive access that accumulated while old duties disappeared.

- **Systems:** Rippling · Okta · Okta System Log
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Recommend review; never remove access from behavioral inference alone.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [Okta](https://developer.okta.com/docs/api/) · [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/)

```text
$play explore [
Outcome: Role entropy after job changes.
Tools: Work only with Rippling, Okta, and Okta System Log. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare recent role changes in Rippling with Okta groups and actual application use. Find additive access that outlived prior duties and prepare an owner-confirmed review queue.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Recommend review; never remove access from behavioral inference alone.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-007 · Login outlives employment

Detect browser or SaaS logins active after a worker's termination or suspension time by aligning HR state with authentication events and application logs.

- **Systems:** Rippling · Okta System Log · Google Admin Reports
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Escalate to security; do not terminate logins without incident authority.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Google Admin Reports](https://developers.google.com/workspace/admin/reports/reference/rest)

```text
$play explore [
Outcome: Login outlives employment.
Tools: Work only with Rippling, Okta System Log, and Google Admin Reports. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Align worker termination and suspension times with Okta and Google Workspace authentication events. Flag logins or activity that continued afterward and preserve an incident-ready evidence timeline.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Escalate to security; do not terminate logins without incident authority.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-008 · API-key privilege versus observed use

Compare an API token's allowed scopes with the endpoints it actually called over a representative period. Produce the narrowest observed permission set plus exceptions that need owner confirmation.

- **Systems:** SaaS audit logs · Okta · 1Password references · agent traces
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never narrow or rotate tokens automatically; absence of use is not proof of no future need.
- **Evidence:** [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log)

```text
$play explore [
Outcome: API-key privilege versus observed use.
Tools: Work only with SaaS audit logs, Okta, 1Password references, and agent traces. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare each selected API token's allowed scopes with endpoints actually used over the review period. Propose the narrowest observed scope and list unproven future needs for owner confirmation.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never narrow or rotate tokens automatically; absence of use is not proof of no future need.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-009 · Dormant webhook still delivering

Find integrations whose source object is inactive but whose webhook endpoint still receives data. Resolve the endpoint owner, payload sensitivity, and last confirmed consumer.

- **Systems:** Linear webhooks · GitHub · Cloudflare DNS · application logs
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not disable delivery; preserve event evidence and redact payloads.
- **Evidence:** [Linear webhooks](https://linear.app/developers/webhooks) · [Git](https://git-scm.com/docs) · [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/)

```text
$play explore [
Outcome: Dormant webhook still delivering.
Tools: Work only with Linear webhooks, GitHub, Cloudflare DNS, and application logs. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find webhooks attached to inactive projects or integrations that still deliver data. Resolve endpoint ownership, payload sensitivity, and last confirmed consumer without disabling anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not disable delivery; preserve event evidence and redact payloads.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-010 · Audit-log silence detector

Model the events a control should generate, then flag systems where expected activity continued but audit events stopped, changed shape, or arrived late.

- **Systems:** Okta System Log · Google Admin Reports · LaunchDarkly audit log · AWS CloudTrail
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Treat silence as a telemetry failure candidate, not proof of no activity.
- **Evidence:** [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Google Admin Reports](https://developers.google.com/workspace/admin/reports/reference/rest) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html)

```text
$play explore [
Outcome: Audit-log silence detector.
Tools: Work only with Okta System Log, Google Admin Reports, LaunchDarkly audit log, and AWS CloudTrail. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Define expected audit events for selected controls, then detect where business activity continued but Okta, Google, LaunchDarkly, or CloudTrail evidence stopped or changed shape. Label uncertainty.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Treat silence as a telemetry failure candidate, not proof of no activity.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-011 · Production data in development artifacts

Inspect CI artifacts, test fixtures, screenshots, and error samples for identifiers that also appear in production-only records. Establish provenance without copying sensitive values into the report.

- **Systems:** GitHub Actions artifacts · Sentry · Git · shell
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Hash or redact sensitive matches; never reproduce customer data.
- **Evidence:** [GitHub Actions artifacts](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts) · [Sentry](https://docs.sentry.io/api/events/list-an-organizations-issues/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Production data in development artifacts.
Tools: Work only with GitHub Actions artifacts, Sentry, Git, and shell. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Check CI artifacts, fixtures, screenshots, and error samples for hashed indicators of production-only data. Establish provenance and affected artifacts without reproducing sensitive values.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Hash or redact sensitive matches; never reproduce customer data.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-012 · Expired exception, missing control

Join security exception records with current configuration and recent system use. Find exceptions that expired while the risky state remained and no compensating control appeared.

- **Systems:** Linear · Notion · Okta · AWS CloudTrail
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not remediate automatically; preserve the approving context.
- **Evidence:** [Linear](https://linear.app/developers/graphql) · [Notion](https://developers.notion.com/reference/intro) · [Okta](https://developer.okta.com/docs/api/) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html)

```text
$play explore [
Outcome: Expired exception, missing control.
Tools: Work only with Linear, Notion, Okta, and AWS CloudTrail. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare expired security exceptions with current configuration and recent use. Flag risky states that remained after expiry without a documented compensating control, preserving the original approval context.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not remediate automatically; preserve the approving context.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-013 · Running exploitability, not CVE volume

Join a local SBOM with OSV and CISA KEV, then prove whether affected versions are present in currently deployed artifacts and reachable services. Prioritize known exploitation on running paths.

- **Systems:** local SBOM tools · OSV · CISA KEV · GitHub Deployments
- **Reach:** shell · api
- **Access:** mixed
- **Best home:** public
- **Complexity:** 5 / 5
- **Safety boundary:** Do not equate package presence with exploitability; preserve reachability uncertainty.
- **Evidence:** [OSV](https://google.github.io/osv.dev/api/) · [CISA Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28)

```text
$play explore [
Outcome: Running exploitability, not CVE volume.
Tools: Work only with local SBOM tools, OSV, CISA KEV, and GitHub Deployments. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Join the current SBOM with OSV and CISA KEV, then map affected versions to deployed artifacts and reachable services. Prioritize known exploitation on running paths and label unproven reachability.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not equate package presence with exploitability; preserve reachability uncertainty.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-014 · Vulnerable but unreachable proof

Trace imports, build inclusion, runtime entry points, network exposure, and feature flags for a known vulnerable package. Assemble evidence about whether the vulnerable path is reachable.

- **Systems:** OSV · Git · build tools · LaunchDarkly
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 5 / 5
- **Safety boundary:** State reachability as evidence and uncertainty, never as a guarantee of safety.
- **Evidence:** [OSV](https://google.github.io/osv.dev/api/) · [Git](https://git-scm.com/docs) · [LaunchDarkly](https://launchdarkly.com/docs/api)

```text
$play explore [
Outcome: Vulnerable but unreachable proof.
Tools: Work only with OSV, Git, build tools, and LaunchDarkly. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. For this vulnerable package, trace imports, build inclusion, runtime entry points, exposure, and feature flags. Assemble evidence for reachable or unreachable status and state uncertainty explicitly.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: State reachability as evidence and uncertainty, never as a guarantee of safety.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-015 · Signing-material policy drift

Inventory certificate and signing-key metadata, then compare algorithms, age, intended use, repository verification settings, and rotation records with current policy.

- **Systems:** 1Password · Git · GitHub Actions · Notion
- **Reach:** shell · api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Metadata only; never export private keys.
- **Evidence:** [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts) · [Git](https://git-scm.com/docs) · [GitHub Actions](https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10) · [Notion](https://developers.notion.com/reference/intro)

```text
$play explore [
Outcome: Signing-material policy drift.
Tools: Work only with 1Password, Git, GitHub Actions, and Notion. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Inventory signing and certificate metadata without exporting private material. Compare algorithms, age, intended use, repository verification, and rotation records with current policy.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Metadata only; never export private keys.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-016 · CI artifact secret residue

Scan build artifacts and logs for high-confidence secret structure, then trace the generating step and retention window. Verify findings against secret names without revealing values.

- **Systems:** GitHub Actions artifacts · GitLab CI · 1Password · shell
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Redact all findings; never print or validate a secret against a live service.
- **Evidence:** [GitHub Actions artifacts](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts) · [GitLab CI](https://docs.gitlab.com/api/pipelines/) · [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts)

```text
$play explore [
Outcome: CI artifact secret residue.
Tools: Work only with GitHub Actions artifacts, GitLab CI, 1Password, and shell. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Scan selected CI artifacts and logs for high-confidence secret residue. Trace the generating step and retention window, verify only against secret names, and redact every value.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Redact all findings; never print or validate a secret against a live service.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-017 · Privileged change outside the window

Align privileged configuration changes with maintenance windows, incident declarations, and approver availability. Distinguish emergency action from unexplained timing.

- **Systems:** AWS CloudTrail · Okta System Log · Google Calendar · PagerDuty
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Evidence only; timing is not proof of unauthorized behavior.
- **Evidence:** [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html) · [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [PagerDuty](https://github.com/PagerDuty/api-schema)

```text
$play explore [
Outcome: Privileged change outside the window.
Tools: Work only with AWS CloudTrail, Okta System Log, Google Calendar, and PagerDuty. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Align privileged AWS and identity changes with maintenance windows, incidents, and approver availability. Separate emergency actions from unexplained timing without inferring intent.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Evidence only; timing is not proof of unauthorized behavior.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-018 · Shared-mailbox shadow administrator

Find operational accounts controlled through shared inboxes, aliases, or delegated mail, then map who can reset or approve access through that mailbox.

- **Systems:** Gmail · Google Admin · Okta
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Inspect delegation and recovery paths only; do not open unrelated mail.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Google Admin Directory](https://developers.google.com/workspace/admin/directory/reference/rest) · [Okta](https://developer.okta.com/docs/api/)

```text
$play explore [
Outcome: Shared-mailbox shadow administrator.
Tools: Work only with Gmail, Google Admin, and Okta. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find operational accounts whose recovery or approval path depends on shared mailboxes, aliases, or delegation. Map who can control those paths using only necessary metadata.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Inspect delegation and recovery paths only; do not open unrelated mail.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-019 · Public link to private incident

Locate broadly shared Drive files referenced from support or incident records, then determine whether customer identifiers, credentials, or internal topology are exposed beyond intended responders.

- **Systems:** Google Drive · Zendesk · PagerDuty
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not widen access or echo sensitive content; report file IDs and classifications.
- **Evidence:** [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [PagerDuty](https://github.com/PagerDuty/api-schema)

```text
$play explore [
Outcome: Public link to private incident.
Tools: Work only with Google Drive, Zendesk, and PagerDuty. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find broadly shared Drive files linked from Zendesk or PagerDuty records. Classify exposure of customer data, credentials, or internal topology without echoing content or changing permissions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not widen access or echo sensitive content; report file IDs and classifications.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-020 · Break-glass readiness proof

Verify that emergency accounts exist, are excluded from ordinary use, have recent controlled tests, reachable owners, and documented recovery material without signing in as them.

- **Systems:** Okta · Google Admin · 1Password · Google Calendar
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never authenticate as a break-glass account during routine verification.
- **Evidence:** [Okta](https://developer.okta.com/docs/api/) · [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Google Admin Directory](https://developers.google.com/workspace/admin/directory/reference/rest) · [1Password CLI](https://developer.1password.com/docs/cli/secrets-scripts) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Break-glass readiness proof.
Tools: Work only with Okta, Google Admin, 1Password, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Verify break-glass accounts, ownership, isolation from daily use, controlled-test evidence, and recovery-material references without signing in as those accounts or reading secrets.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never authenticate as a break-glass account during routine verification.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-021 · Dangling-domain takeover candidate

Find DNS records pointing at deleted deployments, missing repositories, or unclaimed service identifiers. Confirm dangling state from control-plane evidence rather than attempting to claim the resource.

- **Systems:** Cloudflare DNS · Vercel · GitHub · shell DNS tools
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Never attempt resource registration or takeover.
- **Evidence:** [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/) · [Vercel](https://vercel.com/docs/rest-api) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Dangling-domain takeover candidate.
Tools: Work only with Cloudflare DNS, Vercel, GitHub, and shell DNS tools. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Find DNS records pointing to deleted deployments, missing repositories, or unclaimed service identifiers. Confirm dangling state from read-only control-plane evidence and never attempt to claim a resource.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never attempt resource registration or takeover.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-022 · Subprocessor reality mismatch

Compare vendors declared in legal and security documents with domains contacted by production, dependencies shipped in code, and current SaaS integrations. Explain additions and vanished vendors.

- **Systems:** Google Drive · Cloudflare · GitHub · Okta
- **Reach:** api · shell · browser
- **Access:** mixed
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Flag for legal and security review; do not make compliance conclusions automatically.
- **Evidence:** [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Cloudflare DNS](https://developers.cloudflare.com/api/resources/dns/subresources/records/) · [Git](https://git-scm.com/docs) · [Okta](https://developer.okta.com/docs/api/)

```text
$play explore [
Outcome: Subprocessor reality mismatch.
Tools: Work only with Google Drive, Cloudflare, GitHub, and Okta. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare declared subprocessors with production domains, shipped dependencies, and active SaaS integrations. Explain additions and vanished vendors and prepare a legal-security review queue.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Flag for legal and security review; do not make compliance conclusions automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-023 · Auth event to sensitive change

For high-risk authentication events, inspect the narrow subsequent window for repository, identity, feature-flag, and cloud changes attributable to the same principal.

- **Systems:** Okta System Log · Git · LaunchDarkly audit log · AWS CloudTrail
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Correlation is investigative context, not attribution or guilt.
- **Evidence:** [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Git](https://git-scm.com/docs) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html)

```text
$play explore [
Outcome: Auth event to sensitive change.
Tools: Work only with Okta System Log, Git, LaunchDarkly audit log, and AWS CloudTrail. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For selected high-risk authentication events, inspect the following time window for repository, flag, identity, and AWS changes by the same principal. Preserve evidence and label attribution uncertainty.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Correlation is investigative context, not attribution or guilt.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-024 · Identity geography contradiction

Compare authentication geography and device signals with working location, approved travel, and subsequent sensitive actions. Focus on contradictions that survive timezone and VPN normalization.

- **Systems:** Okta System Log · Google Calendar · Google Admin Reports · AWS CloudTrail
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never treat location alone as proof; require security review and contextual normalization.
- **Evidence:** [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Google Admin Reports](https://developers.google.com/workspace/admin/reports/reference/rest) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html)

```text
$play explore [
Outcome: Identity geography contradiction.
Tools: Work only with Okta System Log, Google Calendar, Google Admin Reports, and AWS CloudTrail. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare authentication geography and device signals with working location, approved travel, and sensitive actions. Normalize timezones and VPNs, then report only contradictions that remain.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never treat location alone as proof; require security review and contextual normalization.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### SECURITY-025 · Control evidence chain completeness

For a named control, prove that policy, configuration, execution, exception handling, and review evidence all refer to the same systems and time period. Surface broken links rather than collecting screenshots.

- **Systems:** Notion or Google Drive · Okta · AWS CloudTrail · Linear
- **Reach:** api · browser
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not certify compliance; produce the evidence graph and missing links.
- **Evidence:** [Notion](https://developers.notion.com/reference/intro) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Okta](https://developer.okta.com/docs/api/) · [AWS CloudTrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Control evidence chain completeness.
Tools: Work only with Notion or Google Drive, Okta, AWS CloudTrail, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For this control, connect policy, live configuration, execution evidence, exceptions, and review records for the same systems and period. Show broken links and do not issue a compliance conclusion.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not certify compliance; produce the evidence graph and missing links.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

## Finance, revenue, and commerce

### FINANCE-001 · Webhook-to-cash completeness

Start with every paid-order event and prove its path through webhook delivery, fulfillment, processor balance movement, bank settlement, and accounting entry. Surface economic events that vanished between systems.

- **Systems:** Stripe Webhooks · Shopify · Stripe Balance Transactions · Mercury · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Reconcile and report only; never resend events or post ledger entries automatically.
- **Evidence:** [Stripe Webhooks](https://docs.stripe.com/webhooks) · [Shopify](https://shopify.dev/docs/api/admin-graphql/latest/queries/orders) · [Shopify Fulfillment](https://shopify.dev/docs/api/admin-graphql/latest/queries/Fulfillment) · [Stripe](https://docs.stripe.com/api/balance_transactions) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Webhook-to-cash completeness.
Tools: Work only with Stripe Webhooks, Shopify, Stripe Balance Transactions, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Trace each selected paid-order event through Stripe webhook delivery, Shopify fulfillment, Stripe balance movement, Mercury settlement, and Xero posting. Find missing economic events without resending or writing entries.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Reconcile and report only; never resend events or post ledger entries automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-002 · Settlement-delay causality

Explain why cash arrived later than the customer payment by joining processor availability dates, dispute holds, settlement batches, bank credits, and weekends or holidays.

- **Systems:** Stripe or Razorpay · Mercury · Xero · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Label contractual and banking assumptions; do not promise settlement timing.
- **Evidence:** [Stripe](https://docs.stripe.com/api/balance_transactions) · [Razorpay Settlements](https://razorpay.com/docs/api/settlements/) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Settlement-delay causality.
Tools: Work only with Stripe or Razorpay, Mercury, Xero, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Explain delayed cash arrival by joining processor availability, disputes, settlement batches, bank credits, and calendar boundaries. Produce an evidence timeline and label unresolved banking assumptions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Label contractual and banking assumptions; do not promise settlement timing.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-003 · Duplicate economic event detector

Match payments, refunds, transfers, and journal entries by economic meaning rather than ID. Detect one customer event represented twice after retries, processor migration, or manual correction.

- **Systems:** Stripe · Razorpay · Mercury · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not reverse transactions; produce matched evidence and confidence.
- **Evidence:** [Stripe](https://docs.stripe.com/api/balance_transactions) · [Razorpay Settlements](https://razorpay.com/docs/api/settlements/) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Duplicate economic event detector.
Tools: Work only with Stripe, Razorpay, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Detect duplicate economic events across Stripe, Razorpay, Mercury, and Xero using amount, currency, customer, timing, and source lineage rather than IDs alone. Make no reversals.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not reverse transactions; produce matched evidence and confidence.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-004 · Refund promised, money absent

Find support conversations where a refund was promised, then prove whether it was created, settled back to the customer, and reflected in accounting. Distinguish pending, failed, and never initiated.

- **Systems:** Zendesk · Stripe · Mercury · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not issue refunds; redact customer text in shared output.
- **Evidence:** [Zendesk Ticket Audits](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_audits/) · [Stripe](https://docs.stripe.com/api/balance_transactions) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Refund promised, money absent.
Tools: Work only with Zendesk, Stripe, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find refund promises in Zendesk and verify creation, processor settlement, bank movement, and accounting treatment. Classify pending, failed, and never initiated refunds without issuing one.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not issue refunds; redact customer text in shared output.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-005 · Dispute evidence assembler

For each dispute, assemble the order, delivery proof, customer communication, access logs, refund history, and evidence deadline into a review-ready packet.

- **Systems:** Stripe or Razorpay · Shopify · Zendesk · application logs · Google Drive
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Draft only; require human review before evidence submission.
- **Evidence:** [Stripe Disputes](https://docs.stripe.com/disputes/api) · [Razorpay Disputes](https://razorpay.com/docs/api/disputes/) · [Shopify Fulfillment](https://shopify.dev/docs/api/admin-graphql/latest/queries/Fulfillment) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3)

```text
$play explore [
Outcome: Dispute evidence assembler.
Tools: Work only with Stripe or Razorpay, Shopify, Zendesk, application logs, and Google Drive. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Assemble a review-ready dispute packet from processor data, Shopify fulfillment, Zendesk communication, access logs, and permitted Drive documents. Include the deadline and do not submit evidence.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Draft only; require human review before evidence submission.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-006 · Negative-margin order autopsy

Calculate realized margin after discounts, processor fees, shipping, refunds, support credits, and currency conversion. Explain the policy or exception that produced each loss-making order.

- **Systems:** Shopify · Stripe · Xero · Zendesk
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Treat accounting mappings as configurable and reviewable.
- **Evidence:** [Shopify](https://shopify.dev/docs/api/admin-graphql/latest/queries/orders) · [Shopify Fulfillment](https://shopify.dev/docs/api/admin-graphql/latest/queries/Fulfillment) · [Stripe](https://docs.stripe.com/api/balance_transactions) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/)

```text
$play explore [
Outcome: Negative-margin order autopsy.
Tools: Work only with Shopify, Stripe, Xero, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find orders with negative realized margin after discounts, fees, fulfillment, refunds, support credits, and FX. Explain each loss using source evidence and configurable accounting mappings.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Treat accounting mappings as configurable and reviewable.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-007 · Entitlement-billing contradiction

Compare invoice and subscription state with product entitlements and observed use. Find customers paying without access, consuming without payment, or holding incompatible plan features.

- **Systems:** Stripe Subscriptions · application entitlement store · product logs · Zendesk
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not change billing or access; prepare customer-safe review cases.
- **Evidence:** [Stripe Subscriptions](https://docs.stripe.com/api/subscriptions) · [Stripe Invoices](https://docs.stripe.com/api/invoices) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/)

```text
$play explore [
Outcome: Entitlement-billing contradiction.
Tools: Work only with Stripe Subscriptions, application entitlement store, product logs, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare Stripe subscription and invoice state with product entitlements, observed use, and support history. Find paid-without-access and access-without-payment contradictions without changing either side.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not change billing or access; prepare customer-safe review cases.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-008 · Dormant subscription, live consumption

Find canceled, paused, or unpaid subscriptions whose API keys, seats, storage, or compute still generate usage and cost.

- **Systems:** Stripe Subscriptions · product usage logs · AWS Cost Explorer · HubSpot
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not terminate access automatically; account for contractual grace periods.
- **Evidence:** [Stripe Subscriptions](https://docs.stripe.com/api/subscriptions) · [AWS Cost Explorer](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide)

```text
$play explore [
Outcome: Dormant subscription, live consumption.
Tools: Work only with Stripe Subscriptions, product usage logs, AWS Cost Explorer, and HubSpot. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find canceled, paused, or unpaid subscriptions that still generate product usage or cloud cost. Reconcile customer and contract context, then produce an owner-reviewed action list.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not terminate access automatically; account for contractual grace periods.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-009 · Payroll funding readiness

Before payroll cutoff, reconcile active workers, expected payroll amount, available bank balance, pending transfers, and exceptional compensation changes.

- **Systems:** Rippling · Mercury · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never initiate transfers or alter payroll; minimize employee-level data.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [Mercury](https://docs.mercury.com/docs/welcome) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Payroll funding readiness.
Tools: Work only with Rippling, Mercury, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Before the payroll cutoff, reconcile active workers, expected funding, available Mercury balance, pending transfers, and exceptional compensation changes. Report funding risk without initiating money movement.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never initiate transfers or alter payroll; minimize employee-level data.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-010 · Payroll-to-ledger population mismatch

Compare worker and payroll populations with bank debits and accounting payroll entries. Find missing workers, duplicate groups, and payments posted to the wrong entity or period.

- **Systems:** Rippling · Mercury · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Protect compensation data and do not post corrections automatically.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Payroll-to-ledger population mismatch.
Tools: Work only with Rippling, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Reconcile payroll populations across Rippling, Mercury debits, and Xero entries. Find missing workers, duplicate groups, and wrong entity or period postings while protecting compensation data.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Protect compensation data and do not post corrections automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-011 · Contractor in employee clothing

Find people paid through accounts payable who also hold employee-only access, schedules, or benefits-like entitlements. Assemble classification evidence for qualified review.

- **Systems:** Xero · Rippling · Okta · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not determine worker classification; route evidence to HR and legal review.
- **Evidence:** [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview) · [Rippling](https://developer.rippling.com/documentation/rest-api) · [Okta](https://developer.okta.com/docs/api/) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Contractor in employee clothing.
Tools: Work only with Xero, Rippling, Okta, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find contractors paid through accounts payable who also hold employee-only access, schedules, or entitlements. Assemble evidence for HR and legal review without making a classification decision.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not determine worker classification; route evidence to HR and legal review.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-012 · Changed-bank-detail payment proof

Before paying a changed beneficiary, connect the invoice, vendor history, bank-recipient change, approval conversation, and independent contact path. Surface circular approval evidence.

- **Systems:** Xero · Mercury · Slack · Google Drive
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never send payment; require independent human verification outside the submitted channel.
- **Evidence:** [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview) · [Mercury](https://docs.mercury.com/docs/welcome) · [Slack](https://api.slack.com/web) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3)

```text
$play explore [
Outcome: Changed-bank-detail payment proof.
Tools: Work only with Xero, Mercury, Slack, and Google Drive. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For a vendor with changed bank details, connect the invoice, prior payments, recipient change, approval trail, and independent contact path. Flag circular evidence and do not send money.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never send payment; require independent human verification outside the submitted channel.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-013 · Revenue-recognition exception finder

Compare invoice timing, payment, subscription service period, credits, and accounting entry period to find revenue recognized before or after the underlying obligation.

- **Systems:** Stripe Invoices · Stripe Subscriptions · Xero · Google Drive
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Prepare review cases; do not make accounting judgments or entries automatically.
- **Evidence:** [Stripe Invoices](https://docs.stripe.com/api/invoices) · [Stripe Subscriptions](https://docs.stripe.com/api/subscriptions) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3)

```text
$play explore [
Outcome: Revenue-recognition exception finder.
Tools: Work only with Stripe Invoices, Stripe Subscriptions, Xero, and Google Drive. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare Stripe invoice, payment, subscription service period, credits, contract evidence, and Xero posting period. Produce revenue-recognition review cases without posting adjustments.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Prepare review cases; do not make accounting judgments or entries automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-014 · Credit-note plus refund double relief

Find cases where a customer received both a processor refund and accounting credit relief without the intended linkage, leaving receivables or revenue understated.

- **Systems:** Stripe · Xero · Zendesk
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not reverse or reissue financial documents.
- **Evidence:** [Stripe](https://docs.stripe.com/api/balance_transactions) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview) · [Zendesk Ticket Audits](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_audits/)

```text
$play explore [
Outcome: Credit-note plus refund double relief.
Tools: Work only with Stripe, Xero, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find customer events that produced both a processor refund and an unlinked accounting credit. Reconcile support intent and quantify possible double relief without changing records.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not reverse or reissue financial documents.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-015 · Foreign-exchange fee leak

Trace original charge currency, processor conversion, settlement currency, bank conversion, and ledger rate. Identify avoidable double conversion and silent margin loss.

- **Systems:** Stripe or Razorpay · Mercury · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not recommend financial trades; quantify observed conversions and fees.
- **Evidence:** [Stripe](https://docs.stripe.com/api/balance_transactions) · [Razorpay Settlements](https://razorpay.com/docs/api/settlements/) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Foreign-exchange fee leak.
Tools: Work only with Stripe or Razorpay, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Trace original charge, processor conversion, settlement, bank conversion, and ledger rate for cross-currency transactions. Find double conversion and quantify observed fee leakage.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not recommend financial trades; quantify observed conversions and fees.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-016 · Gift-card liability drift

Reconcile issued, redeemed, refunded, expired, and transferred gift-card value with accounting liability and order adjustments. Preserve jurisdiction-dependent expiry rules as configuration.

- **Systems:** Shopify · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not apply expiry or breakage rules without accounting and legal configuration.
- **Evidence:** [Shopify](https://shopify.dev/docs/api/admin-graphql/latest/queries/orders) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Gift-card liability drift.
Tools: Work only with Shopify and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Reconcile issued, redeemed, refunded, expired, and transferred gift-card value between Shopify and Xero. Show liability drift while treating expiry and breakage rules as reviewed configuration.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not apply expiry or breakage rules without accounting and legal configuration.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-017 · Inventory cash trap

Find products tying up cash by joining inventory aging, sales velocity, refunds, supplier payments, and gross margin. Distinguish deliberate strategic stock from unnoticed stagnation.

- **Systems:** Shopify · Xero · Mercury
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Inform purchasing review; do not place or cancel orders.
- **Evidence:** [Shopify](https://shopify.dev/docs/api/admin-graphql/latest/queries/orders) · [Shopify Fulfillment](https://shopify.dev/docs/api/admin-graphql/latest/queries/Fulfillment) · [Xero Reports](https://developer.xero.com/documentation/api/accounting/reports) · [Mercury](https://docs.mercury.com/docs/welcome)

```text
$play explore [
Outcome: Inventory cash trap.
Tools: Work only with Shopify, Xero, and Mercury. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find inventory tying up cash using Shopify aging and velocity, refunds, Xero costs, and Mercury supplier payments. Separate strategic stock from unexplained stagnation.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Inform purchasing review; do not place or cancel orders.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-018 · Discount leakage after a product change

Explain unexpected discounting through coupon configuration, feature rollout, checkout code, sales promises, and invoice results. Find discounts surviving after their intended campaign or segment ended.

- **Systems:** Stripe Invoices · LaunchDarkly · GitHub · HubSpot
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not alter pricing, coupons, or customer invoices.
- **Evidence:** [Stripe Invoices](https://docs.stripe.com/api/invoices) · [LaunchDarkly audit log](https://launchdarkly.com/docs/api/audit-log) · [Git](https://git-scm.com/docs) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide)

```text
$play explore [
Outcome: Discount leakage after a product change.
Tools: Work only with Stripe Invoices, LaunchDarkly, GitHub, and HubSpot. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Explain unexpected discounting through Stripe invoices, feature rollout history, checkout code, and HubSpot deal promises. Find discounts that survived their intended campaign without changing pricing.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not alter pricing, coupons, or customer invoices.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-019 · Dispute spike after release

Correlate dispute categories and purchase cohorts with checkout releases, fulfillment changes, support symptoms, and error fingerprints to find product-caused chargebacks.

- **Systems:** Stripe Disputes · GitHub Deployments · Shopify · Zendesk · Sentry
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Correlation is a lead; do not submit dispute evidence or roll back automatically.
- **Evidence:** [Stripe Disputes](https://docs.stripe.com/disputes/api) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Shopify Fulfillment](https://shopify.dev/docs/api/admin-graphql/latest/queries/Fulfillment) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [Sentry](https://docs.sentry.io/api/events/list-an-organizations-issues/)

```text
$play explore [
Outcome: Dispute spike after release.
Tools: Work only with Stripe Disputes, GitHub Deployments, Shopify, Zendesk, and Sentry. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Test whether a dispute spike aligns with checkout releases, fulfillment changes, support symptoms, or Sentry errors. Segment by purchase cohort and label causal uncertainty.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Correlation is a lead; do not submit dispute evidence or roll back automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-020 · Nexus evidence without the spreadsheet chase

Aggregate order destinations, employee work locations, inventory presence, and entity records into a time-bounded evidence pack for tax advisers.

- **Systems:** Shopify · Rippling · Xero · Google Drive
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not determine tax nexus; package evidence for qualified advice.
- **Evidence:** [Shopify](https://shopify.dev/docs/api/admin-graphql/latest/queries/orders) · [Rippling](https://developer.rippling.com/documentation/rest-api) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3)

```text
$play explore [
Outcome: Nexus evidence without the spreadsheet chase.
Tools: Work only with Shopify, Rippling, Xero, and Google Drive. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Assemble a time-bounded nexus evidence pack from order destinations, worker locations, inventory presence, entity records, and accounting data. Do not make a tax determination.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not determine tax nexus; package evidence for qualified advice.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-021 · Cross-border payroll conversion leak

Compare compensation currency, payroll debit, bank conversion, worker receipt evidence, and ledger rate to identify repeated spread or routing losses.

- **Systems:** Rippling · Mercury · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Protect compensation data and do not initiate transfers.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Cross-border payroll conversion leak.
Tools: Work only with Rippling, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare compensation currency, payroll debits, bank conversion, and ledger rates across cross-border payroll. Quantify repeated spread or routing loss while protecting employee data.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Protect compensation data and do not initiate transfers.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-022 · Runway versus commitments

Rebuild runway from bank balances, recurring payments, open bills, payroll timing, and signed contractual commitments rather than budget categories alone.

- **Systems:** Mercury · Xero · Rippling · Google Drive · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Present scenarios and assumptions; do not give investment or insolvency advice.
- **Evidence:** [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Reports](https://developer.xero.com/documentation/api/accounting/reports) · [Rippling](https://developer.rippling.com/documentation/rest-api) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Runway versus commitments.
Tools: Work only with Mercury, Xero, Rippling, Google Drive, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Rebuild runway from current bank balances, recurring payments, open bills, payroll timing, and signed commitments. Show scenarios and assumptions without giving financial advice.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Present scenarios and assumptions; do not give investment or insolvency advice.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-023 · Customer entitlement ghost

Find entitlements attached to deleted, merged, or duplicate CRM and billing identities. Resolve the real customer relationship and the revenue attached to each ghost.

- **Systems:** Stripe Subscriptions · HubSpot or Salesforce · application database · Zendesk
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not merge customers or alter access automatically.
- **Evidence:** [Stripe Subscriptions](https://docs.stripe.com/api/subscriptions) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Salesforce](https://developer.salesforce.com/docs/platform/salesforce-cli-reference/guide/cli_reference_api_request_rest.html) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/)

```text
$play explore [
Outcome: Customer entitlement ghost.
Tools: Work only with Stripe Subscriptions, HubSpot or Salesforce, application database, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find product entitlements attached to deleted, merged, or duplicate billing and CRM identities. Resolve likely customer lineage and revenue impact without merging or changing access.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not merge customers or alter access automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-024 · Failed dunning, continued fulfillment

Detect customers whose invoice retries exhausted or subscription became unpaid while physical or digital fulfillment continued. Account for grace periods and contractual exceptions.

- **Systems:** Stripe Invoices · Stripe Subscriptions · Shopify Fulfillment · HubSpot
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not stop fulfillment or customer access automatically.
- **Evidence:** [Stripe Invoices](https://docs.stripe.com/api/invoices) · [Stripe Subscriptions](https://docs.stripe.com/api/subscriptions) · [Shopify Fulfillment](https://shopify.dev/docs/api/admin-graphql/latest/queries/Fulfillment) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide)

```text
$play explore [
Outcome: Failed dunning, continued fulfillment.
Tools: Work only with Stripe Invoices, Stripe Subscriptions, Shopify Fulfillment, and HubSpot. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find customers whose invoice collection failed or subscription became unpaid while fulfillment continued. Apply configured grace periods and contract exceptions, then produce a review queue.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not stop fulfillment or customer access automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### FINANCE-025 · Processor-routing anomaly

Compare similar transactions routed through different processors by geography, method, fee, failure rate, settlement lag, and dispute outcome. Reveal routing rules that cost more without improving success.

- **Systems:** Stripe · Razorpay · Mercury · Xero
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Analyze observed outcomes; do not reroute payments automatically.
- **Evidence:** [Stripe](https://docs.stripe.com/api/balance_transactions) · [Razorpay Settlements](https://razorpay.com/docs/api/settlements/) · [Razorpay Disputes](https://razorpay.com/docs/api/disputes/) · [Mercury](https://docs.mercury.com/docs/welcome) · [Xero Accounting](https://developer.xero.com/documentation/api/accounting/overview)

```text
$play explore [
Outcome: Processor-routing anomaly.
Tools: Work only with Stripe, Razorpay, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare similar transactions routed through Stripe and Razorpay by geography, method, fee, failure, settlement lag, and dispute outcome. Identify costly routing anomalies without changing routing.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Analyze observed outcomes; do not reroute payments automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

## Customers, people, and governance

### PEOPLE-001 · Promised-feature debt

Extract customer promises from deal notes, email, and Slack, then prove whether each became a scoped issue, shipped behavior, or an aging unowned commitment.

- **Systems:** HubSpot · Gmail · Slack · Linear · GitHub Deployments
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not treat sales language as a binding contract without review.
- **Evidence:** [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Slack](https://api.slack.com/web) · [Linear](https://linear.app/developers/graphql) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28)

```text
$play explore [
Outcome: Promised-feature debt.
Tools: Work only with HubSpot, Gmail, Slack, Linear, and GitHub Deployments. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find product promises in CRM notes, email, and Slack. Prove whether each became a Linear issue, shipped release, or aging unowned commitment, and preserve uncertainty about contractual force.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not treat sales language as a binding contract without review.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-002 · SLA clock disagreement

Reconstruct the same customer event using support, incident, and service timestamps. Explain where acknowledgment, impact, pause, and resolution clocks disagree.

- **Systems:** Zendesk Ticket Audits · PagerDuty · Datadog Incidents · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Use configured contract definitions; do not assert breach automatically.
- **Evidence:** [Zendesk Ticket Audits](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_audits/) · [PagerDuty](https://github.com/PagerDuty/api-schema) · [Datadog Incidents](https://docs.datadoghq.com/api/latest/incidents/get-a-list-of-incidents/) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: SLA clock disagreement.
Tools: Work only with Zendesk Ticket Audits, PagerDuty, Datadog Incidents, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Reconstruct selected customer incidents across Zendesk, PagerDuty, and Datadog. Explain disagreements in acknowledgment, impact, pause, and resolution clocks using configured SLA definitions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Require the proposed cause to precede the effect. Preserve competing explanations and label correlation as correlation. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use configured contract definitions; do not assert breach automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-003 · Workaround retirement proof

Find customer workarounds documented in tickets and docs, connect them to the fixing release, and prove whether affected customers still rely on the old path.

- **Systems:** Zendesk · Notion · GitHub Deployments · Sentry
- **Reach:** api · browser
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not remove workarounds or contact customers automatically.
- **Evidence:** [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [Notion](https://developers.notion.com/reference/intro) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Sentry](https://docs.sentry.io/api/events/list-an-organizations-issues/)

```text
$play explore [
Outcome: Workaround retirement proof.
Tools: Work only with Zendesk, Notion, GitHub Deployments, and Sentry. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find documented customer workarounds, connect each to its intended fixing release, and verify whether affected customers still rely on the old path. Produce retirement candidates only.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not remove workarounds or contact customers automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-004 · Knowledge article versus shipped truth

Turn support documentation examples into browser and API checks against the current product. Flag steps, labels, fields, and permissions that no longer match reality.

- **Systems:** Zendesk Guide or Notion · product browser · OpenAPI schema · GitHub
- **Reach:** browser · shell · api
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Use test accounts and read-only product paths.
- **Evidence:** [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [Notion](https://developers.notion.com/reference/intro) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Knowledge article versus shipped truth.
Tools: Work only with Zendesk Guide or Notion, product browser, OpenAPI schema, and GitHub. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Verify support documentation examples against the current product UI, API schema, and repository. Flag stale labels, fields, steps, and permissions using test accounts only.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use test accounts and read-only product paths.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-005 · Churn intent before the CRM

Detect repeated cancellation language, escalation patterns, and declining engagement that appear in support and permitted communication before a churn risk reaches the CRM.

- **Systems:** Zendesk · Gmail or Slack · HubSpot · product usage logs
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Use only authorized business communication; avoid employee private messages and automated customer action.
- **Evidence:** [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Slack](https://api.slack.com/web) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide)

```text
$play explore [
Outcome: Churn intent before the CRM.
Tools: Work only with Zendesk, Gmail or Slack, HubSpot, and product usage logs. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find churn signals in authorized support and customer communication that predate CRM risk status. Join them with usage evidence and produce account-owner review cases, not automated outreach.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use only authorized business communication; avoid employee private messages and automated customer action.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-006 · Renewal owner disappeared

Before a renewal window, prove that the internal owner, customer contacts, open blockers, and decision meetings still exist. Detect renewals inherited by nobody after team changes.

- **Systems:** HubSpot · Rippling · Google Calendar · Linear
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not reassign accounts or contact customers automatically.
- **Evidence:** [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Rippling](https://developer.rippling.com/documentation/rest-api) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Renewal owner disappeared.
Tools: Work only with HubSpot, Rippling, Google Calendar, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For upcoming renewals, verify the internal owner is current, customer contacts are active, blockers are owned, and decision meetings exist. Flag renewals inherited by nobody.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not reassign accounts or contact customers automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-007 · Customer flag without a customer

Find feature targeting rules tied to deleted, merged, churned, or renamed customer identities. Resolve whether each flag is a live obligation, a forgotten workaround, or dead configuration.

- **Systems:** LaunchDarkly · HubSpot · Stripe Subscriptions · GitHub
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not edit targeting rules automatically.
- **Evidence:** [LaunchDarkly](https://launchdarkly.com/docs/api) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Stripe Subscriptions](https://docs.stripe.com/api/subscriptions) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Customer flag without a customer.
Tools: Work only with LaunchDarkly, HubSpot, Stripe Subscriptions, and GitHub. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find feature-flag targets tied to deleted, merged, churned, or renamed customer identities. Resolve live obligations versus forgotten workarounds and produce a review queue.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not edit targeting rules automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-008 · Bug impact priced in pipeline

Connect an error fingerprint to affected accounts, open opportunities, renewals, and support severity so engineering sees commercial exposure without guessing from ticket volume.

- **Systems:** Sentry · HubSpot · Zendesk · Linear
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Restrict revenue data and do not prioritize solely by account value.
- **Evidence:** [Sentry](https://docs.sentry.io/api/events/list-an-organizations-issues/) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Bug impact priced in pipeline.
Tools: Work only with Sentry, HubSpot, Zendesk, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Connect this Sentry issue to affected customer accounts, support severity, renewals, and open opportunities. Quantify commercial exposure while preserving non-revenue severity factors.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Restrict revenue data and do not prioritize solely by account value.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-009 · Sales-demo environment drift

Before a demo, compare the promised scenario with current preview deployment, feature flags, seeded data, user permissions, and last successful rehearsal.

- **Systems:** Google Calendar · HubSpot · Vercel · LaunchDarkly · browser
- **Reach:** api · browser
- **Access:** required
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Use demo accounts; do not alter production or customer data.
- **Evidence:** [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Vercel](https://vercel.com/docs/rest-api) · [LaunchDarkly](https://launchdarkly.com/docs/api)

```text
$play explore [
Outcome: Sales-demo environment drift.
Tools: Work only with Google Calendar, HubSpot, Vercel, LaunchDarkly, and browser. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Confirm the authorized account and least required scope before reading. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Before the next demo, compare the CRM promise and calendar agenda with the demo deployment, flags, seeded data, permissions, and last rehearsal. Use demo accounts only.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use demo accounts; do not alter production or customer data.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-010 · Contract clause to operating control

Extract an approved obligation, connect it to owners, system configuration, recurring evidence, and review dates, then reveal clauses that exist only in the signed document.

- **Systems:** Google Drive · Linear · Notion · Google Calendar · system APIs
- **Reach:** api · browser
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Use approved contracts and legal review; do not interpret ambiguous clauses autonomously.
- **Evidence:** [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Linear](https://linear.app/developers/graphql) · [Notion](https://developers.notion.com/reference/intro) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Contract clause to operating control.
Tools: Work only with Google Drive, Linear, Notion, Google Calendar, and system APIs. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For an approved contract, connect each selected obligation to an owner, live system control, recurring evidence, and review date. Flag clauses that exist only on paper and route ambiguity to legal review.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use approved contracts and legal review; do not interpret ambiguous clauses autonomously.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-011 · Deletion request proof chain

Trace a verified deletion request through CRM, support, billing, files, and product records. Produce proof of completion and explicitly list systems where legal retention overrides deletion.

- **Systems:** Zendesk · HubSpot · Stripe · Google Drive · application database
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Never delete automatically; require identity verification and approved retention policy.
- **Evidence:** [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Stripe](https://docs.stripe.com/api/balance_transactions) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3)

```text
$play explore [
Outcome: Deletion request proof chain.
Tools: Work only with Zendesk, HubSpot, Stripe, Google Drive, and application database. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Trace a verified data-deletion request across support, CRM, billing, Drive, and product records. Produce a reviewable proof chain and list approved retention exceptions without deleting anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never delete automatically; require identity verification and approved retention policy.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-012 · Operational drift after contract redline

Compare the signed revision with earlier drafts and find operational controls, pricing rules, data routes, or service terms that still implement superseded language.

- **Systems:** Google Drive revisions · GitHub · LaunchDarkly · Stripe · Linear
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Legal interpretation requires counsel; produce changed clauses and implementation evidence.
- **Evidence:** [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Git](https://git-scm.com/docs) · [LaunchDarkly](https://launchdarkly.com/docs/api) · [Stripe](https://docs.stripe.com/api/balance_transactions) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Operational drift after contract redline.
Tools: Work only with Google Drive revisions, GitHub, LaunchDarkly, Stripe, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Diff the signed contract against prior revisions and locate code, flags, billing, or work items that still implement superseded language. Produce evidence for legal and operational review.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Legal interpretation requires counsel; produce changed clauses and implementation evidence.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-013 · Scorecard written after the decision

Compare interview end times, scorecard submission times, debrief meetings, and stage changes to find assessments written after group influence or hiring decisions.

- **Systems:** Greenhouse · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Audit process timing, not candidate merit or interviewer intent.
- **Evidence:** [Greenhouse Harvest](https://docs.greenhouse.io/harvest.html) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Scorecard written after the decision.
Tools: Work only with Greenhouse and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare interview end, scorecard submission, debrief, and stage-change times. Find assessments written after group influence or decisions, and report process evidence without judging candidates.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Audit process timing, not candidate merit or interviewer intent.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-014 · Interview load collides with on-call

Find interview panels assigned during incident rotations, known release windows, or concentrated operational load, then propose evidence-backed rescheduling options.

- **Systems:** Greenhouse · Google Calendar · PagerDuty · GitHub Deployments
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Propose options; do not reschedule interviews automatically.
- **Evidence:** [Greenhouse Harvest](https://docs.greenhouse.io/harvest.html) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [PagerDuty](https://github.com/PagerDuty/api-schema) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28)

```text
$play explore [
Outcome: Interview load collides with on-call.
Tools: Work only with Greenhouse, Google Calendar, PagerDuty, and GitHub Deployments. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find interview panels that collide with on-call rotations, release windows, or incident load. Propose alternatives that preserve candidate speed without editing calendars.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Propose options; do not reschedule interviews automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-015 · Offer promise versus day-one reality

Compare approved offer details and recruiting notes with HR title, manager, location, equipment, and access prepared for day one. Find promise gaps before the worker starts.

- **Systems:** Greenhouse · Rippling · Okta · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Restrict compensation and candidate data; do not change offers or employment records.
- **Evidence:** [Greenhouse Harvest](https://docs.greenhouse.io/harvest.html) · [Rippling](https://developer.rippling.com/documentation/rest-api) · [Okta](https://developer.okta.com/docs/api/) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Offer promise versus day-one reality.
Tools: Work only with Greenhouse, Rippling, Okta, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Before start date, compare the approved offer and recruiting commitments with Rippling title, manager, location, Okta access, and onboarding schedule. Flag promise gaps privately.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Restrict compensation and candidate data; do not change offers or employment records.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-016 · Role changed, work pattern did not

After a transfer or promotion, compare the new responsibility with actual application use, repository activity, meetings, and unresolved work. Find duties that never moved with the org chart.

- **Systems:** Rippling · Okta System Log · Git · Google Calendar · Linear
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Use for workload and access review, not employee performance scoring.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [Okta System Log](https://developer.okta.com/docs/reference/system-log-query/) · [Git](https://git-scm.com/docs) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Role changed, work pattern did not.
Tools: Work only with Rippling, Okta System Log, Git, Google Calendar, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. After selected role changes, compare intended responsibility with application use, repository activity, meetings, and unresolved work. Find duties that never moved without scoring employee performance.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use for workload and access review, not employee performance scoring.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-017 · Leave creates an ownership hole

Before planned leave, map the person's on-call shifts, CODEOWNERS paths, approvals, customer commitments, and recurring meetings to concrete temporary owners.

- **Systems:** Rippling · PagerDuty · GitHub · HubSpot · Google Calendar
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Reveal only work-relevant leave timing to authorized planners.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [PagerDuty](https://github.com/PagerDuty/api-schema) · [Git](https://git-scm.com/docs) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Leave creates an ownership hole.
Tools: Work only with Rippling, PagerDuty, GitHub, HubSpot, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Before planned leave, map on-call shifts, code ownership, approvals, customer commitments, and recurring meetings to temporary owners. Limit leave details to authorized planning.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Reveal only work-relevant leave timing to authorized planners.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-018 · New manager inherits invisible commitments

When management changes, assemble the team's unresolved decisions, promised dates, recurring approvals, customer obligations, and operational rotations into a handoff ledger.

- **Systems:** Rippling · Linear · Google Calendar · Gmail · PagerDuty
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Use authorized work communication; exclude private personal mail.
- **Evidence:** [Rippling](https://developer.rippling.com/documentation/rest-api) · [Linear](https://linear.app/developers/graphql) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [PagerDuty](https://github.com/PagerDuty/api-schema)

```text
$play explore [
Outcome: New manager inherits invisible commitments.
Tools: Work only with Rippling, Linear, Google Calendar, Gmail, and PagerDuty. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For a manager transition, assemble unresolved decisions, promised dates, recurring approvals, customer obligations, and on-call rotations into a private handoff ledger.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use authorized work communication; exclude private personal mail.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-019 · Decision made, record missing

Find meetings and Slack threads that contain a clear decision or exception but no durable record, owner, or follow-up in the designated system of record.

- **Systems:** Slack · Google Calendar · Notion · Linear
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Use only authorized channels; draft records for confirmation rather than declaring decisions.
- **Evidence:** [Slack](https://api.slack.com/web) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Notion](https://developers.notion.com/reference/intro) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Decision made, record missing.
Tools: Work only with Slack, Google Calendar, Notion, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find clear decisions or exceptions in authorized meetings and Slack threads that lack a durable record, owner, or follow-up. Draft confirmation packets for the designated system of record.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use only authorized channels; draft records for confirmation rather than declaring decisions.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-020 · Meeting without durable output

For recurring meetings, compare agendas and attendance with decisions, tasks, document changes, and issue movement. Find expensive rituals that produce no inspectable output.

- **Systems:** Google Calendar · Google Drive · Google Tasks · Linear
- **Reach:** api
- **Access:** required
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Do not cancel meetings; provide evidence and exceptions.
- **Evidence:** [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Google Tasks](https://developers.google.com/workspace/tasks/reference/rest) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Meeting without durable output.
Tools: Work only with Google Calendar, Google Drive, Google Tasks, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. For recurring meetings, connect agendas and attendance to decisions, tasks, document revisions, and issue movement. Find meetings with no durable output and preserve known exceptions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not cancel meetings; provide evidence and exceptions.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-021 · Customer escalation arrived through the wrong door

Find urgent customer issues first raised in sales or executive channels instead of support, then reconstruct why normal routing failed and which evidence was lost.

- **Systems:** Gmail · Slack · HubSpot · Zendesk
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Limit access to authorized customer channels and redact executive correspondence.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Slack](https://api.slack.com/web) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/)

```text
$play explore [
Outcome: Customer escalation arrived through the wrong door.
Tools: Work only with Gmail, Slack, HubSpot, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find urgent customer issues first raised through authorized sales or executive channels rather than support. Reconstruct routing failure and lost evidence without exposing private correspondence.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Limit access to authorized customer channels and redact executive correspondence.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-022 · One-customer configuration tax

For customer-specific flags, branches, scripts, and support procedures, calculate the maintenance surface and identify custom behavior with no current commercial or contractual owner.

- **Systems:** LaunchDarkly · GitHub · Zendesk · HubSpot · Stripe
- **Reach:** api · shell
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Do not remove customer behavior; route contractual uncertainty for review.
- **Evidence:** [LaunchDarkly](https://launchdarkly.com/docs/api) · [Git](https://git-scm.com/docs) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Stripe](https://docs.stripe.com/api/balance_transactions)

```text
$play explore [
Outcome: One-customer configuration tax.
Tools: Work only with LaunchDarkly, GitHub, Zendesk, HubSpot, and Stripe. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Inventory customer-specific flags, code, scripts, and support procedures. Quantify maintenance surface and identify customization with no current commercial or contractual owner.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Keep currency, amount units, accounting period, and transaction identifiers attached to every financial value.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not remove customer behavior; route contractual uncertainty for review.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-023 · Sales exception survived the deal

Find temporary pricing, permission, or product exceptions created to close a deal that remain active after the promised end, renewal, or customer change.

- **Systems:** HubSpot · Stripe · LaunchDarkly · Okta · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Review only; do not revoke access, pricing, or features automatically.
- **Evidence:** [HubSpot CRM](https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide) · [Stripe](https://docs.stripe.com/api/balance_transactions) · [LaunchDarkly](https://launchdarkly.com/docs/api) · [Okta](https://developer.okta.com/docs/api/) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Sales exception survived the deal.
Tools: Work only with HubSpot, Stripe, LaunchDarkly, Okta, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find temporary sales exceptions in pricing, permissions, or features that survived their promised end, renewal, or account change. Resolve owner and evidence without changing customer state.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Review only; do not revoke access, pricing, or features automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-024 · Customer-success claim provenance

For status updates sent to a customer, prove each claimed fix, date, metric, and next step against deploy, issue, telemetry, and calendar evidence.

- **Systems:** Gmail · Zendesk · GitHub Deployments · Datadog · Linear
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 5 / 5
- **Safety boundary:** Draft corrections for account-owner approval; never send automatically.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [GitHub Deployments](https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28) · [Datadog](https://docs.datadoghq.com/api/latest/using-the-api/) · [Linear](https://linear.app/developers/graphql)

```text
$play explore [
Outcome: Customer-success claim provenance.
Tools: Work only with Gmail, Zendesk, GitHub Deployments, Datadog, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Verify each fix, date, metric, and next step in selected customer updates against deploy, issue, telemetry, and calendar evidence. Draft discrepancies for owner review without sending mail.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Draft corrections for account-owner approval; never send automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PEOPLE-025 · Vendor roadmap promise aging

Track promises made by a critical vendor across email, public changelogs, support tickets, and internal plans. Detect architecture or launch commitments still waiting on an unshipped dependency.

- **Systems:** Gmail · vendor changelog · Zendesk · Linear · Google Calendar
- **Reach:** api · browser
- **Access:** mixed
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Separate vendor statements from guarantees and preserve source dates.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Zendesk](https://developer.zendesk.com/api-reference/ticketing/introduction/) · [Linear](https://linear.app/developers/graphql) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Vendor roadmap promise aging.
Tools: Work only with Gmail, vendor changelog, Zendesk, Linear, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Track critical vendor promises across authorized email, public changelogs, support tickets, and internal plans. Flag aged dependencies blocking architecture or launch commitments with dated evidence.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Separate vendor statements from guarantees and preserve source dates.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

## Public intelligence and personal operations

### PUBLIC-001 · Package-abandonment early signal

Combine release cadence, maintainer changes, issue response, dependency freshness, and bus factor to identify a public package becoming operationally unsafe before it is officially abandoned.

- **Systems:** npm public registry · GitHub public repositories
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Treat signals as risk indicators, not claims about maintainer intent.
- **Evidence:** [npm](https://docs.npmjs.com/cli/v11/commands/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Package-abandonment early signal.
Tools: Work only with npm public registry and GitHub public repositories. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Assess whether selected public packages show early abandonment risk using releases, maintainer changes, issue response, dependency freshness, and bus factor. Preserve uncertainty and cite public evidence.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Treat signals as risk indicators, not claims about maintainer intent.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-002 · Maintainer-transfer blast radius

Detect package ownership or publishing changes, then map the transferred package into local lockfiles, public dependent repositories, and recent releases. Surface trust changes hidden behind an unchanged package name.

- **Systems:** npm public registry · GitHub public repositories · local lockfiles
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Do not allege compromise; report verifiable ownership and release changes.
- **Evidence:** [npm](https://docs.npmjs.com/cli/v11/commands/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Maintainer-transfer blast radius.
Tools: Work only with npm public registry, GitHub public repositories, and local lockfiles. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Detect recent maintainer or publisher changes for dependencies, then map affected packages into local lockfiles and public dependents. Report trust changes without alleging compromise.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not allege compromise; report verifiable ownership and release changes.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-003 · Silent breaking-release detector

Compare package behavior, exported types, command help, and repository diff across versions with the published release notes. Find breaking changes that the changelog did not disclose.

- **Systems:** npm public registry · GitHub public repositories · local test runner
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Run in a sandbox and distinguish observed incompatibility from semantic-version intent.
- **Evidence:** [npm](https://docs.npmjs.com/cli/v11/commands/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Silent breaking-release detector.
Tools: Work only with npm public registry, GitHub public repositories, and local test runner. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare two public package versions by exports, types, CLI help, repository diff, and sandbox tests. Identify observed breaking behavior absent from release notes and preserve uncertainty.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Run in a sandbox and distinguish observed incompatibility from semantic-version intent.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-004 · Public API contract drift

Snapshot a public API's machine-readable schema and representative responses, then detect removed fields, enum growth, pagination changes, and documentation lag before downstream code fails.

- **Systems:** public OpenAPI or discovery document · browser · Git
- **Reach:** api · browser · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Use small read-only requests and respect published limits.
- **Evidence:** [World Bank Indicators](https://datahelpdesk.worldbank.org/knowledgebase/articles/889392) · [OSV](https://google.github.io/osv.dev/api/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Public API contract drift.
Tools: Work only with public OpenAPI or discovery document, browser, and Git. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Snapshot this public API's schema, documentation, and small representative responses. Detect field, enum, pagination, and documentation drift, then produce a downstream impact note.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use small read-only requests and respect published limits.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-005 · Research correction reaches product claim

Follow corrections, retractions, and post-publication updates from a cited paper into downstream claims. Find company docs, model cards, and repository comments that still rely on the original result.

- **Systems:** Crossref · PubMed · OpenAlex · GitHub public repositories
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 5 / 5
- **Safety boundary:** Do not infer scientific invalidity beyond the published correction or retraction.
- **Evidence:** [Crossref](https://www.crossref.org/documentation/retrieve-metadata/rest-api/) · [NCBI PubMed](https://www.ncbi.nlm.nih.gov/home/develop/api/) · [OpenAlex](https://help.openalex.org/api/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Research correction reaches product claim.
Tools: Work only with Crossref, PubMed, OpenAlex, and GitHub public repositories. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Track corrections, retractions, and post-publication updates for cited research into public product docs, claims, model cards, and repository comments. State only what the sources support.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not infer scientific invalidity beyond the published correction or retraction.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-006 · Prior-art watch for a live implementation

Monitor new papers around a technical claim, then compare methods and constraints with a public repository's current implementation. Highlight newly published approaches that invalidate an assumption or simplify the design.

- **Systems:** arXiv · OpenAlex · GitHub public repositories
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Present technical comparison, not patentability or legal advice.
- **Evidence:** [arXiv](https://github.com/arXiv/arxiv-docs/blob/develop/source/help/api/user-manual.md) · [OpenAlex](https://help.openalex.org/api/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Prior-art watch for a live implementation.
Tools: Work only with arXiv, OpenAlex, and GitHub public repositories. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Monitor new public research around this implementation's core claim. Compare methods and constraints with the repository and flag assumptions newly challenged or simplified. Do not assess patentability.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Present technical comparison, not patentability or legal advice.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-007 · Reproducibility input pack

Given a paper and public code, resolve exact versions, datasets, licenses, citations, commands, and missing inputs into an executable evidence pack. Preserve every unresolved dependency.

- **Systems:** Crossref · PubMed or arXiv · GitHub public repositories · local shell
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 5 / 5
- **Safety boundary:** Do not claim reproduction until outputs and acceptance criteria match.
- **Evidence:** [Crossref](https://www.crossref.org/documentation/retrieve-metadata/rest-api/) · [NCBI PubMed](https://www.ncbi.nlm.nih.gov/home/develop/api/) · [arXiv](https://github.com/arXiv/arxiv-docs/blob/develop/source/help/api/user-manual.md) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Reproducibility input pack.
Tools: Work only with Crossref, PubMed or arXiv, GitHub public repositories, and local shell. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. For this paper and public code, resolve exact versions, datasets, licenses, citations, commands, and missing inputs into a reproducibility pack. Do not claim success unless outputs match stated criteria.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not claim reproduction until outputs and acceptance criteria match.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-008 · Filing-to-homepage contradiction

Compare a company's latest SEC disclosures with current homepage, product, hiring, and developer claims. Surface dated contradictions in markets, dependencies, risk, and operating scale.

- **Systems:** SEC EDGAR · public website · GitHub public repositories
- **Reach:** api · browser · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Quote and date sources; do not infer fraud or investment merit.
- **Evidence:** [SEC EDGAR](https://www.sec.gov/file/api-overview) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Filing-to-homepage contradiction.
Tools: Work only with SEC EDGAR, public website, and GitHub public repositories. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare the latest SEC disclosures with current public website and repository claims. Surface dated contradictions in markets, dependencies, risk, or operating scale without making investment or fraud conclusions.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Quote and date sources; do not infer fraud or investment merit.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-009 · Known-exploit response lag

For open-source products in CISA KEV, measure the path from public exploitation status to maintainer acknowledgment, patch, package release, downstream adoption, and documentation update.

- **Systems:** CISA KEV · OSV · npm public registry · GitHub public repositories
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Use public timelines and avoid exploit instructions.
- **Evidence:** [CISA Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) · [OSV](https://google.github.io/osv.dev/api/) · [npm](https://docs.npmjs.com/cli/v11/commands/) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Known-exploit response lag.
Tools: Work only with CISA KEV, OSV, npm public registry, and GitHub public repositories. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Measure response lag for selected CISA KEV entries from known exploitation to maintainer acknowledgment, patch, package release, downstream adoption, and docs update. Do not include exploit steps.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use public timelines and avoid exploit instructions.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-010 · Typosquat neighborhood watch

Generate visually and keyboard-similar names around dependencies, query the public registry, and compare publication age, maintainers, contents, and install behavior. Focus on names adjacent to actual lockfiles.

- **Systems:** npm public registry · local lockfiles · sandbox shell
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Never install suspicious packages outside an isolated sandbox.
- **Evidence:** [npm](https://docs.npmjs.com/cli/v11/commands/)

```text
$play explore [
Outcome: Typosquat neighborhood watch.
Tools: Work only with npm public registry, local lockfiles, and sandbox shell. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Check the typo-neighborhood around packages in this lockfile. Compare public package age, maintainers, contents, and install scripts, using metadata first and an isolated sandbox only when necessary.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never install suspicious packages outside an isolated sandbox.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-011 · Dataset-definition drift

Track changes in an indicator's definition, source organization, frequency, country coverage, and footnotes, then locate analyses and charts that still compare incompatible periods.

- **Systems:** World Bank Indicators · local notebooks · Git
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Preserve source metadata and do not silently backfill incompatible series.
- **Evidence:** [World Bank Indicators](https://datahelpdesk.worldbank.org/knowledgebase/articles/889392) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Dataset-definition drift.
Tools: Work only with World Bank Indicators, local notebooks, and Git. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Track definition, source, frequency, coverage, and footnote changes for these public indicators. Find notebooks and charts comparing incompatible periods and propose explicit repairs.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Preserve source metadata and do not silently backfill incompatible series.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-012 · Research funding concentration risk

Map a technical field's papers, institutions, funders, citations, and shared datasets to reveal when apparently independent evidence rests on one funding or data source.

- **Systems:** Crossref · OpenAlex
- **Reach:** api
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Concentration is context, not evidence of research misconduct.
- **Evidence:** [Crossref](https://www.crossref.org/documentation/retrieve-metadata/rest-api/) · [OpenAlex](https://help.openalex.org/api/)

```text
$play explore [
Outcome: Research funding concentration risk.
Tools: Work only with Crossref and OpenAlex. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Map papers, institutions, funders, citations, and shared datasets for this technical claim. Reveal concentration and dependencies without implying research misconduct.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Record the expected population and returned count for each source. Explain exclusions before calling the set complete. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Concentration is context, not evidence of research misconduct.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-013 · Climate shock meets supplier geography

Join public weather alerts and forecasts with a declared supplier or facility list, then rank operational exposure by lead time, transport dependency, and available alternatives.

- **Systems:** National Weather Service · public supplier-location file · World Bank Indicators
- **Reach:** api · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 4 / 5
- **Safety boundary:** Advisory only; do not claim precise loss or safety outcomes.
- **Evidence:** [US National Weather Service](https://www.weather.gov/documentation/services-web-API) · [World Bank Indicators](https://datahelpdesk.worldbank.org/knowledgebase/articles/889392)

```text
$play explore [
Outcome: Climate shock meets supplier geography.
Tools: Work only with National Weather Service, public supplier-location file, and World Bank Indicators. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Join current NWS alerts and forecasts with this public supplier or facility list. Rank operational exposure by lead time, transport dependency, and alternatives, stating geographic uncertainty.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Advisory only; do not claim precise loss or safety outcomes.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-014 · Earthquake facility first-look

Turn a new earthquake event into a radius- and intensity-aware list of public facilities, routes, and dependencies. Preserve uncertainty in early event data while identifying items that warrant human checks.

- **Systems:** USGS Earthquake Catalog · public facility file · public maps browser
- **Reach:** api · browser · shell
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Not an emergency-service substitute; never infer structural safety remotely.
- **Evidence:** [USGS Earthquake Catalog](https://earthquake.usgs.gov/fdsnws/event/1/swagger.json)

```text
$play explore [
Outcome: Earthquake facility first-look.
Tools: Work only with USGS Earthquake Catalog, public facility file, and public maps browser. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. For the latest relevant USGS event, identify listed facilities, routes, and dependencies that warrant human checks using conservative distance and magnitude rules. Do not infer structural safety.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Not an emergency-service substitute; never infer structural safety remotely.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PUBLIC-015 · Community hazard action brief

Combine current weather alerts, earthquake events, and public local-service pages into a concise, source-linked action brief with only official instructions and expiry times.

- **Systems:** National Weather Service · USGS · public local-government browser pages
- **Reach:** api · browser
- **Access:** none
- **Best home:** public
- **Complexity:** 3 / 5
- **Safety boundary:** Quote official instructions accurately and defer to emergency authorities.
- **Evidence:** [US National Weather Service](https://www.weather.gov/documentation/services-web-API) · [USGS Earthquake Catalog](https://earthquake.usgs.gov/fdsnws/event/1/swagger.json)

```text
$play explore [
Outcome: Community hazard action brief.
Tools: Work only with National Weather Service, USGS, and public local-government browser pages. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Use public endpoints or local fixtures, respect published limits, and record the source URL or fixture digest. Use public or sanitized inputs so the resulting Play can be published without exposing private context.
Method: Define the target objects, accounts, environment, and time window before the first call. Create a source-linked community hazard brief from current NWS alerts, USGS events, and official local-service pages. Include issue and expiry times and add no unsupported safety advice.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Quote official instructions accurately and defer to emergency authorities.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-001 · Itinerary shock absorber

Before and during travel, join itinerary email, calendar, destination weather, connection time, and meeting commitments. Prepare ranked contingencies before a disruption becomes a missed obligation.

- **Systems:** Gmail · Google Calendar · National Weather Service · Google Tasks
- **Reach:** api
- **Access:** mixed
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Draft contingency options; never rebook or cancel automatically.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [US National Weather Service](https://www.weather.gov/documentation/services-web-API) · [Google Tasks](https://developers.google.com/workspace/tasks/reference/rest)

```text
$play explore [
Outcome: Itinerary shock absorber.
Tools: Work only with Gmail, Google Calendar, National Weather Service, and Google Tasks. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Join my authorized itinerary email and calendar with current destination weather and commitments. Prepare ranked contingency options for likely disruptions without booking or canceling anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Draft contingency options; never rebook or cancel automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-002 · Commitment with no next action

Find promises made in authorized email and Slack that contain a deliverable or date but never became a task or calendar block. Preserve commitments that were later withdrawn.

- **Systems:** Gmail · Slack · Google Tasks · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Draft tasks for confirmation; do not read unrelated private channels or create tasks automatically.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Slack](https://api.slack.com/web) · [Google Tasks](https://developers.google.com/workspace/tasks/reference/rest) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Commitment with no next action.
Tools: Work only with Gmail, Slack, Google Tasks, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Find commitments I made in authorized email and Slack that specify a deliverable or date but have no task or calendar block. Exclude withdrawn promises and draft next actions for review.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Draft tasks for confirmation; do not read unrelated private channels or create tasks automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-003 · Decision decay after meetings

Compare meeting notes and follow-up mail with later tasks, document revisions, and calendar events. Surface decisions that lost an owner, date, or exact wording as they propagated.

- **Systems:** Google Calendar · Google Drive · Gmail · Google Tasks
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Draft reconciliations for participant confirmation.
- **Evidence:** [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Google Tasks](https://developers.google.com/workspace/tasks/reference/rest)

```text
$play explore [
Outcome: Decision decay after meetings.
Tools: Work only with Google Calendar, Google Drive, Gmail, and Google Tasks. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Trace selected meeting decisions into follow-up email, tasks, document revisions, and later calendar events. Surface where owner, date, or wording decayed and draft a confirmation note.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Draft reconciliations for participant confirmation.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-004 · Promise-capacity collision

Compare dated commitments made in messages with actual calendar capacity, travel, focus time, and existing due tasks. Detect impossible weeks before deadlines arrive.

- **Systems:** Gmail · Slack · Google Calendar · Google Tasks
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Propose tradeoffs; never decline commitments or move meetings automatically.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Slack](https://api.slack.com/web) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Google Tasks](https://developers.google.com/workspace/tasks/reference/rest)

```text
$play explore [
Outcome: Promise-capacity collision.
Tools: Work only with Gmail, Slack, Google Calendar, and Google Tasks. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare my dated commitments in authorized messages with calendar capacity, travel, focus time, and due tasks. Find impossible weeks and propose tradeoffs without changing anything.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Propose tradeoffs; never decline commitments or move meetings automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-005 · Quiet-hours reality check

Measure when work communication and meetings actually cross declared focus, leave, and quiet hours. Separate self-scheduled work from pressure created by others and recurring system noise.

- **Systems:** Slack · Gmail · Google Calendar
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 3 / 5
- **Safety boundary:** Use personal analysis only; do not score coworkers or infer wellbeing.
- **Evidence:** [Slack](https://api.slack.com/web) · [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Quiet-hours reality check.
Tools: Work only with Slack, Gmail, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare my authorized work messages and meetings with declared focus, leave, and quiet hours. Separate self-scheduled activity, outside pressure, and system noise without scoring people.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Choose stable identifiers for every handoff. Record the mapping rule whenever two systems use different identifiers.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use personal analysis only; do not score coworkers or infer wellbeing.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-006 · Document-expiry readiness

Locate personal document metadata and renewal instructions, then work backward from expiry through appointment availability, processing time, travel, and dependent bookings.

- **Systems:** Google Drive · Gmail · Google Calendar · browser
- **Reach:** api · browser
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Never expose document numbers or submit government forms automatically.
- **Evidence:** [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Document-expiry readiness.
Tools: Work only with Google Drive, Gmail, Google Calendar, and browser. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. For selected personal documents, work backward from expiry through official renewal steps, appointment timing, travel, and dependent bookings. Keep document numbers private and submit nothing.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Show the rule behind every rank or threshold. Test at least one counterexample and keep uncertainty visible.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Never expose document numbers or submit government forms automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-007 · Family logistics handoff

Turn the next seven days of shared events, school or care messages, travel time, and tasks into explicit handoffs with owner, cutoff, and required item. Reveal assumptions where two people expect the other to act.

- **Systems:** Gmail · Google Calendar · Google Tasks
- **Reach:** api
- **Access:** required
- **Best home:** private
- **Complexity:** 3 / 5
- **Safety boundary:** Use only consented shared data and draft handoffs for confirmation.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Google Tasks](https://developers.google.com/workspace/tasks/reference/rest)

```text
$play explore [
Outcome: Family logistics handoff.
Tools: Work only with Gmail, Google Calendar, and Google Tasks. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Turn the next seven days of consented family messages, shared calendar events, travel time, and tasks into explicit handoffs. Flag conflicting assumptions and create no tasks without review.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone. Resolve locations to stable coordinates, regions, hostnames, or resource identifiers before comparing them.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Use only consented shared data and draft handoffs for confirmation.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-008 · Volunteer coverage before the gap

Compare upcoming volunteer shifts with confirmations, calendar conflicts, required skills, and prior no-shows. Identify coverage gaps early and draft the smallest outreach set.

- **Systems:** Google Calendar · Gmail or Slack · Google Drive roster
- **Reach:** api
- **Access:** required
- **Best home:** either
- **Complexity:** 3 / 5
- **Safety boundary:** Draft outreach only; protect volunteer contact data.
- **Evidence:** [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events) · [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Slack](https://api.slack.com/web) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3)

```text
$play explore [
Outcome: Volunteer coverage before the gap.
Tools: Work only with Google Calendar, Gmail or Slack, and Google Drive roster. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.
Access: Confirm the authorized account and least required scope before reading. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare upcoming volunteer shifts with confirmations, calendar conflicts, required skills, and prior attendance. Identify coverage gaps and draft the smallest outreach set without sending messages.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Join people and accounts with provider identifiers or verified addresses. Never join on a display name alone.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Prove absence by exhausting pagination, the declared time window, and documented exclusions. A missing result from one call is not proof. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Confirm each identity match with a stable provider identifier or a second attribute. Keep ambiguous matches unresolved. Record the expected population and returned count for each source. Explain exclusions before calling the set complete.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Draft outreach only; protect volunteer contact data.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-009 · Job-application narrative consistency

Across applications, resumes, cover letters, interviews, and public profile, find factual dates, titles, metrics, and claims that drifted. Build a private source-of-truth record before the next interview.

- **Systems:** Gmail · Google Drive · Google Calendar · browser
- **Reach:** api · browser
- **Access:** required
- **Best home:** private
- **Complexity:** 4 / 5
- **Safety boundary:** Do not fabricate or optimize false claims; keep employment data private.
- **Evidence:** [Gmail](https://developers.google.com/workspace/gmail/api/reference/rest) · [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Google Calendar](https://developers.google.com/workspace/calendar/api/v3/reference/events)

```text
$play explore [
Outcome: Job-application narrative consistency.
Tools: Work only with Gmail, Google Drive, Google Calendar, and browser. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use the browser for state APIs cannot expose; record the URL, visible state, account context, and capture time.
Access: Confirm the authorized account and least required scope before reading. Keep the result private; redact sensitive fields from summaries but preserve their addresses in the authorized workspace.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare my authorized applications, resume versions, interview notes, and public profile for factual drift in dates, titles, metrics, and claims. Build a private source-of-truth record.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference. Validate with identifiers, hashes, and metadata. Never copy a secret or sensitive payload into the prompt or report. Trace each conclusion to the exact source field or artifact. Mark claims that depend on interpretation rather than recorded evidence. Verify claimed execution with timestamps, exit codes, artifacts, and resulting state. A named test without execution evidence does not count.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Do not fabricate or optimize false claims; keep employment data private.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```

### PERSONAL-010 · Learning plan that notices the field moved

Compare a learning syllabus and saved exercises with new package releases, current documentation, and recent research. Replace obsolete lessons with changes that affect the learner's actual projects.

- **Systems:** Google Drive · Google Tasks · npm public registry · arXiv · GitHub public repositories
- **Reach:** api · shell
- **Access:** mixed
- **Best home:** either
- **Complexity:** 4 / 5
- **Safety boundary:** Propose edits; do not delete notes or tasks automatically.
- **Evidence:** [Google Drive](https://developers.google.com/workspace/drive/api/reference/rest/v3) · [Google Tasks](https://developers.google.com/workspace/tasks/reference/rest) · [npm](https://docs.npmjs.com/cli/v11/commands/) · [arXiv](https://github.com/arXiv/arxiv-docs/blob/develop/source/help/api/user-manual.md) · [Git](https://git-scm.com/docs)

```text
$play explore [
Outcome: Learning plan that notices the field moved.
Tools: Work only with Google Drive, Google Tasks, npm public registry, arXiv, and GitHub public repositories. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses. Use read-only shell commands for local inspection or fixture tests; record directory, tool version, command, exit code, and artifact digest.
Access: Separate public checks from authenticated checks, then confirm the least required scope for each authenticated branch. Separate reusable public logic from account-specific evidence, and mark fields that must remain private.
Method: Define the target objects, accounts, environment, and time window before the first call. Compare my learning syllabus and exercises with current package releases, official docs, recent research, and my actual projects. Propose focused updates without deleting notes or tasks.
Connections: Store every result in the Rote context workspace. Pass response addresses to later steps; never paste raw payloads into the prompt. Before each call, name the source address and join key it consumes. Normalize times to UTC, retain the source time zone, and define the allowed clock skew before correlating events. Carry immutable versions, digests, commit hashes, or artifact identifiers across every software join.
Validation: Check every joined claim against its source address. Requery a representative sample from each system. Confirm source clocks, query bounds, and capture times. Reject events outside the declared correlation window. Compare the same object, version, environment, and time window. Mark unmatched scope before interpreting a difference.
Failure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.
Safety: Propose edits; do not delete notes or tasks automatically.
Complete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.
Return the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.
The second run must reproduce the join or name the changed condition.
]
```