Functional Specification — Review
Everything produced for biohack.it, in one place, structured for a module-by-module review. Give feedback by requirement code — e.g. “SAFETY R1: …”.
How to review — three levels
- Shape (10 min): read the posture + decisions below, and each module's Purpose. Is the direction right?
- Coverage (20 min): skim the requirement titles (collapsed rows) per module. Anything missing or wrong?
- Detail (as needed): expand a requirement to read its scenarios. Reference it by its code when you comment.
Decisions resolved
history: synthesized. PROTOCOLSDomain Model (cross-cutting)
Phase 08 requirementsDefines 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.
DOMAIN · R1Separation of the three protocol facets
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.
- WHEN a user edits a dose inside their
TreatmentPlan - THEN the change creates a new
TreatmentPlanversion - AND the associated
TestingProtocolandGoalare untouched and keep their own version history
- WHEN a user declares a
Goal - THEN the system SHALL let them map it onto one or more Hallmarks of Aging (Schmauck-Medina 2022 framework)
- AND the user's top three goals are flagged as weighted for later analysis
DOMAIN · R2Protocol as public composite
The 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.
- WHEN a user publishes a
Protocol - THEN the composite references specific versions of its three facets
- AND it records origin, author, license posture, and any forked-from lineage
DOMAIN · R3Intervention carries a cycle schema
The 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.
- WHEN a user records "dasatinib 100 mg, days 1–3 of each month"
- THEN the intervention stores pattern=pulsed with on_days=[1,2,3] over a monthly cycle
- AND the pattern is never flattened to "Monthly" with the cycle relegated to free text
DOMAIN · R4Intervention subtypes
The system SHALL support intervention subtypes with their own fields: Substance, Exercise, Device/Therapy, Procedure, Hormonal, and Nutrition/Fasting.
- WHEN the intervention is a Procedure (e.g. IV infusion, plasmapheresis)
- THEN it carries operator, site, consent and a distinct risk profile
- AND the system does not treat it as interchangeable with an oral Substance
DOMAIN · R5Biomarker with role and three ranges
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.
- WHEN a biomarker value is displayed
- THEN the reference range, the optimal range, and the safety threshold are shown as three different things
- AND they are never collapsed into a single band
DOMAIN · R6Measurement provenance
The system SHALL store each Measurement with date, source, laboratory, method/assay, unit (UCUM), and validation state.
- WHEN a measurement is persisted
- THEN it retains its method/assay and originating laboratory
- AND a measurement missing these is flagged as not aggregation-eligible
DOMAIN · R7Safety, adherence and wellness as first-class entities
The system SHALL model SafetyRule, AdherenceLog (four states: taken-as-planned | partial | intentionally-skipped | forgotten), and WellnessCheck, and treat them as core, not optional.
- WHEN a cohort result is computed
- THEN each contribution carries its adherence percentage
- AND a low-adherence contribution can be down-weighted or excluded (see
analytics-and-open-data)
DOMAIN · R8Cohort and Study
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).
- WHEN two or more people practise the same published
Protocol - THEN they belong to its
Cohort - AND the cohort is the unit of comparison and analytics
AI Uses, Provenance & Previous Work (cross-cutting)
Phase 08 requirementsConsolidates 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.
AIUSES · R1Published AI surfaces map — "what is AI, what is NOT AI"
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.
- WHEN a user views a computed value (safety threshold, index, sex/age percentile, trend, schedule)
- THEN the AI surfaces map documents these as deterministic and reproducible, not AI-generated
- AND only extraction, narration, and evidence-review generation are marked as AI surfaces
AIUSES · R2AI4L as the framework for AI-generated reviews and evidence queries
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.
- WHEN the platform generates or refreshes an evidence review, or answers an evidence query with AI
- THEN it runs the AI4L create → audit → correct cycle against the QA checklist, restricted to trusted scientific sources
- AND outputs are cached and reproducible, and the LLM never writes numbers into constrained fields (see
interventions-and-catalog,biomarkers-and-labs)
AIUSES · R3AI4L output conforms to the project's strict normalization
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.
- WHEN AI4L produces or refreshes a review, or answers an evidence query
- THEN its interventions, analytes and outcomes are resolved to the project's coded vocabularies (see
interventions-and-catalog,biomarkers-and-labs) - AND non-resolvable entities are marked ambiguous for review, never left as silent free text
AIUSES · R4Integrate the Evipedia knowledgebase, attributed
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.
- WHEN an intervention has an Evipedia review
- THEN the platform can retrieve its conclusion, metadata (alternate names, PMIDs), and full review via the Evipedia MCP or JSON/MD endpoints
- AND any surfaced Evipedia content carries visible attribution to Forever Healthy (CC BY 4.0)
AIUSES · R5Content structure aligned to the Evipedia / AI4L review model
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.
- WHEN the platform stores an intervention's evidence
- THEN its structure maps to the Evipedia review model (conclusion, grading, risk-benefit, citations, dates)
- AND biohack.it's differential — the Outcome↔Biomarker link and the observed-cohort column — is layered on top (see
evidence-layer,dashboards-and-doctor-view)
AIUSES · R6Previous-work and license register
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.
- WHEN a component or dataset is reused — Evipedia (CC BY 4.0), AI4L (MIT),
get-based(AGPL), LOINC / UCUM / RxNorm / ATC / PubChem / UNII - THEN its license and required attribution are recorded and shown
- AND any license incompatibility is flagged before integration proceeds
- WHEN a physician or researcher asks "can I trust these numbers?"
- THEN the published AI surfaces map + attribution register answers where AI runs, where it does not, and whose vetted knowledge is reused
AIUSES · R7Technical evaluation of reused open-source / open-data components
The 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.
- WHEN an OSS or open-data component is considered for reuse
- THEN it is evaluated for fit, license compatibility, maintenance and integration approach
- AND the evaluation and rationale are recorded (see
data-standards-and-typing,related-initiatives)
AIUSES · R8Notify upstreams of their inclusion
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.
- WHEN a component or dataset is included (e.g. Evipedia, get-based)
- THEN its maintainers are notified of the inclusion and credited
- AND contributions back (e.g. LOINC mapping upstream) are offered where they help
Data Standards & Typing (scientific validity)
Phase 04 requirementsA 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.
STANDARDS · R1Document each standard and its rationale
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).
- WHEN a standard is adopted
- THEN the section states what it is used for and why it matters for validity
- AND alternatives considered are noted where relevant
STANDARDS · R2Typing discipline for scientific validity
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.
- WHEN data is persisted
- THEN coded fields resolve to their vocabularies and free text is separate (see
interventions-and-catalog,biomarkers-and-labs) - AND untyped/unresolved entries are marked ambiguous, never left as silent free text
STANDARDS · R3Coding plus provenance make aggregation valid
The system SHALL treat coding (LOINC/UCUM/…) plus method/lab provenance as the precondition for cross-person / cross-lab comparability and open-data validity.
- WHEN data is aggregated or released for research
- THEN comparison uses coded, provenance-carrying values (lab-relative z-scores) (see
analytics-and-open-data) - AND uncoded data is excluded from the aggregated research export
STANDARDS · R4Published and maintained as a dedicated section
The system SHALL publish this rationale as a dedicated, maintained section for scientific and technical reviewers.
- WHEN a scientist or engineer evaluates the platform
- THEN the data-standards-and-typing section explains the model and its validity basis
Scientific Method & Evidence (cross-cutting)
Phase 06 requirementsStates 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.
METHOD · R1Publicly declared nature and limits
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.
- WHEN a visitor or researcher encounters the platform's results
- THEN the declared nature and limits are available and linked from where results are shown
- AND the stated comparison is against unstructured practice (prose, screenshots, spreadsheets), never against a controlled trial
METHOD · R2Evidence hierarchy
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.
- WHEN evidence supports a statement on the platform
- THEN its level in the hierarchy is shown alongside it (see
evidence-layer) - AND self-reported data is never presented at the level of controlled evidence
METHOD · R3Qualification bar for a distributed trial
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.
- WHEN a study does not meet every published criterion
- THEN it is presented as a self-experiment or a cohort observation, not as a distributed trial
- AND the unmet criteria are visible
METHOD · R4Observed, never caused
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.
- WHEN a cohort result is rendered anywhere in the product or exports
- THEN it is expressed as an observed change in a self-selected group
- AND causal phrasing is not produced by any surface, including AI-generated narration
METHOD · R5Evidence confidence on every displayed number
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.
- WHEN a computed or measured value is rendered anywhere in the product, the doctor sheet, or an export
- THEN it carries its uncertainty, where it came from, and the strength of evidence behind it
- AND if any of those is unavailable, the value is marked not-determinable rather than displayed bare
- WHEN data leaves the platform through open data or the research API
- THEN the same four attributes travel with each value (see
analytics-and-open-data)
METHOD · R6Negative results are first-class
The system SHALL accept, display and encourage null and negative outcomes as valid contributions, with the same standing as positive ones.
- WHEN a user reports that an intervention produced no detectable change
- THEN the result is recorded and shown as a legitimate outcome
- AND it counts toward cohort aggregation and reputation for data quality (see
community-and-social)
Statistical Methodology (cross-cutting)
Phase 06 requirementsGoverns 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.
STATS · R1Named threats to validity
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.
- WHEN an aggregate result is produced for a cohort
- THEN the applicable threats to validity are stated with the result
- AND the result is never presented as if these had been controlled for
STATS · R2Regression to the mean and multiplicity are handled explicitly
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.
- WHEN a cohort is selected on an out-of-range baseline value
- THEN the expected regression-to-the-mean component is declared alongside the observed change
- WHEN an analysis spans multiple biomarkers or interventions
- THEN the number of comparisons is declared and correction is applied or its absence stated
STATS · R3Separate biological change from analytical noise
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.
- WHEN a series contains measurements from different laboratories or assays
- THEN the change point is flagged in the series
- AND the comparison uses lab-relative normalisation rather than raw values (see
analytics-and-open-data)
- WHEN an observed change falls within the analyte's known intra-individual variability
- THEN it is presented as indistinguishable from noise, not as an effect
STATS · R4Missing data is declared, never imputed silently
The system SHALL declare missingness and drop-out in any aggregate, and SHALL NOT silently impute values.
- WHEN participants lack follow-up measurements
- THEN the aggregate states how many contributed at each timepoint and how many dropped out
- AND any imputation is explicit, labelled, and separable from measured values
STATS · R5Uncertainty and effect size are mandatory
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.
- WHEN an effect is reported
- THEN it carries an uncertainty interval and native units
- AND a trend is not computed from two measurements (see
analytics-and-open-data, "stops instead of guessing")
STATS · R6Under-powered comparisons are declared, not hidden
The system SHALL state when a cohort is too small or too sparse to support a comparison, rather than presenting a precise-looking number.
- WHEN a comparison falls below the declared minimum cohort or coverage
- THEN the system reports "not determinable" with what is missing
Accounts & Profiles
Phase 18 requirementsRegistration, 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.
ACCOUNTS · R1Server-hosted account
The system SHALL require a server-hosted account to create or share protocols and measurements; there is no browser-only/local-first mode.
- WHEN a visitor wants to save a protocol or a measurement
- THEN the system requires registration/sign-in
- AND read access to public profiles and protocols does not require an account
ACCOUNTS · R2Self-hosting a full instance (distinct from local-first)
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.
- WHEN a technical user deploys the AGPL software and imports the public OpenData snapshot
- THEN they obtain a running server instance populated with the public protocols, treatments, measurements and public profiles
- AND this is a full instance, not a browser-only local-first mode
ACCOUNTS · R3Public-by-default profile
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).- WHEN a user completes onboarding
- THEN the UI explicitly invites them to make their protocol and outcomes public and explains the collective benefit
- AND the user can withhold specific items, but is not defaulted into a fully private profile
ACCOUNTS · R4Required biological profile
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.
- WHEN a user sets up their profile
- THEN they configure date of birth, sex, ethnicity, height and other stable traits as specifically as possible
- AND these feed sex/age-normalized percentiles and cohort stratification (see
dashboards-and-doctor-view,analytics-and-open-data)
ACCOUNTS · R5Strong invitation to link social and forum identities
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.
- WHEN a user completes onboarding
- THEN they are strongly invited to add Telegram, WeChat, Xiaohongshu (RED) and their Rapamycin News nickname
- AND these appear on the public-by-default profile and link community identity (see
community-and-social)
ACCOUNTS · R6Onboarding "bring your reports"
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.
- WHEN a new user uploads a past lab report during onboarding
- THEN the system parses and charts it (see
biomarkers-and-labs) - AND the empty state teaches ("upload a report you already have"), never sells a test
- AND the original report file is retained and is public by default in its raw original format (see
biomarkers-and-labs,analytics-and-open-data)
ACCOUNTS · R7Two independent reputation axes
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.
- WHEN a physician verifies a credential but has no measurements
- THEN their credential axis is populated and their data-verification axis is empty
- AND discovery can filter by specialty/credential separately from data quality
ACCOUNTS · R8T0 alpha-tester seeding
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.
- WHEN an invited alpha biohacker accepts and imports their running protocol
- THEN their profile and protocol become part of the seeded, browsable library
- AND the platform never presents an empty community at launch (curated + Fabio + alphas)
Management & Delegation (Mentor / Longevity Doctor / Clinic)
Phase 25 requirementsSupports 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.
MANAGER · R1Managing-user role
The system SHALL support a managing-user role — Biohacking Mentor / Longevity Doctor / Longevity Clinic — able to manage one or more users as a roster.
- WHEN a managing user is set up
- THEN they can hold a roster of one or more managed users
- AND the role carries the verified-credential axis (see
accounts-and-profiles)
MANAGER · R2Self-signup, then assign a manager
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.
- WHEN a self-registered user assigns a manager
- THEN a managed-by relationship is created, revocable by the user at any time
- AND using the platform without a manager remains fully possible
MANAGER · R3Management scope — administer, measure, monitor
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.
- WHEN a manager edits a managed user's TreatmentPlan
- THEN the change is applied as
Physician-Assignedwith a mandatory reason (seeprotocols) - AND it is attributed to the manager, not the user
MANAGER · R4Manager actions are attributed
The system SHALL attribute every managing action to the manager in the tracked change/measurement history, visible to the managed user.
- WHEN a manager performs an action on a managed user
- THEN the history records the manager as actor
- AND the managed user can see what their manager did
MANAGER · R5An assigned manager is indicated
The system SHALL indicate, on the managed user's profile and dashboard, that a manager is assigned and who they are.
- WHEN a user has an assigned manager
- THEN the profile and dashboard indicate the manager (name + credential)
- AND revoking the assignment is reflected everywhere it was shown
Protocols (M1 — Protocol Builder & Library)
Phase 18 requirementsThe 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.
PROTOCOLS · R1Create a protocol from scratch
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.
- WHEN a user adds a single intervention and saves
- THEN the protocol persists as a
Draft - AND the system surfaces what is still missing (e.g. "no efficacy markers yet") without blocking the save
- WHEN a user adds interventions to a
TreatmentPlan - THEN the system SHALL propose the efficacy and safety biomarkers implied by those interventions (see
safety-guardrails,measurement-planning) - AND the proposals are shown as an Accept-All / Reject-All block, never auto-applied
PROTOCOLS · R2Import an already-running protocol (experienced baseline)
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).- WHEN a new experienced user declares interventions they are already taking
- THEN the system records
in_effect_sinceseparately fromtracked_sinceand marks the protocolActivefrom import - AND it invites (does not require) backfilling past measurements and prior changes as history
- WHEN the user cannot reconstruct the analytic history of how the protocol evolved
- THEN the system accepts a coarse free-text lineage note ("how you arrived here")
- AND it flags the protocol/baseline as
history: synthesized(notanalytic) so downstream analytics can distinguish it (seeanalytics-and-open-data)
PROTOCOLS · R3Copy / fork an existing protocol
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).
- WHEN a user copies a public protocol
- THEN the new protocol references the source protocol and the exact source version
- AND the inherited safety markers and mandatory baseline travel with it (see
safety-guardrails)
- WHEN the user edits their fork
- THEN changes apply only to their copy
- AND the lineage link to the source is retained for later comparison
PROTOCOLS · R4Versioning and change tracking
The system SHALL version every protocol facet, and SHALL record each change as a tracked, timestamped, attributable event with a mandatory reason.
- WHEN a user changes rapamycin from 6 mg/week to 8 mg/week
- THEN a new version is created with a change event {field, old, new, timestamp, actor, reason}
- AND the change cannot be saved without a reason
- AND the prior version remains retrievable and referenceable by measurements taken under it
- WHEN a user or viewer compares two versions of a protocol
- THEN the system SHALL render a field-level diff of interventions, doses, cycles, and measures
- WHEN a measurement is recorded on a date
- THEN it is associated with the protocol version active on that date
- AND later edits to the protocol never silently reinterpret past measurements
PROTOCOLS · R5Curated and community origin
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.
- WHEN the platform launches
- THEN a set of team-curated protocols (including Fabio's own) SHALL be present as
curated - AND a first cohort of invited alpha-tester profiles can publish
communityprotocols on top of them (seeaccounts-and-profiles)
PROTOCOLS · R6Publish with per-facet visibility
The system SHALL let a user publish a protocol public-by-default, while allowing specific measures or interventions to be withheld per-item.
- WHEN a user publishes a protocol
- THEN the protocol and its outcomes are public unless the user explicitly withholds an item
- AND genomic elements follow the same public-by-default rule, behind heightened consent (see
genomics)
PROTOCOLS · R7Protocol states
The system SHALL support protocol lifecycle states Draft | Active | Paused | Completed and SHALL reflect state in discovery and dashboards.
- WHEN a user sets a protocol to
Paused - THEN measurement-plan Overdue calculations for that protocol pause (see
measurement-planning) - AND the pause is itself a tracked change event
PROTOCOLS · R8Protocol level classification (medical | research)
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.
- WHEN a protocol contains experimental interventions
- THEN it is classified and displayed as
researchlevel - AND a
medical-level protocol is labelled distinctly, with the acknowledgment implication handled insafety-guardrails
Interventions & Substance Catalog
Phase 18 requirementsThe 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.
INTERVENTIONS · R1Substance resolution on codes, not English strings
The system SHALL resolve every substance to external identifiers (RxNorm / ATC / PubChem / UNII) via a multilingual synonym table, never on raw English strings.
- WHEN a user enters "rapamicina"
- THEN the system resolves it to the same entity as "rapamycin"/"sirolimus" via synonyms
- AND the resolved entity carries its external codes for downstream safety and aggregation
- WHEN a substance cannot be resolved to a code
- THEN the entry is marked
ambiguousand queued for review - AND it is never silently discarded or matched to the wrong entity
INTERVENTIONS · R2LLM never writes into constrained columns
The 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.
- WHEN the extractor proposes a value that does not fit a constrained field
- THEN the value is routed to review as
ambiguous - AND the insert neither truncates silently nor loses sibling entries
INTERVENTIONS · R3Input↔output diff at end of extraction
The system SHALL always show the diff between what the user submitted and what was recognised.
- WHEN a user submits eight substances and five resolve
- THEN the system shows "8 submitted, 5 recognised, 3 not understood" with the three listed
- AND the user can correct or confirm the three before anything is committed
INTERVENTIONS · R4Substance catalog metadata
The system SHALL store per Substance: name(s), external identifiers, class, known interactions, and associated safety markers.
- WHEN a substance with known safety markers is added to a plan
- THEN its associated safety biomarkers become candidates for the measurement plan (see
safety-guardrails)
INTERVENTIONS · R5Long extraction jobs are queued and resumable
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.
- WHEN an extraction job exceeds an interactive limit
- THEN it continues in the queue and its partial progress is retained
- AND re-running is idempotent rather than duplicating entries
INTERVENTIONS · R6Seed and enrich the catalog from Evipedia
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.
- WHEN the catalog is seeded or enriched from Evipedia
- THEN Evipedia intervention names and synonyms populate the synonym table alongside RxNorm/ATC/PubChem/UNII
- AND Forever Healthy is attributed (CC BY 4.0)
INTERVENTIONS · R7Posology provenance (human vs animal)
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.
- WHEN a dose is extrapolated from animal studies
- THEN the posology is tagged
animal-derivedwith its source - AND a dose from human trials is tagged
human-derived(seeevidence-layer)
INTERVENTIONS · R8Principal peptides present in the catalog
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.
- WHEN a user searches for a common peptide (e.g. BPC-157, ipamorelin, semaglutide)
- THEN it is present as a known substance with its codes/synonyms and evidence link
- AND peptides are treated like any other substance, not a separate subsystem
Biomarkers & Lab Data — the Blood Layer (M2)
Phase 114 requirementsThe 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.
BLOODLAYER · R1Coded analyte registry
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.
- WHEN a measurement is persisted
- THEN it has a UCUM unit and links to a LOINC-coded analyte
- AND without method/assay and lab it is flagged not aggregation-eligible
BLOODLAYER · R2Three ranges per analyte
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.
- WHEN an ApoB value sits inside the lab reference range but outside the optimal range
- THEN the display shows it as reference-normal yet optimal-out
- AND the optimal range shows its source
BLOODLAYER · R3Optimal-range governance
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.
- WHEN a user opens the optimal range shown for an analyte
- THEN they see its source, the population it derives from, the endpoint it optimises, its evidence grade and when it was last reviewed
- AND a range lacking any of these is not shown as optimal
- WHEN an optimal range is disputed
- THEN the dispute is visible on the range itself and handled as a public contested claim (see
community-and-social)
BLOODLAYER · R4Deterministic pipeline with a hard boundary
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.
- WHEN the same report is imported twice
- THEN the extracted values, mappings, and computed thresholds are identical
- AND any LLM narration is fetched from cache keyed on a fingerprint of the underlying data
BLOODLAYER · R5Import from PDF, photo, and CSV with learned templates
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.
- WHEN a report matches a previously learned laboratory template
- THEN extraction runs deterministically without an LLM call
BLOODLAYER · R6Manual entry of equal standing
The system SHALL support manual measurement entry as a first-class path, with a sanity check on out-of-range values.
- WHEN a user types a value manually
- THEN it is stored with the same provenance fields and a plausibility check
- AND it is not treated as inferior to an imported value except where verification status matters (see
community-and-social)
BLOODLAYER · R7Human review before persistence
The system SHALL require human confirmation before extracted values enter the system, and SHALL fail loudly on anything not understood.
- WHEN the parser cannot interpret a line
- THEN it declares the item and asks, rather than proceeding on an incomplete report
- AND the review step shows recognised / not-recognised / inferred status per item
BLOODLAYER · R8Completeness and freshness indicators
The system SHALL show, per organ system, how complete and how fresh the data is.
- WHEN a system has 6 of 13 expected markers, last updated 4 months ago
- THEN the UI states "Metabolic: 6/13, last updated 4 months ago"
- AND any index computed on sparse data is annotated as such (see
dashboards-and-doctor-view)
BLOODLAYER · R9Biological clocks are first-class biomarkers
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.
- WHEN a biological-clock value exists (computed or uploaded)
- THEN it is stored as a biomarker with method/provider, date, unit and uncertainty
- AND it appears in the biomarker registry and in dashboards (see
dashboards-and-doctor-view)
BLOODLAYER · R10Deterministic PhenoAge computation from the standard panel
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.
- WHEN the standard blood panel is measured
- THEN the system computes PhenoAge deterministically from its constituent analytes (albumin, creatinine, glucose, CRP, lymphocyte %, MCV, RDW, ALP, WBC, and chronological age)
- AND the computation is reproducible (same input → same output), with the LLM never involved
BLOODLAYER · R11Upload of measured biological clocks (epigenetic, glycation)
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.
- WHEN a user uploads a TruAge epigenetic result or a GlycanAge glycation result
- THEN it is stored as a biological-clock biomarker with its provider, method and uncertainty
- AND provider/method are retained because clocks are not comparable across providers
BLOODLAYER · R12Inventory of biological clocks with accessibility assessment
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.
- WHEN a new biological clock is considered
- THEN it is recorded with its accessibility class and provider reputation
- AND clocks computable from existing data are prioritized over ones that must be purchased
BLOODLAYER · R13Optional PII obfuscation on import
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).
- WHEN a user chooses to obfuscate a report containing name and ID
- THEN the PII is obfuscated and the user can see what was removed
- AND by default, without that choice, the original file is retained raw
BLOODLAYER · R14Original report file retained and public raw
The system SHALL retain the original lab report file and make it public by default in its raw original format, as part of OpenData.
- WHEN a user's lab report is public
- THEN the raw original-format file (e.g. PDF) is available exactly as uploaded
- AND it is part of the OpenData public snapshot (see
analytics-and-open-data)
Measurement Planning (M3 — Scheduling & Measurement Planner)
Phase 25 requirementsThe 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.
PLANNER · R1The panel is computed, not chosen
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.
- WHEN a user adds a compound with a renal safety rule
- THEN the relevant renal markers are added to the computed panel with a stated reason
- AND the panel updates as interventions change
PLANNER · R2Phase-dependent cadence
The system SHALL schedule denser measurement during initiation/titration and sparser during maintenance, per intervention phase.
- WHEN an intervention is in titration
- THEN its safety markers are scheduled at a tighter cadence than in maintenance
PLANNER · R3Analyte pooling into one draw
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).
- WHEN several analytes fall due within the same window
- THEN the planner proposes one draw covering them
- AND it honours conflicting pre-analytic constraints or splits when it must
PLANNER · R4Overdue is a safety signal
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.
- WHEN a liver panel is overdue while a hepatically-relevant compound is active
- THEN the system states "rapamycin active for 94 days, liver panel overdue by 34"
- AND this links to the corresponding SafetyRule (see
safety-guardrails)
- WHEN the protocol is
Paused - THEN Overdue accrual for its measures pauses
PLANNER · R5Planner views
The system SHALL provide calendar, year, and table views, filterable by type × status, with any Study timeline overlaid on the personal calendar.
- WHEN a user has an active N-of-1 Study
- THEN its timepoints appear on the personal calendar alongside routine measures
Safety Guardrails (M7)
Phase 1-26 requirementsThe 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.
SAFETY · R1Mandatory baseline AND risk acknowledgment before following a protocol
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.
- WHEN a beginner copies a protocol containing an off-label compound
- THEN the system blocks activation until the required baseline markers are recorded
- AND the user has also explicitly acknowledged the risk (recorded, timestamped)
- AND the required safety markers for that compound are already attached
- WHEN a user acknowledges the risk but has not recorded the required baseline
- THEN activation remains blocked
- AND the UI states which baseline markers are still missing
SAFETY · R2Safety markers inherited automatically
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.
- WHEN a protocol is copied
- THEN its safety markers travel with it into the follower's plan (see
protocols)
SAFETY · R3Dose sanity check
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.
- WHEN a user enters vitamin D3 at 100,000 IU/day
- THEN the system flags it as potentially toxic and asks for confirmation
- AND the same applies to e.g. selenium 2000 mcg or rapamycin 30 mg/day
SAFETY · R4Interaction and critical-value alerts
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.
- WHEN two active substances have a known interaction
- THEN the system warns and states the confidence/source of the interaction claim
SAFETY · R5Escalation with a ready sheet
The system SHALL provide an explicit "consult a physician" escalation that produces the protocol sheet ready to hand over (see dashboards-and-doctor-view).
- WHEN a measured value crosses a safety threshold
- THEN the system escalates with the protocol sheet pre-generated
- AND it never issues a personalised dosage or diagnosis
SAFETY · R6Heightened acknowledgment for research-level or animal-derived dosing
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.
- WHEN a user activates a research-level or animal-derived-dose protocol
- THEN the system requires an explicit acknowledgment naming the level and dose provenance (see
protocols,interventions-and-catalog) - AND this is on top of the mandatory baseline and safety-marker inheritance
Daily Log & Adherence (M13)
Phase 14 requirementsThe 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.
DAILYLOG · R1Daily check-off with dose and slot pre-resolved
The system SHALL present a daily check-off of intakes with dose and time-slot already resolved from the plan.
- WHEN a user opens the daily log
- THEN each due intake shows its resolved dose and slot
- AND the user marks it without re-entering dose
DAILYLOG · R2Four-state adherence
The system SHALL record adherence in four states: taken-as-planned | partial-dose | intentionally-skipped | forgotten, and compute daily and cumulative adherence.
- WHEN a user marks a dose intentionally-skipped
- THEN it is stored distinctly from "forgotten"
- AND both feed the adherence percentage that qualifies results
DAILYLOG · R3Wellness check
The system SHALL capture a daily subjective wellness check — mood 1–5, energy 1–5, sleep hours, sleep quality 1–5, free notes.
- WHEN a user submits a wellness check
- THEN it is stored as a high-frequency series usable in dashboards
- AND it requires no purchase or lab
DAILYLOG · R4Adherence qualifies data downstream
The system SHALL make adherence available to analytics so a low-adherence contribution can be down-weighted or excluded.
- WHEN a contribution has 35% adherence
- THEN analytics can exclude or down-weight it versus a 95% contribution (see
analytics-and-open-data)
Dashboards & Doctor View (M5)
Phase 18 requirementsThe 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.
DASHBOARD · R1Public dashboard grouped by biomarker family
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.
- WHEN a viewer opens the kidney group
- THEN it shows the markers and the reason they are monitored (which active compound requires them)
DASHBOARD · R2Organ-system view unifies efficacy and safety
The system SHALL provide an organ-system view where the same panel that shows efficacy also shows safety gaps.
- WHEN the renal tile shows a trend
- THEN it can simultaneously show "you take a nephrotoxic compound and have not measured creatinine in 8 months"
DASHBOARD · R3Headline metric first, then organ-system grid
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.
- WHEN the dashboard loads and a biological age is available
- THEN the biological-age delta is shown first as the headline, with its uncertainty interval, clock, and lab
- AND the organ-system grid follows below
- WHEN no biological age is available
- THEN the headline falls back to a data-coverage summary (systems covered / freshness)
- AND the organ-system grid still renders in full
DASHBOARD · R4Biological clocks surfaced as a group
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.
- WHEN more than one biological clock is available
- THEN the dashboard shows each clock with its method/provider and uncertainty interval
- AND the headline names which clock and lab it uses, and clocks are not presented as comparable across providers
DASHBOARD · R5Doctor protocol sheet
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.
- WHEN a user chooses "prepare for my doctor"
- THEN the system generates the sheet as link + PDF
- AND it is legible without a platform account
DASHBOARD · R6Double-column literature vs observed
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).
- WHEN an intervention has both literature evidence and a cohort
- THEN the view shows "literature predicts X; the N people who did it show Y"
- AND the comparison uses the Outcome↔Biomarker link (see
evidence-layer,analytics-and-open-data)
DASHBOARD · R7Cohort comparison — inline reference AND dedicated view
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.
- WHEN a biomarker's protocol has a cohort large enough to compare
- THEN its dashboard tile shows a lightweight "you vs cohort" reference (e.g. vs cohort median)
- AND the tile links into the dedicated "vs cohort" view
- WHEN the user opens the "vs cohort" view for a biomarker
- THEN it shows the cohort distribution with n, stratification, and adherence weighting
- AND it declares "not determinable" when the cohort is too small rather than implying precision
DASHBOARD · R8Per-biomarker sex/age-normalized percentile
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.
- WHEN a biomarker value is displayed
- THEN it shows its sex/age-normalized percentile with the reference population declared
- AND this is distinct from the cohort comparison (population percentile vs same-protocol peers)
- WHEN the reference population is insufficient to place a percentile for that sex/age
- THEN the system declares "not determinable" rather than showing a guessed percentile
Community & Social (M6)
Phase 29 requirementsFollowing, 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.
COMMUNITY · R1Follow and copy
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).
- WHEN a user copies a public protocol
- THEN a fork is created and the mandatory baseline/safety gate is applied before activation
COMMUNITY · R2One-click copyable catalog with an informed-decision panel
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.
- WHEN a user chooses to copy any protocol, including a peptide / plasmapheresis / IV one
- THEN before activation an informed-decision panel surfaces: how many others practise it and their outcomes (adoption + Evidence Badge), the evidence corpus and grading, the medical/research level and dose provenance, the potential impacts, and Rapamycin News links for deeper discussion
- AND the copy then proceeds through the safety gate (baseline + heightened acknowledgment for research/animal-derived), with nothing withheld from the copyable catalog
COMMUNITY · R3Cohorts form around protocols
The system SHALL group users practising the same protocol into a Cohort and let a follower compare against it.
- WHEN a user practises a protocol with others
- THEN they can see their own trajectory against the cohort's (see
analytics-and-open-data)
COMMUNITY · R4Integrate with Rapamycin News (Discourse Connect where feasible)
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.
- WHEN Discourse Connect SSO is available
- THEN identity is shared via Discourse Connect and protocol↔thread links are bidirectional
- AND where SSO is not available, bidirectional links are still established
- WHEN a protocol references a compound discussed on Rapamycin News
- THEN the protocol links bidirectionally to that thread
COMMUNITY · R5Host study proposals for comment and consensus
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.
- WHEN a Study is pre-registered (see
studies-nof1) - THEN its question and endpoints appear as a community proposal thread open for comment
- AND the resulting discussion is visible from the Study, and the Study from the thread
COMMUNITY · R6Calculated Evidence Badge
The system SHALL compute reputation from data the system already holds and show its derivation, never a self-declared claim.
- WHEN a protocol has verified measurements
- THEN the badge reads e.g. "Rapamycin 6mg/week, 94 days, adherence 91%; ApoB 78→91 (+17%), ALT stable, lymphocytes −18%; 3 measurements, single lab, verified reports"
- AND no free-form success claim is shown in its place
COMMUNITY · R7Public claim review
The system SHALL make contested claims public, discussed, and traceable — not a private flag to a team.
- WHEN users contest a claim
- THEN the item shows "contested by N people, here's why" publicly
COMMUNITY · R8Two-axis reputation and specialty discovery
The system SHALL keep verified-credential and data-verification as separate axes and provide discovery by specialty, not popularity.
- WHEN a user browses contributors
- THEN they can filter by verified specialty distinct from data-quality
COMMUNITY · R9Gamification only on data quality
The system SHALL gamify only data quality — adherence streaks, panel completeness, documentation continuity — and SHALL NOT rank users by health outcomes.
- WHEN gamification is displayed
- THEN it rewards logging/completeness
- AND there is no "lowest ApoB" or "best biological age" ranking
N-of-1 Studies
Phase 24 requirementsMakes 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.
STUDIES · R1Study with pre-declared endpoints
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.
- WHEN a user creates a Study
- THEN the endpoint must be declared before the study can begin
- AND it is timestamped so later results cannot silently redefine success
STUDIES · R2Timepoints drive the planner
The system SHALL feed a Study's timepoints and test battery into the measurement planner and overlay them on the personal calendar.
- WHEN a Study defines T1 at week 8 with a battery
- THEN those measures appear as due in the planner at week 8
STUDIES · R3Pre/post read-out
The system SHALL compute the declared pre/post comparison at completion and present it against the pre-registered endpoint.
- WHEN a Study completes
- THEN the system reports the endpoint result as declared, including a null result
- AND insufficient data yields "not determinable" rather than a guessed value
STUDIES · R4Study question and endpoints are a community proposal
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.
- WHEN a user pre-registers a Study
- THEN the system publishes the question and endpoints as a community proposal thread open for comments
- AND the Study links bidirectionally to its proposal thread (see
community-and-social)
- WHEN a Study's proposal is open
- THEN comments are collected against the declared question and endpoints
- AND the pre-registered endpoints are immutable — changing them requires a new proposal/version, never a silent edit
Procurement & Inventory (M4)
Phase 33 requirementsTurns 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.
PROCUREMENT · R1Projected need from protocol
The system SHALL project consumption from the active protocol and derive batch purchase suggestions with lead time.
- WHEN projected consumption will exhaust a stock before its lead time elapses
- THEN the system raises a reorder alert in time
PROCUREMENT · R2Inventory with lots and expiry
The system SHALL track stock, lots, and expiry, and alert on expiring stock.
- WHEN a lot approaches expiry
- THEN the system alerts and reflects it in the projected need
PROCUREMENT · R3No monetised procurement initially
The system SHALL NOT monetise procurement or embed supplier affiliations in the initial phase.
- WHEN sourcing information is shown
- THEN it carries no paid placement or affiliate incentive
Pills Management (M4 — daily intake orchestration)
Phase 36 requirementsOrchestrates 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.
PILLS · R1Daily intake schedule across slots
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.
- WHEN two compounds should not be co-administered
- THEN the schedule places them in separated slots with a stated reason
- AND the allocation is deterministic and explainable
PILLS · R2Meal timing and absorption requirements
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.
- WHEN a fat-soluble compound is scheduled
- THEN it is placed with a meal containing sufficient fat
- AND a compound requiring an empty stomach is placed away from meals
PILLS · R3Spacing and distance rules
The system SHALL honour required spacing/distance between compounds (competition, absorption windows) and pre/post-meal distances, or flag an unresolvable conflict.
- WHEN a compound must be taken a set distance from another or from food
- THEN the schedule enforces that distance
- AND it flags the conflict when the constraints cannot all be met
PILLS · R4Restock link to procurement
The system SHALL link pill scheduling to procurement so that low stock triggers a restock action (see procurement-and-inventory).
- WHEN scheduled consumption will exhaust a compound's stock within its lead time
- THEN the system raises a restock action via procurement
PILLS · R5Scale to high-volume regimens
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.
- WHEN a user's regimen involves 60–130 pills per day
- THEN the schedule groups them by slot/meal for legibility and fast check-off
- AND performance and the daily log remain usable at that scale
PILLS · R6Feeds the daily log and calendar
The system SHALL surface the resolved pill schedule in the daily log and the programming calendar.
- WHEN the daily schedule is computed
- THEN each intake appears in the daily log with dose and slot (see
daily-log-and-adherence) - AND on the daily/weekly calendar alongside therapies and exercise (see
measurement-planning)
Therapeutics Management (periodic treatments)
Phase 2-35 requirementsManages 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).
THERAPY · R1Model periodic therapy sessions
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.
- WHEN a user configures an HBOT hypoxia-hyperoxia protocol
- THEN its parameters and session cadence are stored
- AND red light, cryotherapy, cold plunge, plasmapheresis and the others are represented the same way
THERAPY · R2Typed parameters per therapy
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.
- WHEN two different therapies are configured
- THEN each exposes only its characteristic parameters
- AND a cold plunge's water temperature is never conflated with a red-light wavelength
THERAPY · R3Extensible therapy catalog
The system SHALL allow new therapy types to be added and configured with parameters and cadence, without changing the model.
- WHEN a new periodic therapy is introduced
- THEN it can be configured with its parameters and cadence like existing ones
THERAPY · R4Schedule therapy sessions on the calendar
The system SHALL place therapy sessions on the daily/weekly programming calendar and remind the user.
- WHEN a therapy has a due session
- THEN it appears on the calendar (see
measurement-planning) with a reminder
THERAPY · R5Log sessions done or not
The system SHALL log therapy sessions with four-state adherence (done / partial / skipped / missed), feeding adherence.
- WHEN a user completes or misses a therapy session
- THEN it is logged with its adherence state (see
daily-log-and-adherence)
Exercise Reporting
Phase 1-24 requirementsLets 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.
EXERCISE · R1Define the exercise activity profile
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.
- WHEN a user sets up their exercise profile
- THEN they declare strength, cardio, mobility and HIIT yes/no at an activity level
- AND the system does not require per-set/per-rep gym logging
EXERCISE · R2VO2max captured as a biomarker
The system SHALL capture VO2max as a measured biomarker with date and method.
- WHEN a user enters or uploads a VO2max value
- THEN it is stored as a biomarker (see
biomarkers-and-labs) and shown in dashboards
EXERCISE · R3Log done or not-done
The system SHALL log whether a planned exercise activity was done, with four-state adherence, without becoming a gym tracker.
- WHEN a planned strength session is due
- THEN the user marks it done / partial / skipped / missed (see
daily-log-and-adherence) - AND no set-by-set detail is required
EXERCISE · R4Appears in the programming calendar
The system SHALL place exercise activities in the daily/weekly programming calendar alongside pills and therapeutics.
- WHEN the weekly plan is shown
- THEN exercise activities appear alongside pill intakes and therapy sessions (see
measurement-planning)
Nutrition Management
Phase 14 requirementsDefines 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.
NUTRITION · R1Compute TDEE
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.
- WHEN the user's biological profile (see
accounts-and-profiles) and activity level (seeexercise-reporting) are known - THEN the system computes TDEE deterministically with a declared formula
- AND it recomputes when the inputs change
NUTRITION · R2Declare the typical eating schedule/pattern
The 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.
- WHEN a user follows 16/8 intermittent fasting
- THEN the pattern and eating window are recorded
- AND they are reflected in the daily/weekly calendar and inform meal-timed intakes (see
measurement-planning,pills-management)
NUTRITION · R3Typical macronutrient composition
The system SHALL capture the typical macronutrient split — carbohydrate, protein, fat — the user intends to follow.
- WHEN a user sets their typical macros
- THEN the carbs/protein/fat composition is stored and shown on the profile
NUTRITION · R4Log adherence to the nutrition plan
The system SHALL log adherence to the declared nutrition pattern (followed / deviated) with exceptions, feeding overall adherence.
- WHEN a user breaks their fasting window
- THEN the deviation is logged as an exception (see
daily-log-and-adherence)
Evidence Layer (M11)
Phase 0/36 requirementsGrades 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.
EVIDENCE · R1Evipedia as the primary evidence source
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.
- WHEN evidence for an intervention is needed
- THEN the platform first uses the Evipedia review (conclusion, grading, PMIDs), attributed to Forever Healthy
- AND it runs its own AI4L-audited ingestion only where Evipedia has no coverage
EVIDENCE · R2Structured evidence claims
The system SHALL ingest literature (Europe PMC / PubMed / preprints) and extract, in batch, EvidenceClaim records of intervention × outcome × study.
- WHEN literature is ingested
- THEN claims are extracted in batch offline, not in an interactive request
EVIDENCE · R3Confidence separate from effect size
The system SHALL grade confidence with GRADE-inspired weighted factors and report effect size separately, in the outcome's native units.
- WHEN an effect size is stored
- THEN it is in native units, not a percentage derived from absolute values
- AND confidence is a separate field from effect size
EVIDENCE · R4Directional evidence with study counts
The system SHALL record directional evidence with explicit counts of favourable, null, and unfavourable studies.
- WHEN evidence for a compound is summarised
- THEN favourable/null/unfavourable counts are all shown
EVIDENCE · R5Outcome↔Biomarker link
The system SHALL map outcomes to biomarkers so literature predictions can be compared with observed cohort biomarkers.
- WHEN an outcome maps to a biomarker
- THEN the dashboard double-column can align literature and cohort (see
dashboards-and-doctor-view)
EVIDENCE · R6Alerts on evidence change
The system SHALL alert users when evidence for a compound they use materially changes.
- WHEN significant new evidence lands for an active compound
- THEN affected users are alerted
Analytics & Open Data (M8)
Phase 49 requirementsAggregation 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.
ANALYTICS · R1Defined OpenData scope
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.
- WHEN the OpenData set is assembled
- THEN it includes public profiles and their public data, protocols, treatments, measurements, original lab files, and public genomics (incl. gVCF)
- AND it excludes only withheld items (see
genomics,biomarkers-and-labs)
ANALYTICS · R2Full clonable public snapshot
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.
- WHEN a third party downloads the public snapshot
- THEN it contains the public profiles, protocols, treatments, measurements, original lab files and public genomics as published
- AND it is sufficient to stand up an equivalent instance (see
accounts-and-profiles)
- WHEN either the public snapshot or the aggregated research export is produced
- THEN neither includes any withheld item (public genomics, gVCF and original lab files are included, being public)
ANALYTICS · R3Cohort aggregation
The system SHALL aggregate outcomes across a cohort practising the same protocol, weighting contributions by adherence and data completeness.
- WHEN a cohort aggregate is computed
- THEN low-adherence and sparse contributions are down-weighted or excluded by a declared rule
ANALYTICS · R4Compare on z-score, not raw value
The system SHALL compare people using the z-score relative to the originating laboratory's range, not the raw value.
- WHEN two users measured the same analyte at different labs
- THEN comparison uses lab-relative z-scores
ANALYTICS · R5Aggregated research export uses only well-coded data
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.)
- WHEN the aggregated research export runs
- THEN it excludes uncoded/unprovenanced measurements
- AND it suppresses cohorts too small to protect identity
ANALYTICS · R6Researcher access and OMOP export
The system SHALL provide a researcher endpoint (dump + API) and an OMOP CDM export for the research layer.
- WHEN the research export runs
- THEN it produces an OMOP-CDM dataset consumable by OHDSI tooling
ANALYTICS · R7Sex/age-normalized percentile computation
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.
- WHEN a percentile is computed for a marker
- THEN it is normalized for the user's sex and age band
- AND the reference population and its source are declared with the value
- WHEN both a population percentile and a same-protocol cohort comparison exist for a marker
- THEN they are computed and presented as two distinct references (population vs peers-on-this-protocol)
ANALYTICS · R8Raw-data publication validated by a community poll at BETA
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.
- WHEN the public BETA testing call opens
- THEN a poll on Rapamycin News asks participants their view on publishing raw data of everything
- AND the outcome informs the raw-publication policy (see
community-and-social)
ANALYTICS · R9"Stops instead of guessing" in aggregates
The system SHALL declare insufficiency rather than present an approximate synthetic value when coverage is inadequate.
- WHEN an organ-system index or projection lacks coverage
- THEN the system says "not determinable" instead of an approximate number
Genomics (M9 — minimal interpretation, public by default)
Phase 23 requirementsNo 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.
GENOMICS · R1Accept genomic data including gVCF
The system SHALL accept genomic data — interpreted variants/reports and, where provided, the raw gVCF — store it, and treat it as publishable data.
- WHEN a user provides a gVCF
- THEN the system stores it and treats it as publishable, public-by-default data
- AND deep re-analysis (variant calling from raw reads) is out of scope
GENOMICS · R2Actionable interpretation focus
The system SHALL surface genomic interpretation limited to the actionable — pharmacogenomics (CYP metaboliser status; APOE) — while retaining the raw gVCF for sharing and export.
- WHEN an actionable pharmacogenomic variant is present
- THEN it can inform safety context
- AND non-actionable interpretation stays out of scope even though the raw gVCF is retained and shareable
GENOMICS · R3Public by default with heightened consent (incl. gVCF)
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.
- WHEN a user's genomic data (incl. gVCF) is set public
- THEN the system requires an explicit heightened-consent acknowledgment covering identifiability, relatives, and irreversibility
- AND once consented, the data is part of OpenData like other public data (see
analytics-and-open-data)
Agent Access (MCP)
Phase 33 requirementsLets 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.
AGENT · R1Revocable read-only token
The system SHALL issue per-profile, read-only, revocable tokens for agent access, and SHALL never grant write access through this path.
- WHEN a user issues an agent token and later revokes it
- THEN queries succeed before revocation and fail immediately after
- AND the token can never mutate data
AGENT · R2MCP gateway over encrypted context
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).
- WHEN an authorised agent queries via MCP
- THEN it receives the read-only biomarker/protocol context for that profile
AGENT · R3Agent access respects per-item visibility
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.
- WHEN an agent queries a profile
- THEN withheld items are not returned
- AND public data follows the profile's visibility settings
Wireframes
Wireframes — low-fidelity hypotheses
Legend: [button] ( ) radio [x] checkbox ▸ expandable ◔ data-quality dot ⚠ safety.
---
W1 · Public Protocol page (the acquisition + copy surface)
┌────────────────────────────────────────────────────────────────────┐ │ biohack.it Explore People Compounds [Sign in] │ ├────────────────────────────────────────────────────────────────────┤ │ Rapamycin + Metformin longevity base origin: COMMUNITY │ │ by @fabio · verified reports ✓ · forked 12× · cohort: 340 │ │ [ Copy / Follow ]│ │ │ │ EVIDENCE BADGE (calculated — not a claim) │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ Rapamycin 6mg/week · 94 days · adherence 91% │ │ │ │ ApoB 78→91 (+17%) · ALT stable · lymphocytes −18% │ │ │ │ 3 measurements · single lab · reports verified │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ INTERVENTIONS GOALS → hallmarks │ │ • Rapamycin 6mg weekly (Mon) pulsed • Senescence ▸ │ │ • Metformin 500mg 2×/day continuous • Inflammation ▸ │ │ │ │ OUTCOMES (literature ┈ vs cohort ━) SAFETY MARKERS (inherited) │ │ [ ApoB curve: prediction vs observed ] ⚠ ALT/AST ⚠ creatinine │ │ lymphocytes, fasting glc │ │ │ │ Discuss on Rapamycin News ▸ (thread linked) │ └────────────────────────────────────────────────────────────────────┘
Priority order: what it is → is it trustworthy (badge) → what it involves → does it work (double column) → is it safe → discuss. Copy/Follow is always visible.
---
W2 · Copy → Safety gate (harm reduction, blocks activation)
┌────────────────────────────────────────────────────────────────────┐ │ You're copying: Rapamycin + Metformin base (forked from @fabio) │ ├────────────────────────────────────────────────────────────────────┤ │ ⚠ Before you can activate this protocol: │ │ │ │ BASELINE REQUIRED SAFETY MARKERS (auto-added) │ │ [x] Lipid panel (ApoB) • ALT, AST (rapamycin, metf.) │ │ [ ] Kidney (creatinine) • creatinine, eGFR │ │ [ ] Liver (ALT/AST) • fasting glucose, HbA1c │ │ [ ] Fasting glucose │ │ │ │ 1) Provide baseline (REQUIRED): │ │ [ Upload reports ] or [ Enter manually ] │ │ 2) [x] I understand and acknowledge the risk (REQUIRED, logged) │ │ │ │ [ Activate ] ← enabled only when 1 AND 2 are both done │ └────────────────────────────────────────────────────────────────────┘
---
W3 · My Dashboard (organ-system view; efficacy AND safety in one tile)
┌────────────────────────────────────────────────────────────────────┐ │ My Dashboard Biological age Δ −1.4y (±2.1, PhenoAge, LabX)│ ├───────────────┬───────────────┬───────────────┬────────────────────┤ │ LIPIDS ◔◔◔◕ │ KIDNEY ◔◔◑ │ LIVER ◔◔◔◔ │ INFLAMMATION ◔◑ │ │ ApoB ↑ +17% │ ⚠ creatinine │ ALT stable │ hsCRP ↓ │ │ optimal: out │ not measured │ optimal: in │ optimal: in │ │ pctl 78 ♂/age │ 8 months — │ pctl 41 ♂/age │ pctl 22 ♂/age │ │ vs cohort +3 ▸│ nephrotoxic ⚠│ vs cohort −1 ▸│ vs cohort −4 ▸ │ │ reason: rapa │ │ reason: rapa │ reason: goal │ ├───────────────┴───────────────┴───────────────┴────────────────────┤ │ ◔ completeness/freshness · pctl = sex/age-normalized percentile · │ │ "vs cohort ▸" = inline ref (A), opens the dedicated "vs cohort" │ │ view (B) with distribution + n. Index only where coverage suffices. │ └────────────────────────────────────────────────────────────────────┘
The kidney tile shows the whole thesis: the same tile that would show efficacy shows the safety gap. Each tile also carries the sex/age-normalized percentile and a lightweight cohort reference that deep-links to the full "vs cohort" view.
---
W4 · Import lab report → human review (fail loudly)
┌────────────────────────────────────────────────────────────────────┐ │ Import report [ drop PDF/photo/CSV ] PII removed ✓ (view diff)│ ├────────────────────────────────────────────────────────────────────┤ │ We read 68 results. Review before saving: │ │ ✓ recognised (61) ? not recognised (4) ~ inferred (3) │ │ │ │ ✓ ApoB 91 mg/dL LOINC ok method: immunoturb. LabX │ │ ✓ ALT 22 U/L LOINC ok │ │ ? "Lp-PLA2" — not mapped → [ map ] or leave ambiguous │ │ ~ eGFR 88 inferred from creatinine [confirm] │ │ │ │ 8 submitted · 5 recognised · 3 not understood ← always shown │ │ [ Confirm & save ] [ Cancel ] │ └────────────────────────────────────────────────────────────────────┘
---
W5 · Protocol builder + version history
┌────────────────────────────────────────────────────────────────────┐ │ My Protocol [ Draft ▸ Active ] History ▾ [ Publish ] │ ├──────────────────────────────────┬─────────────────────────────────┤ │ INTERVENTIONS [ + add]│ HISTORY / VERSIONS │ │ • Rapamycin 6→8 mg weekly Mon │ v4 today dose 6→8mg "raise" │ │ pattern: pulsed on:[Mon] │ v3 Jul 2 added metformin │ │ ⚠ dose check: within range │ v2 Jun 10 baseline import │ │ • Metformin 500mg 2×/day │ v1 Jun 10 created │ │ │ [ diff v3 ↔ v4 ] │ │ SYSTEM PROPOSES (Accept/Reject) │ │ │ + add creatinine, eGFR (safety) │ measurements bind to the │ │ + add lymphocytes (efficacy) │ version active on their date │ │ [ Accept all ] [ Reject all ] │ │ └──────────────────────────────────┴─────────────────────────────────┘
---
W6 · Daily Log (30 seconds; 4-state adherence + wellness)
┌────────────────────────────────────────────────────────────────────┐ │ Today Mon 4 Aug adherence today 100% · streak 12d │ ├────────────────────────────────────────────────────────────────────┤ │ MORNING ✓ taken ◐ partial ⤫ skipped ○ forgot │ │ Rapamycin 8mg (•) ( ) ( ) ( ) │ │ Omega-3 4 caps (•) ( ) ( ) ( ) │ │ EVENING │ │ Metformin 500mg ( ) ( ) ( ) (•) ← forgot │ │ │ │ WELLNESS mood ●●●●○ energy ●●●○○ sleep 7.5h quality ●●●●○ │ │ note: ____________________________________ │ │ [ Save ] │ └────────────────────────────────────────────────────────────────────┘
---
W7 · For My Doctor (handover sheet)
┌────────────────────────────────────────────────────────────────────┐ │ Protocol sheet — @fabio — generated 4 Aug 2026 [PDF] [link] │ ├────────────────────────────────────────────────────────────────────┤ │ TAKING NOW dose since why measured │ │ Rapamycin 8mg/wk Mon 8 mg Jun 10 mTOR; watch lipids, │ │ lymphocytes, liver │ │ Metformin 500mg 2×/d 500 mg Jul 2 glucose control │ │ MONITORED ApoB↑, ALT/AST stable, creatinine (overdue ⚠), │ │ lymphocytes −18%, fasting glucose normal │ │ OPEN ALERTS ⚠ creatinine overdue 34 days while on rapamycin │ │ Legible without an account. │ └────────────────────────────────────────────────────────────────────┘
---
Layout decisions (resolved 2026-08-04)
- Dashboard leads with the headline biological-age Δ, then the organ-system grid (O5).
- Cohort comparison lives both inline on each tile and in a dedicated "vs cohort" view (O6).
- Every biomarker also shows its sex/age-normalized percentile.
- ~~Copy-flow acknowledge bypass~~ RESOLVED: baseline values are required and an explicit risk acknowledgment is also required — acknowledgment is never a bypass. (W2 updated)