You scheduled the demo last Friday. You spent two hours customizing the ruleset — replaced the company name, populated the empty dashboard, dialed in the chart data, scripted the pre-demo cleanup. You sent the prospect a viewer link this morning.
Sometime between then and now, the product shipped a release. The "Dismiss" button moved one level deeper in the DOM. The stores list got a redesign and your selector no longer matches. The pricing-page banner that wasn't there yesterday is now covering your hero CTA.
Scheduled checks can catch this before demo day; a session-boot check runs again in the background without holding up the viewer.
The baseline problem
Every rule in a MyAISE demo targets something — a JSON path like $.dashboard.metrics[*].value, a CSS selector like .stores-list li, a click target for a pre-demo action. Selectors break for two reasons:
- The underlying app ships a refactor — class names change, components reshuffle, accessibility attributes get added.
- The selector was always brittle — it matched the right element on the day you wrote it, but only by accident.
The traditional fix is a frantic re-record session ten minutes before the call. We didn't want that to be the demo workflow anymore.
What we capture at rule-write time
The moment you finish a click-to-edit interaction or accept an AI-suggested rule, MyAISE snapshots a rich baseline of the targeted element:
- A ranked list of selector candidates — the primary selector you used, plus role-based, label-based, and structural fallbacks.
- The element's accessible name, ARIA role, and any test IDs.
- The element's bounding box at the time of capture (page-relative, viewport-relative).
- A full-page screenshot of the captured page — one per step, shared by that step's overlays.
This baseline is enough that the AI can answer the question "given how this element used to look and this new page, where did it go?" — even when every CSS class has changed.
Healing in the background
When a Team viewer session starts, MyAISE validates the demo's anchors in the background — in a sandboxed browser inside our cloud, running against the same rule-transformed pages your viewer serves. The viewer opens immediately; the check runs alongside it, and scheduled drift checks repeat the same walkthrough on the cadence you set (or on demand).
The healing model gets stored baseline metadata (selector candidates, role, accessible name, geometry) plus a bounded set of structural descriptors from the live page's closest candidate elements. Viewer-session healing can also include the stored baseline and current screenshots; scheduled runner healing uses descriptors. Neither path receives raw DOM. The model returns a new selector and a confidence score. At or above your workspace's auto-apply threshold, verified fixes from a complete, reproducible check can auto-apply and persist as a new ruleset revision — your local desktop app and any sharing teammates receive the committed fix via WebSocket.
"A background check should earn trust by proving each selector on the live, rule-transformed page — and by asking for review whenever it cannot reproduce the demo state."
— MyAISE self-healing design principle
What it doesn't do
Self-healing is conservative on purpose. It will not:
- Auto-apply a patch below your workspace's auto-apply threshold (configurable in drift settings). Below it, the finding lands for review and the demo owner is notified instead.
- Execute your demo's pre-demo or entry actions during background checks. Steps gated on actions are flagged for review rather than guessed at — a check that can't reproduce the action-driven state never auto-applies a heal from it.
- Heal the intent of a rule. If the page restructures so that the data we were rewriting is no longer there, no selector exists to swap to — the rule needs your judgement.
- Run on real customer accounts. MyAISE demos are built to run against data faked by your proxy rules, and background checks apply those same rules, so the pages the checker sees reflect the faked values your rules cover.
How much it changes the SE workflow
Before self-healing, a MyAISE demo had two failure modes. Either it broke in the office the morning of the call (annoying but recoverable), or it broke during the call (career-defining). Both happened often enough that careful SEs would re-record demos before every important pitch.
With self-healing, the failure modes change. The demo either works, or you get an email overnight asking you to approve a low-confidence patch. The morning-of scramble disappears. The during-call disasters disappear. The whole workflow shifts toward "set it once, trust it."
That, honestly, is the part of the product we're most excited about. The AI rule generation, the cross-browser proxying, the cloud sync — those are all features. The bit where a demo just doesn't break anymore is the bit that changes how you work.
Self-healing is available on the AI SE plan. The proxy engine and rule format are source available — the healing model uses Anthropic's Claude with a fairly straightforward prompt; the source is in capartist-com/capartist under src/main/llm/.
Ready to try MyAISE?
Free for individuals. Mac app. 5-minute install. No account needed.