Loading
Every classification on this site is a field an editor set and the content check validated, not a phrase a scraper would have to infer from prose. This page documents the endpoints that publish those fields, and says plainly what they do not support.
All of them are static files, written by the same build as the site from the same read of the same database. Nothing here is a live API, nothing requires a key, and nothing is rate limited. If a value differs between a page and an endpoint, that is a bug — they read the same module.
| Endpoint | Content type | What it is |
|---|---|---|
/corpus.json | application/json | Every article: all classification fields, the editorial backlog, the link graph in both directions, and each article's revision count and timestamps. No body text. |
/taxonomy.json | application/json | The controlled vocabularies with their definitions, plus which kind of article carries which field. |
/raw/<slug> | text/markdown | One article's source, byte for byte as written. |
/llms.txt | text/plain | The index: every article as a title, a summary and a classification, grouped by portal. |
/llms-full.txt | text/plain | The whole corpus as one document. Large; its header says how large. |
/sitemap.xml | application/xml | Every URL this site publishes. |
/feed.xml | application/rss+xml | RSS. One item per article, dated from the `updated` field rather than from the revision log — see below. |
/search-index.json and /search-index-full.jsonalso exist and are not part of this. They are the cache behind this site’s search box: single-letter keys, bodies truncated to snippet length, no readiness, no editorial backlog, no link graph. They are tuned for a fuzzy match on a phone and their shape will change whenever that job changes. Read /corpus.json instead.
One record per article — all 205of them — carrying every field the site classifies on, the article’s own list of known gaps, and its links in both directions. There is no body text in it; that is what /raw/<slug> and /llms-full.txt are for.
Two fields need reading carefully. outbound lists only targets that exist as articles; targets nobody has written are in wantedLinks, kept rather than dropped because an unwritten link is a content signal and the wiki publishes its own gaps. humanEvidence, access and reversibility are null on articles about people, organizations and events, where they would be a category error rather than a missing value — /taxonomy.json says which type carries which.
The file also carries a top-level history object and a per-article one. Those are counts and timestamps from the revision log rather than fields anyone typed; what they contain and what they deliberately leave null is under revision history below.
A complete record, taken from the file rather than written for the documentation:
{
"slug": "in-vitro-fertilisation",
"title": "In vitro fertilisation",
"summary": "The routine clinical procedure in which eggs are fertilised outside the body and an embryo is transferred to a uterus, and the platform every other embryo technology is built on.",
"type": "technology",
"status": "established",
"horizon": "present",
"trl": 9,
"humanEvidence": "Between ten and thirteen million children had been born after assisted reproduction by 2018 and several million since; live-birth rates fall steeply with the age of the egg, and birth defects are modestly more common than after natural conception.",
"access": "Available in most countries with a fertility sector but funded unevenly: NHS-funded cycles fell from 35 percent of UK treatments in 2019 to 27 percent in 2023, and a self-funded cycle costs several thousand pounds or dollars before optional extras.",
"reversibility": "irreversible",
"issues": [
"Cost figures are given for the UK only; a comparable US and international picture is missing."
],
"tags": [
"reproduction",
"ivf",
"embryo selection",
"fertility",
"regulation",
"bioethics"
],
"categories": [
"reproduction",
"society"
],
"updated": "2026-07-28",
"wordCount": 1289,
"readingMinutes": 6,
"url": "https://futurehumanwiki.com/wiki/in-vitro-fertilisation",
"raw": "https://futurehumanwiki.com/raw/in-vitro-fertilisation",
"outbound": [
"embryo-selection",
"germline-editing",
"cryonics",
"polygenic-embryo-screening",
"mitochondrial-replacement-therapy",
"in-vitro-gametogenesis",
"he-jiankui-affair",
"crispr-cas9",
"governance-of-genome-editing",
"designer-babies",
"induced-pluripotent-stem-cells",
"synthetic-embryos",
"access-and-inequality",
"ectogenesis",
"reproductive-longevity",
"artificial-womb",
"uterus-transplantation"
],
"wantedLinks": [],
"backlinks": [
"cancer"
],
"history": {
"url": "https://futurehumanwiki.com/wiki/in-vitro-fertilisation/history",
"revisions": 1,
"edits": 0,
"currentRevision": 1,
"currentRevisionAt": "2026-07-28T17:44:01.747Z",
"createdAt": null
}
}A token is worth nothing to a consumer who cannot see the list it came from. contested and experimental are not self-explanatory, and the difference between them is the entire point of the field, so the definitions are published as data alongside the corpus rather than left in the source. They are the same strings this site prints beside its own badges.
| Vocabulary | Terms | Values |
|---|---|---|
types | 7 | concept, technology, intervention, organization, person, event, risk |
statuses | 6 | established, emerging, experimental, speculative, contested, historical |
horizons | 7 | historical, present, late 2020s, 2030s, 2040s, 2050s+, indefinite |
trl | 9 | 1 basic principles observed … 9 proven in operation |
reversibility | 5 | reversible, partly-reversible, context, difficult, irreversible |
categories | 13 | longevity, genetics, cybernetics, minds, enhancement, reproduction, bodies, nanomedicine, space, society, people, organizations, foundations |
sourceTypes | 9 | paper, preprint, trial, regulator, report, book, news, statement, law |
It also carries the per-type applicability rules and a fields map describing every key in a corpus record, which together are what let a consumer interpret the corpus without reading this repository.
/raw/<slug>returns the current revision’s markdown source, frontmatter included, served as text/markdown. These are the same bytes the revision’s stored checksum is measured over, and the same bytes the corpus held as files. Every record in corpus.json carries its own raw URL, so a crawl needs no URL construction.
This exists because HTML extraction destroys the parts of an article that are hardest to reconstruct. Each footnote definition begins with a source-type token saying whether the citation is a peer-reviewed paper, a preprint, a trial registration, a regulator’s decision or a company’s own statement. Some carry a {…} note saying why that source is the one cited and what it did not measure. Infoboxes, timelines and comparison tables are JSON inside fenced blocks. Links are [[slug]], which name the target rather than a URL. All of it survives in source and none of it survives being read out of a rendered page.
The route is served with X-Robots-Tag: noindex. It is a machine surface, not a second copy of the wiki competing with the articles.
/llms.txt follows the llmstxt.org convention: the whole wiki as an index, one line per article with its summary and classification, grouped by portal. It is a map, and answers nothing on its own.
/llms-full.txtis the other end of that trade — every article’s markdown source in one document, 284,818 words of it. It is the largest thing this site serves by a wide margin, so its header states its own byte size before the body starts and names the smaller endpoints that answer most questions without it.
Every save writes a revision holding the complete article — frontmatter and body, not a patch — and revisions are append-only: the database refuses to rewrite or delete one. The log currently holds 205 revisions across 205 articles, all of which are the migration that loaded this corpus. Nobody has edited an article since, so the log is a record of a load and not yet an edit history.
There is no JSON endpoint for the log. What a consumer can get is a summary and per-article pointers in corpus.json: a top-level history object with the totals above, and on every article record a history object carrying revisions, edits, currentRevision, currentRevisionAt, createdAt, and the url of its history page. The versions themselves are HTML:
/wiki/<slug>/history — every revision of one article, newest first/wiki/<slug>/history/<number> — the article as it stood at one revision/wiki/<slug>/diff/<older>/<newer> — the difference between two of themTwo nulls are meant rather than missing. createdAt is null for every article imported from the markdown corpus: this wiki has no record of when those pages were first published, because the log begins where the database does, and a reconstructed creation date would be an invented fact of exactly the kind the editorial policy forbids in an article. A soft-deleted article disappears from corpus.json and from /changes entirely while its history page keeps rendering, because deleting a page here hides it without touching what it said.
Two different dates now describe an article and they are not interchangeable. The updated field is an editorial claim: the day an editor judged the text to have meaningfully changed. It is typed by hand, it is a date rather than an instant, and it deliberately does not move for a save a reader would not notice. history.currentRevisionAt is the instant the current version was written, which the database recorded and nobody chose.
The site keeps them apart. The feed publishes the editorial date, because a subscriber is promised revisions rather than saves, and the sitemap emits it as lastmod once more than one date exists in the corpus. Updated dates groups the corpus by that field and reconciles it against the log, naming any article that claims a change newer than anything recorded. Recent changes lists the saves. In the structured data on an article page, dateModified is the revision instant once the article has been edited and the editorial date until then, because reporting the moment of a database migration as the moment every article changed would be false to the second.
What the corpus supports a time series on with no caveats at all is its subject matter rather than its own history: the timeline collects every dated event written inside an article, each attached to the article that cites it.
The corpus is a Postgres database. One row per article holds identity and a pointer to its current revision; the text lives in an append-only revisions table, one row per save. A build reads the live corpus in a single query, renders every page and every endpoint on this list from that read, and emits static files. Nothing on this site queries a database when you request it.
Until recently the corpus was a directory of markdown files in the repository, and saying what that arrangement was worth is the honest way to describe replacing it. It meant the whole wiki could be cloned, read, diffed and rebuilt with no service running anywhere; that the edit history was git log, which nobody had to build and everybody already knew how to read; and that the backup problem was solved by the fact that every contributor had a copy. All three of those are now gone. The site cannot be built without reaching a database, the history is a table that exists in one place, and keeping a copy of it is a job somebody has to do on a schedule rather than a consequence of cloning.
What was bought with that: an edit can be saved from a browser by someone who does not have a checkout, two editors saving against the same version get an error instead of one of them losing their work, and every version of every article is addressable and comparable rather than reachable only through the tooling of a version control system. Those are the properties a wiki is supposed to have, and files could not provide them without reimplementing a database badly.
One property was deliberately preserved: /raw/<slug> and /llms-full.txt still serve the exact markdown the files held. The export is byte-identical to what was committed, which is what makes the move reversible in principle rather than only in intention.
Slugs are the primary key and are stable; a renamed slug is treated as a break to be fixed, and every URL the previous version of this site published still resolves. Both JSON files carry a format integer that changes when the shape changes, and not when the corpus does. Fields may be added within a format; existing keys will not change meaning under one.
Values inside the vocabularies are the parts most likely to move, because the corpus grows into them. Read /taxonomy.json at the same time as /corpus.json rather than hard-coding a list.
Text is CC BY-SA 4.0: reuse it, including commercially, with attribution and under the same licence. Images are not included in any of these endpoints and carry their own licences, each named on the credits page.
Cite the dataset as:
Future Human Wiki (futurehumanwiki.com). Corpus dataset, 205 articles. CC BY-SA 4.0. https://futurehumanwiki.com/corpus.jsonOne thing worth saying about what a citation of this corpus is worth. The fields are editorial judgements made under a stated policy, not measurements: a readiness level is one editor’s reading of how far a technology has been built, and the status grade scopes to the specific application an article describes rather than to every use of the platform behind it. The rules those judgements follow are on the editorial policy page, and the places the corpus says it is unsure are collected at open questions. Counting the corpus tells you what this wiki claims. It does not tell you what is true.