Checking · Contacting the Aiyo Runtime Decision Point. · —
Changelog

What's new in Aiyo.

New features and additive changes to the public /v1 API. The contract under /v1 is locked — additions are additive, breaking changes ship only under a new version.

How we tell you about changes. Breaking changes and security fixes reach integrated merchants by direct email — you never learn a contract broke from a feed. New features and additive changes are posted here. Every release is also recorded in CHANGELOG.md, the durable public record.
Unreleased on main

Changes landed on main that have not yet been batched into a tagged release.

Added

Live settlement view
A read-only page rendering the payer → gate → merchant flow, metric tiles, an append-only event log, and a settlement-latency panel. Lights up the moment real settlements flow through the deployed server. No auth, no writes, no credentials.
Read-only GET /v0/skip/sessions/:id
Returns a Skip session's status and its checkout_id once the payer authorizes. Lets a merchant (or an orchestrating agent) poll session progress. Touches no money and no gate.

Notes

Two research/benchmark tools shipped in this window are developer-facing, not part of the API surface: a load-test harness and a multi-step agent demo. The load harness relies on an env-gated mock wallet adapter that is inert in production — it only activates with an explicit flag, never on a real wallet host. Neither changes runtime behavior for merchants.
Positioning refresh (public materials, not API)
Following our Phase 4 governance research and competitive analysis, we have refreshed how Aiyo is described externally. The category noun is now Economic Execution Authorization plane for autonomous systems. The architectural primitive is named the Runtime Decision Point (RDP). Aiyo's differentiation is stated as quadruple-agnostic: actor-agnostic (human, agent, or machine), rail-agnostic (Open Payments, Tempo/MPP, x402, stablecoin rails, card networks on the same authorization contract), wallet-agnostic (non-custodial, works with whatever wallet the merchant already runs), and action-agnostic (payment is one possible evidence signal; procurement, DevOps deploys, data-writes, paid-tool invocations all fit the same primitive). Operating discipline remains Verify first. Execute second.

No API changes. No contract shape moved. Field names, error codes, headers, webhook payloads, and authentication all remain locked under /v1. This entry exists so integrators reading the site and the changelog side-by-side can see the copy shift and know it is external framing only.
1.1.0 2026-06 stable contract · merchant dashboard

Aiyo is becoming observable. This release ships the first set of merchant-facing surfaces that explain not only what executed, but who initiated it, which run it belonged to, how it progressed, and — where applicable — why it failed.

Added — Attribution

Workflow + agent attribution on intents
Intents accept an optional attribution object with merchant-supplied workflow_id and agent_id. Both surface verbatim on dashboard chips and are queryable in the merchant feed. Render-only-when-present discipline: pre-existing intents and untagged intents render no chip.
Wallet, signer, identity, provider, and bridge chips
Every event in the lineage panel now renders attribution chips for the dimensions present on that row — wallet address, signing-credential id, identity attestation subject, settlement provider, bridge rail / chain / tx-hash. Each dimension has its own color so the chip strip is scannable at a glance.

Added — Lineage & run-level tracing

Per-intent lineage panel
Click any intent in the feed to open the full lineage panel: a 5-stage pipeline view (intent → proof → settlement → execution → outcome) over the same chronological event timeline that powers the API. Honest about skipped stages (e.g. OP-native intents render the proof stage as "skipped").
Multi-step agent runs (lineage_id)
Intents accept an optional lineage_id UUID that groups multiple intents into a single agent run. The lineage panel renders a horizontal sibling strip when present — every intent in the run is one click away. Per-merchant scoped; cross-merchant UUID collisions cannot leak.

Added — Retry visibility

Retries card on the merchant dashboard
Four tiles: webhook deliveries in flight, webhook deliveries exhausted, async jobs in flight, jobs stuck (overdue > 1 hour). Each tile is backed by an honest count — zero collapses to "All caught up." Lists below the tiles show the items currently retrying, ordered by soonest-next-attempt.

Added — Failure diagnostics

Structured reason codes on every failure event
27 codes covering proof / settlement / provider / bridge / signer / identity / policy / authorization / retry / workflow / execution failures. Each failure event in the feed carries a reason_code alongside the free-text reason.
Actionable hint cards + per-code runbooks
Click any reason-code chip to reveal a "What to do" card with the merchant-side next step. Five codes link directly to dedicated runbook pages today; the rest will gain runbooks as we encounter the patterns. Hint text is written for the merchant operator, not the engineer.

Added — Decision visibility (foundation)

Authorization decisions are now recorded with evidence
Every policy evaluation — both allows and denies — records the structured inputs the gate saw, the rule that matched, and the verdict. The data exists so future surfaces can answer "why was this allowed?" not only "why was this denied?". Today this is durable groundwork; merchant-facing decision-detail UI follows as design-partner conversations shape it.

Fixed

Lineage panel no longer 404s on Base x402 intents
A timestamp-tie edge case could push a descendant row ahead of the intent itself in the chronological ordering. The intent is now structurally prepended, making the "events[0] is the intent" invariant true regardless of millisecond ties.

Notes

No webhook contract changes. Existing integrators see no changes in their webhook payloads. New attribution and decision data is exposed through dashboard API surfaces only.
1.0.0 2026-05 stable contract · pilot

The first contracted, stable /v1 API surface — the shape design partners integrate against. All fields, error codes, and header names under /v1 are locked.

Added

/v1 API surface (stable contract)
Payment intents, refunds, unlock tokens, merchant onboarding (GNAP interactive grant flow), and an admin audit-log read surface.
API-key authentication on all /v1/* routes
Via the Aiyo-Api-Key header.
Idempotency with byte-identical response replay
Replayed responses do not refresh derived fields — fetch the resource directly for current state.
Stable error codes
Integrations should switch on code, not on message (messages may improve over time).
First Open-Payments-native wallet adapter (GateHub)
Integrated and public-read verified, alongside the interledger-test adapter and a multi-wallet adapter registry.
Durable storage for refund grants and unlock tokens
Postgres-backed and migration-managed, so refund authorization and token revocation survive restarts.
Payer-wallet capture + normalization at the /v1 write boundary
Enabling refunds — Open Payments does not expose the payer wallet to the receiver by default.
Background job rail
Supporting multiple job types, with an idempotency-cleanup janitor as its first consumer.

Core invariant

Verify first. Execute second.
A checkout or intent only reaches settled after settlement is cryptographically verified — the verification returns true or throws, never false. No code path marks something settled without a verified settlement. The Runtime Decision Point emits an authorization artifact or refuses; there is no middle state.