{ "schema": "modiqo.play-ideas.v1", "version": "0.2.0", "researched_at": "2026-08-31", "summary": { "total": 150, "domains": 6, "auth": { "none": 25, "mixed": 30, "required": 95 }, "publication": { "public": 28, "private": 98, "either": 24 }, "modalities": { "api": 140, "proc": 86, "browser": 15 } }, "validation_model": { "status": "documented-capability", "meaning": "Every design is grounded in current first-party documentation for the named surfaces. Authenticated ideas still need a connected-account proof before publication.", "excluded_sources": [ "automation marketplaces", "template galleries", "affiliate listicles" ], "complexity": { "1": "one read-only surface", "2": "two surfaces or a simple local join", "3": "multi-step join with normalization", "4": "cross-system identity, time, or approval logic", "5": "high-consequence reconciliation, policy, or stateful verification" } }, "sources": { "github_deployments": { "system": "GitHub Deployments", "url": "https://docs.github.com/en/rest/deployments?apiVersion=2022-11-28", "supports": [ "deployments", "deployment statuses", "environments" ], "auth": "Required for private repositories; public data may be read without auth." }, "github_actions": { "system": "GitHub Actions", "url": "https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10", "supports": [ "workflow runs", "logs", "reruns", "cancellation" ], "auth": "Required for private repositories; public access varies by endpoint." }, "github_artifacts": { "system": "GitHub Actions artifacts", "url": "https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts", "supports": [ "test output", "logs", "screenshots", "artifact attestations" ], "auth": "Required for private repositories." }, "github_instructions": { "system": "GitHub Copilot instructions", "url": "https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions", "supports": [ "repository instructions", "path instructions", "AGENTS.md" ], "auth": "Repository files can be public or private." }, "gitlab_ci": { "system": "GitLab CI", "url": "https://docs.gitlab.com/api/pipelines/", "supports": [ "pipelines", "jobs", "child pipelines", "statuses" ], "auth": "Required for private projects; public project access varies." }, "datadog": { "system": "Datadog", "url": "https://docs.datadoghq.com/api/latest/using-the-api/", "supports": [ "metrics", "monitors", "events", "service data" ], "auth": "API and application keys required." }, "datadog_incidents": { "system": "Datadog Incidents", "url": "https://docs.datadoghq.com/api/latest/incidents/get-a-list-of-incidents/", "supports": [ "incidents", "relationships", "timestamps" ], "auth": "API and application keys required." }, "linear": { "system": "Linear", "url": "https://linear.app/developers/graphql", "supports": [ "issues", "projects", "teams", "relations" ], "auth": "OAuth or personal API key required." }, "linear_webhooks": { "system": "Linear webhooks", "url": "https://linear.app/developers/webhooks", "supports": [ "issue changes", "project changes", "delivery signatures" ], "auth": "Workspace authorization required." }, "aws_cost": { "system": "AWS Cost Explorer", "url": "https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html", "supports": [ "cost", "usage", "dimensions", "time windows" ], "auth": "AWS credentials and IAM permission required." }, "aws_orgs": { "system": "AWS Organizations", "url": "https://docs.aws.amazon.com/organizations/latest/APIReference/Welcome.html", "supports": [ "accounts", "organizational units", "policies", "central management" ], "auth": "AWS credentials and organization permissions required." }, "aws_cloudtrail": { "system": "AWS CloudTrail", "url": "https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html", "supports": [ "management events", "resource changes", "identities", "90-day lookup" ], "auth": "AWS credentials and CloudTrail permission required." }, "terraform": { "system": "Terraform CLI", "url": "https://developer.hashicorp.com/terraform/cli/commands", "supports": [ "plan", "state", "configuration", "providers" ], "auth": "Local CLI; connected providers may require credentials." }, "cloudflare_dns": { "system": "Cloudflare DNS", "url": "https://developers.cloudflare.com/api/resources/dns/subresources/records/", "supports": [ "DNS records", "imports", "exports", "batch changes" ], "auth": "API token required for managed zones." }, "vercel": { "system": "Vercel", "url": "https://vercel.com/docs/rest-api", "supports": [ "deployments", "projects", "domains", "environment data" ], "auth": "Access token required for account data." }, "sentry_issues": { "system": "Sentry", "url": "https://docs.sentry.io/api/events/list-an-organizations-issues/", "supports": [ "issues", "events", "projects", "release associations" ], "auth": "Auth token required." }, "sentry_releases": { "system": "Sentry Releases", "url": "https://docs.sentry.io/api/releases/list-an-organizations-releases/", "supports": [ "releases", "deploys", "commits", "health" ], "auth": "Auth token required." }, "grafana": { "system": "Grafana", "url": "https://grafana.com/docs/grafana/latest/developer-resources/api-reference/http-api/", "supports": [ "dashboards", "data sources", "folders", "annotations" ], "auth": "Service account token or session required." }, "pagerduty": { "system": "PagerDuty", "url": "https://github.com/PagerDuty/api-schema", "supports": [ "incidents", "on-call schedules", "services", "audit records" ], "auth": "REST API key required." }, "launchdarkly": { "system": "LaunchDarkly", "url": "https://launchdarkly.com/docs/api", "supports": [ "feature flags", "environments", "usage", "members" ], "auth": "Personal or service access token required." }, "launchdarkly_audit": { "system": "LaunchDarkly audit log", "url": "https://launchdarkly.com/docs/api/audit-log", "supports": [ "change history", "timestamps", "resource history" ], "auth": "Access token required." }, "notion": { "system": "Notion", "url": "https://developers.notion.com/reference/intro", "supports": [ "pages", "data sources", "blocks", "search" ], "auth": "Integration token or OAuth required." }, "slack": { "system": "Slack", "url": "https://api.slack.com/web", "supports": [ "conversations", "messages", "users", "reactions" ], "auth": "OAuth token with explicit scopes required." }, "zendesk": { "system": "Zendesk", "url": "https://developer.zendesk.com/api-reference/ticketing/introduction/", "supports": [ "tickets", "users", "organizations", "workflows" ], "auth": "OAuth or API credentials required." }, "zendesk_audits": { "system": "Zendesk Ticket Audits", "url": "https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_audits/", "supports": [ "ticket history", "field changes", "comments", "notifications" ], "auth": "Global read scope required." }, "hubspot": { "system": "HubSpot CRM", "url": "https://developers.hubspot.com/docs/api-reference/latest/crm/objects/deals/guide", "supports": [ "deals", "contacts", "companies", "associations" ], "auth": "OAuth or private app token required." }, "salesforce": { "system": "Salesforce", "url": "https://developer.salesforce.com/docs/platform/salesforce-cli-reference/guide/cli_reference_api_request_rest.html", "supports": [ "REST resources", "queries", "records", "metadata" ], "auth": "Salesforce org authorization required." }, "stripe": { "system": "Stripe", "url": "https://docs.stripe.com/api/balance_transactions", "supports": [ "balance transactions", "fees", "payout reconciliation", "source objects" ], "auth": "Secret or restricted API key required." }, "stripe_invoices": { "system": "Stripe Invoices", "url": "https://docs.stripe.com/api/invoices", "supports": [ "invoices", "payments", "credits", "invoice events" ], "auth": "Secret or restricted API key required." }, "stripe_subscriptions": { "system": "Stripe Subscriptions", "url": "https://docs.stripe.com/api/subscriptions", "supports": [ "subscriptions", "status", "items", "billing state" ], "auth": "Secret or restricted API key required." }, "stripe_disputes": { "system": "Stripe Disputes", "url": "https://docs.stripe.com/disputes/api", "supports": [ "disputes", "deadlines", "structured evidence", "files" ], "auth": "Secret or restricted API key required." }, "stripe_webhooks": { "system": "Stripe Webhooks", "url": "https://docs.stripe.com/webhooks", "supports": [ "event delivery", "signatures", "retries", "manual resend" ], "auth": "Endpoint secrets and account authorization required." }, "mercury": { "system": "Mercury", "url": "https://docs.mercury.com/docs/welcome", "supports": [ "accounts", "transactions", "payments", "recipients" ], "auth": "API token and eligible account required." }, "rippling": { "system": "Rippling", "url": "https://developer.rippling.com/documentation/rest-api", "supports": [ "workers", "employment data", "teams", "company data" ], "auth": "OAuth or company-issued token required." }, "razorpay_disputes": { "system": "Razorpay Disputes", "url": "https://razorpay.com/docs/api/disputes/", "supports": [ "disputes", "evidence", "status", "deadlines" ], "auth": "API credentials required." }, "razorpay_settlements": { "system": "Razorpay Settlements", "url": "https://razorpay.com/docs/api/settlements/", "supports": [ "settlements", "UTRs", "status", "amounts" ], "auth": "API credentials required." }, "xero": { "system": "Xero Accounting", "url": "https://developer.xero.com/documentation/api/accounting/overview", "supports": [ "invoices", "payments", "credit notes", "accounts" ], "auth": "OAuth 2.0 required." }, "xero_reports": { "system": "Xero Reports", "url": "https://developer.xero.com/documentation/api/accounting/reports", "supports": [ "profit and loss", "balance sheet", "aged receivables", "report periods" ], "auth": "OAuth 2.0 required." }, "plaid": { "system": "Plaid", "url": "https://plaid.com/docs/api/", "supports": [ "accounts", "transactions", "identity", "liabilities" ], "auth": "Plaid application credentials and user consent required." }, "shopify_orders": { "system": "Shopify", "url": "https://shopify.dev/docs/api/admin-graphql/latest/queries/orders", "supports": [ "orders", "payments", "returns", "customers" ], "auth": "Admin API access token required." }, "shopify_fulfillment": { "system": "Shopify Fulfillment", "url": "https://shopify.dev/docs/api/admin-graphql/latest/queries/Fulfillment", "supports": [ "fulfillments", "tracking", "status", "line items" ], "auth": "Admin API access token required." }, "okta": { "system": "Okta", "url": "https://developer.okta.com/docs/api/", "supports": [ "users", "groups", "applications", "policies" ], "auth": "OAuth service app or API token required." }, "okta_log": { "system": "Okta System Log", "url": "https://developer.okta.com/docs/reference/system-log-query/", "supports": [ "authentication events", "policy events", "actors", "targets" ], "auth": "OAuth or API token required." }, "google_admin": { "system": "Google Admin Directory", "url": "https://developers.google.com/workspace/admin/directory/reference/rest", "supports": [ "users", "groups", "roles", "devices" ], "auth": "OAuth with admin authorization required." }, "google_reports": { "system": "Google Admin Reports", "url": "https://developers.google.com/workspace/admin/reports/reference/rest", "supports": [ "audit activity", "usage", "login events", "admin events" ], "auth": "OAuth with admin authorization required." }, "onepassword": { "system": "1Password CLI", "url": "https://developer.1password.com/docs/cli/secrets-scripts", "supports": [ "secret references", "runtime injection", "item fields", "vault access" ], "auth": "Signed-in CLI or service account required." }, "greenhouse": { "system": "Greenhouse Harvest", "url": "https://docs.greenhouse.io/harvest.html", "supports": [ "candidates", "applications", "offers", "interviews" ], "auth": "Scoped Harvest API key required." }, "gmail": { "system": "Gmail", "url": "https://developers.google.com/workspace/gmail/api/reference/rest", "supports": [ "messages", "threads", "drafts", "labels" ], "auth": "OAuth with mailbox scopes required." }, "google_calendar": { "system": "Google Calendar", "url": "https://developers.google.com/workspace/calendar/api/v3/reference/events", "supports": [ "events", "attendees", "working location", "focus time" ], "auth": "OAuth required." }, "google_drive": { "system": "Google Drive", "url": "https://developers.google.com/workspace/drive/api/reference/rest/v3", "supports": [ "files", "permissions", "comments", "revisions" ], "auth": "OAuth or service account authorization required." }, "google_tasks": { "system": "Google Tasks", "url": "https://developers.google.com/workspace/tasks/reference/rest", "supports": [ "task lists", "tasks", "due dates", "completion" ], "auth": "OAuth required." }, "microsoft_graph_calendar": { "system": "Microsoft Graph Calendar", "url": "https://learn.microsoft.com/en-us/graph/api/resources/calendar-overview?view=graph-rest-1.0", "supports": [ "events", "calendars", "meeting times", "reminders" ], "auth": "Microsoft identity OAuth required." }, "osv": { "system": "OSV", "url": "https://google.github.io/osv.dev/api/", "supports": [ "vulnerability queries", "package versions", "commits", "batch lookup" ], "auth": "No authentication required." }, "cisa_kev": { "system": "CISA Known Exploited Vulnerabilities", "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog", "supports": [ "known exploitation", "due dates", "vendor and product", "remediation guidance" ], "auth": "No authentication required." }, "nws": { "system": "US National Weather Service", "url": "https://www.weather.gov/documentation/services-web-API", "supports": [ "alerts", "forecasts", "observations", "stations" ], "auth": "No API key; a descriptive User-Agent is required." }, "usgs": { "system": "USGS Earthquake Catalog", "url": "https://earthquake.usgs.gov/fdsnws/event/1/swagger.json", "supports": [ "earthquakes", "magnitude", "geography", "time windows" ], "auth": "No authentication required." }, "sec": { "system": "SEC EDGAR", "url": "https://www.sec.gov/file/api-overview", "supports": [ "submissions", "company facts", "filings", "XBRL data" ], "auth": "No API key; fair-access headers and limits apply." }, "world_bank": { "system": "World Bank Indicators", "url": "https://datahelpdesk.worldbank.org/knowledgebase/articles/889392", "supports": [ "time series", "country indicators", "metadata", "multiple indicators" ], "auth": "No authentication required." }, "crossref": { "system": "Crossref", "url": "https://www.crossref.org/documentation/retrieve-metadata/rest-api/", "supports": [ "DOIs", "funding", "licenses", "post-publication updates" ], "auth": "Public pool requires no authentication." }, "openalex": { "system": "OpenAlex", "url": "https://help.openalex.org/api/", "supports": [ "works", "authors", "institutions", "topics", "citations" ], "auth": "Public API; current plans may use a free key for higher limits." }, "pubmed": { "system": "NCBI PubMed", "url": "https://www.ncbi.nlm.nih.gov/home/develop/api/", "supports": [ "search", "links", "citations", "article retrieval" ], "auth": "Public access; API key recommended for higher request rates." }, "arxiv": { "system": "arXiv", "url": "https://github.com/arXiv/arxiv-docs/blob/develop/source/help/api/user-manual.md", "supports": [ "article search", "ID lookup", "metadata", "paging" ], "auth": "Public API subject to terms and rate limits." }, "npm": { "system": "npm", "url": "https://docs.npmjs.com/cli/v11/commands/", "supports": [ "package metadata", "dependency trees", "versions", "registry inspection" ], "auth": "Public packages require no auth; private packages require registry credentials." }, "git": { "system": "Git", "url": "https://git-scm.com/docs", "supports": [ "history", "blame", "diff", "worktrees" ], "auth": "Local repositories need no auth; remotes may require credentials." }, "mcp": { "system": "Model Context Protocol", "url": "https://modelcontextprotocol.io/specification/2025-11-25/schema", "supports": [ "tool schemas", "structured output", "resources", "capability changes" ], "auth": "Protocol-level auth depends on the connected server." } }, "ideas": [ { "id": "cloud-001", "title": "Release causality window", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Read-only; never roll back or change a flag automatically.", "validation": { "status": "documented-capability", "source_ids": [ "github_deployments", "sentry_releases", "launchdarkly_audit", "datadog" ] }, "copy_prompt": "$play explore [\nOutcome: Release causality window.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Read-only; never roll back or change a flag automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-002", "title": "Feature-flag ghost town", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "either", "complexity": 4, "guardrail": "Produce a review queue; never delete flags.", "validation": { "status": "documented-capability", "source_ids": [ "launchdarkly", "github_deployments", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Feature-flag ghost town.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Produce a review queue; never delete flags.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-003", "title": "Unowned public endpoint", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Inventory only; do not alter DNS or cloud resources.", "validation": { "status": "documented-capability", "source_ids": [ "cloudflare_dns", "aws_orgs", "git", "rippling" ] }, "copy_prompt": "$play explore [\nOutcome: Unowned public endpoint.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Inventory only; do not alter DNS or cloud resources.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-004", "title": "Infrastructure reality split", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "either", "complexity": 5, "guardrail": "Plan and inspect only; never apply Terraform.", "validation": { "status": "documented-capability", "source_ids": [ "terraform", "aws_cloudtrail", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Infrastructure reality split.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Plan and inspect only; never apply Terraform.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-005", "title": "Shadow scheduler map", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Read-only; do not disable schedules.", "validation": { "status": "documented-capability", "source_ids": [ "github_actions", "gitlab_ci", "aws_cloudtrail" ] }, "copy_prompt": "$play explore [\nOutcome: Shadow scheduler map.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Read-only; do not disable schedules.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-006", "title": "Rollback route rehearsal", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Rehearsal only; require explicit approval for any production write.", "validation": { "status": "documented-capability", "source_ids": [ "github_deployments", "vercel", "launchdarkly", "sentry_releases" ] }, "copy_prompt": "$play explore [\nOutcome: Rollback route rehearsal.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Rehearsal only; require explicit approval for any production write.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-007", "title": "Error budget by change batch", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not rank employees; analyze change batches and system conditions.", "validation": { "status": "documented-capability", "source_ids": [ "github_deployments", "datadog", "pagerduty" ] }, "copy_prompt": "$play explore [\nOutcome: Error budget by change batch.\nTools: Work only with GitHub Deployments, Datadog, and PagerDuty. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not rank employees; analyze change batches and system conditions.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-008", "title": "Support-to-release regression graph", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Redact customer content from any shared output.", "validation": { "status": "documented-capability", "source_ids": [ "zendesk_audits", "sentry_issues", "github_deployments", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Support-to-release regression graph.\nTools: Work only with Zendesk, Sentry, GitHub, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Redact customer content from any shared output.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-009", "title": "Green pipeline, broken data", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Read-only; label statistical anomalies as evidence to inspect, not proof of failure.", "validation": { "status": "documented-capability", "source_ids": [ "gitlab_ci", "github_artifacts", "grafana" ] }, "copy_prompt": "$play explore [\nOutcome: Green pipeline, broken data.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Read-only; label statistical anomalies as evidence to inspect, not proof of failure.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-010", "title": "Runbook command truth test", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 3, "guardrail": "Allow-list read-only commands; never execute copied destructive commands.", "validation": { "status": "documented-capability", "source_ids": [ "notion", "google_drive", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Runbook command truth test.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Allow-list read-only commands; never execute copied destructive commands.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-011", "title": "Certificate renewal dependency chain", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never expose secret values; inspect references and metadata only.", "validation": { "status": "documented-capability", "source_ids": [ "cloudflare_dns", "terraform", "onepassword", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Certificate renewal dependency chain.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never expose secret values; inspect references and metadata only.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-012", "title": "Region asymmetry finder", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Read-only; do not rebalance capacity.", "validation": { "status": "documented-capability", "source_ids": [ "aws_cost", "terraform", "datadog" ] }, "copy_prompt": "$play explore [\nOutcome: Region asymmetry finder.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Read-only; do not rebalance capacity.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-013", "title": "Orphan preview environment", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "either", "complexity": 4, "guardrail": "Produce candidates only; require approval before deletion.", "validation": { "status": "documented-capability", "source_ids": [ "vercel", "git", "cloudflare_dns", "aws_cost" ] }, "copy_prompt": "$play explore [\nOutcome: Orphan preview environment.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Produce candidates only; require approval before deletion.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-014", "title": "Shipped but unobservable", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not create monitors or schedules automatically.", "validation": { "status": "documented-capability", "source_ids": [ "git", "datadog", "pagerduty", "rippling" ] }, "copy_prompt": "$play explore [\nOutcome: Shipped but unobservable.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not create monitors or schedules automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-015", "title": "Change-freeze contradiction", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Evidence only; do not infer misconduct from timing alone.", "validation": { "status": "documented-capability", "source_ids": [ "google_calendar", "github_deployments", "launchdarkly_audit", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Change-freeze contradiction.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Evidence only; do not infer misconduct from timing alone.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-016", "title": "Hotfix knowledge gap", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 3, "guardrail": "Draft documentation only; preserve incident privacy.", "validation": { "status": "documented-capability", "source_ids": [ "git", "pagerduty", "linear", "notion" ] }, "copy_prompt": "$play explore [\nOutcome: Hotfix knowledge gap.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Draft documentation only; preserve incident privacy.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-017", "title": "Dependency-change blast radius", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Do not upgrade packages; analyze the proposed or completed change.", "validation": { "status": "documented-capability", "source_ids": [ "npm", "git", "github_artifacts", "sentry_issues" ] }, "copy_prompt": "$play explore [\nOutcome: Dependency-change blast radius.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not upgrade packages; analyze the proposed or completed change.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-018", "title": "Schema-consumer impact map", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Do not regenerate clients or create tickets without approval.", "validation": { "status": "documented-capability", "source_ids": [ "git", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Schema-consumer impact map.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not regenerate clients or create tickets without approval.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-019", "title": "Drift owner resolver", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not revert drift automatically.", "validation": { "status": "documented-capability", "source_ids": [ "aws_cloudtrail", "terraform", "git", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Drift owner resolver.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not revert drift automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-020", "title": "Cost spike as product event", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Treat correlation as a lead, not proof of causation.", "validation": { "status": "documented-capability", "source_ids": [ "aws_cost", "github_deployments", "launchdarkly_audit", "datadog" ] }, "copy_prompt": "$play explore [\nOutcome: Cost spike as product event.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Treat correlation as a lead, not proof of causation.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-021", "title": "Data-residency route proof", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Proof only; do not move data or change routing.", "validation": { "status": "documented-capability", "source_ids": [ "cloudflare_dns", "aws_orgs", "terraform", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Data-residency route proof.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Proof only; do not move data or change routing.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-022", "title": "Secret-expiry launch risk", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Never print secret values; inspect references and metadata only.", "validation": { "status": "documented-capability", "source_ids": [ "onepassword", "github_actions", "vercel", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Secret-expiry launch risk.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never print secret values; inspect references and metadata only.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-023", "title": "Dead-service retirement proof", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never delete the service; produce evidence and blockers.", "validation": { "status": "documented-capability", "source_ids": [ "cloudflare_dns", "datadog", "github_deployments", "aws_cost" ] }, "copy_prompt": "$play explore [\nOutcome: Dead-service retirement proof.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never delete the service; produce evidence and blockers.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-024", "title": "Monorepo test-gap cartography", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 3, "guardrail": "Report missing coverage; do not claim untested code is defective.", "validation": { "status": "documented-capability", "source_ids": [ "github_actions", "github_artifacts", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Monorepo test-gap cartography.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Report missing coverage; do not claim untested code is defective.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "cloud-025", "title": "License-change release gate", "domain": "Software and cloud operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Flag for legal review; do not render legal conclusions.", "validation": { "status": "documented-capability", "source_ids": [ "npm", "git" ] }, "copy_prompt": "$play explore [\nOutcome: License-change release gate.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Flag for legal review; do not render legal conclusions.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-001", "title": "Instruction collision map", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Read-only; do not rewrite instructions automatically.", "validation": { "status": "documented-capability", "source_ids": [ "github_instructions", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Instruction collision map.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Read-only; do not rewrite instructions automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-002", "title": "Tool-permission shadow diff", "domain": "Agent operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Recommend least privilege; do not revoke access automatically.", "validation": { "status": "documented-capability", "source_ids": [ "mcp", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Tool-permission shadow diff.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Recommend least privilege; do not revoke access automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-003", "title": "Tool-schema drift impact", "domain": "Agent operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Do not update published Plays automatically.", "validation": { "status": "documented-capability", "source_ids": [ "mcp", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Tool-schema drift impact.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not update published Plays automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-004", "title": "Replay nondeterminism microscope", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Use fixtures or read-only calls; never replay destructive writes.", "validation": { "status": "documented-capability", "source_ids": [ "git" ] }, "copy_prompt": "$play explore [\nOutcome: Replay nondeterminism microscope.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use fixtures or read-only calls; never replay destructive writes.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-005", "title": "Retry-loop fingerprint miner", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "either", "complexity": 3, "guardrail": "Analyze recorded runs; do not rerun failed writes.", "validation": { "status": "documented-capability", "source_ids": [ "mcp" ] }, "copy_prompt": "$play explore [\nOutcome: Retry-loop fingerprint miner.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Analyze recorded runs; do not rerun failed writes.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-006", "title": "Context payload bloat locator", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Never recommend removing safety or policy instructions solely because they were unused.", "validation": { "status": "documented-capability", "source_ids": [ "mcp", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Context payload bloat locator.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never recommend removing safety or policy instructions solely because they were unused.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-007", "title": "Expert-correction hotspot", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "private", "complexity": 4, "guardrail": "Treat corrections as candidate knowledge, not universal policy.", "validation": { "status": "documented-capability", "source_ids": [ "git", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Expert-correction hotspot.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Treat corrections as candidate knowledge, not universal policy.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-008", "title": "Fallback-model divergence", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Use isolated worktrees and non-production fixtures.", "validation": { "status": "documented-capability", "source_ids": [ "git" ] }, "copy_prompt": "$play explore [\nOutcome: Fallback-model divergence.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use isolated worktrees and non-production fixtures.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-009", "title": "Claimed-test verifier", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "public", "complexity": 3, "guardrail": "Report evidence gaps without inferring intent.", "validation": { "status": "documented-capability", "source_ids": [ "github_artifacts", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Claimed-test verifier.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Report evidence gaps without inferring intent.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-010", "title": "Invisible side-effect census", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Observe only; do not terminate processes or clean files automatically.", "validation": { "status": "documented-capability", "source_ids": [ "git", "npm" ] }, "copy_prompt": "$play explore [\nOutcome: Invisible side-effect census.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Observe only; do not terminate processes or clean files automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-011", "title": "Credential reach versus task need", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never read or emit credential values.", "validation": { "status": "documented-capability", "source_ids": [ "onepassword", "mcp" ] }, "copy_prompt": "$play explore [\nOutcome: Credential reach versus task need.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never read or emit credential values.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-012", "title": "Stale skill versus live CLI", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "none", "publication": "public", "complexity": 2, "guardrail": "Run help and dry-run forms only.", "validation": { "status": "documented-capability", "source_ids": [ "git" ] }, "copy_prompt": "$play explore [\nOutcome: Stale skill versus live CLI.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Run help and dry-run forms only.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-013", "title": "Prompt-to-write provenance", "domain": "Agent operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "private", "complexity": 5, "guardrail": "Audit only; never repeat or undo remote writes automatically.", "validation": { "status": "documented-capability", "source_ids": [ "mcp", "git", "launchdarkly_audit" ] }, "copy_prompt": "$play explore [\nOutcome: Prompt-to-write provenance.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Audit only; never repeat or undo remote writes automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-014", "title": "Cross-harness result parity", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Use isolated fixtures and block external writes.", "validation": { "status": "documented-capability", "source_ids": [ "github_instructions", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Cross-harness result parity.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use isolated fixtures and block external writes.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-015", "title": "Missing stop-condition detector", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "either", "complexity": 3, "guardrail": "Propose stop conditions; do not truncate active work automatically.", "validation": { "status": "documented-capability", "source_ids": [ "mcp", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Missing stop-condition detector.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Propose stop conditions; do not truncate active work automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-016", "title": "Tool-argument instability map", "domain": "Agent operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 3, "guardrail": "Analyze recorded arguments; do not replay destructive calls.", "validation": { "status": "documented-capability", "source_ids": [ "mcp" ] }, "copy_prompt": "$play explore [\nOutcome: Tool-argument instability map.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Analyze recorded arguments; do not replay destructive calls.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-017", "title": "Shared-state contamination test", "domain": "Agent operations", "design": "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" ], "modalities": [ "browser", "proc" ], "auth": "mixed", "publication": "private", "complexity": 4, "guardrail": "Use isolated copies; never expose browser tokens or environment values.", "validation": { "status": "documented-capability", "source_ids": [ "git" ] }, "copy_prompt": "$play explore [\nOutcome: Shared-state contamination test.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use isolated copies; never expose browser tokens or environment values.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-018", "title": "Public canary for tool honesty", "domain": "Agent operations", "design": "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" ], "modalities": [ "api" ], "auth": "none", "publication": "public", "complexity": 2, "guardrail": "Use documented rate limits and small result sets.", "validation": { "status": "documented-capability", "source_ids": [ "osv", "world_bank", "usgs" ] }, "copy_prompt": "$play explore [\nOutcome: Public canary for tool honesty.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use documented rate limits and small result sets.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-019", "title": "Approval-boundary proof", "domain": "Agent operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 5, "guardrail": "Use fake endpoints and disposable fixtures only.", "validation": { "status": "documented-capability", "source_ids": [ "mcp", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Approval-boundary proof.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use fake endpoints and disposable fixtures only.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-020", "title": "Self-modifying instruction watch", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Observe and require human review; do not accept self-modification as authority.", "validation": { "status": "documented-capability", "source_ids": [ "github_instructions", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Self-modifying instruction watch.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Observe and require human review; do not accept self-modification as authority.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-021", "title": "Agent dependency expansion audit", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Do not uninstall or disable dependencies automatically.", "validation": { "status": "documented-capability", "source_ids": [ "npm", "mcp", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Agent dependency expansion audit.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not uninstall or disable dependencies automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-022", "title": "Ungrounded identifier detector", "domain": "Agent operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 3, "guardrail": "Mark unverified identifiers; do not infer the object exists.", "validation": { "status": "documented-capability", "source_ids": [ "git", "linear", "pagerduty" ] }, "copy_prompt": "$play explore [\nOutcome: Ungrounded identifier detector.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Mark unverified identifiers; do not infer the object exists.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-023", "title": "Rate-limit recovery rehearsal", "domain": "Agent operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Use mocks or public read-only endpoints; never provoke a production limit intentionally.", "validation": { "status": "documented-capability", "source_ids": [ "mcp", "crossref" ] }, "copy_prompt": "$play explore [\nOutcome: Rate-limit recovery rehearsal.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use mocks or public read-only endpoints; never provoke a production limit intentionally.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-024", "title": "Judgment per compute cycle", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "private", "complexity": 4, "guardrail": "Do not use the metric to rank individuals; use it to improve task and Play design.", "validation": { "status": "documented-capability", "source_ids": [ "git", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Judgment per compute cycle.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not use the metric to rank individuals; use it to improve task and Play design.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "agent-025", "title": "Repeated-trace Play candidate ranker", "domain": "Agent operations", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "private", "complexity": 4, "guardrail": "Propose candidates; do not publish a Play without expert review.", "validation": { "status": "documented-capability", "source_ids": [ "git", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Repeated-trace Play candidate ranker.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Propose candidates; do not publish a Play without expert review.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-001", "title": "Dormant admin, live token", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never revoke access automatically; require identity-owner confirmation.", "validation": { "status": "documented-capability", "source_ids": [ "okta", "okta_log", "git", "onepassword" ] }, "copy_prompt": "$play explore [\nOutcome: Dormant admin, live token.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never revoke access automatically; require identity-owner confirmation.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-002", "title": "Former-employee deploy lineage", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Preserve forensic evidence and require approval before key rotation.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "github_actions", "git", "aws_cloudtrail" ] }, "copy_prompt": "$play explore [\nOutcome: Former-employee deploy lineage.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Preserve forensic evidence and require approval before key rotation.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-003", "title": "SSO-bypass path graph", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Read-only; do not test bypasses by attempting unauthorized access.", "validation": { "status": "documented-capability", "source_ids": [ "okta", "okta_log", "google_admin", "google_reports" ] }, "copy_prompt": "$play explore [\nOutcome: SSO-bypass path graph.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Read-only; do not test bypasses by attempting unauthorized access.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-004", "title": "Ownerless machine identity", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Never disable machine identities automatically.", "validation": { "status": "documented-capability", "source_ids": [ "okta", "google_admin", "github_actions", "rippling" ] }, "copy_prompt": "$play explore [\nOutcome: Ownerless machine identity.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never disable machine identities automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-005", "title": "Secret-rotation blast radius", "domain": "Security and compliance", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Inspect references only; never print or rotate the secret.", "validation": { "status": "documented-capability", "source_ids": [ "onepassword", "github_actions", "vercel", "terraform" ] }, "copy_prompt": "$play explore [\nOutcome: Secret-rotation blast radius.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Inspect references only; never print or rotate the secret.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-006", "title": "Role entropy after job changes", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Recommend review; never remove access from behavioral inference alone.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "okta", "okta_log" ] }, "copy_prompt": "$play explore [\nOutcome: Role entropy after job changes.\nTools: Work only with Rippling, Okta, and Okta System Log. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Recommend review; never remove access from behavioral inference alone.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-007", "title": "Login outlives employment", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Escalate to security; do not terminate logins without incident authority.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "okta_log", "google_reports" ] }, "copy_prompt": "$play explore [\nOutcome: Login outlives employment.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Escalate to security; do not terminate logins without incident authority.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-008", "title": "API-key privilege versus observed use", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never narrow or rotate tokens automatically; absence of use is not proof of no future need.", "validation": { "status": "documented-capability", "source_ids": [ "okta_log", "onepassword", "launchdarkly_audit" ] }, "copy_prompt": "$play explore [\nOutcome: API-key privilege versus observed use.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never narrow or rotate tokens automatically; absence of use is not proof of no future need.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-009", "title": "Dormant webhook still delivering", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not disable delivery; preserve event evidence and redact payloads.", "validation": { "status": "documented-capability", "source_ids": [ "linear_webhooks", "git", "cloudflare_dns" ] }, "copy_prompt": "$play explore [\nOutcome: Dormant webhook still delivering.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not disable delivery; preserve event evidence and redact payloads.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-010", "title": "Audit-log silence detector", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Treat silence as a telemetry failure candidate, not proof of no activity.", "validation": { "status": "documented-capability", "source_ids": [ "okta_log", "google_reports", "launchdarkly_audit", "aws_cloudtrail" ] }, "copy_prompt": "$play explore [\nOutcome: Audit-log silence detector.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Treat silence as a telemetry failure candidate, not proof of no activity.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-011", "title": "Production data in development artifacts", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Hash or redact sensitive matches; never reproduce customer data.", "validation": { "status": "documented-capability", "source_ids": [ "github_artifacts", "sentry_issues", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Production data in development artifacts.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Hash or redact sensitive matches; never reproduce customer data.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-012", "title": "Expired exception, missing control", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not remediate automatically; preserve the approving context.", "validation": { "status": "documented-capability", "source_ids": [ "linear", "notion", "okta", "aws_cloudtrail" ] }, "copy_prompt": "$play explore [\nOutcome: Expired exception, missing control.\nTools: Work only with Linear, Notion, Okta, and AWS CloudTrail. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not remediate automatically; preserve the approving context.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-013", "title": "Running exploitability, not CVE volume", "domain": "Security and compliance", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "mixed", "publication": "public", "complexity": 5, "guardrail": "Do not equate package presence with exploitability; preserve reachability uncertainty.", "validation": { "status": "documented-capability", "source_ids": [ "osv", "cisa_kev", "github_deployments" ] }, "copy_prompt": "$play explore [\nOutcome: Running exploitability, not CVE volume.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not equate package presence with exploitability; preserve reachability uncertainty.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-014", "title": "Vulnerable but unreachable proof", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 5, "guardrail": "State reachability as evidence and uncertainty, never as a guarantee of safety.", "validation": { "status": "documented-capability", "source_ids": [ "osv", "git", "launchdarkly" ] }, "copy_prompt": "$play explore [\nOutcome: Vulnerable but unreachable proof.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: State reachability as evidence and uncertainty, never as a guarantee of safety.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-015", "title": "Signing-material policy drift", "domain": "Security and compliance", "design": "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" ], "modalities": [ "proc", "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Metadata only; never export private keys.", "validation": { "status": "documented-capability", "source_ids": [ "onepassword", "git", "github_actions", "notion" ] }, "copy_prompt": "$play explore [\nOutcome: Signing-material policy drift.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Metadata only; never export private keys.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-016", "title": "CI artifact secret residue", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Redact all findings; never print or validate a secret against a live service.", "validation": { "status": "documented-capability", "source_ids": [ "github_artifacts", "gitlab_ci", "onepassword" ] }, "copy_prompt": "$play explore [\nOutcome: CI artifact secret residue.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Redact all findings; never print or validate a secret against a live service.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-017", "title": "Privileged change outside the window", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Evidence only; timing is not proof of unauthorized behavior.", "validation": { "status": "documented-capability", "source_ids": [ "aws_cloudtrail", "okta_log", "google_calendar", "pagerduty" ] }, "copy_prompt": "$play explore [\nOutcome: Privileged change outside the window.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Evidence only; timing is not proof of unauthorized behavior.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-018", "title": "Shared-mailbox shadow administrator", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Inspect delegation and recovery paths only; do not open unrelated mail.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "google_admin", "okta" ] }, "copy_prompt": "$play explore [\nOutcome: Shared-mailbox shadow administrator.\nTools: Work only with Gmail, Google Admin, and Okta. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Inspect delegation and recovery paths only; do not open unrelated mail.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-019", "title": "Public link to private incident", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not widen access or echo sensitive content; report file IDs and classifications.", "validation": { "status": "documented-capability", "source_ids": [ "google_drive", "zendesk", "pagerduty" ] }, "copy_prompt": "$play explore [\nOutcome: Public link to private incident.\nTools: Work only with Google Drive, Zendesk, and PagerDuty. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not widen access or echo sensitive content; report file IDs and classifications.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-020", "title": "Break-glass readiness proof", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never authenticate as a break-glass account during routine verification.", "validation": { "status": "documented-capability", "source_ids": [ "okta", "okta_log", "google_admin", "onepassword", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Break-glass readiness proof.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never authenticate as a break-glass account during routine verification.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-021", "title": "Dangling-domain takeover candidate", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "public", "complexity": 4, "guardrail": "Never attempt resource registration or takeover.", "validation": { "status": "documented-capability", "source_ids": [ "cloudflare_dns", "vercel", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Dangling-domain takeover candidate.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never attempt resource registration or takeover.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-022", "title": "Subprocessor reality mismatch", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc", "browser" ], "auth": "mixed", "publication": "private", "complexity": 5, "guardrail": "Flag for legal and security review; do not make compliance conclusions automatically.", "validation": { "status": "documented-capability", "source_ids": [ "google_drive", "cloudflare_dns", "git", "okta" ] }, "copy_prompt": "$play explore [\nOutcome: Subprocessor reality mismatch.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Flag for legal and security review; do not make compliance conclusions automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-023", "title": "Auth event to sensitive change", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Correlation is investigative context, not attribution or guilt.", "validation": { "status": "documented-capability", "source_ids": [ "okta_log", "git", "launchdarkly_audit", "aws_cloudtrail" ] }, "copy_prompt": "$play explore [\nOutcome: Auth event to sensitive change.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Correlation is investigative context, not attribution or guilt.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-024", "title": "Identity geography contradiction", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never treat location alone as proof; require security review and contextual normalization.", "validation": { "status": "documented-capability", "source_ids": [ "okta_log", "google_calendar", "google_reports", "aws_cloudtrail" ] }, "copy_prompt": "$play explore [\nOutcome: Identity geography contradiction.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never treat location alone as proof; require security review and contextual normalization.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "security-025", "title": "Control evidence chain completeness", "domain": "Security and compliance", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not certify compliance; produce the evidence graph and missing links.", "validation": { "status": "documented-capability", "source_ids": [ "notion", "google_drive", "okta", "aws_cloudtrail", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Control evidence chain completeness.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not certify compliance; produce the evidence graph and missing links.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-001", "title": "Webhook-to-cash completeness", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Reconcile and report only; never resend events or post ledger entries automatically.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_webhooks", "shopify_orders", "shopify_fulfillment", "stripe", "mercury", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Webhook-to-cash completeness.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Reconcile and report only; never resend events or post ledger entries automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-002", "title": "Settlement-delay causality", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Label contractual and banking assumptions; do not promise settlement timing.", "validation": { "status": "documented-capability", "source_ids": [ "stripe", "razorpay_settlements", "mercury", "xero", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Settlement-delay causality.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Label contractual and banking assumptions; do not promise settlement timing.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-003", "title": "Duplicate economic event detector", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not reverse transactions; produce matched evidence and confidence.", "validation": { "status": "documented-capability", "source_ids": [ "stripe", "razorpay_settlements", "mercury", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Duplicate economic event detector.\nTools: Work only with Stripe, Razorpay, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not reverse transactions; produce matched evidence and confidence.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-004", "title": "Refund promised, money absent", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not issue refunds; redact customer text in shared output.", "validation": { "status": "documented-capability", "source_ids": [ "zendesk_audits", "stripe", "mercury", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Refund promised, money absent.\nTools: Work only with Zendesk, Stripe, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not issue refunds; redact customer text in shared output.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-005", "title": "Dispute evidence assembler", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Draft only; require human review before evidence submission.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_disputes", "razorpay_disputes", "shopify_fulfillment", "zendesk", "google_drive" ] }, "copy_prompt": "$play explore [\nOutcome: Dispute evidence assembler.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Draft only; require human review before evidence submission.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-006", "title": "Negative-margin order autopsy", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Treat accounting mappings as configurable and reviewable.", "validation": { "status": "documented-capability", "source_ids": [ "shopify_orders", "shopify_fulfillment", "stripe", "xero", "zendesk" ] }, "copy_prompt": "$play explore [\nOutcome: Negative-margin order autopsy.\nTools: Work only with Shopify, Stripe, Xero, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Treat accounting mappings as configurable and reviewable.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-007", "title": "Entitlement-billing contradiction", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not change billing or access; prepare customer-safe review cases.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_subscriptions", "stripe_invoices", "zendesk" ] }, "copy_prompt": "$play explore [\nOutcome: Entitlement-billing contradiction.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not change billing or access; prepare customer-safe review cases.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-008", "title": "Dormant subscription, live consumption", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not terminate access automatically; account for contractual grace periods.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_subscriptions", "aws_cost", "hubspot" ] }, "copy_prompt": "$play explore [\nOutcome: Dormant subscription, live consumption.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not terminate access automatically; account for contractual grace periods.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-009", "title": "Payroll funding readiness", "domain": "Finance, revenue, and commerce", "design": "Before payroll cutoff, reconcile active workers, expected payroll amount, available bank balance, pending transfers, and exceptional compensation changes.", "systems": [ "Rippling", "Mercury", "Google Calendar" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never initiate transfers or alter payroll; minimize employee-level data.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "mercury", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Payroll funding readiness.\nTools: Work only with Rippling, Mercury, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never initiate transfers or alter payroll; minimize employee-level data.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-010", "title": "Payroll-to-ledger population mismatch", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Protect compensation data and do not post corrections automatically.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "mercury", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Payroll-to-ledger population mismatch.\nTools: Work only with Rippling, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Protect compensation data and do not post corrections automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-011", "title": "Contractor in employee clothing", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not determine worker classification; route evidence to HR and legal review.", "validation": { "status": "documented-capability", "source_ids": [ "xero", "rippling", "okta", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Contractor in employee clothing.\nTools: Work only with Xero, Rippling, Okta, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not determine worker classification; route evidence to HR and legal review.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-012", "title": "Changed-bank-detail payment proof", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never send payment; require independent human verification outside the submitted channel.", "validation": { "status": "documented-capability", "source_ids": [ "xero", "mercury", "slack", "google_drive" ] }, "copy_prompt": "$play explore [\nOutcome: Changed-bank-detail payment proof.\nTools: Work only with Xero, Mercury, Slack, and Google Drive. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never send payment; require independent human verification outside the submitted channel.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-013", "title": "Revenue-recognition exception finder", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Prepare review cases; do not make accounting judgments or entries automatically.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_invoices", "stripe_subscriptions", "xero", "google_drive" ] }, "copy_prompt": "$play explore [\nOutcome: Revenue-recognition exception finder.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Prepare review cases; do not make accounting judgments or entries automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-014", "title": "Credit-note plus refund double relief", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not reverse or reissue financial documents.", "validation": { "status": "documented-capability", "source_ids": [ "stripe", "xero", "zendesk_audits" ] }, "copy_prompt": "$play explore [\nOutcome: Credit-note plus refund double relief.\nTools: Work only with Stripe, Xero, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not reverse or reissue financial documents.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-015", "title": "Foreign-exchange fee leak", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not recommend financial trades; quantify observed conversions and fees.", "validation": { "status": "documented-capability", "source_ids": [ "stripe", "razorpay_settlements", "mercury", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Foreign-exchange fee leak.\nTools: Work only with Stripe or Razorpay, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not recommend financial trades; quantify observed conversions and fees.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-016", "title": "Gift-card liability drift", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not apply expiry or breakage rules without accounting and legal configuration.", "validation": { "status": "documented-capability", "source_ids": [ "shopify_orders", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Gift-card liability drift.\nTools: Work only with Shopify and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not apply expiry or breakage rules without accounting and legal configuration.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-017", "title": "Inventory cash trap", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Inform purchasing review; do not place or cancel orders.", "validation": { "status": "documented-capability", "source_ids": [ "shopify_orders", "shopify_fulfillment", "xero_reports", "mercury" ] }, "copy_prompt": "$play explore [\nOutcome: Inventory cash trap.\nTools: Work only with Shopify, Xero, and Mercury. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Inform purchasing review; do not place or cancel orders.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-018", "title": "Discount leakage after a product change", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not alter pricing, coupons, or customer invoices.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_invoices", "launchdarkly_audit", "git", "hubspot" ] }, "copy_prompt": "$play explore [\nOutcome: Discount leakage after a product change.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not alter pricing, coupons, or customer invoices.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-019", "title": "Dispute spike after release", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Correlation is a lead; do not submit dispute evidence or roll back automatically.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_disputes", "github_deployments", "shopify_fulfillment", "zendesk", "sentry_issues" ] }, "copy_prompt": "$play explore [\nOutcome: Dispute spike after release.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Correlation is a lead; do not submit dispute evidence or roll back automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-020", "title": "Nexus evidence without the spreadsheet chase", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not determine tax nexus; package evidence for qualified advice.", "validation": { "status": "documented-capability", "source_ids": [ "shopify_orders", "rippling", "xero", "google_drive" ] }, "copy_prompt": "$play explore [\nOutcome: Nexus evidence without the spreadsheet chase.\nTools: Work only with Shopify, Rippling, Xero, and Google Drive. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not determine tax nexus; package evidence for qualified advice.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-021", "title": "Cross-border payroll conversion leak", "domain": "Finance, revenue, and commerce", "design": "Compare compensation currency, payroll debit, bank conversion, worker receipt evidence, and ledger rate to identify repeated spread or routing losses.", "systems": [ "Rippling", "Mercury", "Xero" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Protect compensation data and do not initiate transfers.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "mercury", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Cross-border payroll conversion leak.\nTools: Work only with Rippling, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Protect compensation data and do not initiate transfers.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-022", "title": "Runway versus commitments", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Present scenarios and assumptions; do not give investment or insolvency advice.", "validation": { "status": "documented-capability", "source_ids": [ "mercury", "xero_reports", "rippling", "google_drive", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Runway versus commitments.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Present scenarios and assumptions; do not give investment or insolvency advice.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-023", "title": "Customer entitlement ghost", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not merge customers or alter access automatically.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_subscriptions", "hubspot", "salesforce", "zendesk" ] }, "copy_prompt": "$play explore [\nOutcome: Customer entitlement ghost.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not merge customers or alter access automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-024", "title": "Failed dunning, continued fulfillment", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not stop fulfillment or customer access automatically.", "validation": { "status": "documented-capability", "source_ids": [ "stripe_invoices", "stripe_subscriptions", "shopify_fulfillment", "hubspot" ] }, "copy_prompt": "$play explore [\nOutcome: Failed dunning, continued fulfillment.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not stop fulfillment or customer access automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "finance-025", "title": "Processor-routing anomaly", "domain": "Finance, revenue, and commerce", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Analyze observed outcomes; do not reroute payments automatically.", "validation": { "status": "documented-capability", "source_ids": [ "stripe", "razorpay_settlements", "razorpay_disputes", "mercury", "xero" ] }, "copy_prompt": "$play explore [\nOutcome: Processor-routing anomaly.\nTools: Work only with Stripe, Razorpay, Mercury, and Xero. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Analyze observed outcomes; do not reroute payments automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-001", "title": "Promised-feature debt", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not treat sales language as a binding contract without review.", "validation": { "status": "documented-capability", "source_ids": [ "hubspot", "gmail", "slack", "linear", "github_deployments" ] }, "copy_prompt": "$play explore [\nOutcome: Promised-feature debt.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not treat sales language as a binding contract without review.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-002", "title": "SLA clock disagreement", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Use configured contract definitions; do not assert breach automatically.", "validation": { "status": "documented-capability", "source_ids": [ "zendesk_audits", "pagerduty", "datadog_incidents", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: SLA clock disagreement.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use configured contract definitions; do not assert breach automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-003", "title": "Workaround retirement proof", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not remove workarounds or contact customers automatically.", "validation": { "status": "documented-capability", "source_ids": [ "zendesk", "notion", "github_deployments", "sentry_issues" ] }, "copy_prompt": "$play explore [\nOutcome: Workaround retirement proof.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not remove workarounds or contact customers automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-004", "title": "Knowledge article versus shipped truth", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "browser", "proc", "api" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Use test accounts and read-only product paths.", "validation": { "status": "documented-capability", "source_ids": [ "zendesk", "notion", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Knowledge article versus shipped truth.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use test accounts and read-only product paths.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-005", "title": "Churn intent before the CRM", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Use only authorized business communication; avoid employee private messages and automated customer action.", "validation": { "status": "documented-capability", "source_ids": [ "zendesk", "gmail", "slack", "hubspot" ] }, "copy_prompt": "$play explore [\nOutcome: Churn intent before the CRM.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use only authorized business communication; avoid employee private messages and automated customer action.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-006", "title": "Renewal owner disappeared", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not reassign accounts or contact customers automatically.", "validation": { "status": "documented-capability", "source_ids": [ "hubspot", "rippling", "google_calendar", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Renewal owner disappeared.\nTools: Work only with HubSpot, Rippling, Google Calendar, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not reassign accounts or contact customers automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-007", "title": "Customer flag without a customer", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not edit targeting rules automatically.", "validation": { "status": "documented-capability", "source_ids": [ "launchdarkly", "hubspot", "stripe_subscriptions", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Customer flag without a customer.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not edit targeting rules automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-008", "title": "Bug impact priced in pipeline", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Restrict revenue data and do not prioritize solely by account value.", "validation": { "status": "documented-capability", "source_ids": [ "sentry_issues", "hubspot", "zendesk", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Bug impact priced in pipeline.\nTools: Work only with Sentry, HubSpot, Zendesk, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Restrict revenue data and do not prioritize solely by account value.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-009", "title": "Sales-demo environment drift", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "required", "publication": "either", "complexity": 4, "guardrail": "Use demo accounts; do not alter production or customer data.", "validation": { "status": "documented-capability", "source_ids": [ "google_calendar", "hubspot", "vercel", "launchdarkly" ] }, "copy_prompt": "$play explore [\nOutcome: Sales-demo environment drift.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use demo accounts; do not alter production or customer data.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-010", "title": "Contract clause to operating control", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Use approved contracts and legal review; do not interpret ambiguous clauses autonomously.", "validation": { "status": "documented-capability", "source_ids": [ "google_drive", "linear", "notion", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Contract clause to operating control.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use approved contracts and legal review; do not interpret ambiguous clauses autonomously.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-011", "title": "Deletion request proof chain", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Never delete automatically; require identity verification and approved retention policy.", "validation": { "status": "documented-capability", "source_ids": [ "zendesk", "hubspot", "stripe", "google_drive" ] }, "copy_prompt": "$play explore [\nOutcome: Deletion request proof chain.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never delete automatically; require identity verification and approved retention policy.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-012", "title": "Operational drift after contract redline", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Legal interpretation requires counsel; produce changed clauses and implementation evidence.", "validation": { "status": "documented-capability", "source_ids": [ "google_drive", "git", "launchdarkly", "stripe", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Operational drift after contract redline.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Legal interpretation requires counsel; produce changed clauses and implementation evidence.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-013", "title": "Scorecard written after the decision", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Audit process timing, not candidate merit or interviewer intent.", "validation": { "status": "documented-capability", "source_ids": [ "greenhouse", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Scorecard written after the decision.\nTools: Work only with Greenhouse and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Audit process timing, not candidate merit or interviewer intent.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-014", "title": "Interview load collides with on-call", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Propose options; do not reschedule interviews automatically.", "validation": { "status": "documented-capability", "source_ids": [ "greenhouse", "google_calendar", "pagerduty", "github_deployments" ] }, "copy_prompt": "$play explore [\nOutcome: Interview load collides with on-call.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Propose options; do not reschedule interviews automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-015", "title": "Offer promise versus day-one reality", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Restrict compensation and candidate data; do not change offers or employment records.", "validation": { "status": "documented-capability", "source_ids": [ "greenhouse", "rippling", "okta", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Offer promise versus day-one reality.\nTools: Work only with Greenhouse, Rippling, Okta, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Restrict compensation and candidate data; do not change offers or employment records.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-016", "title": "Role changed, work pattern did not", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Use for workload and access review, not employee performance scoring.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "okta_log", "git", "google_calendar", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Role changed, work pattern did not.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use for workload and access review, not employee performance scoring.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-017", "title": "Leave creates an ownership hole", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Reveal only work-relevant leave timing to authorized planners.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "pagerduty", "git", "hubspot", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Leave creates an ownership hole.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Reveal only work-relevant leave timing to authorized planners.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-018", "title": "New manager inherits invisible commitments", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Use authorized work communication; exclude private personal mail.", "validation": { "status": "documented-capability", "source_ids": [ "rippling", "linear", "google_calendar", "gmail", "pagerduty" ] }, "copy_prompt": "$play explore [\nOutcome: New manager inherits invisible commitments.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use authorized work communication; exclude private personal mail.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-019", "title": "Decision made, record missing", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Use only authorized channels; draft records for confirmation rather than declaring decisions.", "validation": { "status": "documented-capability", "source_ids": [ "slack", "google_calendar", "notion", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Decision made, record missing.\nTools: Work only with Slack, Google Calendar, Notion, and Linear. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use only authorized channels; draft records for confirmation rather than declaring decisions.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-020", "title": "Meeting without durable output", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "either", "complexity": 3, "guardrail": "Do not cancel meetings; provide evidence and exceptions.", "validation": { "status": "documented-capability", "source_ids": [ "google_calendar", "google_drive", "google_tasks", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Meeting without durable output.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not cancel meetings; provide evidence and exceptions.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-021", "title": "Customer escalation arrived through the wrong door", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Limit access to authorized customer channels and redact executive correspondence.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "slack", "hubspot", "zendesk" ] }, "copy_prompt": "$play explore [\nOutcome: Customer escalation arrived through the wrong door.\nTools: Work only with Gmail, Slack, HubSpot, and Zendesk. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Limit access to authorized customer channels and redact executive correspondence.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-022", "title": "One-customer configuration tax", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Do not remove customer behavior; route contractual uncertainty for review.", "validation": { "status": "documented-capability", "source_ids": [ "launchdarkly", "git", "zendesk", "hubspot", "stripe" ] }, "copy_prompt": "$play explore [\nOutcome: One-customer configuration tax.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not remove customer behavior; route contractual uncertainty for review.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-023", "title": "Sales exception survived the deal", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Review only; do not revoke access, pricing, or features automatically.", "validation": { "status": "documented-capability", "source_ids": [ "hubspot", "stripe", "launchdarkly", "okta", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Sales exception survived the deal.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Review only; do not revoke access, pricing, or features automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-024", "title": "Customer-success claim provenance", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 5, "guardrail": "Draft corrections for account-owner approval; never send automatically.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "zendesk", "github_deployments", "datadog", "linear" ] }, "copy_prompt": "$play explore [\nOutcome: Customer-success claim provenance.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Draft corrections for account-owner approval; never send automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "people-025", "title": "Vendor roadmap promise aging", "domain": "Customers, people, and governance", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "mixed", "publication": "private", "complexity": 4, "guardrail": "Separate vendor statements from guarantees and preserve source dates.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "zendesk", "linear", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Vendor roadmap promise aging.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Separate vendor statements from guarantees and preserve source dates.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-001", "title": "Package-abandonment early signal", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Treat signals as risk indicators, not claims about maintainer intent.", "validation": { "status": "documented-capability", "source_ids": [ "npm", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Package-abandonment early signal.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Treat signals as risk indicators, not claims about maintainer intent.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-002", "title": "Maintainer-transfer blast radius", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Do not allege compromise; report verifiable ownership and release changes.", "validation": { "status": "documented-capability", "source_ids": [ "npm", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Maintainer-transfer blast radius.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not allege compromise; report verifiable ownership and release changes.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-003", "title": "Silent breaking-release detector", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Run in a sandbox and distinguish observed incompatibility from semantic-version intent.", "validation": { "status": "documented-capability", "source_ids": [ "npm", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Silent breaking-release detector.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Run in a sandbox and distinguish observed incompatibility from semantic-version intent.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-004", "title": "Public API contract drift", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "browser", "proc" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Use small read-only requests and respect published limits.", "validation": { "status": "documented-capability", "source_ids": [ "world_bank", "osv", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Public API contract drift.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use small read-only requests and respect published limits.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-005", "title": "Research correction reaches product claim", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 5, "guardrail": "Do not infer scientific invalidity beyond the published correction or retraction.", "validation": { "status": "documented-capability", "source_ids": [ "crossref", "pubmed", "openalex", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Research correction reaches product claim.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not infer scientific invalidity beyond the published correction or retraction.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-006", "title": "Prior-art watch for a live implementation", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Present technical comparison, not patentability or legal advice.", "validation": { "status": "documented-capability", "source_ids": [ "arxiv", "openalex", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Prior-art watch for a live implementation.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Present technical comparison, not patentability or legal advice.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-007", "title": "Reproducibility input pack", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 5, "guardrail": "Do not claim reproduction until outputs and acceptance criteria match.", "validation": { "status": "documented-capability", "source_ids": [ "crossref", "pubmed", "arxiv", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Reproducibility input pack.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not claim reproduction until outputs and acceptance criteria match.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-008", "title": "Filing-to-homepage contradiction", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "browser", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Quote and date sources; do not infer fraud or investment merit.", "validation": { "status": "documented-capability", "source_ids": [ "sec", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Filing-to-homepage contradiction.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Quote and date sources; do not infer fraud or investment merit.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-009", "title": "Known-exploit response lag", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Use public timelines and avoid exploit instructions.", "validation": { "status": "documented-capability", "source_ids": [ "cisa_kev", "osv", "npm", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Known-exploit response lag.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use public timelines and avoid exploit instructions.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-010", "title": "Typosquat neighborhood watch", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Never install suspicious packages outside an isolated sandbox.", "validation": { "status": "documented-capability", "source_ids": [ "npm" ] }, "copy_prompt": "$play explore [\nOutcome: Typosquat neighborhood watch.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never install suspicious packages outside an isolated sandbox.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-011", "title": "Dataset-definition drift", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Preserve source metadata and do not silently backfill incompatible series.", "validation": { "status": "documented-capability", "source_ids": [ "world_bank", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Dataset-definition drift.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Preserve source metadata and do not silently backfill incompatible series.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-012", "title": "Research funding concentration risk", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Concentration is context, not evidence of research misconduct.", "validation": { "status": "documented-capability", "source_ids": [ "crossref", "openalex" ] }, "copy_prompt": "$play explore [\nOutcome: Research funding concentration risk.\nTools: Work only with Crossref and OpenAlex. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Concentration is context, not evidence of research misconduct.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-013", "title": "Climate shock meets supplier geography", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "none", "publication": "public", "complexity": 4, "guardrail": "Advisory only; do not claim precise loss or safety outcomes.", "validation": { "status": "documented-capability", "source_ids": [ "nws", "world_bank" ] }, "copy_prompt": "$play explore [\nOutcome: Climate shock meets supplier geography.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Advisory only; do not claim precise loss or safety outcomes.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-014", "title": "Earthquake facility first-look", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "browser", "proc" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Not an emergency-service substitute; never infer structural safety remotely.", "validation": { "status": "documented-capability", "source_ids": [ "usgs" ] }, "copy_prompt": "$play explore [\nOutcome: Earthquake facility first-look.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Not an emergency-service substitute; never infer structural safety remotely.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "public-015", "title": "Community hazard action brief", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "none", "publication": "public", "complexity": 3, "guardrail": "Quote official instructions accurately and defer to emergency authorities.", "validation": { "status": "documented-capability", "source_ids": [ "nws", "usgs" ] }, "copy_prompt": "$play explore [\nOutcome: Community hazard action brief.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Quote official instructions accurately and defer to emergency authorities.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-001", "title": "Itinerary shock absorber", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "mixed", "publication": "private", "complexity": 4, "guardrail": "Draft contingency options; never rebook or cancel automatically.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "google_calendar", "nws", "google_tasks" ] }, "copy_prompt": "$play explore [\nOutcome: Itinerary shock absorber.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Draft contingency options; never rebook or cancel automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-002", "title": "Commitment with no next action", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Draft tasks for confirmation; do not read unrelated private channels or create tasks automatically.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "slack", "google_tasks", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Commitment with no next action.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Draft tasks for confirmation; do not read unrelated private channels or create tasks automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-003", "title": "Decision decay after meetings", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Draft reconciliations for participant confirmation.", "validation": { "status": "documented-capability", "source_ids": [ "google_calendar", "google_drive", "gmail", "google_tasks" ] }, "copy_prompt": "$play explore [\nOutcome: Decision decay after meetings.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Draft reconciliations for participant confirmation.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-004", "title": "Promise-capacity collision", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Propose tradeoffs; never decline commitments or move meetings automatically.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "slack", "google_calendar", "google_tasks" ] }, "copy_prompt": "$play explore [\nOutcome: Promise-capacity collision.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Propose tradeoffs; never decline commitments or move meetings automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-005", "title": "Quiet-hours reality check", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 3, "guardrail": "Use personal analysis only; do not score coworkers or infer wellbeing.", "validation": { "status": "documented-capability", "source_ids": [ "slack", "gmail", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Quiet-hours reality check.\nTools: Work only with Slack, Gmail, and Google Calendar. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use personal analysis only; do not score coworkers or infer wellbeing.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-006", "title": "Document-expiry readiness", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Never expose document numbers or submit government forms automatically.", "validation": { "status": "documented-capability", "source_ids": [ "google_drive", "gmail", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Document-expiry readiness.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Never expose document numbers or submit government forms automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-007", "title": "Family logistics handoff", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "private", "complexity": 3, "guardrail": "Use only consented shared data and draft handoffs for confirmation.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "google_calendar", "google_tasks" ] }, "copy_prompt": "$play explore [\nOutcome: Family logistics handoff.\nTools: Work only with Gmail, Google Calendar, and Google Tasks. Use documented API reads; follow pagination and retain source identifiers, timestamps, and Rote response addresses.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Use only consented shared data and draft handoffs for confirmation.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-008", "title": "Volunteer coverage before the gap", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api" ], "auth": "required", "publication": "either", "complexity": 3, "guardrail": "Draft outreach only; protect volunteer contact data.", "validation": { "status": "documented-capability", "source_ids": [ "google_calendar", "gmail", "slack", "google_drive" ] }, "copy_prompt": "$play explore [\nOutcome: Volunteer coverage before the gap.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Draft outreach only; protect volunteer contact data.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-009", "title": "Job-application narrative consistency", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "browser" ], "auth": "required", "publication": "private", "complexity": 4, "guardrail": "Do not fabricate or optimize false claims; keep employment data private.", "validation": { "status": "documented-capability", "source_ids": [ "gmail", "google_drive", "google_calendar" ] }, "copy_prompt": "$play explore [\nOutcome: Job-application narrative consistency.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Do not fabricate or optimize false claims; keep employment data private.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" }, { "id": "personal-010", "title": "Learning plan that notices the field moved", "domain": "Public intelligence and personal operations", "design": "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" ], "modalities": [ "api", "proc" ], "auth": "mixed", "publication": "either", "complexity": 4, "guardrail": "Propose edits; do not delete notes or tasks automatically.", "validation": { "status": "documented-capability", "source_ids": [ "google_drive", "google_tasks", "npm", "arxiv", "git" ] }, "copy_prompt": "$play explore [\nOutcome: Learning plan that notices the field moved.\nTools: 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.\nAccess: 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.\nMethod: 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.\nConnections: 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.\nValidation: 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.\nFailure handling: Preserve failed branches, conflicting evidence, and expert corrections. Stop a blocked branch; name the missing access, tool, identifier, or evidence.\nSafety: Propose edits; do not delete notes or tasks automatically.\nComplete only when every conclusion cites evidence, every conflict remains visible, and the join can run again from declared parameters.\nReturn the result, evidence map, validation results, blocked branches, and proposed Play inputs. Before crystallizing the Play, rerun the smallest representative case.\nThe second run must reproduce the join or name the changed condition.\n]" } ] }