MZN Wake-up with context
A reminder arrives in the context of the day rather than as a disconnected alarm. What matters: timing, permission, user preference and continuity.
Zoyan Experience · Product vision
A companion should feel continuous, not fragmented.
The legacy Zoyan work explored multiple specialist roles. The Phase 3 product architecture reorganizes them as experience surfaces inside one contextual companion.
The scenarios on this page are product-design artifacts. They show intended experience and system relationships; they are not proof that the described capabilities have been deployed.
01 · Experience system
Five surfaces. One continuity layer.
Continuous Companion
Carry the useful context.
Conversation, reminders and context over time connect the other surfaces rather than forcing the user to start from zero each time.
Personal Operations
Calendar, tasks and coordination.
A strong candidate for a bounded early product surface: reminders, scheduling, task context, communication support and confirmation-based actions.
Style & Personalization
Preference can become practical.
Wardrobe, size/fit and style context remain a possible future product surface. The separate style program is intentionally held outside the current Zoyan build.
Business & Decision Support
Help organize a decision.
Source-aware synthesis, preparation and planning — with uncertainty preserved rather than hidden behind confident language.
Wellness & Personal Context
Support without pretending to diagnose.
Sleep/activity context, reminders, approved device signals and user-provided information may be explored. Clinical diagnosis, treatment or medical-device claims remain outside the current public claim boundary.
Commerce / Action
Connect intent to a service.
Shopping, seller response, discovery or other service actions can be routed through Mazzaneh or third parties when permission and product scope allow.
02 · One Day With Zoyan
A legacy scenario, reframed as an experience test.
The earlier Day With Zoyan material is valuable because it forces the product to work across time rather than in one isolated prompt. The sequence below preserves that design intent while avoiding any implication of deployment evidence.
Calendar and preparation
Zoyan surfaces relevant commitments and preparation needs. An early product could stay entirely within personal operations here.
Work / meeting support
Selected context can help prepare a meeting, organize notes or create a bounded draft. Business support remains source-aware and confirmation-based.
Style in context
A future style surface could combine occasion, preference and wardrobe/size context when an independently reviewed style service is available.
Wellness context
Activity, sleep or user-provided wellness information may change reminders or recommendations. This remains wellness support, not medical diagnosis.
Purchase intent becomes an action path
If the user chooses, a request can route toward commerce or services. Mazzaneh is one possible ecosystem, not a requirement.
Outcome updates context
What actually happened can reinforce, weaken or leave unchanged earlier assumptions. One event should not become permanent truth automatically.
Scenario boundary
This day-in-life is a product vision / evaluation scenario. Each moment should eventually be converted into a testable product requirement, permission rule, failure condition and measurable pilot behavior.
03 · Form factor
The ring matters because friction matters.
A voice-first ring can place interaction closer to the moment of intent. But Zoyan's identity should survive if Phase 3 selects an app-first, phone-first or hybrid v1.
Smart-ring direction · candidate interaction architecture, not production hardware evidence.
04 · Next review