Biometric Data Retention & Destruction Policy

Operator: Jetpack Properties, LLC d/b/a Jetpack Publishing (a Tennessee limited liability company), Nashville, Tennessee
Service: ReadBy ("the App") — AI-narrated personalized bedtime stories
Governing law: State of Tennessee · Contact: support@readby.app
Effective date: September 1, 2026
Document type: Public written biometric data retention and destruction schedule, published pursuant to Section 15(a) of the Illinois Biometric Information Privacy Act (740 ILCS 14/15(a)) and analogous state requirements.

1. Purpose & Scope

This policy is ReadBy's publicly available written schedule and guidelines for the retention, and for the permanent destruction, of biometric identifiers and biometric information that ReadBy collects, captures, or otherwise obtains. It is published to satisfy Section 15(a) of the Illinois Biometric Information Privacy Act ("BIPA") and to document, transparently, how ReadBy handles biometric data under the other state laws that govern this category of data.

In scope — biometric data ReadBy collects: human voice recordings and the voiceprints (voice models) derived from them, used solely to narrate stories within the App. These are collected only from adults — either the account holder (a parent or guardian, "Account Holder") or an invited adult ("Voice Donor," for example a grandparent or co-parent) — never from children.

Photo-to-avatar pipeline — NOT biometric. ReadBy also lets a user submit a photograph to generate a stylized "paper-cutout" avatar. ReadBy's position is that this pipeline is not a biometric collection: it is image-to-image generative stylization, not facial recognition, and ReadBy derives and stores no recognition-capable facial-geometry template (a "faceprint") and deletes the source photo after stylizing. This position is supported by (a) an engineering attestation verified against the source code (the companion Gemini Photo-Pipeline Engineering Attestation, 2026-06-17) and (b) ReadBy's reliance on Google's standard Vertex AI / Gemini service terms for the vendor side. The pipeline is addressed further in Section 3.2 below and in Section 12 (Positions). This is ReadBy's adopted position (Section 12, item 1). The voice recordings and voiceprints described above remain clearly in scope as biometric, regardless of how the photo pipeline is ultimately classified.

Out of scope: synthesized story narration audio (the spoken-word output generated from a voice model) is a deliverable work product, not itself a biometric identifier; it is governed by ReadBy's general Privacy Policy and data-retention practices, not by this policy.

2. Legal Classification

ReadBy treats human voice recordings and the voiceprints (voice models) derived from them as biometric identifiers / biometric information, and applies the highest applicable standard of care to them. This classification reflects, among others:

• Illinois — Biometric Information Privacy Act (BIPA), 740 ILCS 14. Voiceprints are biometric identifiers under BIPA. BIPA carries a private right of action with statutory damages, which is why the public-schedule, written-release, and destruction-timeline requirements below are treated as strict obligations.
• Texas — Capture or Use of Biometric Identifier Act (CUBI), Tex. Bus. & Com. Code § 503.001. Voiceprints are biometric identifiers; CUBI is enforced by the Texas Attorney General.
• Washington — My Health My Data Act (MHMDA) and Washington's biometric statute (RCW 19.375), which govern biometric and related sensitive data.
• COPPA, as amended (2025) — the federal Children's Online Privacy Protection Rule, which expressly lists voiceprints among biometric identifiers that constitute personal information, and which applies because ReadBy is a child-directed service even though the voice subjects are adults.

ReadBy also honors the biometric and sensitive-data provisions of other state privacy laws (including the California Consumer Privacy Act and the comprehensive privacy statutes of Colorado, Connecticut, Virginia, Oregon, and others) to the extent they apply.

3. What We Collect & The Consent Basis

3.1 Voice (in scope)

Consent basis.

• Account Holder. Voice cloning is optional and sits behind a parental gate (a math challenge that confirms an adult is present) before any voice capture begins. The Account Holder must listen to and explicitly approve a preview before a cloned voice becomes usable; rejecting or cancelling deletes the cloned voice and the underlying recording.
• Voice Donor. An invited adult records on the public page at readby.app/record/<token>. Before the recorder loads, that page presents a written notice and release — what is collected, the purpose, and the retention term — and the Donor must affirmatively accept it. The recording interface does not load and no microphone access is requested until they do, and the Donor may decline. ReadBy retains the affirmation as evidence the release was obtained (Section 12, item 2). The voice does not become usable until the Account Holder approves the preview. The Account Holder warrants that they invited only an adult and had that person's permission to do so.

Written release (Section 12, item 2). The Donor-facing written release described above is the written-consent mechanism BIPA contemplates for the individual whose biometrics are collected. It is presented directly to the Donor, and it is required — it is in addition to, not a substitute for, the Account Holder's warranty above.

3.2 Photo-to-avatar pipeline (NOT biometric)

When a user opts to generate a paper-cutout avatar from a photo, the source photo is sent once to Google Gemini for image-to-image stylization, and is then deleted (deleted immediately when the user approves the generated avatar, with a 30-day automated "janitor" sweep of any abandoned uploads as a safety net). For children's photos, a parental gate precedes camera or photo-library access. The avatar builder also offers a no-photo Manual (trait-picker) path that uses no photograph at all — the clean no-biometric-surface default.

ReadBy does not derive or persist a facial-recognition geometry template (a "faceprint") from these photos. BIPA and analogous biometric laws attach to facial data only if a recognition-capable face-geometry template is created and/or stored. ReadBy's position is that this pipeline is NOT a biometric collection: it is image-to-image generative stylization (not facial recognition), ReadBy stores no faceprint, and the source photo is deleted after stylizing. This position is now supported by an engineering attestation verified against the source code — the companion Gemini Photo-Pipeline Engineering Attestation (2026-06-17), which confirms there is no face-detection, landmarking, embedding, or template code anywhere in the pipeline — and by ReadBy's reliance on Google's standard Vertex AI / Gemini service terms for the vendor side. This classification is ReadBy's adopted position (Section 12, item 1). As a precaution regardless of the outcome, ReadBy maintains strict source-photo handling (single-use, delete-on-approve, 30-day janitor). By contrast, the voice / voiceprint pipeline remains clearly in scope as biometric.

4. Purpose of Collection

ReadBy collects voice recordings and voiceprints for a single purpose: to create a personalized voice model that narrates stories for the children on the relevant account, within the App. We do not use this data for advertising, for profiling, or for any purpose unrelated to producing the user-requested narration. We do not use it to develop or train any general-purpose model; the only model created is the user's own narration voice model, produced by our processor in the cloning step.

5. Retention Schedule

ReadBy does not retain biometric data indefinitely. Retention is bounded both by the active-use rule above and by the destruction outer limit in Section 6.

6. Destruction Policy & Timeline

Consistent with BIPA § 15(a), ReadBy's standing rule is that biometric identifiers and biometric information are permanently destroyed at the earlier of:

(a) the date on which the initial purpose for collecting or obtaining the data has been satisfied — for example, when the user deletes the voice or the account, or the voice is no longer used to narrate stories; or (b) three (3) years after the individual's last interaction with ReadBy.

In addition to that outer limit, destruction is triggered on request:

• User- or parent-initiated deletion. When an Account Holder deletes their account (Settings → Delete My Account & Information) or asks us to delete a specific voice by emailing support@readby.app, or when a Voice Donor (or the Account Holder on the Donor's behalf) asks us to remove a Donor voice, ReadBy deletes the voice profile on the ReadBy side and sends a best-effort deletion request to the processor (Inworld AI) for the associated voice model and any underlying recording.
• Withdrawal of consent. A subject may withdraw consent at any time (Section 8); withdrawal is treated as a deletion request and follows the same path.

ReadBy honors deletion and destruction requests within thirty (30) days.

How destruction at the processor works. The raw recording and the voiceprint reside with the processor (Inworld AI), so destruction of that data happens on ReadBy's request rather than by ReadBy's own hand. ReadBy's position is that it requests destruction from the processor, and does so for every deletion event described above. ReadBy deletes what it holds directly and issues the corresponding deletion request to the processor within the same thirty (30) day window. ReadBy does not warrant a specific processor-side or backup-overwrite window, because that timing is the processor's to state, not ReadBy's. The same approach applies to the photo pipeline processor (Google, Gemini): the source photo is deleted from ReadBy's storage after use, and deletion is requested of the processor.

7. Destruction Method

When biometric data is destroyed:

• On ReadBy systems, the voice profile is removed and the associated reference identifier and SHA-256 hash are deleted, so that the data is no longer accessible or recoverable through the App.
• At the processor, ReadBy issues a deletion request for the voice model and any underlying recording, and relies on the processor's contractual obligation, under the Data Processing Agreement incorporated into its terms of service, to process data only on ReadBy's documented instructions and to delete it on termination. The processor has confirmed in writing that a deletion request removes the voice model and its source recording from its active systems; it has not committed to a backup-purge window, and ReadBy therefore does not state one.
• Backups. Residual copies that may exist in routine, rolling backups are overwritten in the ordinary course of business as those backups cycle; they are not restored to active use.

Destruction is permanent. Destroyed biometric data is not retained in any form intended to permit later re-identification of the subject.

8. No Sale, Lease, Trade, or Profit

Consistent with BIPA § 15(c) and the analogous prohibitions under Texas CUBI and Washington law, ReadBy does not sell, lease, trade, or otherwise profit from any person's biometric identifiers or biometric information. ReadBy derives no revenue from biometric data; voice data exists only to deliver the narration feature the user requested.

9. Disclosure Limits

ReadBy discloses biometric data only as strictly necessary to provide the narration feature, and only to its processor:

• Inworld AI receives the voice sample to create, host, and serve the voice model. Inworld AI acts as a processor on ReadBy's instructions, not as an independent controller, and is bound by the Data Processing Agreement incorporated into its terms of service, which establishes processor (not controller) status, processing only on ReadBy's documented instructions, no sale or sharing, sub-processor flow-down with notice, breach notification, annual audit or report rights, and return or deletion of data on termination. That agreement is general to Inworld's services and does not contain biometric-specific commitments; Inworld offers those only at its enterprise tier (Section 12, item 3).

ReadBy does not otherwise disclose biometric data to any third party without the subject's consent, except where disclosure is required by law, by valid legal process, or as necessary to protect against imminent harm. ReadBy does not disclose biometric data to advertisers, data brokers, or analytics providers.

10. Data-Subject Rights

Any individual whose voice data ReadBy holds — Account Holder or Voice Donor — may:

• Access / know — request confirmation of, and information about, the biometric data associated with their voice;
• Delete — request deletion of their voice profile and the associated model and recording (Account Holders by deleting their account in Settings → Delete My Account & Information, or by emailing support@readby.app to delete a specific voice; Voice Donors by emailing support@readby.app or asking the Account Holder to remove the voice);
• Withdraw consent at any time — withdrawal is treated as a deletion request and follows the destruction path in Section 6.

To exercise any of these rights, contact support@readby.app. ReadBy responds within thirty (30) days.

11. Security

ReadBy protects biometric data using a reasonable standard of care that meets or exceeds the standard ReadBy applies to other confidential information:

• In transit: encryption using TLS 1.2 or higher for all transmission of voice data between the App, ReadBy systems, and the processor.
• At rest: AES-256 encryption for stored data.
• Access controls: access to biometric-related records is limited to the systems and personnel that require it to operate the service.
• Minimization: ReadBy does not persist raw recordings on its own servers; it stores only a reference identifier and a one-way SHA-256 hash.

12. Positions

Four questions were flagged for counsel while this policy was drafted. All four are settled, and ReadBy's position on each is stated below as its current position. If a position changes, this section changes with it.

1. Photo pipeline (Gemini) — not biometric. An engineering attestation verified against the source code (the companion Gemini Photo-Pipeline Engineering Attestation, 2026-06-17) confirms the photo-to-avatar pipeline performs image-to-image stylization only — no face detection, landmarking, embedding or face-template code — and the source photo is deleted after use. On that basis, together with Google's standard Vertex AI / Gemini service terms, on which ReadBy relies for the vendor side, the Section 3.2 classification is not biometric. ReadBy requests deletion from the processor as it does for voice.
2. Voice Donor written release — required, and in place. Before any recording begins, the public Voice Donor page presents a written notice and release naming the biometric identifier collected, the purpose, and the retention term. The recorder does not load and no microphone access is requested until the Donor affirmatively accepts. ReadBy records the affirmation — its version, a timestamp, and a hashed IP address — as evidence that a written release was obtained, consistent with BIPA Section 15(b). This is in addition to, not instead of, the Account Holder's warranty described in Section 3.1.
3. Processor destruction (Inworld AI). ReadBy requests destruction from the processor for every deletion event in Section 6, within the same thirty-day window, and deletes what it holds directly. ReadBy does not warrant a processor-side or backup-overwrite window, because that timing is the processor's to state. A Data Processing Agreement with Inworld AI is in force — it is incorporated into Inworld's terms of service and binds on use rather than by separate signature. It does not, however, contain biometric-specific commitments; Inworld offers those only at its enterprise tier. Inworld has confirmed in writing that cloned-voice source audio is retained for the life of the voice, is not eligible for its zero-data- retention option, and that a deletion request removes the voice model and source recording from its active systems — it has made no commitment as to backups, timing, or a deletion receipt. The processor-side representations in Sections 5 to 7 therefore remain best-effort as to timing and backups, as those sections state.
4. Destruction default window — three years. The three (3) year outer limit in Section 6(b) is adopted as stated, alongside the purpose-satisfied trigger in Section 6(a), which is what governs in ordinary use.

Jetpack Properties, LLC d/b/a Jetpack Publishing · ReadBy · support@readby.app · Effective 2026-08-27