How the atlas is built

The canonical scientific unit is a claim: subject —predicate→ object, with conditions, evidence, evidence status and review provenance. Process claims may additionally record an energy ledger, a constitutive relation and explicit handoff tokens. Entities provide the things those claims refer to: disequilibria, phenomena, carriers, outputs, quantities, materials, constraints, coupling families and devices.

Entities come in these types: system, quantity, disequilibrium, state, interaction, phenomenon, transition, carrier, coupling family, transducer, material, constraint and output. Only four of them can sit in a route — disequilibrium, phenomenon, carrier and output. The rest describe conditions, bounds, materials and devices. A coupling family (thermoelectric, piezoelectric, osmotic, …) is a column of the matrix; a phenomenon belongs to a family through a member_of claim; a disequilibrium is a row.

The predicates are:

drives · produces · couples_to · converts_into · mediated_by · member_of · implemented_by · requires · inhibited_by · enhanced_by · bounded_by · conserves · dissipates_to · observed_in · predicted_in · demonstrated_with · governed_by

Four of them — drives, produces, couples_to, converts_into — carry energy from one node to the next and are the only ones route construction follows. Process claims are expected to record an energy ledger; missing ledgers are permitted by the schema and cause the relevant physics checks to return unresolved or unknown rather than being silently inferred. In this revision 261 claims are process claims (1 without a ledger); 16 claims carry a constitutive relation and 126 carry machine-checkable condition tags.

A condition tag on a claim applies in a scope — medium (the matter the phenomenon acts in), boundary (a surface, contact or gap the step uses) or environment (a surrounding field, atmosphere, vacuum or source) — and on a named region of the device (active unless the claim says otherwise): condition_requirements, expanded from the flat tags with each tag's default scope when a claim has not been curated. Entity-level tags describe the entity and are never inherited into a route step. Two requirements can conflict only in the same scope on the same region — as members of one exclusive group (material state; coarse temperature regime) or as one of the few universal same-region incompatibilities — and an adjacent-step change of medium on the same continuing region is a region transition that an interface record must name: a gas–solid acoustic boundary, an electrode contact, a heat-exchanger wall, a window, a membrane, a coupling, a free surface. A demonstrated record resolves the transition; a theoretical or proposed one is shown on the route and leaves the boundary check unresolved; none leaves it unresolved and the interface unrecorded. Interface records live in data/canonical/interfaces and are served in /api/graph.json.

Definitions of every enumerated value — entity types, predicates, statuses, energy forms, domains — are generated from one source file and served as /api/vocabulary.json (docs/vocabulary.md). This page renders those definitions where it needs them rather than restating them. The ontology itself is described in docs/ontology.md.

From each disequilibrium, the compiler follows only drives, produces, couples_to and converts_into claims depth-first. It never revisits a node, stops after 7 claims, records routes that reach an output, and stops after 4,000 enumerated routes per source. Route ids are the first ten hexadecimal digits of SHA-1 over the ordered claim ids. Literature search does not generate these routes.

If a route's claim sequence is exactly a named, reviewed pathway (a thermoelectric generator, a wind turbine, a hydrovoltaic generator) it inherits that pathway's status, knowledge level and measured performance; otherwise it has none of its own. This revision enumerated 771 routes from 25 disequilibria; no disequilibrium reached the per-source cap, so no route set is truncated. The algorithm is specified in docs/candidate-generation.md.

A route and a pathway are one linear causal chain from one source to one terminal output. A combined-cycle plant is not: its topping gas turbine delivers electrical work and hands its exhaust enthalpy to a bottoming steam cycle — one step with two outputs. Since loop-3 pass 34 the atlas records such architectures as systems: members reference whole pathways by role, a handoff records the residual stream from one member to the disequilibrium the next member's route starts from (the loader checks it is that route's actual source), and outputs say which members deliver what and whether they add. A handoff is never a route claim, so system topology never enters route enumeration or the candidate frontier; the eight checks are not run over a system — it shows its members' route results and its handoffs' status, and a system is not clear merely because its members are. A system's efficiency lives on the system and on no member: the 46.93 % of the Omani combined-cycle station belongs to the natural-gas combined cycle, not to the gas-turbine pathway that had been carrying a combined-cycle record figure until this pass. Served as /api/systems.json.

Every route is passed through eight checks. Each returns pass, fail, unresolved (the data needed to decide is partly present) or unknown (none of it is recorded), and a sentence saying what was examined; the site shows the sentence, never just the verdict. The definitions below are the registry served as /api/checks.json, rendered here so this page cannot drift from the code. The five marked core decide whether a composition is physically coherent — the fifth, driver / regime sufficiency (loop-3 pass 30), asks whether each conversion step gets the regime it needs from its causal source rather than merely a typed edge: pyroelectricity needs a temperature that changes in time, which a static gradient does not supply, so the pyroelectric spelling from a temperature gradient reads unresolved until a route step or a stated condition supplies the change. Requirements and providers are machine-readable tokens on claims, disequilibria and reviewed pathways, every token frozen with its definition in a registry (vocabulary regime.token; an unregistered token fails validation) — since pass 36 a hot-gas → expansion step requires an expansion pressure drop the carrier itself never implies, and a pathway may supply that token only with a preceding providing step, an auxiliary_requirements entry saying how its implementation establishes it (a gas turbine's compressor, driven from its own shaft — a feedback branch no linear route carries, so it is metadata, never a route step) or, since pass 43, a regime_establishments entry for a process inside the implementation itself (the combustor and nozzle that set the pressure drop a combustion MHD generator's expansion needs — while the expansion that makes the flow is a route step, never metadata); a pathway's own structured temperatures (T_h_K, T_c_K, dT_dt_K_s, T_transition_K, cycle_frequency_Hz, from the registry served as vocabulary measurement.parameter) supply regimes to its exact route only; nothing is inferred from prose. Since pass 19 a check passes only when it has actually decided something: the thermodynamic bound passes only when a hard limit (an upper bound with its stated basis, or a formula such as Carnot evaluated from the datum's own recorded temperatures) has been compared with a comparable physical measurement — a model-scope datum (a design point, a simulation) is evaluated and reported as model-consistent or model-inconsistent but never decides the route, just as it supplies no regime (pass 33) — the dimensional check only when every conversion step carries a balanced relation, and the coverage check only when a structured datum exists. Benchmarks such as Curzon–Ahlborn and relations such as Onsager–Casimir reciprocity are listed as recorded limits and never decide. Most routes therefore read unresolved or unknown, which is the honest state of an undemonstrated composition.

Typed chain

Is every step a valid process relation and does the chain run disequilibrium → … → output without a break?

• pass every step is a typed process relation and the chain is unbroken from a disequilibrium to an output
• fail a step is not a process relation, a step is dangling, or the chain does not start at a disequilibrium or end at an output
• unresolved not used
• unknown not used

reads claim.subject, claim.predicate, claim.object, entity.type

Energy-form continuity · core

Does each step's declared output energy form match the next step's declared input form?

• pass every declared seam matches
• fail at least one adjacent pair declares mismatched forms
• unresolved some steps declare their ledger and the declared seams match, but at least one step has no ledger
• unknown no step declares its energy forms yet

reads claim.energy.input, claim.energy.output

Source work availability · core

Does the source carry exergy relative to the reference environment, and does every step account for its energy? (Not a verified first-law balance: no quantitative energy accounting is recorded.)

• pass the source has positive exergy and every step declares its ledger
• fail the source carries no exergy relative to the reference environment
• unresolved the source's exergy is conditional (it carries exergy only relative to a specific reference environment), or source exergy is positive but at least one step has no energy ledger entry
• unknown the source has no exergy assessment recorded

reads entity.exergy, claim.energy

Thermodynamic bound · core

Which hard limits (bounded_by claims whose constraint is an upper-bound or a formula-bound applying to the route's source, output and phenomena) can be evaluated against a comparable recorded datum, and does every such datum respect them? Benchmarks, constitutive relations and resource limits are listed, never decisive.

• pass at least one hard bound is fully evaluated against a physical-scope datum (laboratory, device, module, system, plant, field, or a summary efficiency — a numeric ceiling with the required basis, or a formula evaluated from the datum's recorded parameters) and every comparable physical datum is within it
• fail a comparable physical-scope datum exceeds a fully evaluated hard bound
• unresolved a hard bound applies but no physical datum can be evaluated: no datum of its metric, a datum without the required basis, missing formula inputs (for Carnot, the hot and cold temperatures of that datum), or only model-scope data — a model datum is evaluated and reported as model-consistent or model-inconsistent but never decides the physical route, exactly as it supplies no regime
• unknown no hard bound is recorded for the route (a thermal source implies Carnot, but only a bounded_by claim records it)

reads bounded_by claims, constraint.constraint_kind, constraint.metric, constraint.max_efficiency, constraint.formula, constraint.formula_inputs, constraint.requires_basis, constraint.applies_to_sources / _outputs / _phenomena, pathway.bounds[].constraint (pass 42: the exact pathway's architecture-specific bounds, same machinery), pathway.performance.measurements[].value_numeric / metric / basis / parameters

Dimensional consistency

For every step with a constitutive relation, do the input quantity, coefficient unit and output quantity balance in SI dimensions — and does every conversion step (drives / couples_to, unless marked not-applicable) carry one?

• pass every conversion step carries a relation and every recorded relation balances (bookkeeping steps — produces / converts_into — are not expected to carry one)
• fail a relation does not balance, or a quantity or unit in it is unknown
• unresolved every recorded relation balances, but at least one conversion step has no relation
• unknown no step records a constitutive relation

reads claim.relation, claim.relation_requirement, quantity.dimension, ontology/units.yaml

Boundary compatibility · core

Do the scoped condition requirements of one step conflict on the same region, or does the active medium change state between two adjacent steps without a demonstrated interface record (for example a thermoacoustic gas column next to a solid acoustoelectric element)?

• pass no two requirements of one step conflict in the same scope on the same region, no environment requirements conflict anywhere on the route, and every adjacent-step medium transition has a demonstrated interface record
• fail two requirements of one step conflict in the same scope on the same region (a listed pair, or two members of one exclusive group), or environment requirements on the same region conflict anywhere on the route
• unresolved an adjacent-step medium transition has no interface record, or only a theoretical or proposed one
• unknown no step carries a scoped condition requirement

reads claim.condition_requirements (or condition_tags with default scopes), ontology/conditions.yaml conflicts and exclusive_groups, data/canonical/interfaces

Driver / regime sufficiency · core

Does each conversion step get the regime it needs from its causal source — not merely a syntactically valid edge? Pyroelectricity needs a temperature that changes in time; a static temperature gradient supplies a spatial gradient, not that.

• pass every regime requirement recorded on a step is supplied by the route source's regime_provides, a preceding step's regime_provides (or that of the disequilibrium it produces), the exact reviewed pathway's regime_provides, or an independent external condition the step records (never a property of its own subject)
• fail the route source's regime_excludes names a required regime nothing else supplies
• unresolved a requirement is recorded but no provider is recorded
• unknown no step records a machine-readable regime requirement

reads claim.regime_requires / regime_provides / regime_external, entity.regime_provides / regime_excludes, pathway.regime_provides

Measured performance coverage

Does the recorded pathway carry a structured measurement — value, unit, regime and source — for this composition? A coverage statement, not a physics verdict.

• pass at least one structured measurement with value, unit, regime and source is recorded
• fail a structured datum is malformed: a conversion efficiency or power coefficient outside [0, 1]
• unresolved a performance record exists with notes but no structured datum
• unknown no performance record exists for this composition (the honest state of an undemonstrated route)

reads pathway.performance.measurements

Measured performance coverage is one of the eight checks and asks whether the recorded pathway carries a structured measurement for the whole composition; it is a coverage statement, not a physics verdict. magnitude_screen is a separate frontier-ordering diagnostic: quantified means whole-composition measurements exist; relation-complete means every relation-required conversion step — a drives or couples_to step, or one whose relation_requirement is required; a produces step projects the carrier its phenomenon emits and is not asked for one, the same notion the dimensional check uses — carries a dimensionally valid constitutive relation, and no route magnitude is thereby asserted (a formula with no coefficient value bounds nothing numerically, which is why the value is not called bounded); missing means at least one such step has no relation. Interface transmission relations stay outside the screen (interface_model_coverage counts them separately). Neither field estimates performance.

Five different fields answer five different questions and must not be collapsed into one confidence label: claim evidence status describes a relation; route search status describes recorded searches for the whole composition; frontier class describes how an enumerated route compares with evidence, checks and recorded pathways; structural kind describes whether the route is a genuine composition or a representational/engineering variant; matrix-cell status summarizes one driver × coupling-family coordinate.

The values of each field, with the definition from the vocabulary and how often the value occurs in this revision. A value with no occurrences is still a valid value; the order in which the compiler decides between them is in docs/status-model.md.

Knowledge level is a scale, not a state layer. It places a phenomenon or a named pathway on one ladder:

A composed route with no demonstration has no level of its own: the compiler records its constituent floor (the lowest level among its claims) and caps the displayed level at K4, because the composition has only been assembled, not observed.

Candidate is an atlas classification, not a novelty claim. A frontier candidate has no failed physics check, has constituent evidence at least demonstrated, is not an energy-form round trip, has every declared carrier handoff provided by an earlier step (otherwise it is classed unresolved handoff), and is not classified as derived from a sufficiently similar demonstrated pathway. A pathway recorded with status proposed is shown on the route but does not change its class; so is one recorded with status observed — one physical experiment traversed every conversion phenomenon and handoff in order but the route's output was not delivered (a polarization, current, force or flow measured, no work), and the frontier row then leads with observed · output not delivered while the class stays candidate. The default frontier further requires structural_kind = composition. A candidate may be not searched, partially searched, or covered by a completed negative search; none of those states means that no such device or experiment exists outside the atlas.

“Derived” means the route shares with a demonstrated pathway ordered claims that contain the whole pathway, form a strict prefix or suffix of it, span two or more of its phenomena, or share its driver step and first conversion and then diverge into the same coupling family; or at least two phenomena as a source-variant or sink-variant of the closest demonstrated pathway: it extends, truncates or re-drives something known and is shown apart from fresh candidates. Sharing only a generic tail (a produced carrier turning a rotor, a rotor turning a generator) does not make a route derived, and neither does a shared first mechanism whose next conversion changes coupling family — coupling a familiar mechanism into a different family is a new composition.

A matrix cell takes the first of these that applies, in this order:

1. direct relation — a drives claim links the row's disequilibrium to a phenomenon of the column's family; the cell shows the best status among those claims (established, demonstrated, theoretical, contradicted), or insufficient when every such claim cites nothing;
2. forbidden row — the row's disequilibrium carries a second-law bounded_by claim;
3. reviewed direct demonstration — a reviewed search of the cell found a qualifying demonstration;
4. qualifying composition bridge — a route from the row through the family has structural kind composition and frontier class candidate, derived or demonstrated: the cell is a candidate;
5. reviewed negative direct search — a reviewed search that passed the protocol gate found no qualifying demonstration;
6. search incomplete — any other search record exists (an automated index run, or a reviewed search left partial or blocked);
7. not searched — no record.

So a search record can move a cell only among the last five states. It can never create a direct relation; that takes a canonical claim, reviewed separately.

A search record changes search state; it does not by itself rewrite canonical physics. An automated run freezes index results and can only produce search-incomplete. A reviewed positive can mark the searched target as demonstrated, but a new direct relation still requires a separate canonical-claim review. A reviewed negative may produce “no demonstration found” only when its protocol gate passes. A physical hit that reaches the requested coupling through a separately resolvable intermediate conversion is route-only evidence and must not promote the direct matrix cell.

The gate, enforced by the loader so that a negative that skips it fails validation:

• completeness protocol-complete-negative;
• a named reviewer and a completion date;
• no hit whose decision is “qualifies”;
• runs on every discovery engine: OpenAlex, Semantic Scholar and Google Scholar (Crossref only verifies DOIs; a manual web search does not count);
• runs in every mandatory query form: driver × family, driver × each member phenomenon, and the demonstration-precision form; the citation chase is required by the protocol but is not machine-checked;
• anything incomplete or blocked — unscreened results beyond the cap, an engine that failed, an inaccessible hit, a member phenomenon not searched — leaves the record inconclusive with completeness partial or blocked.

A positive may stop early: one unambiguous qualifying experiment, read in full, is conclusive. In this revision 13 reviewed search records and 16 frozen automated runs exist; 995 of 1000 cells have no search record of either kind. The protocol is data/canonical/searches/README.md.

The five home readouts are counts over the current compiled revision, not estimates of physics: DRIVER × COUPLING MATRIX is the number of disequilibrium rows × coupling-family columns (25 × 40); CELLS WITH RECORDED DIRECT RELATIONS counts cells with at least one canonical direct drives relation (68); CELLS WITH NO SEARCH RECORD counts cells with neither a reviewed search nor an automated run (995); FRONTIER CANDIDATE COMPOSITIONS counts routes with frontier_class = candidate and structural_kind = composition (10); ROUTES WITH COMPOSITION DEMONSTRATIONS counts routes whose whole-composition search status is demonstrated (86).

The coverage page carries the corpus-scale counts per domain and the editorial target inventories those counts are measured against.

Addresses like D.04 × C.11 are stable dataset addresses: rows and columns are numbered in file order and filtering never renumbers them, so /matrix?cell=D.04:C.11 is a permanent link to one scientific question.

claim:seebeck-drives records Temperature gradient —drives→ Seebeck effect under stated solid-conductor conditions, with thermal → electrical energy, ΔV = S · ΔT, 3 cited sources and status established. claim:seebeck-member-thermoelectric places the Seebeck effect in coupling:thermoelectric, so that direct drives claim makes D.01 × C.01 a recorded direct-relation cell. The compiler can then chain claim:seebeck-drives → claim:seebeck-produces-carriers → claim:charge-carriers-convert-electricity; that exact sequence hashes to route p-d4b83f7f17 and matches the named Thermoelectric generator pathway, which supplies whole-composition evidence and performance.

- id: claim:seebeck-drives
  subject: disequilibrium:temperature-gradient
  predicate: drives
  object: phenomenon:seebeck-effect
  condition_tags: [state-solid, medium-conductor, temp-gradient-required]
  energy: { input: thermal, output: electrical, dissipation: thermal }
  relation: { formula: "ΔV = S · ΔT", coefficient_unit: V/K }
  evidence: [source:seebeck-1826, source:goldsmid-2016, source:callen-1948]
  status: established

id: p-d4b83f7f17
nodes: disequilibrium:temperature-gradient → phenomenon:seebeck-effect → carrier:charge-carriers → output:electricity
energy: thermal → electrical
structural_kind: atomic · frontier_class: demonstrated · search_status: demonstrated
evidence_status: established (weakest: claim:seebeck-drives)
magnitude_screen: quantified
checks: typed chain: pass · energy-form continuity: pass · source work availability: pass · thermodynamic bound: pass · dimensional: pass · boundary compatibility: pass · driver / regime sufficiency: pass · measured performance coverage: pass

cell: D.01:C.01 (Temperature gradient × Thermoelectric)
status: established
direct_claims: claim:seebeck-drives, claim:thomson-drives, claim:nernst-drives
searched: false

id: pathway:thermoelectric-generator
steps: claim:seebeck-drives > claim:seebeck-produces-carriers > claim:charge-carriers-convert-electricity
status: commercial · knowledge_level: K8
measurements: 1 datum-level records
evidence: source:rowe-2006, source:snyder-toberer-2008, source:goldsmid-2016

The longer version, with what would change each of these records, is docs/worked-example.md.

Every claim except a hypothesised claim must cite at least one source; a hypothesised claim may cite none. The statuses, in the vocabulary's wording, with the minimums a test enforces:

• established — textbook physics: two independent groups, or a review or book, among the sources (tested: at least two independent first-author groups, or a review or book, among the sources)
• replicated — several groups, recent; sources from two independent first authors (tested: at least two independent first-author groups)
• demonstrated — at least one credible device or experiment
• reported — a single paper reports it; no independent confirmation recorded
• theoretically-predicted — predicted by theory, not yet observed
• hypothesised — proposed without a supporting calculation; may cite no source
• disputed — credible sources disagree
• contradicted — a credible source contradicts the claim
• invalid — the claim has been withdrawn or shown wrong

Route-level evidence is kept apart from constituent evidence. A compiled route carries constituent_source_ids (sources cited by its steps) and composition_source_ids (sources cited by a recorded pathway for the whole route, including its datum-level measurements). The site never presents the first as evidence for the composition.

Sources with a DOI are checked against Crossref by a pipeline that records whether the DOI resolves and whether the title Crossref returns matches the one on file; the result is shown beside each reference. Historical sources that predate DOIs are listed with their venue. Authoring rules: docs/evidence-model.md.

Enumeration is exhaustive only within the recorded graph and its configured bounds. The compiler follows canonical process claims only, forbids node revisits, enumerates at most 7 claims per route and stops after 4,000 routes from any one disequilibrium. Therefore “all enumerated routes” means all routes found under those rules in this revision, not all physically possible conversions.

• no route contains a cycle, so a process that genuinely revisits a node cannot be represented;
• a conversion that would need more than 7 claims is absent;
• the per-source cap can truncate a dense source; in this revision none is truncated (meta.enumeration in every export);
• a missing claim, alias or family membership cannot be discovered by enumeration — the compiler can only recombine what is recorded;
• boundary conditions and carrier handoffs that no claim records stay unresolved or unknown; they are never inferred;
• the coverage page's target inventories are editorial checklists of what the atlas intends to record, not estimates of what exists in nature.

The atlas does not infer missing physics, use a language model to create canonical relations, treat graph absence as impossibility, treat constituent evidence as composition evidence, convert an automated search into a negative result, estimate performance where no recorded magnitude exists, or claim patentability, novelty or experimental feasibility from a generated route.

Generated routes are public as compositions of recorded relations, and that is all they are. There is no review queue, no proposal pipeline and no publication policy in this release; the schema reserves a few queue statuses that the compiler never assigns.

Three facts govern how to read any status on this site. First, a status describes recorded evidence, never nature: a candidate composition is a route the atlas has not seen demonstrated, not one that cannot be built; an inconclusive search is a search whose protocol obligations are not all met, not a finding that nothing exists. Second, uncertainty stays first-class: the atlas does not convert an incomplete search into a negative, a stage figure into a route figure, or a range into a best, to close a count. Third, what the atlas does not know is enumerated, not hidden — every open uncertainty in a current record (an incomplete search with the engine and query it still owes; a hit that could not be decided for want of its text; a claim one paper reports; a figure whose boundary or definition the source does not state) is a residual, with the record it hangs on and what would close it.

The live list is api/residuals.json — 36 residuals at revision rbfbfcbb70e57 (evidence-interpretation-pending 2 · evidence-not-observed 5 · evidence-single-source 4 · measurement-boundary-unresolved 1 · measurement-definition-unresolved 1 · pathway-observed-not-delivered 1 · search-incomplete 13 · source-read-pending 9). It is a projection of the compiled atlas and its audits, regenerated with every revision, and may shrink, grow or change as work continues; it sits beside the exports and outside the v0.5.0 contract. The immutable snapshot of the same collection at the close of the third review loop, with every invariant regenerated and a separate inventory of deferred work, is design/reviews/loop-3/pass-50-closure.md; that file never updates.

The canonical data is YAML under data/canonical, source-controlled and reviewed in pull requests. Validation rejects unknown units, invalid predicates, dangling entities, missing provenance, malformed conditions and negatives that skip the search gate before anything is compiled. The compiler is deterministic: the dataset revision shown in the status rail is a hash of the canonical files, so two people building the same commit see the same numbers, and every published revision is listed with its counts and the ids it added or removed in docs/dataset-changelog.md.

Review provenance is never manufactured: a record's last_reviewed date changes only when that record was actually re-read, and generated records inherit the revision's data_hash and source_commit, not a review date. The rules for contributors are in AGENTS.md.

To cite the atlas as a dataset, use CITATION.cff and include the exact meta.data_hash of the revision used. To cite a claim, entity, source, route or matrix cell, cite its stable canonical URL together with dataset revision rbfbfcbb70e57; the stable id identifies the record and the hash identifies the canonical files from which that page was compiled. Citation does not grant reuse rights: the current dataset and code licence remain PENDING OWNER RULING.

The full data is public under /api/ — every file carries the same meta block (dataset revision, build provenance, enumeration bounds, counts, schema pointer and reuse terms): stats.json · graph.json · entities.json · claims.json · claims.ndjson · claims.csv · sources.json · pathways.json · systems.json · paths.json · matrix.json · coverage.json · checks.json · vocabulary.json · schema/v0.5.0.json. The contract is docs/data-api.md; the export format is v0.5.0.