CloseLoop Outcome Management for Alexa+

CloseLoop gives Alexa+ responsibility for the outcome, not just the action.

Comment

Inspiration

When an assistant says “done,” it may only mean that an API accepted a request. The user still needs to know whether the requested change actually happened.

A cancellation request can succeed while a subscription remains set to renew. The user then has to remember the obligation, check the account, follow up with the company and save the evidence.

CloseLoop is an outcome-management layer designed for Alexa+. It keeps responsibility for a consequential request until independent evidence establishes the outcome and helps the user recover safely when the first action is not enough.

What it does

The flagship demo begins with an ordinary request. “Cancel StreamBox before next Friday and make sure I don't get charged again.”

StreamBox accepts the cancellation, but an independent account check shows that auto-renew is still enabled. CloseLoop keeps the request open and continues observational checks without repeating the cancellation.

As the deadline approaches in simulated time, its attention policy determines that the user needs to hear about the unresolved cancellation. It proposes a support follow-up using the saved cancellation details. Repeated notices about unchanged conditions are suppressed.

The follow-up is a new action and requires separate authorization. The original cancellation approval cannot authorize it. After recovery executes, CloseLoop checks the account again. A recovery receipt establishes that the action ran; it does not prove that the subscription was canceled. Qualifying independent evidence must show that auto-renew is off before the cancellation can be verified.

An alternate scenario introduces a simulated $19.99 renewal charge after the cancellation request and deadline. CloseLoop preserves the request, confirmation, execution receipt and observed charge. It can offer an unsent refund-request draft without claiming that a refund was requested or received.

Open Loops shows what the assistant is still handling, whether anything needs attention and what happens next. Resolution Receipts explain terminal outcomes in plain language and let the user inspect the supporting evidence. Both views use authoritative persisted records rather than a separate browser history.

The three outcomes remain Verified, Not completed and Awaiting proof. If evidence is unavailable, the resolution remains open. CloseLoop does not infer success or failure from missing information.

How we built it

CloseLoop uses Python, FastAPI, the MCP Python SDK and SQLAlchemy. Its authenticated Streamable HTTP interface exposes seven tools for creating, confirming, retrieving, listing and rechecking resolutions. Clients cannot write a verdict.

A bounded internal Outcome Contract records the supported cancellation goal, target, deadline, required evidence, prohibited outcome and recovery policy. It does not make arbitrary English executable or give a language model authority over the result.

The original action, provider claim, independent observation, verification attempt and recovery action are distinct records. A deterministic verifier evaluates fresh evidence correlated to the owner, resolution, target and attempt. Internally, PASS maps to Verified, FAIL to Not completed and INCONCLUSIVE to Awaiting proof.

The service confirmation contract uses signed, short-lived, single-use authorization bound to the owner, resolution and canonical action digest. Recovery has its own action identity and confirmation. Rechecks only observe account state and never repeat the cancellation. Terminal outcomes are immutable.

SQLite provides the local repository path. An optional DynamoDB repository implements strongly consistent reads and conditional writes, with behavior tested through Moto. The public Vercel demo runs real CloseLoop code against temporary server-side SQLite state and a simulated provider.

Challenges we faced

The central challenge was keeping execution separate from verification. A provider's success response is useful evidence of an accepted request, but it cannot establish the final outcome.

Recovery adds a separate permission boundary. A proposal cannot authorize execution, a previous approval cannot be reused, and a recovery receipt cannot certify the original goal. Owner, target, action and attempt binding, atomic execution claims and replay protection enforce those distinctions.

Missing evidence also needs its own treatment. An outage must not become a false success or an invented failure. The system preserves uncertainty while keeping the obligation visible.

Finally, persistent attention needs restraint. The user should hear about meaningful changes and urgency, rather than receive the same notification after every check.

Accomplishments

The product demonstrates an accepted cancellation, contradictory account evidence, persistent responsibility, deadline attention, separate recovery authorization, a bounded follow-up and independent reverification. The resulting receipt has inspectable evidence beneath its consumer-friendly summary.

The violation scenario remains useful after a failed outcome by preserving the timeline and offering an unsent next step. The outage scenario demonstrates that unknown information remains unknown.

The documented recovery milestone passed 249 tests with no failures or skips, including browser coverage. Production verification exercised five scenarios signed out at widths of 390, 820 and 1280 pixels. Adversarial coverage includes confirmation replay and tampering, concurrent execution, cross-owner access, forged evidence, client verdict manipulation, recovery binding and notification deduplication. These checks do not establish live Alexa+ or AWS operation.

What we learned

Verification is one step in a longer responsibility lifecycle. Users also need the request remembered, attention when conditions matter, an authorized next action when something goes wrong and another independent check afterward.

Recovery is a separate bounded plan with its own permission and evidence. CloseLoop must be able to say that it does not know yet, even when an action reports success.

What comes next

CloseLoop is intended to sit beneath Alexa+ experiences so users can speak normally without learning MCP or internal verification terminology.

Future integration work would establish live Alexa+ account linking and a trusted confirmation authority, real provider adapters, scheduled delivery of due checks and Alexa Proactive Events delivery for eligible attention events. The current scope remains bounded subscription cancellation and simulated recovery.

Implementation boundaries

The implemented system includes persistent resolution models and repository paths, bounded Outcome Contracts, deterministic verification, target-bound evidence, owner isolation, observational rechecks, attention policies and notification suppression. It also includes recovery proposals and state, separate recovery confirmation, independent reverification, Open Loops, Resolution Receipts and evidence provenance.

The public demo simulates StreamBox, billing observations, time passage, spoken Alexa interaction and demo consent. Its temporary SQLite state expires after 15 minutes or loss of the server instance. The demo does not provide durable production storage or a live Alexa confirmation authority.

Live Alexa+ execution and account linking, real cancellation and billing access, actual refunds, Alexa Proactive Events, a production scheduler, DynamoDB and CloudFormation deployment have not been verified. DynamoDB is Moto-tested. This write-up does not assert AWS bonus eligibility.

Prior CUF concepts informed the verification work, but no CUF source code was copied. CloseLoop's lifecycle, MCP interface, consumer experience and recovery work are documented in the build provenance.

Built With

Share this project:

Updates

Submission history