Privacy and provider status
Every disclosure below stays fully rendered on this page: current behavior, later behavior, and the exact retention limits are always present and searchable.
On this page
Collection and sharing boundary
Implemented behavior may keep bounded public-route scroll metadata, a strictly validated /planner session draft and non-content History view, a strictly validated current trip in localStorage after generation as a guest, shared, or saved workspace, and separate browser-local companion progress. Guest and saved current-trip localStorage includes an opaque server-issued exact-envelope save authorization proof or capability; shared workspaces omit it. That proof is not account identity or share authority. A local clear removes it with the workspace. D1 does not store this proof. Share and voter credentials are runtime-only in active page memory or a one-time reveal and are never written to localStorage, sessionStorage, History, the URL, analytics, or logs. Optional fixed-plans text remains memory-only unless explicit session opt-in and same-origin HMAC verification succeed; a trip shaped by that text cannot be persisted without the same consent and verification. The current-trip schema has no dedicated raw-note field, and final validation rejects complete verbatim note reflection while still allowing generated guidance shaped by the note's planning constraints. Deliberate concept and final submissions use the disclosed validated inputs. A final same-origin browser request may carry the authenticated concept pair and full selection for validation, while DeepSeek receives only the chosen structural route projection rather than the alternative route. A deliberate saved-day rewrite sends the saved itinerary and a bounded reason through MichiWise to DeepSeek. DeepSeek, Google OAuth, Maps Embed, affiliates, and Stripe each require exact readiness or configuration plus a deliberate user or runtime action. Readiness, implementation, and local tests do not prove a real provider, restriction, conversion, payment, OAuth, or production success. Generated stops include user-activated, unchecked Google search handoffs and may include an unchecked Google Maps place-search handoff. An optional selected-day Maps embed and affiliate category actions require exact readiness or configuration plus a deliberate user action; they do not claim live directions, fares, inventory, or booking status. Current-trip localStorage may hold an unavailable affiliate state or four signed category contexts. Fresh V2 D1 may keep Better Auth identity and session rows, HMAC owner keys, saved validated envelopes, hashed share credentials including rows retained during downgrade suspension, voter keys, ballots and minute counts, feedback text and optional ratings, skipped-stop and shortlist stop IDs, integer-JPY ledgers including participant names and expense labels, rewrite reservation and quota fingerprints or metadata, and aggregate or fixed-category operational metadata. Any deployed preview is non-production and uses only a fresh V2 D1, never a legacy import. Feedback text and ledger names or labels are persisted free text. D1 does not persist rewrite reasons, AI prompts, provider bodies, browser draft bodies, or raw optional notes. Better Auth session rows may include an opaque session token identifier used with the signed HttpOnly session cookie and browser User-Agent metadata; Google OAuth access and refresh tokens are encrypted at rest and an ID token is not persisted. Raw IP addresses are not stored. Subscriptions remain disabled with no configured price until owner-authorized enablement and configuration. A Stripe call or purchase requires that enablement plus a deliberate Checkout or Portal action. Legacy records are not imported.
Browser storage
Implemented behavior
- Current behavior
- Implemented browser storage may keep bounded public-route scroll metadata. /planner uses the exact sessionStorage key michiwise:v2:planner-draft:2001. Before concepts, that strictly validated draft may contain the safe structured planner command and current step. Optional fixed-plans text is memory-only by default; it enters the draft only after explicit session opt-in and same-origin HMAC derivation and verification. A valid post-concept draft may contain canonical planner input and fingerprint, an opaque concept proof, exactly two validated concepts, the selected structural preimage, and validated final assumptions. That post-concept state is allowed only when no optional text was submitted, or when submitted optional text was explicitly opted into session persistence and verified. Planner History state remains an exact non-content projection containing only kind, step, phase, and revision. The exact localStorage key michiwise:v2:current-trip:2001 may hold only a strictly validated current-trip record after generation: a discriminated guest, shared, or saved workspace with its record time and an envelope with generation ID, generated time, mode, planner fingerprint, planner input snapshot and fixed-plan fingerprint state, final assumptions, the full validated structural selection preimage, first planning base, stays, days, stops, transit, recovery windows, official-search references, and quality flags. Guest and saved current-trip records include an opaque server-issued exact-envelope save authorization proof or capability. Shared workspaces omit that proof. It is not account identity or share authority, is never shown, copied, or placed in the URL or History, and a local clear removes it with the workspace. Share and voter credentials are runtime-only in active page memory or a one-time reveal and are never written to localStorage, sessionStorage, History, the URL, analytics, or logs. That selection preimage retains both reviewed route snapshots, selected index and concept ID, and pair, route, and selection fingerprints; the UI uses its selected route. The current-trip schema has no dedicated raw-note field. Before projection or persistence, final validation rejects a provider candidate that repeats the complete normalized optional note verbatim in a day summary, recovery suggestion, stop title or description, transit guidance, or official-search query. Generated guidance may still incorporate the note's planning constraints without quoting the complete note. When a trip was shaped by optional text, the canonical builder rejects localStorage persistence unless explicit opt-in and HMAC verification succeed. The companion key michiwise:v2:trip-companion:2001 may hold only generation ID, update time, and completed stop IDs; it never mutates trip content. Strict companion restoration returns absent, incompatible, stale-generation, corrupt, or valid rather than guessing. A signed-in account may persist only validated trip envelopes, never raw optional notes. Opening a saved trip writes only a serializer-authorized current-trip record into localStorage under the exact current-trip key. The same current-trip record may include an unavailable affiliate state or four signed category contexts. Those contexts may contain common envelope, generation, timestamp, and proof metadata; flight origin, Japan destination, dates, and traveller count; hotel base query, label, dates, and travellers; activity first-day-base query, label, dates, and travellers; and eSIM only the neutral Japan eSIM query. Signed contexts have a maximum 30-day server acceptance window and are reissued on generation, saved or shared open, copy, and rewrite. A local clear removes them with the workspace.
- Later behavior
- The planner draft stays separate from current-trip localStorage, and neither the current-trip nor companion schema has a dedicated raw-note field. Guest and saved current-trip records may include that opaque save authorization proof until a local clear removes the workspace. Shared workspaces omit it. Share and voter credentials remain runtime-only and are never written to localStorage, sessionStorage, History, the URL, analytics, or logs.
DeepSeek AI
Implemented behavior
- Current behavior
- A deliberate concept submission sends validated planner input, including normalized optional fixed plans when entered, to DeepSeek for exactly two route concepts. A deliberate final submission sends a same-origin browser request to MichiWise carrying the authenticated concept pair and full structural selection for server validation. From that trusted state, the DeepSeek final request sends validated planner input, a server-derived projection containing only the exact chosen structural route with selected index and concept ID plus route and selection fingerprints, final dates and arrival/departure assumptions, and normalized fixed plans when entered. The alternative route snapshot and pair fingerprint are not sent to DeepSeek. Both paid public submissions use configured Cloudflare Turnstile verification and its token before quota or provider work. Fast uses bounded non-streamed generation with at most one correction. Detailed/Pro requires account entitlement and uses a bounded server-only blueprint, canonical rebuild, expansion, and optional repair path within one shared three-call and deadline budget. Raw blueprints, streams, partial trips, and sample results never reach the browser or browser storage. Every provider output is untrusted and must pass strict validation before display or persistence. A deliberate saved-day rewrite sends the saved itinerary and a bounded owner reason through MichiWise to DeepSeek, consumes owner quota, and does not persist raw provider output; failure keeps the previous saved data. A DeepSeek call requires configured readiness plus a deliberate concept, final, or rewrite submission. Readiness, implementation, and local tests do not prove a real DeepSeek call or production success. Operational logs exclude prompts, free text, trip or provider bodies, credentials, tokens, raw identity, and raw IP addresses.
- Later behavior
- A real provider call still requires valid server configuration, bot and quota checks, and explicit owner-authorized external evidence. Deterministic local results do not prove provider readiness or production success.
Google identity
Implemented behavior
- Current behavior
- Implemented Google identity behavior can create fresh Google-only Better Auth identity, session, account, and verification records when Google sign-in readiness is configured. Each deliberate sign-in creates exactly one Google OAuth state whose logical and server validity is exactly five minutes, and the browser state cookie shares that same five-minute validity. That one-time state is stored as a D1 verification row counted against a global cap of 1,024 retained/live verification rows. Only an exact, valid callback consumes its one state, and it does so before the provider token exchange; an invalid or expired callback, a session read, detached background work, any scheduled job, or external cleanup never removes those rows. An expired row may therefore remain physically stored after its logical expiry until a later admitted Google sign-in: each admitted sign-in removes at most the 128 oldest expired verification rows immediately before inserting its own unique state, and fails closed if capacity is still full. Better Auth session rows store an opaque session token identifier used with the signed HttpOnly session cookie; that identifier is not a Google OAuth credential. Google OAuth access and refresh tokens are encrypted at rest. A Google ID token is not persisted. Better Auth IP tracking is disabled and x-forwarded-for is stripped, so a raw IP address is not persisted. Session rows may store browser User-Agent metadata. The caller email is display data only in Better Auth tables and the caller's own session response. Application records use an HMAC-derived owner key, never raw email. Session access expires after seven days. Server sign-out invalidates the current session and does not delete saved trips. There is no self-service account deletion. A Google OAuth exchange requires configured readiness plus a deliberate sign-in. Readiness, implementation, and local tests do not prove a real OAuth exchange, configuration change, or external verification.
- Later behavior
- A real Google sign-in still requires owner-authorized OAuth configuration, exact hostname and origin agreement, and external evidence. Deterministic local identity composition is not that evidence.
Fresh D1 application data
Implemented behavior
- Current behavior
- Implemented fresh V2 D1 behavior may hold Better Auth identity, session, account, and verification rows, with verification rows globally capped at 1,024 retained/live rows; HMAC-derived owner keys; saved validated trip envelopes rather than raw optional notes; hashed share credentials and share metadata, including rows retained during downgrade suspension; pseudonymous voter keys, ballots, vote history, and per-minute vote counts; private feedback text plus optional 1-5 ratings; skipped-stop and shortlist stop IDs; integer-JPY expense ledgers including participant names and expense labels; rewrite reservation and quota fingerprints or metadata; allowlisted aggregate funnel counts and affiliate aggregate fixed-event counts by category for configured-impression, action-requested, and tracked-link-returned, retaining Japan date, category, fixed event, count, and update timestamp; fixed-category or numeric quota, one-use reservation, attempt, and telemetry metadata, including fingerprints; one overwriteable Portal-attempt row per derived owner key that retains only the owner key, its aligned Unix ten-minute window start, the admitted attempt count, and its update time, never raw email, an IP address, a Stripe identifier, a hosted URL, request history, or an attempt ledger, and owner deletion cascades to it; a keyed owner-and-email command-binding fingerprint used only for immutable first-Checkout correlation, not authorization or raw identity; checkout intents that retain a derived owner key, plan and configuration binding, exact return URLs, opaque session and association identifiers, the hosted Checkout URL, and expiry, attempt, lease, reconciliation state, and event watermarks; subscription rows that retain tier and status, opaque customer and subscription identifiers, period, and lifecycle or Checkout watermarks; and webhook rows that retain only event ID, type, time, state, and attempt, lease, or update metadata, not the raw webhook payload. Better Auth session rows may store an opaque session token identifier used with the signed HttpOnly session cookie, and may store browser User-Agent metadata. That session token identifier is distinct from Google OAuth credentials. Google OAuth access and refresh tokens are encrypted at rest. A Google ID token is not persisted. Better Auth IP tracking is disabled and x-forwarded-for is stripped, so a raw IP address is not persisted. Feedback text and ledger participant or expense content are persisted free text. D1 does not persist rewrite reasons, AI prompts, provider bodies, browser draft bodies, raw optional notes, the browser save-authorization proof, raw email, or raw identity outside Better Auth. No D1 retention duration has owner approval. Any deployed preview is non-production and uses only a fresh V2 D1, never a legacy import.
- Later behavior
- Subscription purchase remains inactive until owner-authorized activation. Application subscription, Checkout-intent, and webhook/event tables continue to use derived owner keys rather than raw email, while Better Auth retains the caller identity email as disclosed above, and no legacy rows are imported. Stored checkout-intent, subscription, and webhook rows do not prove a real Stripe call or production success.
Google search and Maps
Implemented behavior
- Current behavior
- Each generated day stop exposes a user-activated exact https://www.google.com search link built from that validated stop's officialSearch query. Clicking it sends the query and ordinary browser request metadata to Google. The handoff is labelled unchecked and does not mean MichiWise fetched or verified the result. A separate user-activated unchecked Google Maps place-search handoff may also open Google Maps search for that exact validated stop. An optional selected-day Google Maps embed may load one fixed transit route for the selected day's displayed stops when a configured browser-visible key with a valid shape is ready. The iframe applies referrerPolicy strict-origin. A Maps Embed load requires a configured browser-visible key plus a deliberate selected-day embed. Readiness, implementation, and local tests do not prove origin transmission, API or referrer restriction, or production success. Without that key, Google Maps iframe directions remain inactive and unconfigured. The embed does not verify transit service, delays, opening hours, or accessibility, and it is not live directions.
- Later behavior
- A real Maps embed still requires an owner-configured browser-visible key, exact host referrer steps, and separately verified API and referrer restrictions. Without that key the iframe stays unavailable; an embed would not verify service, delays, opening hours, or accessibility, and it does not prove referrer restriction or production success.
Affiliate handoffs
Prepared, not active
- Current behavior
- Affiliate categories are unconfigured and inactive until owner-approved provider, template, host, signing, and durable-control values are complete. These public information pages send no category or trip context to an affiliate provider and provide no booking fallback. When a current trip exists, an unavailable affiliate state or four signed category contexts may be stored in current-trip localStorage. Those contexts may include common envelope, generation, timestamp, and proof metadata; flight origin, Japan destination, dates, and traveller count; hotel base query, label, dates, and travellers; activity first-day-base query, label, dates, and travellers; and eSIM only the neutral Japan eSIM query. Server acceptance is at most 30 days. Contexts are reissued on generation, saved or shared open, copy, and rewrite, and a local clear removes them. Rendering a genuinely actionable slot automatically submits that signed context to MichiWise for verification, but not to Travelpayouts before click. The three fixed aggregate events are configured-impression, action-requested, and tracked-link-returned. D1 retains only Japan date, category, fixed event, count, and update timestamp. Signed contexts, route details, returned URLs, and SubIDs are not retained in that aggregate table and are not logged. A configured-slot impression is recorded only for a genuinely actionable rendered category. A deliberate Travelpayouts handoff happens only on one click, posts only the signed context, uses a server-generated SubID, and accepts only a changed HTTPS URL with host exactly tp.media. There is no direct or generic fallback URL. Affiliate actions do not use Turnstile; signed context, burst limits, and fixed durable quota controls apply instead. A Travelpayouts conversion requires configured readiness plus a deliberate click. Readiness, implementation, and local tests do not prove provider activation, conversion, or production success.
- Later behavior
- When a reviewed category is activated, MichiWise sends only allowlisted category context: flight may use origin, destination, dates, and traveller count; eSIM uses only a neutral Japan query. Success requires a changed HTTPS URL with host exactly tp.media; failure returns no direct or generic fallback URL. Real provider activation, conversion, and referrer-restriction verification remain owner-authorized later work.
Stripe
Prepared, not active
- Current behavior
- Subscriptions remain disabled with no configured price until owner-authorized enablement and configuration. A Stripe call or purchase requires that enablement plus a deliberate Checkout or Portal action. Readiness, implementation, and local tests do not prove a real Stripe call, payment, or production success. Billing Portal creation is gated by first-party attempt controls: at most three admitted Portal provider attempts per derived owner key per aligned Unix ten-minute window, admitted Portal provider failures and aborts consume that capacity, and a refused Portal attempt opens no billing page. Checkout is not gated by this row. Public information pages do not send identity, payment, or subscription data to Stripe. After owner-authorized activation, an authorized first-customer Checkout sends the verified account email to Stripe in transit only; raw email is absent from application subscription, Checkout-intent, and webhook/event tables and from operational logs, while Better Auth retains the caller identity email as disclosed in the Google identity section. D1 stores a keyed owner-and-email command-binding fingerprint for immutable first-Checkout correlation only; that fingerprint is not authorization and is not raw identity. Checkout intents retain a derived owner key, plan and configuration binding, exact return URLs, opaque session and association identifiers, the hosted Checkout URL, and expiry, attempt, lease, reconciliation state, and event watermarks. Subscription rows retain tier and status, opaque customer and subscription identifiers, period, and lifecycle or Checkout watermarks. Webhook rows retain only event ID, type, time, state, and attempt, lease, or update metadata, not the raw webhook payload. Stripe-hosted Checkout and Portal handle payment and billing details. They are browser handoffs only after the server returns a validated exact-host URL, and no successful activation is claimed here. Fixed-category operational events contain request IDs, outcomes, and timing only, not raw email, provider IDs or URLs, or payloads.
- Later behavior
- A real Stripe Checkout, Portal, or webhook still requires owner-approved enablement, prices, secrets, and endpoint configuration. Deterministic local billing states do not prove a real Stripe call, payment, or production success.
Retention and deletion
Owner decision pending
- Current behavior
- sessionStorage and browser History follow browser page-session and session-history semantics. localStorage current-trip and companion records persist under browser semantics until a deliberate MichiWise clear or browser action succeeds; no stronger fixed retention period is promised. Deliberate clear attempts the planner draft, current trip, and companion. A local browser clear removes only this browser's planner draft, current workspace, and companion progress. That local clear also removes any guest or saved exact-envelope save authorization proof stored with the current workspace. It also removes any unavailable affiliate state or signed category contexts stored with that workspace. It does not perform server actions. Distinct server actions are: revoke a share; reset votes or skipped stops; delete feedback or the expense ledger; update shortlist stop IDs one at a time; and delete one saved trip. Those server actions do not clear this browser. A browser write failure remains visible. A browser clear error also remains visible and means prior data may remain. Restored planner, current-trip, and companion values are strictly validated; incompatible, corrupt, unverifiable, or stale data is rejected rather than replaced with a sample. Fresh V2 D1 may retain Better Auth identity, session, account, and verification rows, including an opaque session token identifier used with the signed HttpOnly session cookie and browser User-Agent metadata; HMAC-derived owner keys; saved validated trip envelopes rather than raw optional notes; the aggregate or fixed-category operational metadata described above; the first-Checkout command-binding fingerprint; checkout intents; subscription rows; webhook metadata; and the single overwriteable Portal-attempt row described above, which is rewritten in place each aligned window rather than accumulated into request history. Google OAuth access and refresh tokens are encrypted at rest and a Google ID token is not persisted. Raw IP addresses are not persisted. Google OAuth verification rows are removed only by use: an exact, valid callback consumes its one state before the provider token exchange, while invalid or expired callbacks, session reads, detached background work, scheduled jobs, and external cleanup never delete those rows. An expired row may remain physically stored after its logical expiry until a later admitted Google sign-in, whose insert removes at most the 128 oldest expired verification rows before writing its own unique state and fails closed if capacity is still full. No approved durable D1 retention duration exists. Completed or expired checkout intents and webhook metadata are not promised automatic deletion. Server sign-out invalidates the current session and does not delete saved trips, checkout intents, subscription rows, or webhook metadata. Downgrade suspension retains share rows, hashed credentials, pseudonymous voter keys, ballots, and vote history. Suspended credentials are inaccessible for read, copy, and voting; suspension is not revocation or deletion. Only eligible active or trialing Pro return can reactivate a link, and only while it remains current, unrevoked, and unexpired. Revoking, expiry, or staleness of the active Free share does not rotate a suspended link into the slot. Deleting one saved trip deletes that saved itinerary plus associated sharing, anonymous votes/collaboration, feedback, skipped-stop progress, expense ledger, shortlist/engagement, and rewrite records. There is no self-service account deletion. Legacy users, identities, sessions, trips, shares, tools, counters, quotas, and subscription records are not imported. The legacy database remains separate and untouched pending an owner retention or deletion decision.
- Later behavior
- There is still no approved durable retention schedule. Completed or expired checkout intents and webhook metadata are not promised automatic deletion. Sign-out does not delete them. There is no self-service account deletion. Stripe records remain inactive until separately activated and disclosed.
Fresh accounts and no legacy import
Implemented behavior
- Current behavior
- Every identity, session, and saved-trip record starts fresh. Legacy users, identities, sessions, trips, shares, tools, counters, quotas, and subscription records are not imported or accepted. There is no legacy import, reader, converter, or compatibility path.
- Later behavior
- Any deployed preview is non-production and uses only a fresh V2 D1, never a legacy import. Production, if later authorized, also starts from empty V2 data. Legacy production records remain separate and are not imported.
Activation requirement
This notice describes implemented collection, sharing, retention, and deletion behavior. Review and update it when those behaviors change, or when DeepSeek, Google OAuth, Maps Embed, affiliates, or Stripe is activated or its readiness, restriction, conversion, or payment configuration changes. Deployment itself is not a prerequisite for this notice remaining true. Activation requires readiness plus a deliberate user or runtime action. Readiness, implementation, and local tests do not prove a real provider, restriction, conversion, payment, OAuth, or production success.