# HIFP — Life-Insurance / DI / LTC Underwriting-Judo Memo v0.1 **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. --- ## Executive Frame (SCQ) **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. --- ## Governing Thought **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: 1. **Data-scope is the primary defense — contract is the backup.** Legal restrictions on carrier use of aggregated data are thin and state-fragmented. What we don't produce cannot be demanded. HIFP's exports must be planning-scenario outputs (numbers, projections, tradeoffs), never raw longitudinal biomarker or claim rows. 2. **"Insurance partner" as a named category is conditional, not confirmed.** The 2026-09-04 three-category commercial framing (specialty healthcare longevity · insurance · employer) holds only if the insurance role is navigation/advocacy/education — never underwriting-adjacent. If a carrier partner asks for underwriting-usable data, that is a category-defining refusal, not a negotiation point. 3. **This becomes a distinctive trust-brand asset, not just a risk mitigation.** If HIFP's public posture is "we do not build underwriting files, we do not partner with carriers on underwriting, and we contract for it" — that is a marketing wedge in a market where Gen X + Boomer skepticism is the primary friction. Turn the risk into the pitch. --- ## §1 · The regulatory landscape (what carriers actually can and cannot do) ### 1.1 · GINA does not cover life / DI / LTC **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. ### 1.2 · State-level restrictions are patchwork and mostly narrow **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. ### 1.3 · Existing carrier signal-consumption is already broad **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. ### 1.4 · NAIC AI Bulletin — guidance, not restriction 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. ### 1.5 · Bottom-line legal posture **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. --- ## §2 · Failure-mode analysis — how the judo actually plays out ### 2.1 · Direct-disclosure failure mode **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. ### 2.2 · Indirect-signal failure mode **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. ### 2.3 · Physician-channel indirect failure mode **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. ### 2.4 · Chain-effect / press-cycle failure mode **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. --- ## §3 · Mitigation options (ranked) ### 3.1 · **Option A — Data-scope architecture (primary defense)** **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." ### 3.2 · **Option B — Contractual + consent firewall (backup)** **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. ### 3.3 · **Option C — Partner-category reshape from "insurance partner" to "coverage navigator"** **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. ### 3.4 · **Option D — Policy engagement and precedent-setting position** **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. ### 3.5 · **Rejected option — pursue an underwriting-side carrier partnership as a revenue source** **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. --- ## §4 · Recommendation for Monday alignment **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: 1. **Data-scope architecture principle** locked into Product Design v3.2 and treated as a Gate (new Gate 8 candidate — subject to Ledger §5.3 gate list decision). 2. **ToS + Privacy + consent-flow language** drafted with counsel before first user onboards (blocking gate on Ledger §5.2). 3. **Partner-category naming discipline** — "coverage navigator" appears verbatim in POV v3.2 and all external materials. "Insurance partner" is retired from HIFP vocabulary. 4. **Public posture statement** published on HIFP's public site by MVP: "HIFP does not build underwriting-usable exports of your data, and does not partner with life / DI / LTC carriers in any capacity that routes your data toward underwriting decisions. Ever." 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. --- ## §5 · Open items owed before external publication **VERIFY-flagged rows for Brandon-with-web-access (2 hours):** 1. Florida SB 1189 (2020) — current status, scope, and whether extended to "genetic information" narrowly or derived phenotypic data. 2. NAIC state-by-state matrix — which states currently restrict aggregated health/wearable data in life / DI / LTC underwriting; timeline of pending expansion. **Counsel-required (post-SAFE):** 3. Draft ToS/Privacy language for Option B (carrier-firewall provisions). 4. Draft standard-of-care disclaimer for HIFP-authored planning outputs used in underwriting. 5. Assess litigation exposure if a user files a "HIFP data used to deny me coverage" complaint — even absent HIFP fault, defense cost and press cycle need modeling. **Product/eng owed for Option A implementation:** 6. Specify the "exportable representation" — what exactly leaves HIFP, in what fidelity, to whom, with what consent event. Feeds Product Design v3.2 §Data Export. 7. Design the alternative-share pattern for users who legitimately want to share raw data with fiduciaries (redirect to source systems). --- ## §6 · What this memo does not resolve - **The direct-question adversarial vector** — a user could still be *asked* by a carrier "do you use HIFP" and answer honestly. HIFP posture doesn't change that. Users electing HIFP membership accept that data-exposure risk implicitly; the counter is that HIFP membership does not *worsen* their file relative to non-membership, which Option A ensures. - **The APS indirect-channel risk (§2.3)** — mitigated only by physician-partner discipline (contractual and educational). Ledger row owed: "physician-partner APS-hygiene protocol" — feeds Chain Partnership Playbook. - **Future carrier acquisition of a HIFP-comp (Superpower / Function / etc.)** — if a carrier buys an aggregator, the acquired user base is fully exposed. Doesn't affect HIFP directly but affects the demographic's aggregator-trust posture. External to HIFP's control. --- *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]].*