Embed MyAISE demos in your own product

The viewer-session feature solves one demo-distribution problem really well: send a link, the prospect explores the customized product in our cloud browser, you watch from their side of the table. We're proud of it. But it doesn't solve every problem — and the one it doesn't solve is the one the last six customer asks all rhymed on.

"Can we put the demo experience in our product? On our customers' accounts? With their data?"

That's a different ask. The viewer is a proxy: we serve the page, we customize the page, the prospect plays in a sandbox we built. The embed library is the opposite shape — your customer's site serves itself, on your customer's own accounts, and MyAISE just renders an overlay layer on top. No proxy, no PII upload, no shadow site. The demo runs in the browser tab they were already in.

One script, every demo

One bundle, one script tag:

It renders the full overlay set — modals, banners, tooltips, spotlights, callouts, hotspots, number badges — with thirteen CSS-keyframe enter animations, the CSS step transitions (blur, slide, zoom, circle), and the full Three.js transition set. Three.js scenes use modern-screenshot for FROM/TO viewport snapshots, and the bundle is zero eval / new Function, so it works under strict CSP without script-src 'unsafe-eval'.

The clever part is per-demo asset packs. The bundle ships a handful of built-in scenes; every other transition, every custom theme and animation a demo uses, is fetched at launch() as a single SRI-verified pack and registered at runtime — the Three.js scene-code arrives as a nonce'd <script>, never eval. So the bundle stays the same size whether a demo uses one built-in wipe or a dozen bespoke marketplace transitions. No "pick the heavy build" tradeoff.

Each demo carries a target_runtime (embed_lite / embed_pro) that drives the studio's transition picker filter and gates which assets are embed-eligible. The paste snippet is the same one script tag regardless, SRI hash already filled in.

What runs in the customer's browser

Overlays mount into a Shadow DOM root with mode: "closed", so the host page's CSS can't reach in and the host page's JS can't reach out. Themes are CSS custom properties — pick from glass / ocean / violet / candy / graphite / sunset, or set color_scheme per demo to recolor any of them for the customer's brand. Animation defaults are per-overlay-type (modals get the rotating portal; tooltips get rise; banners get fade), but any overlay can override with overlay.animation: "elastic" (or any of the other twelve wire ids) for the exact moment you want.

Step transitions sit above all overlay z-indices. CSS variants animate the live DOM. Three.js variants snapshot FROM before navigation, TO after the page has settled (both page-only; overlays are stripped from both captures), render the scene against those textures, then tear the canvas down. Overlays mount after the canvas is gone, with their own CSS enter animations carrying the final visual touch. It's a "transition, then overlays fly in" sequence instead of one bigger swap.

"The demo should feel like part of the product — not a screen-recording the prospect has to imagine themselves into."

— The bar the embed library is built to

Privacy is the part we cared most about during the design. The library does not dispatch synthetic events on the customer's DOM. It does not record the screen. It does not upload PII from the host page. Click capture is overlay-only: only clicks on the controls we render (Next, Back, Dismiss, button overlays) get logged to OpenSearch; the customer's underlying page DOM is invisible to us. If a demo needs to walk the customer through real actions (filling forms, clicking buttons), the desktop studio strips those steps automatically and the embed runtime calls onError({ code: "ACTIONS_NOT_SUPPORTED" }) so your code can fall back to instructions instead.

Drift checks against a test account you provide

Embed demos still need to survive your next release. The drift runner pattern from self-healing demos works the same way here, with one twist: the cloud needs a way to render the page the way the customer's session will. We don't run against real customer accounts — those have PII we have no business reading — so you configure a test account per ruleset in the studio. MyAISE's headless Playwright runner authenticates as that account, walks the demo, and checks every overlay anchor against the live DOM. Selector drift triggers an AI heal at confidence ≥ your team's threshold; the new selector lands in a versioned ruleset revision your sites pick up on the next demo launch.

Two credential modes: encrypted at rest (you paste cookies or headers, we envelope-encrypt with AES-256-GCM and decrypt only at drift-check time) or JWT callback (we POST your webhook at check time; you return a short-lived signed token containing the credentials). Nothing persists in the JWT case. Both modes are TLS-only, lifecycle-bound, and never visible to other tenants.

Strict CSP, optional self-host

The bundle is intentionally evaluator-free. The desktop's transition runtime constructed per-scene update functions via new Function(body), which forces script-src 'unsafe-eval' in the customer's Content-Security-Policy. The embed library does the opposite: built-in scenes are statically bundled, and pack-delivered scene-code runs from a nonce'd <script> the browser parses normally — never new Function. grep new Function dist/capartist.min.js returns zero hits. The locked-down sites — banks, healthcare, anything with a CSP review board — can use it without an unsafe-eval exception.

For the strictest setups, self-host: drop the bundle into your own static directory and point <script src> there. The cloud's RELEASES.json publishes the SHA-384 SRI hash for every bundle artifact; the public docs page (/docs/api#embed-library) generates the matching integrity= attribute for you on every release.

The full transition set, via packs

The bundle hard-codes four scenes for the offline floor: dissolve (shader noise wipe with a violet glow), cube (3D pivot rotation between FROM and TO faces), flip (Y-axis flip with a mid-flip scale dip), and glitch (RGB shift + horizontal-band tearing). The desktop studio's fifty-plus other scenes — cosmic, party, splitflap, blackhole, wormhole — no longer need porting: each one's scene-code rides in the demo's asset pack and registers at launch, so any transition you author in the studio renders in the embed the same way it does in the viewer. Custom marketplace transitions work through the exact same path.

Two transitions we'll never ship in embed: koi (loads an external 3D model file) and tiltshift (mounts a srcdoc iframe with a separate file:// Three.js path). They work great in the desktop viewer; they don't fit the customer-browser model.

The embed library is on the AI SE plan, alongside live viewer sessions, shared rulesets, and AI self-healing. One bundle covers every demo — a demo's target_runtime just gates which transitions are embed-eligible; the rest arrive as per-demo packs. See the docs for the full install + scoping reference, or issue your first publishable key from the studio.