Happy Charlie Privacy Notice
Version 2026-10-10.1 · Effective on publication after approval
Publication candidate. This version is now the application's legal source. Entity/contact fields and the publication conditions below remain pending; promotion does not approve unresolved legal or vendor issues or change historical consent.
The short version
- Care records, free text, milestones and information about a baby's identity are sensitive information. Pumping records and support messages can also contain a caregiver's health information.
- Happy Charlie does not sell personal or health information or use care records for advertising. We may introduce AI training to improve Happy Charlie, only as permitted by applicable law, obtaining consent where required. No such training program is currently operating; Section 3 explains the conditions before it begins.
- Optional platform speech and Siri services handle information under their own terms. Their handling can include service or model improvement separately from Happy Charlie's planned training. Sections 5 and 7 explain these differences.
- Every current member of your family can see its shared care records. A family administrator can export them. Other people do not need a Happy Charlie account to ask us about their own privacy rights.
- You can delete your account. Shared family records and their recorded attribution may remain; statutory deletion requests are assessed separately from that product control.
- Analytics and crash reporting are not in use. Optional off-device speech is off until enabled; Siri timer/diaper/name access on iPhone and lock-screen feed status are on by default on each phone and can be turned off. Their legal and vendor approvals must be completed before external use.
1. Who this notice is for
This notice covers Happy Charlie's apps, website, support channels and information about the people described in its records. TMIC, Inc. is responsible for the processing described here.
Privacy rights, consent requirements and response obligations apply to the extent required by the law governing the relevant person, information and processing. Applicable law can include federal law and the mandatory laws of a state or other jurisdiction; it is not limited to our governing-law state. This notice describes current practices and planned processing but does not extend a jurisdiction's statutory rights to everyone or guarantee that current features and practices will remain unchanged. Changes remain subject to applicable law and existing obligations.
The service is designed for parents and adult caregivers. A baby is normally the subject of a record, rather than someone signing in. Information about a caregiver, including pumping records and support text, can also be personal or health information. Eligibility and permitted helpers are described in the Terms; Section 10 explains relevant privacy considerations.
2. What we collect, and why
| Category | Information and purpose |
|---|---|
| Account and sign-in | Email address, chosen display name, sign-in codes, session and provider identifiers, and the Terms version/time accepted; to authenticate, maintain access and identify the person to their family. |
| Family and membership | Family membership, role, invitations, attribution and the optional relationship to a baby; to manage access and shared records. |
| Baby profile | Name/nickname, birth date, optional profile photo, and the U.S. state, district or territory the baby lives in; to organise records, identify the selected baby, and know which state's law applies to the family's information. |
| Care records | Feeds, pumping, sleep, diapers, weight, tummy time, manually entered medication/supplement and temperature records, solids/foods, times, values, units, observations and notes; to keep the history the family requests. |
| Milestones, food catalogue and derived information | Recorded or caregiver-added milestones, measured milestones, totals and trends; family food names/types/icons and optional food pictures; retained legacy goal records where present. These organise and describe the family's own history, not a clinical assessment. |
| Imported records | Entries confirmed from a caregiver-selected export file, with their source/provenance. The file is read on the phone/in the browser; the app-controlled copy is temporary and is not uploaded. Imported confirmed entries follow the care-record schedule. |
| Settings and choices | Display units, time/night settings, reminders, activity selections, permission settings, recorded privacy choices and notice acknowledgments; to provide the requested presentation and choices. |
| Push and technical information | Our push token/installation registration for enabled lock-screen status; app/build/platform information and limited operational information needed for service security and reliability. Platform providers also process delivery and technical metadata as explained in Section 5. |
| Support and suggestions | The text you send, staff replies, request status and optional app details you attach. Answer emails and incoming email replies can contain health information; asking you to leave health details out does not prevent receipt. Suggestions are separate from family records. |
We do not ask an account holder's age, date of birth or a separate eligibility answer. Creating an account represents eligibility under the Terms; we record assent, not age. A baby's birth date is a separate profile field.
These are caregiver-entered care records, not a clinical medical record. Information can be consumer health data where it meets the applicable legal definition, including linked physical-health observations or inferences. Happy Charlie's protective handling classification is broader: all care entries and free text receive restricted-data protection even if an individual item is not legally health data. A standalone food name, ordinary photo or generic technical identifier is not automatically consumer health data merely because it appears in this inventory. Optional photos are private profile/food images; we do not use them for face recognition.
Sources include caregivers' app/web entries and support messages, the files they choose to import, chosen sign-in or speech services, and our calculations and operational interactions. We do not buy health data from brokers or obtain care histories directly from other tracker companies.
3. Current practices and planned AI training
- No sale of personal or consumer health data, advertising SDKs, targeted advertising, advertising audiences, data brokers or cross-app advertising tracking.
- Our hosting/support processors must be limited to approved purposes by reviewed terms. Optional speech/Siri provider practices are disclosed separately; enabling a service does not make an unapproved vendor use acceptable.
- No collection of precise location by Happy Charlie, uploading of contacts, health-facility geofencing, session replay, public child profiles or social discovery.
- When a baby is added, the state field is pre-filled with a suggestion from the approximate region Cloudflare derives from the request's network (IP) address. Our servers receive only the country and region for that one request, not the address, and keep neither; only the state you choose and save is stored, and an administrator can change it later.
- Staff access to production information is restricted to an authorised operational reason and audited. We do not provide unrestricted staff access to care histories.
- We do not make solely automated decisions with legal or similarly significant effects about people. Totals and trends describe the family's own records and mark missing data; they do not assess whether a baby is healthy or developing appropriately.
Planned AI training. We may use care records to train and evaluate AI models to improve the accuracy, reliability and functionality of Happy Charlie, only as permitted by applicable law. Where applicable law requires consent, we obtain it before using the information for training, including separate consent for sharing where required.
Happy Charlie does not currently operate this training program. Any introduction is subject to the disclosures, notices, consent and other choices required by applicable law, including identification of the information, specific purposes and recipients where required. Where legally required consent is obtained, we provide the required withdrawal route. Updating this notice does not itself authorise reuse of previously collected information or remove obligations arising from earlier commitments.
4. Sharing inside your family
Every current family member can see the family's shared care records and who entered them. Corrections retain change history. Administrators manage invitations, membership, complete family export and child/family deletion.
Removing a member ends server access on the next request. It cannot recover what that person already read, exported or photographed, and a disconnected phone cannot receive a revocation until it reconnects. Local cache clearing follows the app's access/sign-out controls.
If you leave or delete your account, shared records ordinarily remain. Attribution can retain your recorded display name, marked as a former member; the former membership's other profile information is removed. This product behavior does not override statutory access, correction or deletion rights. Section 8 describes the separate rights route.
5. Other recipients and platform services
The following are the material recipients described by the current architecture. Contract approval and production configuration remain prerequisites to publication, not facts established by this draft.
| Recipient | Role and information |
|---|---|
| Supabase | Database, authentication, API execution and private storage. Receives account, family, profile, care, milestone, food and support information required for those services. Primary production storage: [[PRODUCTION HOSTING REGION — United States intended; verify]]. |
| Cloudflare | Hosts web content and forwards tracker/API requests. TLS terminates there and is re-established to Supabase, so forwarded requests/responses can include care records and session information in transit. It derives the approximate country and region used to suggest a baby's state (Section 3). Its network is global. Static website requests expose ordinary request/technical information; account-level logging and retention must be verified. |
| Resend | Sends sign-in/account/staff-service emails and support answers; receives support email replies. Receives addresses, message content, routing and reply information. Support content may include health information. Its sent/inbound retention and applicable processor terms must be confirmed. |
| Apple, Google, or your Android phone's maker (speech recognition) | Optional off-device recognition when the phone cannot recognise the language locally. Receives audio/recognised words for the entry, which may include child or caregiver health information. The app receives the words and retains the confirmed entry, not a recording. Identify the actual Android service on the device; its own practices may differ. |
| Apple (Siri: App Shortcuts/App Intents) | On iPhone, opens in-app voice entry, can start/stop nursing, pumping, sleep or tummy-time timers, log a diaper change and undo the last Siri entry. Timer/diaper/name access follows the app's Siri setting, on by default with a one-time notice and turned off in Settings → Privacy → Siri. Siri handles the spoken request and answers; the app supplies baby first names and opaque app identifiers as choices, and identifying replies with saved baby/time/values and an entry identifier for Undo/Edit when protected data is available. |
| Apple Push Notification service / Google Firebase Cloud Messaging | Wake enabled phones to refresh lock-screen feed status. Our server sends a push token and a constant wake-up payload with no care record, child/family/account identifier, record type or event time. Providers also process app/delivery/technical metadata; the Android messaging service uses installation identifiers. Event-triggered delivery timing can be sensitive in context. |
| Google / Apple sign-in | Only when selected. The provider processes the authentication request and returns verified identity information. We reduce the supplied name to first name/last initial for the family display, which you can change. We do not send care records or request contacts for sign-in. |
Supabase, Cloudflare and Resend must have reviewed processor terms covering their actual health-data flows. Platform sign-in, speech, Siri and push can also have provider-controlled processing; do not assume everything a platform does is solely on Happy Charlie's instructions.
Apple's Siri handling can include transcript/request-data model improvement separately from its additional audio-improvement setting. See Apple's Siri privacy notice and Improve Siri & Dictation. Review in-app recognition separately from Siri/keyboard dictation; their rules need not be identical.
Google distinguishes Firebase customer data from service data. The latter has additional technical/operational purposes described in Firebase privacy information. A care-free payload is not a promise that the provider receives no other information. Health-data classification and permitted uses for these metadata require the documented review described in our publication checks.
Product analytics and crash reporting are not in use in this version. Any future activation requires an identified, reviewed provider, accurate disclosures and valid consent where required. A present answer to a placeholder future setting is not blanket permission for unidentified future data practices.
We disclose information for legal process or other purposes only where required or permitted by applicable law. Business transfers, new recipients and new purposes remain subject to applicable protection, notice and consent requirements and existing obligations concerning the information.
6. How long we keep things
We retain information for the disclosed purposes for as long as needed and permitted by applicable law. The criteria below apply to information we control. Account deletion does not trigger deletion of every shared category; statutory requests, deletion deadlines and permitted retention exceptions are assessed under applicable law. Internal operating targets are not additional contractual or statutory deadlines.
| Category | Retention and deletion |
|---|---|
| Shared care records, profiles, milestones, family foods and retained legacy goals | Kept to provide the family's requested history while that purpose continues and retention is lawful. Relevant record/child/family deletion and statutory requests determine what is removed. Production and backup deletion follow applicable legal requirements and permitted exceptions. Retained shared attribution follows the associated record. |
| Profile photos / family food pictures | One current image per child/food. Replaced or removed images are removed through the image-deletion process; change history does not retain the old image. Production and backup deletion follow applicable legal requirements and permitted exceptions. |
| Account information, personal settings, reminders and app-controlled privacy records | Kept while needed for the account/choice. Account deletion removes covered information; shared record attribution is distinguished above. Any minimal legally required consent/security evidence retained longer needs a documented basis and period. |
| Our push registrations | Current registration controls remove registrations on status Off, sign-out/revocation, lost access, account/family deletion, invalid token, or after 60 days without refresh. Backup deletion is subject to applicable law. Provider installation/delivery histories have separate retention and deletion processes. |
| Our wake-up queue | Pending wake-up records expire within an hour; they contain no care content, although their internal association/timing remains access-restricted. |
| Invitation links | Current links expire after use or 72 hours. Minimal security records are kept as needed for security and permitted by applicable law, without the invitation token value. |
| Operational logs / security audit records | Kept for troubleshooting, security, incident handling and applicable legal requirements, for periods limited to the relevant need and permitted by law. Logs exclude restricted record content. |
| Support / suggestions | Kept as needed to handle the request, follow up and consider the product suggestion, and for permitted legal or security needs. Relevant closure, account deletion and statutory requests affect retention. A non-identifying suggestion count may remain. Provider email copies follow their applicable retention/deletion arrangements. |
| Import/export/PDF and framing temporary files | App-controlled files are deleted when their import/share/framing step ends. Copies left by a crash/forced closure are cleaned at the next app start. Saved files outside the app are controlled by you and their recipients. |
| Service statistics | Non-identifying, suppressed/rounded aggregate statistics are kept under the documented operational schedule; they contain no care text or individual identifiers. We do not re-identify properly de-identified information. |
Apple controls Siri history outside Happy Charlie. Its notice describes retention up to two years for certain request history, with some reviewed information kept longer; separate Apple settings govern additional retained audio. Google describes installation-ID removal up to 180 days after its deletion process. These provider periods are separate from Happy Charlie's deletion process. Provider practices do not remove our applicable duties to propagate deletion or satisfy health-data law. Their adequacy remains a publication gate.
Retention exceptions and explanations of information retained after a request are governed by applicable law. Information retained solely for legal preservation is restricted to that purpose.
7. Choices and withdrawal
- Analytics/crash reporting: neither is in use. Declining the settings leaves the product available. New activation requires its own review and adequate disclosures/choice.
- In-app speech: typing/buttons work without it. The app asks for microphone permission when you use speech. Supported recognition runs locally; off-device recognition is offered with its own opt-in when local recognition is unavailable. Turn off that permission in Settings → Privacy. Happy Charlie keeps no recording and discards separate parsed text after the entry is saved/discarded; the platform's retention is governed separately.
- Siri: opening voice entry invokes Siri's own handling. Happy Charlie's Siri timer/diaper/name access is on by default on iPhone; a one-time notice says so with a Turn off button, and Settings → Privacy → Siri turns it off or on again. Turning it off stops the app's future timer/name integration; it does not switch off Siri itself or erase Apple's existing history. When iOS protected data is unavailable, app replies are generic. Protected data can be available on an unlocked phone or a phone without a passcode; do not assume a phone without a passcode hides identifying replies.
- Lock-screen feed status: On by default on each phone, showing time and amount; on Android it appears only if notifications are allowed. Settings → Lock screen turns it off or chooses the baby and display level. Anyone holding the phone may see the baby's name and feed timing/details at that level. While on, the phone is registered for provider wake-ups; disabling stops this service and removes our registration. Delivery/background updates can be delayed and are not a medical monitoring service.
- Other reminders: optional local reminders use generic wording. OS permission and app settings control them. A reminder sound can reveal an activity category, even without a name or amount.
- Family display and records: change your display name/relationship; correct records within the applicable product permissions. Administrators can export/delete child or family data; Section 8 provides the separate statutory-rights route.
A permission setting is not automatically legally sufficient consent to every category/purpose. Required consent must precede covered processing, be specific and informed, and be withdrawable. We must confirm consent adequacy and representative authority before offering a covered flow externally.
8. Privacy rights and requests
Depending on applicable law, rights may include confirmation/access and a portable copy, correction, deletion, withdrawal of consent, relevant opt-outs, nondiscrimination and appeal. Our health data notice explains the applicable health-data rights process.
We do not currently sell information, share it for California cross-context behavioral advertising, or use it for targeted advertising or solely automated decisions producing legal or similarly significant effects. Those terms do not mean ordinary family/provider disclosures never occur. We provide legally required responses and honor preference signals to the extent required by applicable law.
How to ask: write to support@happy-charlie.com with the right requested and information sufficient to find/verify the relevant person. You may request for yourself or through a lawful representative, including for a child. No new Happy Charlie account is required. We request only information reasonably necessary to verify identity and authority; product membership is not proof of either. Do not send a full care history or identity document without a specific necessary, secure request from us.
We handle covered requests within the period required by applicable law, using only extensions and exceptions that law permits and providing required notices. For example, Washington's normal health-request period is 45 days from receipt; Nevada starts its health-request period after authentication. Verification does not restart Washington's receipt clock. Where no legal right applies, we may consider a request without committing to a particular outcome or response period.
Appeals: where applicable law provides an appeal right, reply to the privacy contact stating that you appeal. We provide the review, response, reasons and complaint route required by that law. Washington and Nevada require responses within 45 days of appeal receipt. Relevant regulator complaint routes include Washington AG, Nevada AG and Connecticut AG.
We provide the actual health-data recipient/affiliate list and active online contacts when required. The provider-category table is not a substitute for that request-specific list. Information is provided free at the frequency required by law; any fee/refusal for excessive requests is limited to what the law permits and explained.
Self-service account deletion is available in-app and at /delete-account. It removes account information but does not automatically delete shared records or former-member attribution. Statutory rights are evaluated separately, including where you have lost family access or cannot use an administrator-only export. A family role alone does not justify denying a legal right.
9. Security
Server communications use transport encryption; production/staging server storage has the approved at-rest protections. The mobile cache relies on the phone's file protection, not an additional app database encryption layer. Device security and timely cache clearing matter. The web tracker holds its health-record database in the open tab's memory rather than persistent browser storage.
The server checks current family access from the authenticated identity. Web sessions use HttpOnly cookies and a 30-minute inactivity period; mobile session credentials use secure storage and a 90-day inactivity period. Signing out/revocation ends access under the service's session controls. These configuration claims must be verified for the release.
Logs exclude care records, child names, free text, family identifiers, precise event times and raw payloads. Report concerns to support@happy-charlie.com. If notification is required, we notify affected people/regulators and any required media under applicable law. Encryption at rest is not a promise that every incident is exempt from notification.
10. Children and representatives
Accounts are limited by the Terms to people of local majority age or legally emancipated minors. The Terms permit a younger supervised helper on the account holder's session without a separate account, profile, membership or attribution. This does not eliminate possible collection of that helper's own voice or device information. Emancipation does not automatically remove age-based privacy protections.
The app is not designed or marketed to attract children. Adult-provided baby information and information collected directly from an actual minor user require different legal analyses. A report that a child uses the service or has submitted personal information is investigated under applicable law. Contact support@happy-charlie.com to report one or exercise a child's rights. The lawful guardian/representative and known-child consent paths must be confirmed before covered processing; Terms acceptance alone is not a substitute for legally required parental or sensitive-data consent.
11. Health information
We provide the separate Consumer Health Data Notice, including categories, sources, purposes, recipients and applicable health-data rights. Its availability does not extend a jurisdiction's statutory rights to people or processing outside that law's coverage. Washington/Nevada necessity exceptions are assessed flow by flow; other applicable sensitive-data rules may require consent even for core processing.
12. Geography, cookies and preference signals
Happy Charlie is offered for U.S. use. Intended primary database/file storage is in the United States, in the production region identified in Section 5. Cloudflare traffic transit and optional platform services can involve processing elsewhere. U.S. distribution does not mean every provider operation occurs only in the United States.
The tracker uses session/security cookies for sign-in and request protection. Happy Charlie does not embed advertising pixels or cross-site analytics. The current application does not change its operation in response to the browser's Do Not Track signal; the restrictions on sale and advertising apply regardless of that signal. Chosen platform services have their separately disclosed practices. This statement is not a claim that every platform provider never uses technical information across its services.
13. Changes
We post revised notices with their version/effective date and provide additional notice, consent or other choices where and when required by applicable law. A new policy page does not itself authorise a new category, purpose or recipient or remove existing obligations. We obtain fresh affirmative consent where required, including relevant Nevada recipient changes. Replacing a vendor within a broadly named category is not automatically exempt. Existing choices are not relabelled as consent to this revision.
14. Contact
TMIC, Inc.
70 Hemlock Dr.
Holland PA 18966
- Privacy requests and appeals: support@happy-charlie.com
- Security: support@happy-charlie.com
- Support: support@happy-charlie.com
Publication conditions — internal, remove only after completion
- Fill real monitored contacts, entity and production region. Confirm category-specific retention, deleted-image jobs, backup settings, audit exceptions and global routing.
- Approve Supabase/Cloudflare/Resend contracts for all actual flows, including health information in transit/support and inbound mail; obtain accepted platform agreements and verify service/installation data, deletion and provider uses.
- Resolve Apple's health-information restriction and Siri's conflict with Regulatory PR-6/§6. This draft discloses behavior; it does not grant a policy exception or contractual permission.
- Complete jurisdiction coverage, required core sensitive/known-child consent, representative authority and minor-user analysis. The current first-entry “Got it” is only an acknowledgment.
- Implement or lawfully staff the rights/appeals/recipient/deletion process in the runbook and name its owners. A future automation milestone does not postpone applicable legal rights.
- Reconcile UI disclosures, Siri acknowledgment, actual Android speech provider, APNs opt-in/withdrawal and release SDK metadata with this version. Do not treat this revision as proof the current controls satisfy consent.
- Verify store declarations, accessible public legal routes, homepage health link, release configuration and source/consent/assent version activation. Record the exceptions listed in the linked conflict register as closed before claiming a match.
- Verify the stated retention criteria against actual configuration and required category-specific disclosures. Where CCPA applies, its notice-at-collection rule requires intended category-specific retention lengths, using criteria only where specifying a length is not possible; supply the actual lengths before covered collection rather than substituting vague criteria. Internal PR-5 operating targets remain unchanged; this candidate does not promise additional public deadlines. Before any AI-training activation, resolve NR-08 and existing notice/Terms commitments; do not claim the revised page alone supplies lawful authority.