Skip to content

Downloads

Stable, machine-readable artifacts from the Encyclopedia of Abstractions. Every registered file is copied byte-for-byte from its build output and covered by the public checksum manifest below.

Which graph download should I use?

Integrity / provenance

Catalog data (JSONL)

  • Prime abstractions — encyclopedia.primes.jsonl.gz (9.5 MiB) — One JSON object per prime abstraction (the detailed v2 record): slug, name, one_liner, categories, origin domain[s], aliases, and the full prose of every section (Core Idea, Structural Signature, Clarity, Manages Complexity, Abstract Reasoning, Knowledge Transfer, Examples, Structural Tensions, Solution Archetypes, Notes) plus fact anchors and word count. The complete text of the prime catalog in one line-delimited file — feed it to an assistant or index it directly. Gzip-compressed (gunzip it, or read directly with pandas / gzcat). Schema in encyclopedia.manifest.json.
  • Domain-specific abstractions — encyclopedia.domain_specific.jsonl.gz (18.6 MiB) — One JSON object per domain-specific abstraction (the detailed v2 record, with the concise v1 one_liner folded in): slug, name, one_liner, candidate domain / subdomain, and the full prose of every section (Core Idea, Scope of Application, Clarity, Manages Complexity, Abstract Reasoning, Knowledge Transfer, Notes). The second-layer catalog — abstractions that live inside a single field — in one file. Gzip-compressed (gunzip it, or read directly with pandas / gzcat). Schema in encyclopedia.manifest.json.
  • Solution archetypes — encyclopedia.archetypes.jsonl.gz (8.7 MiB) — One JSON object per solution archetype: slug, name, canonical family, source / related primes, components, mechanisms, the essence and compression statements, the problem signature (structural problem, triggers, symptoms, root tension, anti-signatures), the intervention signature (action logic, decision rules, target invariants, expected outcomes), and every prose section. Both generated and hand-curated archetypes, distinguished by a source field. Gzip-compressed (gunzip it, or read directly with pandas / gzcat). Schema in encyclopedia.manifest.json.
  • Components — encyclopedia.components.jsonl.gz (376.8 KiB) — One JSON object per solution-archetype component (the parts archetypes decompose into): slug, name, and the list of archetypes each component appears in with a count. The connective layer between archetypes and the mechanisms that implement them. Gzip-compressed (gunzip it, or read directly with pandas / gzcat). Schema in encyclopedia.manifest.json.
  • Mechanisms — encyclopedia.mechanisms.jsonl.gz (1.8 MiB) — One JSON object per mechanism (concrete implementation machinery that instantiates part of a solution archetype): slug, name, the archetypes it appears in, and a documented flag. Where an authored page exists (documented: true) the record is enriched with its one_liner, mechanism_type, instantiating archetype, and the components it implements; un-authored mechanisms are name-only until written. This is a progressive build — the full set is the ceiling and the documented fraction grows each release — so expect many name-only entries for now. Gzip-compressed (gunzip it, or read directly with pandas / gzcat). Schema in encyclopedia.manifest.json.
  • Schema manifest — encyclopedia.manifest.json (3.9 KiB) — Self-describing companion to the five catalog JSONL exports (uncompressed — it is tiny): schema version, the record shape (field list) for primes, domain-specific abstractions, archetypes, components, and mechanisms, per-file record counts at build time, and provenance notes (which corpus directories each file is read from).

Reference registry

Every work the encyclopedia cites, deduplicated into a registry of unique works, plus the article-to-work edges that connect them to the claims they support. Start with the works file for a bibliography; use the citations file to ask which claims rest on a given source. The manifest carries the checksums, the schemas, and an explicit list of what the data does not cover. Browsable at /references/.

  • Reference registry (works) — references.jsonl.gz (4.0 MiB) — One JSON object per unique WORK the encyclopedia cites, deduplicated from the corpus's footnote definitions: stable id, title/subtitle, authors, container, year, DOI/ISBN, the chosen canonical link plus every link variant the corpus actually used, publication type, intellectual base, derived domains, and how often it is cited. The unit of identity is the edition, not the title — a 1988 book and its 2013 revised edition are two records, because they carry different content. Coverage is uneven across catalogs; the breakdown is on the references page. Gzip-compressed (gunzip it, or read directly with pandas / gzcat). Schema in references.manifest.json.
  • Reference registry (citations) — citations.jsonl.gz (6.1 MiB) — One JSON object per article-to-work EDGE: the citing article as a typed id, the work's registry id, the footnote key as authored, whether the reference is attached to a claim in the body or merely listed, the claim markers it supports, and the sentence it terminates. Edge-level rather than work-level because what a source supports is a property of the claim, not of the work — which is also why contested-claim data will land here rather than on the work. Gzip-compressed (gunzip it, or read directly with pandas / gzcat). Schema in references.manifest.json.
  • Reference registry manifest — references.manifest.json (1.9 KiB) — Self-describing companion to the two registry exports (uncompressed — it is tiny): record counts, byte sizes and SHA-256 checksums for both the raw and gzipped files, pointers to the two JSON Schemas, and an explicit caveats list naming what the data does not cover — uneven per-catalog coverage, works with no assignable publication type, and works with no authoritative link yet.

Version history

  • Entity versions — versions.jsonl.gz (10.2 MiB) — One JSON object per versionable entity (prime, domain-specific abstraction, solution archetype, mechanism), keyed by slug: its current version, the date that edition was published, the content hash it was computed from, the per-part sub-hashes, its source files, and the summary of the change that produced it. The index behind every "Version" header and History link on the site. Gzip-compressed. Schema in versions.manifest.json.
  • Editions archive — editions_archive.jsonl.gz (143.1 MiB) — The full history, append-only: one record per (entity, edition) carrying the complete canonical content snapshot for that edition, its content hash, the change summary, and the specific per-part diffs against the previous edition (which parts moved, prose versus structure, and the unified diff of the prose). Delta-only — a publish snapshots just the entities that changed — so this is the artifact that shows exactly what changed between any two versions of any entry. This is the CONTINUING archive: it grows with every publish, and corrections reach it as new editions rather than as edits to old ones. A stray parent_in_child schema token was removed from 24 DAG-edge reasons in the corpus on 2026-09-07; the 37 editions published before then record it faithfully and always will, and the corrected prose appears here in the editions cut by the first publish after that date. The errata file below lists every affected edition. Gzip-compressed.
  • Editions index — editions_index.jsonl.gz (1.5 MiB) — A compact row per edition (entity, version, date, change summary, which parts changed and how) with the byte offset of the full record inside editions_archive.jsonl, so a consumer can seek straight to any edition without reading the whole archive. Fully derived from the archive. Gzip-compressed.
  • Version index schema — versions.manifest.json (4.1 KiB) — Schema, entity counts by type and version, the extractor identity and source mode each type's content hash was computed with, and the digest of versions.jsonl. Read this to know exactly what was hashed.

Frozen releases

Sealed, never regenerated. The archive and index here are the edition history exactly as it stood on the date in their names, with the errata file alongside them recording what is known to be wrong inside it. They exist so a claim about what was published on a given date can still be checked against a fixed, citable file. They are preserved as published, defects included, because every edition's content hash is computed over its stored prose — repairing the prose would either break hash verification or forge a hash for content that was never published.

  • Editions archive, sealed at the 2026-09-06 publish — eoa_editions_archive_2026-09-06.jsonl.gz (120.0 MiB) — The edition history exactly as published on 2026-09-06 — 18,561 editions across 15,557 entities — byte-identical to what this site served on that date, and never regenerated. Same schema as the live archive above. Kept because a published record should stay retrievable as published, including its defects: 37 editions of 17 entities here carry a bare internal schema token (parent_in_child) inside canonical_content_snapshot.parts.dag_edges[].reason, an authoring slip corrected in the corpus on 2026-09-07. It is preserved rather than repaired, because each edition's stored content_hash is computed over that exact prose — editing it would either break hash verification or forge a hash for content that was never published. The errata file lists every affected edition. Use the live archive for current content; use this to verify what was actually published. Gzip-compressed.
  • Editions index, sealed at the 2026-09-06 publish — eoa_editions_index_2026-09-06.jsonl.gz (1.2 MiB) — The seek index matching the sealed archive above. Because the archive is append-only, the sealed file is a byte-exact prefix of the live one, so these offsets resolve against either — this index simply stops at the 2026-09-06 publish. Gzip-compressed.
  • Errata for the sealed editions archive — eoa_editions_archive_errata_2026-09-06.json (66.7 KiB) — About 66 KB naming every known defect in the sealed archive above: the affected typed ids, the exact (entity, version) editions, the field path, what the text should have read, and when the corpus was corrected. The honest alternative to rewriting history — the archive stays as published and this file says what to know when reading it.

Solution-archetype trigger logic

The condition-level relationship between solution archetypes and the prime and domain-specific catalogs. Start with the JSONL for analysis or LLM ingestion; use the schema and manifest to validate its meaning and provenance.

  • Solution-archetype trigger logic — JSONL (21.2 MiB) — One presentation-safe record for each of the 1,134 solution archetypes in the completed trigger-relinking corpus and append-only extension: remedy-free diagnostic problem, DNF condition sets, accepted prime and domain-specific groundings, required guards, open residuals, coverage state, explanatory-copy provenance, and source-ledger hashes. This is the machine-readable source for the ‘When This Archetype Applies’ section on archetype pages.
  • Solution-archetype trigger logic — schema (18.1 KiB) — JSON Schema for the reader-facing trigger-logic projection, including typed catalog references, condition-set logic, guards, residual research states, coverage counts, and provenance boundaries.
  • Solution-archetype trigger logic — build manifest (2.3 KiB) — Input and output hashes, projection version, record count, and validation status for the trigger-logic publication artifact.

Diagnostic applicability graph

A condition-preserving factor graph for asking when a solution archetype is worth examining. It connects primes and domain-specific abstractions to atomic structural conditions, conditions to conjunctive sets, and alternative sets to archetypes. Residuals and non-trigger requirements remain explicit. This graph complements the hierarchy below; it does not add hierarchy edges. Start with the compressed indexed bundle, or use the node and relation streams for graph tooling.

  • Diagnostic applicability graph — indexed bundle (4.6 MiB) — The complete condition-level graph in one compressed JSON object: all prime, domain-specific, structural-condition, condition-set, archetype, residual, supporting-context, and non-trigger nodes; every typed relation; and the forward and reverse indexes needed for traversal. Condition sets are AND; alternative sets are OR. This is an applicability graph, not a hierarchy.
  • Diagnostic applicability nodes — JSONL (2.3 MiB) — Compressed streaming node table for the diagnostic applicability graph. Includes the full current prime and domain-specific catalogs so consumers can distinguish a known abstraction with no applicability links from an unknown identifier.
  • Diagnostic applicability relations — JSONL (1.1 MiB) — Compressed streaming relation table preserving trigger grounding, supporting context, condition-set membership, alternative diagnostic routes, non-trigger requirements, and open residuals as separate relation types.
  • Diagnostic retrieval documents — JSONL (437.3 KiB) — Compressed diagnostic heads and atomic structural-condition predicates used for candidate retrieval. Similarity against these documents proposes archetypes to inspect; it does not establish that a condition or complete diagnostic route holds.
  • Diagnostic applicability graph — build manifest (3.5 KiB) — Source hashes, schema identity, node and relation counts, validation status, and byte-level SHA-256 records for every raw and compressed graph artifact.
  • Diagnostic applicability graph — validation record (1.4 KiB) — Machine-readable integrity checks for endpoint resolution, relation typing, acyclicity, complete catalog coverage, DNF preservation, trigger groundings, supporting context, residuals, and the exclusion of discovery-history edges.
  • JSON Schema — diagnostic applicability graph v1 (5.3 KiB) — Draft 2020-12 JSON Schema for the indexed diagnostic applicability bundle, including its graph semantics, typed nodes, typed relations, source hashes, and traversal indexes.

Typed mixed DAG (canonical)

These are the authoritative schema-v2 graph artifacts. Typed IDs preserve Prime and Domain-specific identity; every logical relation and its proof fields are present. See the typed mixed-DAG consumer contract for direction and edge semantics.

  • Canonical typed nodes — mixed_dag.nodes.jsonl (4.0 MiB) — One schema-v2 record per abstraction, with collision-safe node_id, node_kind (prime or domain_specific), declared source type, canonical route, one-liner, and source path. Pair this streaming-friendly node table with mixed_dag.relations.jsonl. Validated by node.v2.schema.json.
  • Canonical logical relations — mixed_dag.relations.jsonl (12.4 MiB) — One schema-v2 record per logical relation, using typed child and parent IDs. Includes relation identity, edge type and effective flavor, qualifier, short proof, full justification, condition or exception, and normalized mutual endpoint explanations. Validated by relation.v2.schema.json.
  • Canonical indexed graph bundle — mixed_dag.json (21.3 MiB) — The same typed nodes and logical relations in one JSON object, plus collision-safe by_child and by_parent indexes. Use this when loading one in-memory graph is more convenient than joining the two JSONL streams.
  • Canonical graph manifest — mixed_dag.manifest.json (5.2 KiB) — Counts, graph diagnostics, edge vocabulary and direction, frozen-release validation, topology and identity seals, byte sizes and SHA-256 hashes, schema locations, and the status of the prime-only compatibility projection.
  • JSON Schema — typed DAG node v2 (1.6 KiB) — Draft 2020-12 JSON Schema for every record in mixed_dag.nodes.jsonl, including cross-field constraints among typed identity, declared type, route, and canonical source path.
  • JSON Schema — typed DAG logical relation v2 (3.9 KiB) — Draft 2020-12 JSON Schema for every record in mixed_dag.relations.jsonl, including direction, allowed endpoint-kind pairs, flavors, qualifiers, proof fields, and mutual normalization.

DAG convenience export

A denormalized, node-oriented rendering of the same canonical mixed graph. Choose this for document retrieval or LLM ingestion; choose the canonical node/relation streams above for graph computation.

  • Node-oriented mixed-DAG convenience export — hierarchy.jsonl (25.1 MiB) — One JSON record per typed prime or domain-specific abstraction carrying its node ID, canonical route, identity metadata, curated one_liner, first Core Idea paragraph, and every parent relation with full reason text. The whole mixed DAG is recoverable, but this denormalized shape is optimized for browsing, LLM ingestion, and node-at-a-time analysis rather than graph database loading. Schema documented in hierarchy.manifest.json.
  • Convenience-export manifest — hierarchy.manifest.json (2.9 KiB) — Self-describing companion to hierarchy.jsonl: schema version, field definitions, relation storage rule, direction, edge vocabulary, corpus and relation counts, release seals, byte size, and SHA-256 hash.

Prime-only DAG (legacy compatibility)

Compatibility only — not canonical. These files intentionally omit all domain-specific nodes and every non-prime-to-prime relation. The projection manifest gives the exact current omissions. New consumers should not start here.

Inverse Innovation

Report and data

The public research report and its harmonized evidence layer. Start with the complete Markdown report for reading, the publication package for audit context, or the candidate JSONL for computational use.

  • complete report (Markdown) (776.0 KiB) — The main research report, all 59 candidate dossiers, artifact index, and expert-review appendix in one Markdown document. Reader-facing revision: August 2026.
  • publication package (7.0 MiB) — The report source package, complete Markdown edition, candidate data, editorial derivation records, literature review, nearest-systems matrix, report design, validation result, and revision history.
  • 59-candidate dataset (594.6 KiB) — One harmonized machine-readable record per dossier candidate, including endpoint, archetype, domain, proposal, prior-art sources, practical scores, cost bands, tests, risks, and original-artifact paths.
  • canonical report facts (196.1 KiB) — The cross-experiment quantitative fact table used to audit the report's counts, denominators, outcomes, and resource claims.
  • publication manifest (2.2 KiB) — Machine-readable publication identity, ordered source components, website chapters, candidate counts, display-revision policy, and release identifier.
  • data and archive manifest (5.1 KiB) — Sizes, SHA-256 digests, file counts, scope, and archive policy for the report, code, harmonized data, and fifteen raw experiment downloads.
  • public-release audit (458 B) — The credential-pattern scan, local-path disclosure, and explicit cache/OS-file exclusions applied before packaging the experimental tree.
  • analysis and execution code (11.2 KiB) — The inverse-innovation builders, controllers, analyzers, validators, sealers, and publication scripts referenced by the artifact index.

Raw experiments

Complete, separately packaged records for Experiments 1–11. The per-experiment archives keep the full program downloadable without forcing readers to fetch one very large all-or-nothing bundle. File counts and checksums are in the inverse-innovation data manifest above.

  • Experiment 1 — calibration archive (6.6 MiB) — Complete Experiment 1 design, prompts, cells, outputs, reviews, analyses, and audits.
  • Experiment 2 — mechanism-context archive (28.2 MiB) — Complete Experiment 2 pilot and main-20 records, iterative trajectories, blinding materials, opportunity assessment, analyses, and source snapshot.
  • Experiment 3 — 320-cell matrix archive (24.1 MiB) — Complete matrix, closed-book runs, opportunity assessment, external research, amendments, analyses, and completion records.
  • Experiment 4 — retrieval-order archive (17.5 MiB) — Complete paired proposal-first versus retrieval-first design, searches, trajectories, evaluations, analysis, and resource records.
  • Experiment 5 — proposal-portfolio archive (16.2 MiB) — Complete five-proposal portfolio pilot, diversity audits, researched evaluations, revisions, analysis, and resource records.
  • Experiment 6 — 60-cell replication archive (53.5 MiB) — Complete four-proposal generalization run, partner-lane calibration and adjudications, researched trajectories, analyses, and telemetry.
  • Experiment 7 — retrospective selector archive (40.4 MiB) — Complete blinded selector design, decisions, frozen policies, false-negative analysis, validation, and resource records.
  • Experiment 8 — yield-decomposition archive (12.0 KiB) — Frozen post-hoc method, complete archetype and domain decompositions, machine-readable results, and interpretive report.
  • Experiment 9 — archetype-breadth archive (23.9 MiB) — Complete 50-archetype, 150-cell breadth probe: corrected design freeze, canonical archetype packets, 150 closed-book proposals, 150 four-source screens, analysis, validation, raw calls, and telemetry.
  • Experiment 10 — proposal-type archive (9.2 MiB) — Frozen post-hoc method, 422 blinded inputs, withheld outcomes, two classifier passes, third-pass adjudications, joined analysis rows, raw call records, and report.
  • Experiment 11 — externally researched context comparison (11.1 MiB) — Complete 20-cell comparison of relevant mechanisms, archetype-only context, and irrelevant mechanisms after eight-source external scrutiny: blinded inputs, amendments, 60 evaluations, 49 judgments, analysis, validation, and telemetry.
  • Experiment 12 — paired substrate-denial intervention (26.7 MiB) — Complete 72-cell matched intervention and triggered 18-cell Max follow-up: frozen design, prompts, 108 proposal calls, blinded classifications and quality judgments, 102 authorized web screens, analyses, validation, and telemetry.
  • Experiment 13 — second-slot portfolio policy (62.3 MiB) — Complete 60-cell comparison of ordinary and alternative-substrate second proposals: probability-sampled archetypes and domains, frozen design, 180 proposals, blinded classifications and quality judgments, web screens, analysis, validation, and telemetry.
  • Experiment 14 — Applicability Graph retrieval and verification (9.4 MiB) — Complete 40-archetype, 120-case construct benchmark: frozen design, case corpus, duplicate blinded audits and adjudications, sealed retrieval outputs, 114 opaque DNF verifications, analysis, validation, and telemetry.
  • Experiment 15 — Route-aware diagnostic retrieval (13.3 MiB) — Complete fresh 40-archetype, 120-case construct replication: frozen design, case corpus, duplicate blinded audits and adjudications, seven sealed retrieval arms, post-hoc failure localization, analysis, validation, and telemetry.

Learnability

  • Learnability data export — learnability.jsonl (6.2 MiB) — One JSON object per prime: slug, name, tier, curriculum order, the lowest age at which a faithful explanation is possible, all 5 age-graded explanations (ELI5/10/15/18/specialist), and 3 levels of everyday-English name (ELI5/10/15). Includes na_reasons for the 9 K-unteachable primes where some lower levels genuinely cannot be reached. Intended for LLM consumption — feed it to an assistant to build adaptive curriculum, run teach/test exercises, generate questions or worked examples, or build a learner-or-teacher game. Schema documented in learnability.manifest.json.
  • Schema manifest — learnability.manifest.json (3.4 KiB) — Self-describing companion to learnability.jsonl: schema version, field definitions, level targets (word-count budgets and vocabulary constraints per ELI level), source-file hashes, tier-distribution stats, and intended-use notes.

Companion writing

  • The Nothingness Ladder (363.9 KiB) — A ~16,000-word standalone essay structured as a four-rung hierarchy of what "nothing" could mean (quantum vacuum → topological vacuum → metageometric void → logical nullity). Not part of the encyclopedia catalog itself, but a worked example of the kind of cross-domain abstraction the catalog tries to surface. Linked from the About page.

Miscellaneous

  • Distinctiveness pipeline — prime_labeling.py (40.2 KiB) — The re-runnable script that computes each prime's distinctiveness / neighborhood-density and the families (incremental + batch-recompute modes). See the conceptual paper Distinctiveness and the Neighborhood Structure of Abstraction Space.
  • Runtime-scaffolding experiments — raw data (projects 02–04) (1.3 MiB) — Every prompt, model output, private manifest / blinded-grade mapping, coverage key, grade-set, and score from the A/B/C/B′ verb-engine, low-coverage, and faithfulness experiments, plus the re-runnable harness scripts. The reproducibility bundle behind the retrospective The Limits of Runtime Scaffolding.
  • Operator-driven prime discovery — raw data (2.3 MiB) — The reproducibility bundle behind the conceptual papers Operator-Driven Discovery of Prime Abstractions and The Operator Compendium. Every quantitative claim's raw material: the per-application crank outputs for all fourteen operators (input prime, proposed candidate, NEW/COLLAPSE verdict, nearest existing prime) — from which every NEW-rate, fixed-point census, and convergence count can be independently recomputed; the per-operator result ledgers (prose + a machine-readable operators_summary.csv); the fixed-point / already-X audit censuses behind the saturation gradient; the 128 candidate-prime stubs the search surfaced; the ~295 candidate hierarchy edges harvested as a byproduct; the retained hard-negatives; and the frozen Stage-0 prompt for every operator. A README maps each file to the paper claim it substantiates. Snapshot 2026-07-04, corpus frozen at 1,325 primes; acceptance counts provisional pending final human curation (the raw data itself is final).
  • Learnability scoring + ELI ladder — implementation bundle (42.4 KiB) — The five re-runnable Python scripts behind the By-Learnability page: the curriculum scorer (Kahn's topological sort with difficulty priority queue), the ELI ladder setup + consolidator (triangulated 3-generator + 1-judge pipeline), the page builder, and the v0.5 weight-tuning experiment. Each script is single-file and dependency-free. The conceptual paper Curriculum Construction over a Prime Catalog is included, plus a README explaining how the pieces fit together and what external inputs (Kuperman 2012, Brysbaert 2014) are required.