/how it works
How moc. thinks without pretending it has the whole story.
Not another confidence-only chatbot. A turn lands, a cautious answer ships, and only selected, provenance-carrying thread receipts may survive into the next turn.
input → safety gate → thread draft → correction check → constrained reply → continuity ledger
text/voice input → risk + abuse checks → observation parser → authority resolver → response synthesis → session graph
Architecture callout
This is the operational sketch we use in reviews: deterministic enough for trust, soft enough for real humans.
Signal route (full turn)
Safety route map
If a gate flags risk, the room hands control to a fixed escalation/review path before any reply leaves.
Entry point: what the room accepts
Text is always the default. Voice and camera are optional, secondary textures.
- Text is the strongest claim source and first-class signal for continuity.
- Microphone can add pacing and hesitation patterns, but never outranks explicit text.
- Face/camera is opt-in only and used only as weak context.
- Nothing goes into long-term continuity unless it passes the thread confidence gate.
Permission copy and prompts
Prompts only appear if they help safety, continuity, or unlock a real task.
- Microphone: what / why now — “voice can help pace long thoughts, and we still keep text in the lead.” Refuse at any time, and chat keeps working.
- Camera: what / why now — “camera can add expression texture for non-urgent context.” Refuse, and the room keeps the same continuity.
- Notifications: what / why now — “only for specific user-owned threads you are already waiting on.” No generic check-ins, ever.
- Biometrics: what / why now — “optional local unlock for returning-users. It never decides any model claim.” Skip, and the room still opens the same way.
What passes to continuity
| Layer | What we do | What never passes |
|---|---|---|
| Ephemeral layer | Current-turn response shaping, tone calibration, and immediate helper suggestions. | Any claim that depends on uncertain or unsupported signals. |
| Continuity candidate layer | Recurring phrases, corrections, goals, and user-confirmed context with a timestamp. | Therapeutic diagnosis, mental state labels, or medical advice claims. |
| Thread ledger | Small thread receipts: what passed, why it passed, and when it should be revisited. | Raw camera stream, raw emotion certainty claims, or uncorrected assumptions. |
Authority and correction logic
moc. is built around one control principle: user intent is the highest authority. Correction is not cosmetic; it is structural.
- User correction marks truth precedence. A corrected item is downgraded until it is reconciled.
- Confidence is explicit. We do not hide uncertainty when it matters.
- Propagation is staged. A correction updates future openings only where that thread would have been used.
- Conservatism over personality. If signal is thin, the room stays honest and under-commits.
assertion → validation → correction → reconcile → thread update → openings recheckedInfrastructure in plain English
- Client layer: web/iOS surfaces capture text first, run a light local UX pass, then send signed payloads.
- Guard layer: hard safety hooks run before and during response construction; this is where crisis routing and risky patterns are intercepted.
- Context layer: the continuity ledger stores what is carryable, not everything that was said.
- Computation layer: response generation is bounded by prompt constraints, provenance checks, and explicit claim boundaries.
- Persistence layer: minimal thread receipts persist, each with provenance so users can inspect what changed and why.
The product is not trying to be a clinician. It is trying to be a consistent room where the next thought lands somewhere it can actually continue.
When it refuses
Refusal is not failure here. It is the default when confidence, context, or safety signal is not sufficient.
Safety refusal
High-risk content and crisis patterns follow fixed escalation paths. This is not improvisation; it is a hard gate.
Uncertain refusal
If the ledger cannot anchor a confident response path, moc. says so and asks for clarity rather than pretending certainty.
Notification copy guard
Notifications never mention generic wellness progress. They only trigger for specific user-owned threads and include a local action path to silence the prompt.