AIZOYA Keyboard Journeys

Inspiration

A checkout can work with a mouse while a keyboard customer gets stuck. Product teams need evidence showing the attempted route, focus movement, observed outcome, reproduction and correction - without turning one bounded run into a universal accessibility verdict.

What it does

AIZOYA Keyboard Journeys runs mouse and constrained keyboard routes in separate Chromium contexts against an owned fictional store. Teams can inspect every action and focused control, replay saved actions in a fresh context, and export a fixed-template Playwright regression-test draft.

The reusable CI adapter runs customer-owned applications on loopback. Four stable data attributes report controls, selection, completion and outcome. Remote targets and credentials are rejected, Muse is capped at eight requests with no automatic retry, and each pull request receives a reviewable JSON evidence artifact.

Why Meta technology matters

Muse Spark 1.3 is integrated through the Meta Model API with strict structured output and an allowlisted keyboard vocabulary. Muse chooses one permitted key. Playwright executes it. Deterministic store code - not the model - decides whether the task completed.

The strongest verified comparison uses one adaptive fixture. Muse first selected Sand. The application then made Sand unavailable and identified Blue as the remaining valid option. Muse consumed the changed state, selected Blue and completed in six bounded requests with no retry.

We replayed a previously successful five-key route unchanged on that same fixture. It reached Blue but missed the necessary activation and remained incomplete with zero inference. This shows one saved sequence becoming stale; it does not prove every deterministic policy fails. Replay of the successful Muse actions reproduced completion with zero additional model calls.

How we built it

• Meta Model API with Muse Spark 1.3
• Node.js 22 and authored HTML/CSS/JavaScript
• Playwright Chromium and @playwright/test
• GitHub Actions, Docker and Vercel
• Independent application receipts, bounded request accounting and permanent evidence manifests

Challenges and lessons

The hard part was preserving authority boundaries. The model cannot click directly, generate executable code, declare itself successful or silently retry. Negative evidence is preserved, including an obstacle run that did not complete and a disclosed runner-classification limitation.

Verified results

• Adaptive Muse run: six requests, completed, no retry
• Fixed-route counterfactual: zero model calls, incomplete
• Saved-action replay: zero additional model calls, same completed outcome
• Three successful bounded Meta checks plus one preserved incomplete obstacle check
• Automated source, container and Chromium verification
• Public MIT-licensed repository and mobile-responsive deployment

Current scope

This is a hackathon prototype using owned synthetic fixtures. It is not WCAG certification, a customer production benchmark or arbitrary public-site automation. Public live inference remains disabled; the hosted judge flow uses clearly labeled scripted examples and permanent verified Meta artifacts.

Try it

• 2-minute case study: https://meta.aizoya.com/case-study
• Live product: https://meta.aizoya.com
• Source: https://github.com/aizoya/aizoya-meta-keyboard-journeys
• Adaptive result: https://meta.aizoya.com/provenance/meta-adaptive-v1/result.json
• Counterfactual: https://meta.aizoya.com/provenance/meta-adaptive-counterfactual-v1/result.json

Promotional teaser

https://www.youtube.com/watch?v=CcWVfMJIkl0

This 63-second teaser uses an AI presenter and illustrative interfaces. It is supplementary to the actual browser-run evidence and is not an application screen recording.

Built With

• css
• docker
• github-actions
• html
• javascript
• meta-model-api
• muse-spark-1.3
• node.js
• playwright
• vercel