Skip to content

0096 — Bring-your-own-ARIA

Status

Proposed. Gated on an automation-policy ruling — what third-party automation is permitted acting through the API — that has not yet been made; tracked as deferred design session item 13 in DECISIONS.md, and given a trackable Pending entry at DECISIONS.md § byo-aria-automation-policy. Not scheduled for build until that ruling lands.

Context

ADR-0094 establishes that the entire game is playable via the REST API, with no web client required. One of the horizons that pillar keeps open — but does not itself commit to — is a player attaching their own external intelligence to the game through API calls of their own, in place of or alongside the first-party ARIA. This is distinct from the other two API-first horizons (a first-party text-only client, player-crafted third-party UIs): those are alternative presentations of the same first-party game logic, while bring-your-own-ARIA is a player supplying their own decision-making agent against the live API surface.

That distinction is why this horizon needs its own decision rather than riding on ADR-0094's acceptance. ADR-0092 governs ARIA-the-product's autonomy — the session-live rule, the rejection of offline autonomy as a botting surface — but that rule is scoped to ARIA, the first-party companion. It says nothing about a player-operated external agent driving the same API a human player would use. No canon today states whether that is permitted, and if so under what constraints: fair-play boundaries (does an external agent count as automation/botting regardless of session-liveness), rate limits distinct from a human's natural click cadence, authentication posture for non-first-party automated clients, and how (or whether) such play is distinguishable from a human at a terminal.

Until that policy question is resolved, no build work should proceed on this horizon — an unresolved automation policy is exactly the kind of gap that turns a permissive API surface into an unintended botting vector.

Decision

Deferred. This ADR does not decide the automation/fair-play policy; it exists to hold the horizon and its dependency until deferred design session 13 is picked up. When that session resolves the automation-policy question, this ADR is revised with the concrete decision (permitted/rejected, and if permitted, under what constraints) and its status moves accordingly.

Consequences

  • No bring-your-own-ARIA work is scheduled or buildable until the automation-policy ruling lands.
  • ADR-0092's session-live boundary is unaffected — this ADR does not loosen or extend it. It governs a separate question: whether a player may drive the API through their own external agent, not whether ARIA herself may act while her player is offline.
  • When picked up, the design session must also settle the third-party-client posture shared with the other API-first horizons: API stability/versioning and auth for non-first-party clients (see ADR-0094 and deferred design session 13).
  • ADR-0094 — the API-first pillar this horizon stands on.
  • ADR-0092 — ARIA-the-product's session-live autonomy boundary (does not itself resolve this horizon).
  • DECISIONS.md — deferred design session 13, "Alternative clients & bring-your-own-intelligence," which owns the automation-policy question this ADR is gated on.