Settled directions that shape every capability. Where one supersedes an earlier spec decision it says so; these are the frame within which the requirements below are read.
specs/analytics-and-open-data.specs/analytics-and-open-data.specs/genomics.specs/ai-uses-and-attribution.Defines the entities every other capability builds on, and the one relation that carries the whole system. This capability owns no screens; it constrains all the others. Derived from docs/hackingbiology-project-spec.md §5, extended with the protocol-lifecycle clarifications of 2026-08-04.
The load-bearing relation:
`` Substance → SafetyRule → Biomarker → Measurement → Dashboard ``
"What you take" and "how you are" are the same structure read from two sides.
The system SHALL model what-I-measure, what-I-take, and what-I-want as three distinct, independently versioned entities — TestingProtocol, TreatmentPlan, and Goal — rather than a single fused "protocol" record.
TreatmentPlanTreatmentPlan versionTestingProtocol and Goal are untouched and keep their own version historyGoalThe system SHALL expose Protocol as a read-facing composite of a TestingProtocol + TreatmentPlan + Goal, carrying an origin of curated or community, that is the unit which is published, followed, forked, and copied.
ProtocolThe system SHALL represent every Intervention with an explicit cycle schema — pattern (continuous | pulsed | titration | on-off), on_days/off_days, cycle length, cycles per year, titration steps — not merely a frequency.
The system SHALL support intervention subtypes with their own fields: Substance, Exercise, Device/Therapy, Procedure, Hormonal, and Nutrition/Fasting.
The system SHALL model Biomarker with a role (efficacy | safety | baseline), a collection modality, and three distinct ranges per analyte — laboratory reference, longevity-optimal, and safety threshold.
The system SHALL store each Measurement with date, source, laboratory, method/assay, unit (UCUM), and validation state.
The system SHALL model SafetyRule, AdherenceLog (four states: taken-as-planned | partial | intentionally-skipped | forgotten), and WellnessCheck, and treat them as core, not optional.
analytics-and-open-data)The system SHALL model Cohort (the set of people practising the same protocol) and Study (a self-experiment container with pre-declared endpoints and timepoints).
ProtocolCohortConsolidates three things the scientific and biohacker audience asks first: where AI is used and — crucially — where it is not, which frameworks and external knowledgebases the platform builds on, and the attribution and licensing of prior work. It adopts the published "AI surfaces map" pattern and names the shoulders biohack.it stands on — above all Forever Healthy's Evipedia and AI4L, plus get-based and the open vocabularies. It also makes biohack.it a connector that evaluates, credits and notifies the upstream projects whose data effort it binds together. This capability governs the others; it owns the trust artifact, not a product screen.
The system SHALL maintain and publish a canonical map of every surface where AI is used and every surface where it is deliberately not, so a reader can trust the numbers.
The system SHALL use Forever Healthy's AI4L audit-based-prompting framework for any AI-generated evidence review or evidence data query, rather than ad-hoc prompting.
interventions-and-catalog, biomarkers-and-labs)The system SHALL ensure AI4L-generated reviews and evidence queries conform to biohack.it's strict data normalization — analytes coded to LOINC/UCUM, substances resolved to RxNorm/ATC/PubChem/UNII, outcomes mapped to biomarkers — rather than free-text entities.
interventions-and-catalog, biomarkers-and-labs)The system SHALL integrate Forever Healthy's Evipedia as an external evidence knowledgebase via its MCP server (mcp.evipedia.ai) and public endpoints (/reviews.json, /search.json, /{slug}.md, /{slug}.meta.json), and SHALL attribute Forever Healthy per Evipedia's CC BY 4.0 license wherever its content is surfaced.
The system SHALL align its intervention-evidence structure — conclusion, graded evidence, risk-benefit, ordered citations with PMIDs, review dates — with the Evipedia/AI4L model, so content interoperates and can be reused both ways.
evidence-layer, dashboards-and-doctor-view)The system SHALL maintain a register of reused prior work with its license and attribution, and SHALL keep every integration compatible with the project's AGPL-3.0 license.
get-based (AGPL), LOINC / UCUM / RxNorm / ATC / PubChem / UNIIThe system SHALL maintain a technical evaluation of every reused open-source and open-data component — what it is, its fit, license, maintenance/health, and how it is integrated — with the rationale for use.
data-standards-and-typing, related-initiatives)The system SHALL notify each upstream project whose work is included or built upon, so biohack.it acts as a connector of others' data effort rather than a silent consumer.
A dedicated section documenting the data structures and standards in use and why — the backbone that makes biohack.it's data typed, comparable across people and labs, aggregatable, and scientifically credible. It consolidates the coding and typing discipline otherwise scattered across the modules, for scientific and technical reviewers.
The system SHALL document each data standard in use and why it is used — HL7 FHIR (internal clinical vocabulary), OMOP CDM (research export), LOINC + UCUM (analytes and units), RxNorm / ATC / AIFA (drugs), PubChem / ChEBI / UNII (molecules), CPIC / PharmGKB (pharmacogenomics), the Hallmarks of Aging framework, and gVCF (genomics).
The system SHALL enforce typing discipline — closed enums populated by deterministic code, free text kept separate, and entities resolved to codes — so data is typed rather than free-form.
interventions-and-catalog, biomarkers-and-labs)The system SHALL treat coding (LOINC/UCUM/…) plus method/lab provenance as the precondition for cross-person / cross-lab comparability and open-data validity.
analytics-and-open-data)The system SHALL publish this rationale as a dedicated, maintained section for scientific and technical reviewers.
States publicly what this data can and cannot support, so credibility comes from declared limits rather than from claimed rigour. It carries the project's honest position — self-managed, self-declared, self-selected experimentation, not a clinical trial — the evidence hierarchy that ranks what we hold, the bar a study must clear before the words *distributed trial* are used, and the cultural commitment to negative results.
The honest comparison is not against a controlled trial, which this loses and does not try to win. It is against what exists today: a dose written in prose, a screenshot of a lab report, a spreadsheet nobody else can open.
The system SHALL publish, as a first-class page, that its data is self-managed, self-declared and self-selected, without randomisation, blinding or controlled conditions, and that participants change protocols mid-course, measure irregularly and drop out.
The system SHALL declare and apply an evidence hierarchy — controlled trial > observational > N-of-1 > anecdote — and SHALL state when an N-of-1 is genuinely informative and when it is not.
evidence-layer)The system SHALL publish the criteria a study must meet before it is described as a distributed trial — pre-registered endpoint, shared protocol version, declared timepoints, adherence floor, minimum cohort size, published analysis plan — and SHALL apply the term only to studies that meet them.
The system SHALL phrase aggregate findings as observation, not causation — "among qualifying users exposed to X, the observed change was Y" — and SHALL NOT state or imply that an intervention caused an outcome.
The system SHALL accompany every meaningful number it displays or exports with four things — value, uncertainty, provenance and evidence level — and SHALL suppress or mark as not-determinable any number that cannot carry them.
analytics-and-open-data)The system SHALL accept, display and encourage null and negative outcomes as valid contributions, with the same standing as positive ones.
community-and-social)Governs how the platform reasons about numbers, so that aggregate output is defensible rather than merely computed. It names the threats to validity that self-selected, self-reported longitudinal data carries, separates biological change from analytical noise, and makes uncertainty mandatory. Companion to scientific-method-and-evidence, which owns the declared limits and the phrasing discipline; this capability owns the arithmetic behind them.
The system SHALL declare, and where possible surface or mitigate, the threats to validity carried by its data — confounding, regression to the mean, healthy-user bias, survivor and drop-out bias, selection at entry, measurement error, and multiple testing.
The system SHALL account for regression to the mean when a cohort is defined by an extreme baseline, and SHALL correct or declare multiplicity when several biomarkers or interventions are examined together.
The system SHALL distinguish intra-individual biological variability and assay drift from genuine change, using the method/assay and laboratory provenance stored with every measurement.
analytics-and-open-data)The system SHALL declare missingness and drop-out in any aggregate, and SHALL NOT silently impute values.
The system SHALL express every reported effect with its uncertainty and in the outcome's native units, and SHALL NOT derive a trend from insufficient data.
analytics-and-open-data, "stops instead of guessing")The system SHALL state when a cohort is too small or too sparse to support a comparison, rather than presenting a precise-looking number.
A clearly highlighted, maintained public register of similar initiatives — commercial and non-commercial — across longevity/biohacking data, protocols, and biomarkers, stating what each does, its data and licensing posture, and biohack.it's relationship to it (reuse, complement, differentiate, or contact). Honesty about the ecosystem is a credibility and acquisition surface, and the basis for being a connector rather than a walled garden. (This is the dedicated home for the landscape that was deliberately kept out of the conference deck.)
The system SHALL maintain a register of similar initiatives — commercial and non-commercial — each with what it does, its data/licensing posture, and biohack.it's relationship to it.
The system SHALL classify each initiative's relationship as reuse, complement, differentiate, or contact-upstream.
reuse (see ai-uses-and-attribution)differentiateThe system SHALL surface this register as a clearly highlighted public section and keep it current as the field moves.
Registration, the public profile, onboarding journeys, and the T0 seeding of curated content and invited alpha testers. Server-hosted; no local-first mode. Public-by-default posture starts here.
The system SHALL require a server-hosted account to create or share protocols and measurements; there is no browser-only/local-first mode.
The system SHALL be self-hostable as a full instance under AGPL-3.0 by a technically capable user, seedable from the public OpenData snapshot; this is distinct from a per-user local-first mode, which does not exist.
The system SHALL make a user's profile, protocols and biomarker outcomes public by default, and SHALL present sharing as the expected path while allowing per-item withholding.
genomics).The system SHALL require the user to configure their biological attributes — date of birth (for age), sex, ethnicity, height, and other stable or slowly-changing traits — as specifically as possible, used for sex/age normalization and stratification.
dashboards-and-doctor-view, analytics-and-open-data)The system SHALL strongly invite the user to configure their social and community identities — Telegram, WeChat, Xiaohongshu (RED / "Little Red Book"), other social profiles, and their Rapamycin News forum nickname — surfaced on the public profile.
community-and-social)The system SHALL onboard users around importing lab reports they already have, targeting first value within ten minutes at zero spend, with a persistent multi-step progress indicator.
biomarkers-and-labs)biomarkers-and-labs, analytics-and-open-data)The system SHALL model reputation as two separate axes — verified professional credential (who you are) and data verification (what your measurements show) — and SHALL never fuse them into one score.
The system SHALL support inviting a first cohort of biohackers as alpha testers with real, attributed profiles, so that curated content and early community protocols coexist at launch.
Supports a third-party managing user — a Biohacking Mentor / Longevity Doctor / Longevity Clinic — who supervises and manages one or more users' protocols: administering, measuring, and monitoring on their behalf. Kept deliberately lean: a user signs up on their own and may then assign a manager; if assigned, it is indicated. Builds on existing hooks — TreatmentPlan Physician-Assigned, attributable change events, the doctor view, and the verified-credential reputation axis — so it is additive rather than a rewrite.
The system SHALL support a managing-user role — Biohacking Mentor / Longevity Doctor / Longevity Clinic — able to manage one or more users as a roster.
accounts-and-profiles)The system SHALL let a user sign up on their own and then assign — and revoke — a manager who follows them; assignment is the user's choice and never required to use the platform.
The system SHALL let an assigned manager administer (author/adjust the managed user's TreatmentPlan as Physician-Assigned), measure (enter/import measurements), and monitor (view dashboards), within what the user has granted.
Physician-Assigned with a mandatory reason (see protocols)The system SHALL attribute every managing action to the manager in the tracked change/measurement history, visible to the managed user.
The system SHALL indicate, on the managed user's profile and dashboard, that a manager is assigned and who they are.
The authoring, versioning, and lifecycle of protocols: created from scratch, copied/forked from another user, or imported from an already-running regimen. Protocols are living objects — they change, and every change is tracked. Covers the curated vs community origin and the T0 seeding that removes the chicken-and-egg problem. Discovery and the social act of following are specified in community-and-social; this capability owns the object and its history.
The system SHALL let a user author a Protocol by composing a TestingProtocol, a TreatmentPlan, and one or more Goals, in a builder that does not require all three to be complete before saving a draft.
DraftTreatmentPlansafety-guardrails, measurement-planning)The system SHALL support an onboarding path for an experienced biohacker who is already running a protocol, capturing the current regimen and its historical baseline rather than assuming a clean start. Where the analytic history is hard to reconstruct, the system SHALL accept a coarse free-text lineage note and SHALL flag the record as starting from a summarized, non-analytic history.
in_effect_since ≠ tracked_since; where reconstruction is hard, accept a coarse "how you got here" note AND flag the record as history: synthesized (versus analytic).in_effect_since separately from tracked_since and marks the protocol Active from importhistory: synthesized (not analytic) so downstream analytics can distinguish it (see analytics-and-open-data)The system SHALL let a user copy another user's public Protocol, producing a new protocol that records its forked_from lineage (source protocol + version).
safety-guardrails)The system SHALL version every protocol facet, and SHALL record each change as a tracked, timestamped, attributable event with a mandatory reason.
The system SHALL tag each protocol with origin curated (authored/vetted by the HackingBiology team) or community, and SHALL make origin visible wherever a protocol is shown.
curatedcommunity protocols on top of them (see accounts-and-profiles)The system SHALL let a user publish a protocol public-by-default, while allowing specific measures or interventions to be withheld per-item.
genomics)The system SHALL support protocol lifecycle states Draft | Active | Paused | Completed and SHALL reflect state in discovery and dashboards.
Pausedmeasurement-planning)The system SHALL classify a protocol by level — medical (established, clinician-grade) or research (experimental) — and display the level wherever the protocol appears, so a follower sees what kind of protocol they are copying.
research levelmedical-level protocol is labelled distinctly, with the acknowledgment implication handled in safety-guardrailsThe catalog of substances and the entity-resolution discipline that keeps a multilingual, .it project from silently ignoring what users enter. Owns Substance records, external coding, synonyms, and the input→output diff. Extends spec v0.3 §8.5quater.
The system SHALL resolve every substance to external identifiers (RxNorm / ATC / PubChem / UNII) via a multilingual synonym table, never on raw English strings.
ambiguous and queued for reviewThe system SHALL populate closed enums by deterministic code after validation; free text goes to a separate wide notes field; out-of-enum proposals are marked ambiguous.
ambiguousThe system SHALL always show the diff between what the user submitted and what was recognised.
The system SHALL store per Substance: name(s), external identifiers, class, known interactions, and associated safety markers.
safety-guardrails)The system SHALL run long parsing/extraction jobs in an idempotent queue with resume, never as an interactive request that can time out with quota consumed and no result.
The system SHALL seed and enrich its substance/intervention catalog from Evipedia's interventions and their alternate names (see ai-uses-and-attribution), to bootstrap coverage and multilingual entity resolution.
The system SHALL record, per intervention posology, whether the dosing derives from human or animal experimentation, with its source, so extrapolated dosing is never presented as established.
animal-derived with its sourcehuman-derived (see evidence-layer)The system SHALL include the principal, commonly-used peptides as known substances in the catalog (resolved to codes and synonyms), so peptide-first users find them — handled as ordinary substances, without a peptide-specific subsystem.
The flagship of Phase 1. Analyte registry with mandatory coding, the deterministic import pipeline, manual entry of equal standing, three ranges per analyte, and completeness/freshness. Standalone value: "upload your past lab reports, get your clinical history in graphs, free." The architecture here is what makes open data possible later.
The system SHALL maintain a biomarker registry where every analyte carries a LOINC code and a UCUM unit, and every stored measurement additionally carries its method/assay and originating laboratory.
The system SHALL store and display three distinct ranges — laboratory reference (method-dependent), longevity-optimal (with cited source), and safety threshold — and never collapse them.
The system SHALL attach to every longevity-optimal range its source, reference population, endpoint, evidence grade and last-reviewed date, and SHALL make them inspectable in one interaction from wherever the range is shown. An optimal range without this provenance SHALL NOT be displayed.
community-and-social)The system SHALL make extraction, mapping, and threshold/index computation deterministic and reproducible (same input → same output); the LLM SHALL only produce the plain-language narration, generated once and cached.
The system SHALL import lab data from PDF, photo, and CSV; on recognising a laboratory's format it SHALL generate a deterministic template so subsequent imports from that lab bypass the LLM.
The system SHALL support manual measurement entry as a first-class path, with a sanity check on out-of-range values.
community-and-social)The system SHALL require human confirmation before extracted values enter the system, and SHALL fail loudly on anything not understood.
The system SHALL show, per organ system, how complete and how fresh the data is.
dashboards-and-doctor-view)The system SHALL model biological (aging) clocks as biomarkers with role and provenance, covering both computed clocks and uploaded measured clocks, and SHALL surface them within biomarkers and dashboards.
dashboards-and-doctor-view)The system SHALL compute PhenoAge (Levine 2018) deterministically from its constituent blood analytes, and SHALL include those analytes in the standard blood panel so PhenoAge is computable from routine labs.
The system SHALL accept uploaded biological-clock results — epigenetic clocks (e.g. TruAge and others) and glycation clocks (e.g. GlycanAge and others) — as measurements, with provider, method, date and uncertainty.
The system SHALL maintain an inventory of biological clocks classified by accessibility — computable from existing data, easy to calculate, or purchasable from a reputable provider — to guide which clocks to add.
The system SHALL offer PII obfuscation of imported documents as an option with a reviewable diff; by default the original file is retained raw (the user chooses to obfuscate).
The system SHALL retain the original lab report file and make it public by default in its raw original format, as part of OpenData.
analytics-and-open-data)The engine that turns active interventions into "what to measure, when, and why". Computes the panel, sets phase-dependent cadence, pools analytes into a single blood draw, and treats Overdue as a safety signal rather than a calendar nag.
The system SHALL derive the required panel from the protocol as Safety Core + Δ safety-rule markers of active substances + Δ efficacy markers of goals + optional deep-dives.
The system SHALL schedule denser measurement during initiation/titration and sparser during maintenance, per intervention phase.
The system SHALL pool analytes due within a near window into a single blood draw (set-cover), respecting pre-analytic requirements (fasting, wash-outs, timing).
The system SHALL compute Overdue for due measurements and SHALL express it in safety terms tied to the responsible intervention, not as a generic reminder.
safety-guardrails)PausedThe system SHALL provide calendar, year, and table views, filterable by type × status, with any Study timeline overlaid on the personal calendar.
The module that justifies the project. Baseline gating before following a protocol, automatically inherited safety markers, dose plausibility, interaction and critical-value alerts, and escalation with a ready protocol sheet. Describes what to monitor; never prescribes what to take.
The system SHALL require BOTH (a) the required baseline safety markers to be recorded — by import or manual entry — AND (b) an explicit, logged risk acknowledgment, before a user can set a copied/followed protocol to Active. Neither substitutes for the other.
The system SHALL attach a substance's associated safety markers to the user's measurement plan whenever that substance becomes active — safety is not opt-in.
protocols)The system SHALL compare an entered dose against tolerable upper limit, usual therapeutic dose, and maximum reported-in-literature dose, and flag it on three levels: outside-common-use / above-upper-limit / potentially-toxic. This is numeric plausibility validation, not clinical advice.
The system SHALL raise interaction warnings between active substances and alerts on critical out-of-range measured values, with declared confidence where interaction data is uncertain.
The system SHALL provide an explicit "consult a physician" escalation that produces the protocol sheet ready to hand over (see dashboards-and-doctor-view).
The system SHALL require an explicit, logged risk acknowledgment — accepting the risk knowingly — before activating a protocol that is research level or whose posology is animal-derived, in addition to the mandatory baseline.
protocols, interventions-and-catalog)The thirty-seconds-a-day surface that keeps the platform alive between blood draws, and the source of the adherence signal that makes an N-of-1 interpretable and weights a cohort contribution. Phase 1.
The system SHALL present a daily check-off of intakes with dose and time-slot already resolved from the plan.
The system SHALL record adherence in four states: taken-as-planned | partial-dose | intentionally-skipped | forgotten, and compute daily and cumulative adherence.
The system SHALL capture a daily subjective wellness check — mood 1–5, energy 1–5, sleep hours, sleep quality 1–5, free notes.
The system SHALL make adherence available to analytics so a low-adherence contribution can be down-weighted or excluded.
analytics-and-open-data)The public dashboard and the physician-facing output. Organ-system decomposition, biological-age delta shown honestly, the doctor protocol sheet, and the double-column "literature vs observed" comparison that no competitor can build.
The system SHALL present dashboards grouped by biomarker family (lipids, glucose, kidney, liver, inflammation, hormones, body composition, biological age), each stating why the group is monitored.
The system SHALL provide an organ-system view where the same panel that shows efficacy also shows safety gaps.
The system SHALL lead the personal dashboard with a single headline metric — the biological-vs-chronological age delta — shown with its uncertainty interval and the clock and laboratory declared, followed by the organ-system grid. It SHALL NOT use this metric as a reputation or ranking metric.
The system SHALL present the available biological clocks — computed (PhenoAge) and uploaded (epigenetic, glycation) — as a dashboard group, each with its method/provider and uncertainty; the headline biological-age delta uses a declared default clock.
The system SHALL generate a "protocol sheet" for a physician: everything taken, doses, timing, since when, markers monitored with rationale, trends, and open alerts — as a public link and a PDF.
The system SHALL, per intervention, place side by side what the literature predicts (Evidence Layer) and what the biomarkers of people practising it show (cohort).
evidence-layer, analytics-and-open-data)The system SHALL surface cohort comparison in BOTH forms: (A) a lightweight inline reference on each dashboard tile, AND (B) a dedicated "vs cohort" view with distribution, percentile, stratification, sample size (n), and adherence weighting.
The system SHALL, for every biomarker measurement, report the percentile it falls in, normalized for sex and age against published reference distributions, alongside the reference / optimal / safety ranges, and SHALL declare the published source used.
Following, copying, cohorts, the calculated Evidence Badge, public claim review, two-axis reputation, and data-quality-only gamification — attached to the pre-existing Rapamycin News community rather than launched cold.
The system SHALL let a user follow another user and copy/subscribe to a public protocol, with copying invoking the protocol fork + safety inheritance path (see protocols, safety-guardrails).
The system SHALL keep every intervention — including the most sensitive (peptides, plasmapheresis, IV) — in the public catalog, one-click copyable, with nothing documentable-but-not-copyable, and SHALL present an informed-decision panel at the point of copy.
The system SHALL group users practising the same protocol into a Cohort and let a follower compare against it.
analytics-and-open-data)The system SHALL integrate community with the existing Rapamycin News (Discourse) — via Discourse Connect SSO where feasible, falling back to bidirectional links otherwise — and SHALL treat community as an extension of it rather than a cold-launched social feature.
The system SHALL host N-of-1 Study proposals (research question + endpoints) as community threads open for comment, and SHALL surface the proposal discussion alongside the Study.
studies-nof1)The system SHALL compute reputation from data the system already holds and show its derivation, never a self-declared claim.
The system SHALL make contested claims public, discussed, and traceable — not a private flag to a team.
The system SHALL keep verified-credential and data-verification as separate axes and provide discovery by specialty, not popularity.
The system SHALL gamify only data quality — adherence streaks, panel completeness, documentation continuity — and SHALL NOT rank users by health outcomes.
Makes a self-experiment interpretable by forcing the question and the endpoint to be declared before it starts. The container that later composes into distributed, grassroots trials. Pre-registration costs nothing and disarms the main methodological objection in advance.
The system SHALL model a Study with a research question and endpoints declared before T0, an associated protocol, timepoints (T0 baseline, T1…Tn), a per-timepoint test battery, duration, wash-out, stop criteria, and a pre/post statistical comparison.
The system SHALL feed a Study's timepoints and test battery into the measurement planner and overlay them on the personal calendar.
The system SHALL compute the declared pre/post comparison at completion and present it against the pre-registered endpoint.
The system SHALL require a Study's research question and endpoints to be published as a community proposal — a forum thread open for comments (Rapamycin News / Discourse) — as the act of pre-registration, so that pre-registration serves consensus rather than a private declaration. The questions a Study seeks to answer are themselves subject to community proposal.
community-and-social)Turns a protocol into a supply plan — projected need, batch purchase, inventory, lots and expiry — and links to Pills Management for restock. Daily intake scheduling lives in pills-management. Phase 3. No commercial integration with suppliers in the initial phase — the main conflict-of-interest surface to keep clean.
The system SHALL project consumption from the active protocol and derive batch purchase suggestions with lead time.
The system SHALL track stock, lots, and expiry, and alert on expiring stock.
The system SHALL NOT monetise procurement or embed supplier affiliations in the initial phase.
Orchestrates the daily intake of pills and supplements: which to take, when, how to distribute them across the day, spacing between them, whether with or away from meals, and what a substance needs for absorption (e.g. dietary fat). Links to procurement for restock. This is the daily-intake half split out of the original M4; purchase and inventory live in procurement-and-inventory, and the schedule surfaces in the daily log and the programming calendar.
The system SHALL allocate intakes into day slots optimising bioavailability and avoiding interference and toxicity summation (mineral separation, competing compounds, hepatic load), using a constraint solver rather than an LLM.
The system SHALL model each substance's meal constraints — with-meal, away-from-meals, and any co-ingested substance required for absorption (e.g. dietary fat for fat-soluble compounds) — and reflect them in the schedule.
The system SHALL honour required spacing/distance between compounds (competition, absorption windows) and pre/post-meal distances, or flag an unresolvable conflict.
The system SHALL link pill scheduling to procurement so that low stock triggers a restock action (see procurement-and-inventory).
The system SHALL remain usable and legible for high-volume regimens — dozens to well over a hundred pills per day (e.g. 60–130) — grouping intakes and keeping check-off fast.
The system SHALL surface the resolved pill schedule in the daily log and the programming calendar.
daily-log-and-adherence)measurement-planning)Manages interventions that require a periodic treatment session rather than a pill — red light / photobiomodulation, HBOT (incl. hypoxia-hyperoxia), IHHT (intermittent hypoxia-hyperoxia training), sauna, cold exposure / cold plunge, whole-body cryotherapy, therapeutic plasma exchange (TPE / plasmapheresis), IV infusions (e.g. NAD+, vitamins), ozone / EBOO, PEMF, whole-body vibration, vagus nerve stimulation (tVNS), and others to add — capturing their typed parameters, scheduling their sessions, and logging done/not-done. Builds on the Device/Therapy and Procedure intervention subtypes (see domain-model).
The system SHALL model periodic therapy interventions — red light / photobiomodulation, HBOT (incl. hypoxia-hyperoxia), IHHT (intermittent hypoxia-hyperoxia training), sauna, cold exposure / cold plunge, whole-body cryotherapy, therapeutic plasma exchange (TPE / plasmapheresis), IV infusions (e.g. NAD+, vitamins), ozone / EBOO, PEMF, whole-body vibration, vagus nerve stimulation (tVNS) — with their parameters and session cadence, and the catalog SHALL be extensible.
The system SHALL type each therapy with its own characteristic parameters — for example red light (wavelength(s), irradiance, duration, distance, body area), HBOT (pressure in ATA, FiO2 profile, duration), IHHT (FiO2 high/low cycle, cycle count, session duration), cryotherapy / cold plunge (temperature, duration), sauna (temperature, humidity, duration), TPE / plasmapheresis (volume exchanged, replacement fluid, frequency), IV infusion (agent, dose, rate), whole-body vibration (frequency, amplitude, duration), tVNS (intensity, site, duration) — so each exposes only what is meaningful for it.
The system SHALL allow new therapy types to be added and configured with parameters and cadence, without changing the model.
The system SHALL place therapy sessions on the daily/weekly programming calendar and remind the user.
measurement-planning) with a reminderThe system SHALL log therapy sessions with four-state adherence (done / partial / skipped / missed), feeding adherence.
daily-log-and-adherence)Lets a user define what their physical activity is and log whether they did it — not a gym-management app. Covers strength training, cardio, mobility, whether HIIT is performed, and VO2max. Its job is to make the activity explicit, log done/not-done, and place it in the daily/weekly programming alongside pills and therapeutics.
The system SHALL let a user declare their exercise activity — strength training, cardio, mobility, and whether HIIT is performed — at the level of what they do, not per-set gym tracking.
The system SHALL capture VO2max as a measured biomarker with date and method.
biomarkers-and-labs) and shown in dashboardsThe system SHALL log whether a planned exercise activity was done, with four-state adherence, without becoming a gym tracker.
daily-log-and-adherence)The system SHALL place exercise activities in the daily/weekly programming calendar alongside pills and therapeutics.
measurement-planning)Defines the user's dietary regime so it can be represented, scheduled and logged alongside the rest of the protocol: a computed TDEE, the typical eating schedule/pattern they intend to follow (OMAD, calorie restriction, intermittent fasting, or conventional breakfast-lunch-dinner), and the typical macronutrient split (carbohydrate / protein / fat). Builds on the Nutrition/Fasting intervention subtype (see domain-model) and connects to meal-timed intakes in pills-management.
The system SHALL compute the user's Total Daily Energy Expenditure deterministically from their biological profile and activity level, and SHALL show the formula used.
accounts-and-profiles) and activity level (see exercise-reporting) are knownThe system SHALL let the user declare their typical intended eating pattern — OMAD, calorie restriction, intermittent fasting (e.g. 16/8), or conventional breakfast-lunch-dinner — together with the eating window.
measurement-planning, pills-management)The system SHALL capture the typical macronutrient split — carbohydrate, protein, fat — the user intends to follow.
The system SHALL log adherence to the declared nutrition pattern (followed / deviated) with exceptions, feeding overall adherence.
daily-log-and-adherence)Grades literature into structured, comparable claims and — crucially — links each outcome to a biomarker, which is what lets the platform compare prediction with observation. Bootstrapped on the longevity subset first.
The system SHALL use Forever Healthy's Evipedia knowledgebase as its primary source of intervention evidence reviews (via ai-uses-and-attribution), and SHALL run its own AI4L-audited ingestion only for interventions Evipedia does not cover.
The system SHALL ingest literature (Europe PMC / PubMed / preprints) and extract, in batch, EvidenceClaim records of intervention × outcome × study.
The system SHALL grade confidence with GRADE-inspired weighted factors and report effect size separately, in the outcome's native units.
The system SHALL record directional evidence with explicit counts of favourable, null, and unfavourable studies.
The system SHALL map outcomes to biomarkers so literature predictions can be compared with observed cohort biomarkers.
dashboards-and-doctor-view)The system SHALL alert users when evidence for a compound they use materially changes.
Aggregation across cohorts, honest cross-person comparison, stratification, and the open-data discipline that decides whether researchers cite the dataset or ignore it. OpenData ships as two products: a full clonable public snapshot (public profiles and their public data, protocols, treatments, measurements) that lets anyone self-host an equivalent instance, and an aggregated research export (lab-relative z-scores, cohort thresholds, OMOP). Phase 4.
The system SHALL define OpenData as everything a user has made public: public user profiles and their public data, defined protocols, treatments/interventions, measurements, raw original lab report files, and public genomic data including the gVCF. Only withheld per-item data is excluded.
genomics, biomarkers-and-labs)The system SHALL publish OpenData as a full, clonable snapshot sufficient to seed an independent self-hosted instance, in addition to the aggregated research export.
accounts-and-profiles)The system SHALL aggregate outcomes across a cohort practising the same protocol, weighting contributions by adherence and data completeness.
The system SHALL compare people using the z-score relative to the originating laboratory's range, not the raw value.
The system SHALL include in the aggregated research export only measurements carrying LOINC + UCUM + declared provenance, and only above minimum cohort thresholds guarding re-identification. (The full public snapshot, by contrast, carries public data as published.)
The system SHALL provide a researcher endpoint (dump + API) and an OMOP CDM export for the research layer.
The system SHALL compute, per biomarker, a percentile normalized for sex and age against published reference distributions, and SHALL expose it to dashboards and the doctor view (see dashboards-and-doctor-view), declaring the published source used per marker.
The platform's policy of publishing raw data (raw lab reports, gVCF, and all public data) SHALL be put to a community poll on Rapamycin News when the public BETA testing call opens, to gauge participant opinion, and the outcome SHALL inform the raw-publication policy.
community-and-social)The system SHALL declare insufficiency rather than present an approximate synthetic value when coverage is inadequate.
No heavy re-analysis pipeline: the platform imports selected interpreted variants and, where provided, retains the raw gVCF, focused on the actionable. Like all other data on biohack.it, genomic data — including the gVCF — is public by default and part of OpenData, behind a heightened, explicit consent step because it is maximally identifying.
The system SHALL accept genomic data — interpreted variants/reports and, where provided, the raw gVCF — store it, and treat it as publishable data.
The system SHALL surface genomic interpretation limited to the actionable — pharmacogenomics (CYP metaboliser status; APOE) — while retaining the raw gVCF for sharing and export.
The system SHALL make genomic data — including the gVCF — public by default like other data, gated by an explicit heightened-consent step stating its identifiability, the exposure of biological relatives, and the effective irreversibility of publication.
analytics-and-open-data)Lets a biohacker query their own data with their own agent through a revocable, read-only token and a lightweight MCP gateway. Low cost, high cultural impact for the hacker audience, and something no commercial competitor will ship.
The system SHALL issue per-profile, read-only, revocable tokens for agent access, and SHALL never grant write access through this path.
The system SHALL expose a lightweight MCP endpoint returning the profile's data context, queryable by external agents (e.g. Claude, Cursor, a Nostr bot).
The system SHALL return through agent access only data consistent with the profile's visibility settings — withheld items are never returned; public data (including public genomics, where the user made it public) follows those settings. There is no special genomics carve-out.