The receipt surface your AI product hands its own customers. Licensed as an SDK.
Phase 0 sold the receipt. This licenses the receipt-maker. AYA Receipts Platform is the same three-surface bundle we built for our own agents (redaction proof, GDPR consent verdict with its Article 12 processing-log event, HMAC execution-liveness heartbeat, bound and signed per turn), packaged so your AI company embeds it inside your product and hands receipts to YOUR customers, under your own brand. Counts, verdicts, and ids only, never the underlying data.
Talk to us about embedding receipts
THE PROBLEM
From August 2, 2026, the EU AI Act's GPAI obligations apply and Article 12 record-keeping becomes the operative demand on high-risk AI: systems must automatically record events over their lifetime. That deadline does not land on one company, it lands on every AI company selling into the EU at once, including yours. And the honest state of the art is grim: observability vendors log what happened, GRC suites collect evidence after the fact, and most AI teams are looking at two quarters of building an audit substrate nobody budgeted for. Meanwhile the buyers of your buyers are already asking for proof. Enterprise security reviews now stall on "show me the record of what your agent did with our data", and a vendor who can answer with a contemporaneous, signed, per-decision receipt wins reviews its competitors sit in for months.
HOW IT WORKS
The bundle binds three surfaces to the same turn, at the moment of processing, and seals them:
- the redaction proof, what was scrubbed from the payload before it left the boundary, as counts and categories, never the data itself, - the consent verdict, whether the user allowed this processing, plus the Article 12 processing-log event that records it, - the execution-liveness heartbeat, an HMAC proof that the enforcement actually ran, not just that a log line got written.
Fail-closed end to end: no consent means the processing is blocked and the receipt says so, and a missing surface is declared on the bundle, never dressed up as a green check. The result is a tamper-evident record produced at decision time, as a product primitive, not a reconstruction workflow you run when the auditor calls.
WHAT YOU GET
- the receipt discipline as a component, embedded in your product line, not a consulting engagement and not a two-quarter internal build, - your brand on the receipt, your customers see your trust surface, we license the machinery, - the fail-closed defaults built in, blocked processing produces a receipt that says blocked, - a revenue argument, not just a compliance cost, per-decision receipts are the artifact that clears the security reviews your competitors stall in.
WHO IT'S FOR
AI companies (agent platforms, vertical AI SaaS, healthcare, fintech, and legal AI vendors) that owe record-keeping obligations for what their models and agents do, and would rather embed the receipt surface than build it. Second, RegTech and GRC platforms that want to resell a per-decision trust surface to their own regulated customers. The buyer is the CTO or VP Eng who owns the AI platform, with the Head of Compliance or DPO co-signing. If you only need receipts on your own AYA agents, that is the Phase-0 product (AYA Receipts), not this SDK tier.
PRICING (the ladder)
We price the ladder, not a single number, and every number below is a hypothesis we validate with you, not a commitment.
- Pilot license (hypothesis: $7,500 fixed), a bounded pilot: embed the receipt surface in one product line, one environment, with our engineers on the integration. Proves the bundle renders under your brand before anyone commits. - Usage metered (hypothesis: $50 per 1,000 signed bundles), a production license metered on signed receipt bundles produced by your deployment, with volume bands and a floor. - Platform, resale rights: white-label the receipt surface into products you sell onward, negotiated value-metered terms, annual minimum.
IP is licensed, never assigned. The receipt surface stays ours, the receipts are yours. Any step that takes your money is gated fail-closed and requires explicit human confirmation before it runs, nothing charges silently.
THE PROOF (dogfood)
The capability being licensed runs on AYA itself today, and we will be precise about how much of it: two of its three surfaces are live on AYA right now. Every AYA capability terminates as a verification receipt on disk, every countermeasure writes an HMAC execution-liveness heartbeat, and the redaction receipt rides on AYA's own outbound response envelope. That is the same proof discipline this SDK would embed in your product. The third surface, the consent and Article 12 processing-log store, is authored but not yet wired inside AYA, and we say so here rather than round two-of-three up to done. We built this discipline for ourselves first, under the same deadline you face, and being exact in public about which surfaces are live is the discipline itself.
HONEST NOTE
We would rather under-promise. What exists: the working receipt capability inside AYA (two of three surfaces live, as above) and the committed, quality-gated pattern that defines the bundle. What does NOT exist yet: the SDK. There is no client library, no stable versioned API contract, no packaging, no integration docs, and no external company has embedded anything. The Article 12 store is unwired, so no live signed bundle exists yet even inside AYA. That is exactly why the call to action on this page is a design-partner conversation and not a checkout button: the first partner shapes the API contract with us, and an SDK cannot honestly ship a surface its author has not run end to end on itself. First tests, in order: wire the Article 12 store and produce one live signed bundle on AYA, then define the SDK contract and land one design-partner embed with a receipt of the integration.
Talk to us about embedding receipts
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*