Last updated July 15, 2026

Privacy notice

This notice describes the Home-Office development preview as it exists today. It does not claim data practices, retention periods, certifications, or production features that have not been implemented and verified.

Information you choose to provide

Account and onboarding flows can receive an email address, founder name, company name, Home-Office login password, mission, audience, goals, current challenge, and related workspace answers. The managed-pilot request form can receive a contact email, product or site identifier, recurring operating burden, requested workflow, and the actions you want to keep human-controlled. A Home-Office login password is transformed into a salted PBKDF2-SHA-256 hash before storage; the plaintext password is not stored. Do not submit passwords for other services, API keys, confidential source code, regulated records, or information you are not authorized to share.

How the preview uses information

Submitted information is used to create or locate your workspace, tailor dashboard artifacts to the business brief, maintain an authenticated session, and operate the features you request. Home-Office does not sell personal information and the current site contains no advertising or third-party analytics tracker.

When you generate the no-account free operating brief, the company name, business description, and any optional audience or 90-day goal you enter are sent to the same-origin Home-Office board-preview function so it can compose and return the artifacts. Those brief fields are processed for that response and are not persisted by the endpoint. After a successful response, Home-Office records only one aggregate operating-day completion event with no brief, company, contact, cookie, visitor identifier, IP address, user agent, or referrer. Repeated or automated requests may count, and the total is not treated as people, demand, customers, or revenue.

The managed-service page sends one bodyless, same-origin request so TIMxAI can count an aggregate operating-day discovery signal. The funnel table stores only the fixed event name, operating date, and count; it does not store a cookie, visitor identifier, IP address, user agent, referrer, contact detail, or page payload. Reloads and automated traffic may count, blocked or failed requests may not, and the result is not treated as a count of people, permission to contact, demand, customers, or revenue.

After the free operating brief is successfully copied or downloaded, the page sends one bodyless, same-origin request so TIMxAI can count an aggregate operating-day retention signal. The brief and exported file stay on your device. The request carries no brief, artifact, company, contact, cookie, visitor identifier, IP address, user agent, referrer, filename, or other page payload. Repeated exports may count more than once; blocked or failed requests may not count. This operating signal is not treated as a count of people, customers, demand, or revenue.

After a free brief is completed, its company name, one-line description, optional audience, and optional 90-day goal are kept temporarily in same-tab session storage for up to two hours. If you choose Create a free workspace, the signup and onboarding pages use those device-local facts so you do not have to enter the same brief again; the company name is included in the account request, while the remaining business fields are not sent until you submit onboarding. The workspace handoff is removed after successful onboarding. If you choose the protected-review link, the managed-service page uses the company name and one-line description only to prefill the business name and show prompts for the remaining review fields. The brief context is not sent to TIMxAI by the handoff itself. Clicking the protected-review link sends one separate bodyless, same-origin aggregate event with no brief, identity, contact, cookie, visitor identifier, IP address, user agent, referrer, or other page payload; repeated clicks or automation may count, blocked or failed requests may not, and the signal is not treated as a pilot request, contact permission, demand, a customer, or revenue. The protected-review handoff does not create a cookie or account, and its device-local context is removed after a successful pilot-request submission. TIMxAI receives the pilot form fields only after you complete the form, acknowledge this privacy notice, and press Send.

Storage and service providers

Cloudflare serves the website and its server functions. When production environment variables are configured, account and workspace records can be stored in TIMxAI's Supabase project. A product-scoped, bearer-protected Home-Office proxy can send a limited goal, challenge, and open-question count to a local TIMxAI student model. The model may select only allowlisted action IDs; its prose never ships. Home-Office compiles the briefing from verified workspace facts and validates the result, otherwise it uses its deterministic composer. There is no direct paid text-model fallback in this path. A bearer-protected TIMxAI relay receives the signup email address, founder name, company name, and confirmation-message content, then forwards that message through TIMxAI's internal SMTP server; no external transactional-email API is used for this confirmation. If you deliberately email or submit the managed-pilot request form, TIMxAI receives the contact email, product or site identifier, recurring burden, workflow cadence, visitor-estimated weekly hours, requested workflow, measurable success condition, human-control boundary, and message-routing metadata needed to deliver the request. The form sends those fields through the same bearer-protected relay to TIMxAI's internal SMTP server. The relay recipient and sender are fixed; visitor input cannot choose either address. Inbound mail passes through the company security wall and the pilot-request route is held for owner review without an automatic external reply, enrollment, quote, or payment action. The contact details and request content remain in the protected mailbox; after security release, the operating receipt may retain only the workflow cadence, weekly-hour estimate, whether a success measure was present, and whether those bounded operating facts were complete. It never copies the contact, product identifier, recurring-burden text, requested-workflow text, success-measure text, or human-control text. A private receipt endpoint also accepts body-free operational counts from TIMxAI's Flock product. For internal income verification, a bearer-scoped function in TIMxAI's TICKIN Supabase Edge runtime uses its managed Stripe credential for read-only account, exact Payment Link, checkout-session, charge, balance-transaction fee, refund, and dispute checks. Stripe can provide a payer email for attribution and owner-test exclusion inside that function; the payer email is discarded after calculation and only aggregate-only totals, processing-fee evidence, counts, and hashed account/link identifiers return to the local reporting bot. The function cannot create checkout, change a price, refund, transfer, or request a payout. Provider use must match the environment actually configured for the request.

Sessions and security

The server can issue a Secure, HttpOnly session cookie tied to one workspace. Some older passwordless access code also stores a Supabase session in the browser on that device. To limit automated account, signup-email, and pilot-request abuse, the signup and pilot-request functions temporarily use the client address supplied by Cloudflare as an in-memory rate-limit key inside the serving edge isolate. That key is not written to Supabase, workspace metadata, consent receipts, application logs, or email, and the current limits are not globally durable across every edge isolate. The pilot-request form also uses a hidden honeypot field; a filled honeypot is discarded without sending email. Access controls and tenant checks are intended to prevent one workspace from reading another, but this remains a development preview and is not a substitute for your own security, legal, or compliance review.

Retention, access, and deletion

Home-Office does not publish a fixed retention promise while the product is still under development. You may ask what information is associated with your account, request correction, or request deletion by contacting hello@home-office.ai. We will verify the request before acting and may retain limited records where reasonably required for security, legal, or operational integrity.

Changes

This notice will change as the product's verified data flow changes. A commercial launch requires a fresh factual review and appropriate qualified legal review; generated drafting text is not treated as legal clearance.