Purpose. Answer the existential question Fatima raised at the 2026-09-04 demo: could life / disability-income (DI) / long-term-care (LTC) carriers require or reach for HIFP-shape aggregated health + financial data during underwriting and use it to price up, exclude, or deny coverage? And if so, what is the mitigation posture that keeps HIFP's trust thesis intact. Date. 2026-09-04 (v0.1 · weekend homework pre-Monday 2026-09-07 alignment) Author. Brandon. Companion artifacts. [[HIFP-session-notes-2026-09-04-demo]] §1.1 · [[HIFP-red-team-v3]] T20 · [[HIFP-insurance-liability-v0.1]] (HIFP's own E&O — distinct from this) · [[HIFP-open-items-ledger-v0.1]] §3.16, §7.15 · [[hifp-life-insurance-existential-risk]] (memory). Status. Draft for Monday alignment. Two claims in §2 are marked VERIFY — human-web research owed before this memo publishes externally.
Situation. HIFP aggregates biomarker + wearable + clinical-record + financial signal into a user-owned longitudinal record. Life / DI / LTC underwriters — unlike health insurers — are not restricted by GINA from using genetic or aggregated health data, are actively expanding the signal set they consume (MIB, Rx-history databases, wearable-tied policies), and already require applicants to attest to and disclose relevant health data at application.
Complication. If carriers begin to require HIFP-shape aggregated exports as part of application disclosure, HIFP users will be systematically worse off than non-users — because our users have a nicely-packaged record we produced. HIFP would become the reason people get denied. One press cycle to that effect kills the trust-brand thesis in the Gen X + Boomer target demographic; recovery is not obvious.
Question. Is the risk real enough to reshape the "insurance partner" category (one of the three Brandon named on-record 2026-09-04), and what mitigation posture is sufficient to keep both HIFP's trust thesis and the insurance-lane commercial opportunity intact?
Answer. The risk is real, not hypothetical, and asymmetric — carriers can and do use aggregated health data for life / DI / LTC underwriting in most states. HIFP does not need to prevent that (we cannot). HIFP needs to make itself non-privileged as an underwriting source through three coordinated moves: (a) data-scope architecture that never produces a carrier-ready export, (b) contractual + consent posture that keeps carrier access user-controlled per-request, (c) partner-category reshape from "insurance partner" to "carrier-agnostic coverage navigator." The three moves, together, are sufficient. Any single one alone is not.
HIFP survives the underwriting-judo risk only if we architect the product so we are not the easiest path a user or carrier can take to build a rich underwriting file — through data-scoping, contractual firewalling, and category-reshape from "insurance partner" to "coverage navigator." Three consequences follow:
Fact. The Genetic Information Nondiscrimination Act (GINA, 2008) prohibits use of genetic information in health insurance and employment decisions. It does not cover life insurance, disability-income insurance, or long-term-care insurance. In those three lines, carriers may (and routinely do) use genetic and health data as an underwriting input.
Implication. The federal floor Gen X + Boomer applicants may assume protects them (from health-insurance experience) does not apply to the three lines most relevant to HIFP's target demographic — exactly the coverage lines where a longitudinal biomarker + wearable + clinical record would be highest-signal.
Florida (2020). SB 1189 — restricts life, DI, and LTC carriers from using genetic-test results in underwriting without express consent per policy. First state to extend GINA-style protection beyond health insurance to these lines. VERIFY: current-year status, any preemption, whether it covers "genetic information" narrowly or extends to derived phenotypic data. [Human web research owed.]
Other states. A handful of states restrict specific data classes (e.g., HIV status, specific genetic markers) for specific lines. Aggregated wearable or self-reported health data is generally not covered. VERIFY: current state-by-state matrix. [Human web research owed — the NAIC Life Insurance and Annuities (A) Committee maintains updated summaries.]
Washington MHMDA. RCW 19.373 restricts collection and disclosure of "consumer health data" by regulated entities but has consumer-consent carve-outs; carrier receipt of user-provided data is not the primary regulated act.
MIB (Medical Information Bureau). Cross-carrier database — when applicants apply, prior application data (including declines, ratings, condition attestations) is shared across member carriers. Applicants sign consent to MIB check as part of standard application.
Rx history databases. Milliman IntelliScript, ExamOne ScriptCheck — carriers pull prescription-history reports at application, typically 5–7 years back, with applicant consent buried in application language. This is the closest existing analog to what HIFP-shape aggregation would produce.
Wearable / behavioral partnerships. John Hancock Vitality (2018+) offered life-insurance discounts tied to Apple Watch data — precedent that carriers want wearable signal and will build direct channels for it. Discount framing rather than penalty framing, but the underlying signal-consumption is the same act.
Attending Physician Statements (APS). Carriers routinely request records from named physicians on higher-face policies. If a user names a concierge/longevity physician who ingests HIFP outputs into their clinical notes, HIFP-derived signal reaches the carrier through the APS channel indirectly.
NAIC Model Bulletin on Use of AI Systems by Insurers (issued 2023, adopted by most states 2024–2026) requires carriers to govern AI/ML underwriting responsibly (bias testing, documentation, human oversight). It does not restrict the data classes carriers may consume. A carrier using HIFP-shape aggregated data through an AI-underwriting model is required to document and govern that use — but is not prohibited from it.
Carriers can lawfully use HIFP-shape aggregated data for life / DI / LTC underwriting in most states today, subject to consumer consent (which is routinely obtained as part of the standard application flow). No pending federal legislation would change this materially in the next 24 months. State-level extensions of GINA to these lines are proceeding one-state-at-a-time and will not create a national floor in HIFP's operating horizon.
Conclusion. HIFP cannot rely on legal restrictions to prevent the underwriting-judo failure mode. Product architecture and contractual posture are the only durable defenses.
Scenario. A life / DI / LTC application adds a question: "Do you use a personal health-data aggregator (Function, HIFP, Superpower, similar)? If yes, please provide a copy of your current record." The user, having signed the standard consent block, either provides it, refuses (which itself is an underwriting signal), or is declined for non-cooperation.
Likelihood. Medium in a 24–36 month horizon; high in a 48+ month horizon if aggregators grow to the point where enough of the applicant pool has them to make the question worth asking. Carriers add application questions when the population penetration justifies it.
Blast radius. Every HIFP user who applies for life / DI / LTC after the question is added is systematically worse off than a non-user. Non-users disclose only what carriers can otherwise pull (MIB + Rx + APS). HIFP users disclose additionally what HIFP has aggregated.
Scenario. Even without a direct application question, carriers surveil for behavioral signals — subscription patterns, public partnerships, LinkedIn profiles mentioning HIFP membership. Presence in the HIFP user base becomes a soft underwriting factor. This is undetectable to the applicant.
Likelihood. Low in the 24-month horizon (population too small); rises with penetration.
Blast radius. Systemic and undetectable — worst-case pattern because the affected users never know why their premium was different.
Scenario. User's concierge/longevity physician (a HIFP partner-side integrator) receives HIFP-derived planning outputs and cites them in the clinical record. On a large-face life policy, the carrier requests an APS from that physician, which now contains HIFP-derived language ("HIFP planning-scenario projections indicate elevated cardiovascular reserve requirement …"). The carrier ingests HIFP signal through the APS channel we did not directly enable.
Likelihood. Medium if partner physicians ingest HIFP outputs into clinical records without care about downstream carrier requests.
Blast radius. User-specific but severe — high-face policies trigger APS review; that user's rating shifts. This is the mode where our partner-side wins (specialty healthcare longevity partnerships) create the underwriting-judo exposure.
Scenario. One user (or one lawyer representing one user) frames a denial as "HIFP data was used to deny me life insurance." Press pickup. Trust-brand collapse in the exact demographic that funds tiered revenue.
Likelihood. Low base rate per user; near-certain over an N of 100K+ users given standard denial rates and typical media pickup dynamics.
Blast radius. Category-existential regardless of underlying legal merit. This is the reason the risk is existential and not just a slow-burn UX problem.
Posture. HIFP's exportable, portable, and shareable representations of user data are planning-scenario outputs only — numbers, projections, tradeoff analyses, the "Plan-Delta" narrative. Raw longitudinal biomarker rows, connected-source claim data, and wearable time-series data are not exportable. They live inside HIFP, powering computation, and never leave in a carrier-usable form.
Why this is primary. What we don't produce cannot be demanded. A carrier asking "provide your HIFP record" receives at most a planning-outputs PDF — non-privileged relative to what the user could have written on a napkin. The signal advantage evaporates.
Cost. Meaningful — restricts the "share with your advisor" and "share with your physician" flows in the same architectural way. Requires deliberate design of what can be exported, in what fidelity, to whom, with what user affirmative consent per event.
Constraint it introduces. Users who legitimately want to share raw longitudinal data with a fiduciary (a physician, an actuary, a family member managing their care) cannot do so through a HIFP export. They have to go back to source systems (b.well, patient portals, wearables) directly. This is a real UX cost and needs deliberate design of an alternative pattern.
Recommendation. Adopt as v3.2 architectural principle. Reflect in Product Design v3.2 §Data Export + Advice-Boundary Whitepaper §Data-Sovereignty section. Add a new gate to the Gate list: "Zero carrier-exportable raw-data feature ships from HIFP in any form."
Posture. HIFP's Terms of Service, Privacy Policy, and per-integration consent flows explicitly: - Prohibit programmatic (API/webhook) integration by any life / DI / LTC carrier as a HIFP-provided export destination. - Require per-event affirmative user consent for any manual export the user could theoretically send to a carrier (with a clear on-screen warning naming the underwriting-use risk). - Disclaim warranty for planning outputs used in underwriting decisions; carrier or applicant using HIFP outputs for underwriting does so with no HIFP-side representation of accuracy for that purpose.
Why this is backup. Contracts bind HIFP's behavior; they do not bind carrier behavior toward the user. A user who wants to share their HIFP data with a carrier can screenshot the app — no ToS can prevent that. But contracts do bind whether HIFP itself facilitates the flow, and set the standard-of-care perimeter for HIFP-authored materials.
Cost. Low direct cost; requires counsel drafting cycle (Ledger §5.2 dep).
Recommendation. Adopt in parallel with Option A. Companion to Data-Lifecycle SLA. Not sufficient alone.
Posture. The third named partner category (per 2026-09-04 three-category framing) is renamed and rescoped. Not "insurance partner." Instead: carrier-agnostic coverage navigator — HIFP-side capabilities are portability warnings (Sindhu's employer-benefits point), coverage-gap identification, comparative-quote question-asking prompts, and consumer-side advocacy content. Zero underwriting-side integrations, zero carrier-side partnerships that would route HIFP data toward underwriting decisions.
Why this is category-defining. The category name broadcasts the posture. "Insurance partner" reads to a sophisticated observer (or a carrier BD team) as "eventually they'll want a co-marketing / co-underwriting deal." "Coverage navigator" reads as "consumer-side advocacy, not a carrier channel." Language shapes the deals people ask us to do.
Cost. Modest — narrows the insurance-lane commercial surface, forecloses some (probably-unattractive) carrier-co-marketing deals. Aligns with the "own the category" audacity Brandon articulated: HIFP is the consumer's tool, not the carrier's channel.
Recommendation. Adopt. Update Ledger §7.15 alignment recommendation from "ratify insurance partner" to "ratify coverage navigator." Update Pivot Log §2.4 to reflect reshaped third category. Reflect in POV v3.2 GTM section.
Posture. HIFP publishes a position paper (as an early chapter of the Advice-Boundary Whitepaper H1 track) on carrier data-use in life / DI / LTC underwriting. Advocates for state-level extension of GINA-style protections to these three lines. Engages with NAIC AI Bulletin implementation. Positions HIFP as the industry voice for user-side data sovereignty.
Why this is second-order. Doesn't change any 24-month underwriting outcome. Does establish HIFP's public posture, generates press cycles that reinforce the trust-brand thesis, and creates policy-side goodwill that pays off in a regulatory-inquiry scenario. Also positions Brandon/Sindhu as expert voices in the category.
Cost. Low direct cost; opportunity cost of Brandon's attention.
Recommendation. Adopt as H1 initiative, not MVP-critical. Sits under §3.17 Ethical Framework as the outward expression of the internal commitment.
Rejected because it defines HIFP as a carrier channel, collapses the trust thesis, and the revenue is not large enough to justify. Even the Vitality-style "discount for good behavior" framing is upstream of the same failure mode — once HIFP is a carrier-facing signal source in any form, the reputational risk lands regardless of user-visible framing. This option is off the table.
Adopt Options A + B + C together. Defer Option D to H1. Reject the underwriting-partner path outright.
Ratify Ledger §7.15 as "coverage navigator" — not "insurance partner" — with the following commitments:
This posture converts an existential risk into a distinctive trust-brand asset — the kind of clarifying commitment Gen X + Boomer skeptics find credible precisely because it forecloses obvious revenue paths.
VERIFY-flagged rows for Brandon-with-web-access (2 hours):
Counsel-required (post-SAFE):
Product/eng owed for Option A implementation:
End of memo. Recommendation for Monday: adopt A + B + C, defer D, reject the underwriting-partner path. Reshape §7.15 from "insurance partner" to "coverage navigator." This is the answer Brandon should walk into Monday advocating for; the trio decides jointly per [[feedback-hifp-joint-decision-framing]].