Future Human Wiki documents the technologies that change what a human being is, and grades every one of them on how much has actually been demonstrated.
Future Human Wiki is a reference work on human biological and cognitive futures. It covers the biology of aging, genome editing, brain–computer interfaces, reproductive technology, tissue and organ replacement, nanomedicine, bodies in extreme environments, and the ethical and governance arguments attached to all of it. The corpus currently holds 215 articles, roughly 303,000 words, and 3,679 internal links.
The organising problem is that this subject is usually written about badly. Popular coverage flattens a mouse study and an approved therapy into the same sentence. Advocacy treats a forecast as a schedule. Dismissal treats every unproven idea as equally unserious. This site tries to hold the middle: state the claim precisely, say how far it has been demonstrated, and name the people who expect it to fail.
It is not a manifesto. It takes no position on whether any of these technologies should be built, and it does not sort them into progress and peril. It is not a prediction market: the site publishes no forecasts of its own. It is not a health resource — several articles describe compounds people take without adequate evidence, and they are described because people take them, not because the evidence supports it.
It sells nothing, carries no advertising, and sets no tracking cookies. Where a technology has a company behind it, the article names the company and treats its statements as claims rather than findings. Where a field has a devoted community, the article reports what that community believes without adopting it.
Articles are filed into thirteen portals, each broad enough to hold a real literature and narrow enough to browse in one sitting. An article can belong to as many as three; the first is its home, and drives its colour and its breadcrumb.
Underneath the prose, every article carries four machine-readable fields. Type says what kind of thing the subject is: concept, technology, intervention, organization, person, event, or risk. Status is the evidence grade — six values running from established down to speculative, with contested reserved for claims under active dispute rather than claims that are merely unproven. Horizon is when the topic could plausibly matter at scale, attributed in the body to whoever made the estimate. TRL is a technology readiness level from 1 to 9, carried by the 86 articles concrete enough to warrant one.
These fields are not decoration. The filters, the timeline, the readiness matrix, and the search index all read them, and they are published verbatim in llms.txt. An article whose status contradicts its own body text is treated as a defect, not a matter of taste. Roughly 10% of the corpus is marked speculative outright, and the statistics page shows the full distribution.
Three rules do most of the work.
Take speculative subjects seriously enough to report the objections. Mind uploading, negligible senescence, and longevity escape velocity all get full articles, written straight. Each one also carries the mainstream case against it, from named critics, in the same register as the case for. Treating an idea as beneath argument is not skepticism; it is an excuse to skip the argument.
Never blur species. A result in mice is reported as a result in mice, in the same sentence as the effect size. Most interventions that extend rodent lifespan have no demonstrated effect on human lifespan, and the articles say so where that is the case.
Never state a forecast as fact. Dates appear as attributed estimates, with the estimator named and the estimate dated. The horizon field is a filing aid for browsing, not a schedule. The full rules are on the editorial policy page.
Every save writes a new revision holding the whole article, and revisions are never rewritten or deleted — the database refuses both, so the rule survives a hotfix as well as it survives good intentions. The log currently holds 263 revisions, of which 48 are edits across 48 articles.
Recent changes lists every save. Each article has its own history, reachable from the article, where any version can be read on its own and any two compared. Separately, each article carries an updated date its editor sets by hand when the text changes in a way a reader would notice; updated dates groups the corpus by that field and checks it against the log. The two disagree by design, and the page says how.
The corpus is a Postgres database: one row per article, and an append-only table of revisions holding the text. A build reads it once, renders every page and every machine-readable file from that read, and emits static files, so nothing queries a database when a reader requests a page.
Before that, the corpus was a directory of markdown files, and what the move cost is worth stating. The whole wiki could be cloned and rebuilt with no service running anywhere. Its edit history was git log — nothing to build, and already understood by everyone who might read it. Backups were a side effect of the fact that every contributor had a copy. None of those are true now: the site cannot be built without reaching a database, the history lives in one place, and keeping a copy of it is a scheduled job rather than a consequence of cloning.
What it bought is what a wiki is supposed to have. An edit can be saved from a browser by someone with no checkout. Two people editing the same article at the same time get an error rather than one of them silently losing their work. Every version of every article is a URL. The markdown itself is unchanged and still served in full at /raw/<slug>, byte for byte as it was committed, which is what keeps the move reversible in practice and not only in principle.
Press ⌘K or / anywhere for full-text search across every article; the index is a single static file, fetched once and cached. Beyond search there are five distinct ways in.
Around those sit the interactive tools, the glossary, 570 cross-cutting tags, and wanted pages — topics that existing articles link to but nobody has written yet, ranked by how many articles asked for them. If you want to land somewhere unplanned, there is a random article.
Text is available under CC BY-SA 4.0. Reuse it, including commercially, provided you attribute futurehumanwiki.com and licence your version the same way.
Nothing on this site is medical advice. Articles describe drugs, supplements, implants, and clinic offerings in order to report what is known about them, which routinely includes reporting that very little is known. Dosing, self-experimentation, and treatment decisions are outside this site’s scope. Talk to a clinician who can see your records.
9 surfaces expose the corpus without scraping. All of them are written at build time from the same database read as the pages, so they cannot disagree with them. The data page documents each one, says how to cite the corpus, and states what the endpoints do not support.
corpus.json — every article's classification, the link graph in both directions, and each article's revision counts and timestampstaxonomy.json — the controlled vocabularies, with the definition of every valuellms.txt — a map of the whole corpus in the llmstxt.org format, one line per articlellms-full.txt — every article's markdown source in one documentsearch-index.json — titles, summaries and classification — what the command palette readssearch-index-full.json — the full text of every article, fetched only when somebody searchesfeed.xml — RSS, dated from each article's updated fieldsitemap.xml — every route this site publishes/raw/<slug> — one article's markdown source, with the wikilinks, source-type tokens and data blocks that do not survive HTMLThe revision log is not among them. It is published as HTML — one page per revision, one diff per pair — and summarised as counts and timestamps inside corpus.json.