Path B Florist Case Study

Path B is the reference flower shop implementation of Adaptive Experience Architecture, hosted at https://aea.artof.link.

In Plain English: When creating an e-commerce experience powered by conversational AI, you need a realistic testbed to prove that the architecture works under real-world conditions. Path B is our working reference design: a flower shop called Lily's Florist. It demonstrates how a single customer session smoothly adapts between wide desktop monitors and handheld mobile phones without losing cart contents or conversation context.

Reference store (pilot): https://aea.artof.link — default evening demo window daily 20:00–22:00 Europe/Berlin, otherwise down unless woken on demand (short Lambda lease). Not 24/7; not office hours. Off-window visitors get a nice resting HTML page (ALB fixed-response; Probed 2026-09-17). Schedule/wake Lambda automation remains Documented until fully in git and probed.

Knowledge about Path B lives on this site. The shop host serves the store (/ and /florist). It does not publish /native or /framework documentation pages.

What Path B Demonstrates

Path B implements the core AEA formula: Shared Understanding + Domain Services + Outer Harness.

It provides an Adaptive Workspace that changes its presentation depending on the device:

• Desktop (16:9 Widescreen): An interactive, spatial workspace. The customer chats with the florist assistant on one side, while visual tiles (arrangement preview, greeting card note, delivery calendar, and cart total) dynamically appear and update on the other side.
• Mobile (9:16 Handheld): A streamlined, vertical concierge interface (Need → Pick → Pay) tailored for quick thumb scrolling and tap-to-select choices.

Both interfaces share the exact same underlying session, inventory catalog, and business rules. The Android companion is a thin third client of that same store (ADR-017) — not a second catalog and not a second florist app.

The Four Tested Customer Journeys

To verify the store's behavior, we test the shopping flow against four distinct customer personas:

1. Urgent Sam — Same-Day Delivery

Sam needs roses delivered today for an unexpected celebration. The assistant quickly filters the catalog for arrangements currently in the cooler, verifies immediate delivery driver slots, and guides Sam through rapid checkout.

2. Planner Sarah — Custom Arrangement & Message

Sarah is planning a milestone anniversary days in advance. She customizes her order with a keepsake glass vase, luxury satin ribbon, and a heartfelt handwritten card message, using interactive card controls to review and confirm every detail.

3. Loyal Alex — Seamless Session Persistence

Alex adds flowers to their cart, steps away, and accidentally reloads the browser window. Instead of forgetting the cart or restarting the conversation, the session memory instantly restores Alex's selections, occasion context, and active cart.

4. Tracker Chris — Order Status & Florist Escalation

Chris placed an order earlier and wants to know when it will arrive. Chris enters their order reference to see real-time fulfillment status, and taps "Contact Florist" to send an instant note directly to the atelier staff.

Florist staff console (not a second native app)

Staff fulfill orders on the same store host, at /florist in a browser (phone, tablet, or laptop). That page is mobile web, not a separate Play Store app for florists.

What is on the staff page as of 4 September 2026 (when the pilot is up), in plain terms:

• Day windows: Staff Orders can show Today / next 3 days / next 7 days / Delayed / All, with counts on each pill. Contact Florist has its own day windows (looking backward).
• Load more: Long lists page in rather than dumping everything at once.
• Phone layout: Tables collapse; a Details sheet opens the arrangement and card; nav pills wrap so Forecast is not clipped off-screen; tap targets are at least 44 pixels.

A native Android app for florists is a possible later product. It is not current work. The customer companion stays the only native Path B app until shop-floor proof, a hard web/PWA limit, a second Play track the staff will actually maintain, and an explicit go are all evidenced.

Atelier Shift Routine: 4 Daily Steps for Shop Staff

For florists working the shop floor, the daily workflow follows 4 focused steps:

1. Morning Batching (#prepare): Check arrangement tallies (e.g. 5× Classic Rose Dozen) and delivery window splits (Morning / Afternoon). Tap Details ↗ to open the bottom sheet and transcribe the customer's handwritten card messages.
2. Order Fulfillment (#orders): Work through the Today queue. Note channel badges (web vs companion-android) and packaging notes.
3. Inquiry Triage (#inbox): Watch for real-time customer escalations from the Contact Florist button. Tap any inquiry to jump to that customer's shared session context.
4. End-of-Day Review: Switch filters to Delayed to ensure zero missed orders, then check 3 days / 7 days to plan upcoming flower cooler inventory.

The longer florist operator guide lives in the repository. It is not a Pages route. Staff work stays on the shop host at /florist.

Architectural Honesty: Intended vs. Verified

• Pilot uptime (sponsor schedule): aea.artof.link is an evening demo window (daily 20:00–22:00 Europe/Berlin) plus optional on-demand wake with a short lease via Lambda — not always-on Fargate and not 08:00–20:00 office hours. Off-window shop API/healthz probes are expected to fail; the public origin still returns a resting page (ALB HTTPS fixed-response from infra/aws/static/offline.html, ≤1024 bytes) — Probed live 2026-09-17. Phase 1 keeps MSK and NAT running (they do not hibernate with the app services). Schedule/wake Lambda (dso-aea-pilot-uptime) and S3 aea-pilot-offline stay Documented / DSO-owned until in git + probed. This is unrelated to architecture.artof.link (GitLab Pages), which stays as-is. NFR-003 assistant availability (local/fail-closed path) is not this ECS pilot schedule.
• Dual-Viewport Layout: Providing side-by-side desktop and mobile views from a single codebase is the intended architectural design. While responsive CSS has been deployed, a continuous side-by-side video walkthrough recorded simultaneously on both viewports remains Unknown. Path B stays transparently labeled as not fully verified until that dual probe is recorded.
• Payment Processing: Payment is safely handled by a deterministic simulation engine under ADR-016; live credit card processing (Stripe) is deliberately inactive.

Path B runtime map (Archify)

Interactive dual-host runtime map (shop aea.artof.link vs docs architecture.artof.link, plus sleep/wake honesty). Source of truth stays on GitLab main under docs/archify/; the Pages build copies allowlisted HTML into same-origin /archify/.

• Open full page (same-origin Pages after deploy: /archify/path-b-runtime.html) · source HTML · IR JSON · README

Status: Documented documentation aid only — not a Live/isolated production claim. Evening demo window (20:00–22:00 Europe/Berlin) and MSK/NAT phase-1 honesty above are unchanged.

Related Documentation

• System Stack — How the cloud servers, message bus, and mobile clients connect.
• Mobile Companion — Details on the native Android app and Google Play release.
• Project Journal — Stories of real-world challenges, solutions, and hard-learned lessons.
• Architecture Glossary — Plain-English definitions of terms and concepts.
• Framework Home — Return to the overview.