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

aiyoplane-spring-ai — AEAP Composition Boundary Adapter for Spring AI, first JVM adapter (October 13, 2026)
Ninth shipped Composition Boundary Adapter, published at github.com/aiyoplane/aiyoplane-spring-ai. Opens the JVM/Java ecosystem. Attaches the AEAP Runtime Decision Point to Spring AI's ToolCallback surface through an @AiyoGated annotation that sits alongside existing @Tool methods — host apps opt in per-tool without touching Spring AI itself. Ships Spring Boot 3 auto-configuration, RuntimeDecisionPoint.createLocalRdp / createHostedRdp factory methods matching the Python packages' shape, an IntentBuilder interface for translating raw args into AEAP Intent payloads, and Ed25519-signed Execution Receipts over RFC 8785 JCS canonical intent. Policy YAML schema (action_type / effect / amount_max) is shared with every other AEAP adapter. Apache 2.0, Java 17+, 1,040 LOC, six passing JUnit tests covering ALLOW / ESCALATE / BLOCK paths and conditional policy matches.
Trust page: Spring AI adapter entry and shipped-adapters count updated to 17 (October 14, 2026)
Added aiyoplane-spring-ai to the AEAP Composition Boundary Adapters catalog on aiyoplane.com/trust. Section count updated from 16 to 17. Subsection description now names JVM alongside Node and Python ecosystems. The adapter list under the Composition Boundary Enforcement credential (§9) is also updated to include Spring AI.
Trust page: Spring AI adapter entry repositioned to reflect Spring AI's native tool-call confirmation shipping (October 18, 2026)
Spring AI merged native tool-call confirmation on October 15 via PR #7157 (milestone 2.1.0-RC1). The aiyoplane-spring-ai entry on aiyoplane.com/trust is updated to position the adapter as composing above native confirmation rather than filling an absent native feature — Spring AI handles the pause/resume, AEAP adds policy-driven ALLOW/ESCALATE/BLOCK semantics and portable receipts. The specific native-confirmation composition surface is in design-spike review; a follow-on release will land once the integration is tested across approve, deny, altered-argument, expiration, and retry conditions. The shipped 1.0.0 works independently of the native mechanism today.
AEAP v0.9.2-DRAFT — §15 Security Model and Responsibility Boundaries (October 8, 2026)
Additive update to the AEAP specification published at github.com/aiyoplane/aeap. §15 codifies the responsibility boundary between AEAP Core, the RDP Implementation, and the Protected Party / Executor; names the properties AEAP Core guarantees; and explicitly names the properties AEAP Core does NOT guarantee — exactly-once execution, pre-expiration revocation of individual receipts, policy correctness, Evidence Signal truthfulness, enforcement exhaustiveness at the Composition Boundary in a given deployment, and complete execution lineage without cooperative Executor participation. No change to receipt format, signing, verification, or canonicalization rules. Conformant 0.9.1-DRAFT implementations remain conformant to 0.9.2-DRAFT. Tag: v0.9.2-DRAFT.
Trust page: Security model & responsibility boundaries section (October 8, 2026)
New section on aiyoplane.com/trust walking the four-question security framework — receipt authenticity, decision integrity, enforcement integrity, operational accountability — and naming the explicit non-guarantees (exactly-once execution, pre-expiration revocation, policy correctness, Evidence source truthfulness) against the responsible party. Public-facing counterpart to AEAP §15.
Blog — AEAP Security Model & Responsibility Boundaries (October 8, 2026)
Narrative walkthrough of the four-question framework, the explicitly-named non-guarantees codified in §15, and the operational security work we're building toward.
AEAP Composition Boundary Adapters — 12 packages across npm and PyPI (October 5-7, 2026)
The first set of AEAP Composition Boundary Adapters, each a thin wrapper around @aiyoplane/mcp-authz / aiyoplane-mcp-authz. Seven agent-framework ecosystems covered: MCP (npm + PyPI), LangChain, LangGraph, OpenAI Agents SDK, CrewAI (Python), Microsoft Agent Framework, Google ADK (Python), and the Claude Agent SDK. Each adapter translates the framework's native tool / node / middleware primitive into an AEAP Intent, invokes the Runtime Decision Point, and composes the ternary verdict — ALLOW, ESCALATE, BLOCK — back into the framework's native control flow. All Apache 2.0, fail-closed on every ambiguous condition. Full catalog on aiyoplane.com/trust.
Blog — The First AEAP Composition Boundary Adapters, Shipped (October 6, 2026)
What a Composition Boundary Adapter is, why we chose a thin wrapper over a per-framework product, which framework each adapter is designed for, who it's ideal for, and how to install it.
AEAP v0.9.1-DRAFT — initial public specification (October 4, 2026)
Initial public draft of the Aiyo Execution Authorization Protocol, published at github.com/aiyoplane/aeap under Creative Commons Attribution 4.0 International (specification) and Apache 2.0 (conformance test vectors). Fourteen sections plus appendices covering terminology and conformance, the Runtime Decision Point, Intent representation, Policy evaluation, Evidence Signals, ternary verdict semantics, Execution Receipt format, JWKS and key rotation, Composition Boundary invariants, rollout discipline, three Interop Profiles (HAP, Okta Cross App Access & ID-JAG, Alibaba/Cisco AOA), and versioning. v1.0 is gated on Appendix A conformance test vectors passing identically against the reference implementations.
Blog — Introducing AEAP and The AEAP Ecosystem — October 2026 (October 4, 2026)
Protocol narrative — why a specification separate from any single implementation, what AEAP guarantees, and how AEAP composes with adjacent efforts (A2SPA, IETF Adaptive Authorization, SCITT Pre-Execution Permit, DRP, EMILIA).
@aiyoplane/verify — offline Ed25519 receipt verifier published to npm (v1.0.1, September 30, 2026)
Standalone verifier for Aiyo execution receipts, published as @aiyoplane/verify under the @aiyoplane npm scope. Any receipt Aiyo issues is now verifiable offline against Aiyo's published JWKS in one command: npx @aiyoplane/verify path/to/receipt.txt. Programmatic import (import { verify } from '@aiyoplane/verify') also supported. Apache 2.0 licensed. Zero runtime dependencies. Ships with typed errors (ReceiptFormatError, ReceiptSignatureError, ReceiptExpiredError, JwksFetchError, UnknownKeyError, UnsupportedVersionError) and a fail-closed posture at every failure mode. Third parties — auditors, downstream systems, merchants' own compliance tooling — can now verify Aiyo receipts without depending on Aiyo being available at verification time.
aiyoplane/homebrew-tap — native macOS install path for the Aiyo verifier (September 30, 2026)
Homebrew tap at github.com/aiyoplane/homebrew-tap. Engineers who verify Aiyo receipts from the terminal without a Node runtime installed can now install with brew install aiyoplane/tap/aiyo. Wraps @aiyoplane/verify as native macOS commands aiyo-verify and verify. Homebrew handles Node as an auto-installed dependency.
Trust surface at aiyoplane.com/trust (September 30, 2026)
Single canonical view of every public Aiyo surface — reference packages, rail adapters, wallet integrations, public demos, engineering research, and corporate identity — each with a status label, a verification date, and a live link where applicable. Written under explicit honesty rules published on the page itself. This is the page to link when someone asks "what has Aiyoplane, Inc. actually shipped?" Grows over time as new surfaces go live.
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 settlement-verified 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.