The canonical text of TRACE v0.1. Maintained by Materiascope, licensed CC BY 4.0. The reference implementation — JSON Schema, validator and worked examples — lives in the TRACE repository.
0. Why this exists
Ashby’s method — translate, screen, rank, document — has organised material selection for thirty years and is not in question here. It was written when the data came from one curated, human-checked database, and the only question about a number was whether you had read the right row.
That assumption no longer holds. A shortlist assembled today mixes specification minima from standards, typical values from supplier datasheets, DFT results from open computational databases, machine-learned predictions, and — increasingly — numbers produced by a language model that will state them in the same font and the same tone of voice as all the others.
The numbers are not equally defensible, and nothing in the presentation says so.
TRACE adds one step to Ashby’s method and formalises another. The new step is Assess: before you rely on a value, you record where it came from and how far it can be defended. The formalised step is Export: the output of a selection is not a shortlist but a record that a third party can audit without talking to you.
This is not a claim that computed or predicted values are inferior. Some of the most useful numbers in modern materials work are computed. It is a claim that a design decision has to know which is which, and that the engineer who signs the drawing is entitled to that distinction being visible rather than reconstructable.
1. Scope and conformance language
This specification defines:
- an evidence ladder (§3) for individual values;
- rules governing how evidence levels propagate and change (§4);
- a decision procedure (§2) that produces an auditable record;
- a data structure — the Material Decision Record, MDR (§5) — that carries the result;
- three conformance levels (§6) against which a tool or a workflow can be assessed.
The key words must, must not, should, should not and may are used in the sense of RFC 2119.
TRACE governs the evidentiary quality of a selection. It does not govern engineering correctness. A record can be fully TRACE-conformant and still describe a bad decision. The framework makes a decision auditable; it does not make it right, and it does not move responsibility for it away from the engineer.
2. The five steps
T — Translate
Convert the design requirement into function, constraints, objectives and free variables. Unchanged from Ashby, and still the step most often skipped.
Each constraint must be recorded as a property, an operator, a value, a unit and the
condition it applies at. corrosion resistance: good is not a constraint. pitting resistance equivalent number PREN ≥ 32, seawater, 40 °C is.
Each objective must name the quantity to be minimised or maximised and, where a material index is used, state the index and its derivation.
Requirements that cannot be expressed as a testable constraint must still be recorded, in a separate field, as qualitative requirements. They are real — weldability, availability, approval history, a customer’s preference — and hiding them inside a numeric constraint is how selections get quietly rigged.
R — Retrieve
Assemble the candidate set. Every candidate must carry the name of the source it came from, including candidates proposed by a model.
A source is anything that supplied a candidate or a value: a standard, a handbook, a mill datasheet, an aggregator, a computational database, a paper, a supplier, a colleague, a language model. Each source must be recorded with an identifier that a third party can resolve — a DOI, a URL, a standard designation with edition, a database entry ID, or, for a model, the model name and version.
Retrieval must record the date. Computational databases are revised; aggregator entries change without notice; models are replaced. A value without a retrieval date cannot be reproduced and, under §4.3, cannot exceed E3.
Candidates rejected at this stage must be recorded with the reason. A shortlist that does not say what it excluded is not reviewable, and “what did you rule out and why” is the first question a competent reviewer asks.
A — Assess
For every value that will be used to satisfy a constraint, rank a candidate, or appear in the record, assign an origin (§3.1) and an evidence level (§3.2), and record the provenance fields required at that level.
Assessment is a human-accountable act. A tool may propose a level; a person accepts it. The
record must distinguish proposed levels from accepted ones (§5, assessed_by).
This is the step that does not exist in the classical method, because in the classical method there was nothing to assess: the data came from one place, and that place was the answer.
C — Compare
Screen against constraints, then rank on the objective. Ashby’s screening and ranking, performed on values that now carry levels.
Screening must apply the admissibility rule (§4.1). Ranking must apply the weakest-link rule (§4.2) to every derived quantity, including material indices, safety margins and scores.
Where candidates are separated by less than the stated uncertainty of the governing property, the ranking must record them as not separated rather than presenting an order that the data does not support. A ranking that is precise beyond its inputs is a fabrication performed by arithmetic.
Property charts remain the recommended presentation. Where a chart mixes evidence levels, the levels should be visually distinguished.
E — Export
Emit a Material Decision Record (§5).
The record must be self-contained: a reader who has never seen the tool, the session or the engineer must be able to reconstruct which values were used, where each came from, how well each is supported, what was rejected and why, and what the engineer decided.
The record must state the decision separately from the analysis, and must name the person accountable for it. A record with no named human is a document nobody signed.
3. Evidence
3.1 Origin
Every value carries exactly one origin. Origin describes what kind of thing the number is. It is descriptive and carries no ranking.
| Origin | Meaning |
|---|---|
measured | Obtained from a physical experiment on a physical sample |
specified | A limit set by a standard, specification or certificate, not itself a measurement |
computed | Produced by a physics-based calculation — DFT, CALPHAD, FEA, thermodynamic model |
predicted | Produced by a statistical or machine-learned model — MLIP, surrogate, generative model |
asserted | Stated without a recoverable basis — including a language-model answer with no citation |
3.2 Evidence levels
Evidence level describes how far a value can be defended in front of somebody who did not make the selection. It is a property of the record of the value, not of the underlying physics. A superb measurement, recorded without its method, is a weakly evidenced value.
E5 — Specified or certified. A specification minimum or a certified test result. Requires: named standard with designation and edition, or a certificate identifier; the clause or table; the product form; the condition. Examples: a minimum proof strength from ASTM A240; an MMPDS A- or B-basis allowable; a value from a mill test certificate for the actual heat. This is the only level admissible as a design allowable without explicit sign-off (§4.1).
E4 — Measured and traceable. An experimental value whose primary source resolves. Requires: a resolvable primary source (DOI, handbook edition and page, test report); the test method; the specimen condition; the temperature or environment. A measurement, not a limit.
E3 — Sourced but thinly traceable. A real value — measured, or computed by the source — from a supplier datasheet, catalogue or property aggregator, where the material is named but the method, sample condition or provenance chain is not. Requires: a resolvable source and a retrieval date. Sufficient for screening. Not sufficient as a design allowable. Most of what a search engine returns for a property query lands here.
E2 — Computed and transparent. A physics-based calculation that a third party could in principle repeat. Requires: the method and code; the functional, database or model parameters; a resolvable entry identifier where the calculation comes from a database; the retrieval date. A DFT elastic tensor from an open database with its entry ID is E2. The same number quoted without the ID is not.
E1 — Predicted. The output of a statistical or machine-learned model. Requires: model name and version; the training set or its citation; the quantity predicted; the reported uncertainty where the model provides one, or an explicit statement that it does not. A hypothesis with an address.
E0 — Asserted. A number with no resolvable basis. A language-model answer without a citation, a figure from a forum, a value whose origin cannot be reconstructed. E0 values must not be used to satisfy a constraint or to rank a candidate. They may appear in a record only as rejected inputs, and recording them is encouraged: a record that shows what was discarded is more useful than one that pretends it never appeared.
3.3 What the levels are not
The ladder is not a ranking of scientific merit, and it is not an ordering of methods. A DFT result at E2 is not “worse science” than a datasheet value at E3; it is a different kind of number, held to a standard that reflects what a reviewer can do with it. Computed and predicted values sit low on the ladder because the ladder measures defensibility in design documentation, which is what the engineer is exposed on. In a research context the same values may be exactly what is wanted.
Nor does a high level make a value correct. Standards contain errors, certificates are occasionally wrong, and a specification minimum for the wrong product form is worse than a good measurement. The ladder tells you how far the value can be defended, not whether it is true.
4. Rules
4.1 Admissibility
- A value at E0 must not be used to satisfy a constraint or to rank a candidate.
- A value below E3 must not be used to satisfy a constraint unless the record states the constraint is being evaluated provisionally, and marks the result as provisional.
- A value below E5 must not be used as a design allowable unless a named engineer records an explicit acceptance, with a reason, in the record.
A design allowable is a value the component is sized from — the number that sets a
thickness, a section, a margin. It is distinct from a screening criterion, which only decides
whether a candidate stays on the list. The distinction matters because the consequences
differ: a weak screening value costs you a wasted shortlist entry, a weak allowable costs you
the component. Constraints that carry design allowables must be flagged as such in the
record (design_allowable: true), and a tool must not decide that flag on the engineer’s
behalf.
The acceptance rule is the one that will be argued about. It is deliberate. It does not forbid using an E3 datasheet value as an allowable — engineers do this daily and often correctly. It requires that doing so is a recorded decision by a person rather than an invisible default of the tool. In the worked example in this repository, every value is E3, the record still conforms at Level 2, and the one value that sizes the part carries a named acceptance that expires when the mill certificate arrives. That is the intended shape of the rule: it does not stop work, it makes the weak link visible and gives it an owner.
4.2 The weakest link
The evidence level of any derived quantity — a material index, a margin, a ratio, a score, a ranking — is the minimum of the levels of its inputs.
Arithmetic does not create evidence. A specific stiffness computed from an E5 modulus and an E1 predicted density is an E1 quantity, and must be recorded as one.
4.3 Date
Every value must carry the date it was retrieved. A value without a retrieval date must not be recorded above E3, regardless of its source, because it cannot be reproduced: the reader cannot know which revision of the database, standard or datasheet was consulted.
4.4 Demotion
If a claimed level cannot be verified by a third party following only what the record contains, the value must be demoted one level, and the demotion, its reason, and the condition for restoring the level must be recorded.
Demotion is normal and is not a defect. The worked example in this repository contains a demoted value, for exactly this reason.
4.5 No silent promotion
A value’s level may rise only when a person records the additional source that justifies it. A tool must not raise a level on its own, and must not raise a level because a model expressed confidence. Confidence is not provenance.
4.6 Reproducibility
A conforming tool at Level 3 (§6) must produce identical records when the same query is re-run against the same date-pinned sources, or must state in the record that its output is non-deterministic and why.
A selection that produces a different shortlist each time it is run is not a selection method. It is a generator.
4.7 Qualitative requirements
Requirements that are not numeric — weldability, availability, an approvals history, a customer restriction, a supply-chain constraint — must be recorded as qualitative requirements with a named source. They must not be converted into a numeric score in order to make them rankable. A qualitative requirement that eliminates a candidate is recorded as an elimination with its reason; a qualitative requirement that merely worries you is recorded as an open question.
4.8 Origin bounds level
Origin and level are independent fields, but not freely independent:
- a value with origin
assertedmust be E0; - a value with origin
predictedmust not exceed E2; - a value at E5 must have origin
specifiedormeasured.
A number with no recoverable basis does not become defensible by being labelled well.
5. The Material Decision Record
The MDR is the artefact TRACE produces. Its schema is in schema/mdr.schema.json; a
human-writable form is in templates/material-decision-record.md.
A conforming MDR contains:
| Block | Contents |
|---|---|
meta | record ID, TRACE version, creation date, tool and version, author, accountable engineer |
problem | function, service conditions, constraints, objectives, free variables, qualitative requirements |
sources | every source consulted, with a resolvable identifier and a retrieval date |
candidates | every candidate considered, including rejected ones, with the reason for rejection |
values | every value used, with origin, evidence level, provenance fields, retrieval date, assessor |
comparison | screening results, ranking, index derivations, separations judged insignificant |
decision | the selected material, the accountable engineer, the acceptances recorded under §4.1, open questions |
limitations | what this record does not cover and what would change it |
The limitations block is mandatory and must not be empty. Every real selection has
conditions it did not examine — fatigue, a joining method, a supplier’s actual heat, a
temperature excursion nobody mentioned. Naming them is the difference between a decision
record and a sales document.
6. Conformance
A tool, a workflow or an individual record may claim conformance at one of three levels. The claim is meaningful only if it names the version — for example, TRACE v0.1 Level 2.
Level 1 — Traceable. Every number presented to the user carries a resolvable source, a retrieval date and an evidence level. No number is displayed without them.
Level 2 — Auditable.
Level 1, plus: the tool exports a valid MDR; the admissibility (§4.1) and weakest-link (§4.2)
rules are enforced rather than advisory; rejected candidates and their reasons are recorded;
limitations is populated.
Level 3 — Reproducible.
Level 2, plus: sources are date-pinned; an identical re-run produces an identical record;
tool version, model versions and database snapshots are recorded in meta.
Self-assessment is permitted and expected. A self-assessment must publish the failures
alongside the passes; a conformance claim that lists only what passes is not a conformance
claim. docs/tool-audit-checklist.md is the instrument; docs/materiascope-self-assessment.md
is the maintainer’s own, including where it currently fails.
7. Relationship to existing practice
Ashby’s method. TRACE is Ashby with one step added and one made explicit. Translate is unchanged. Screening and ranking become Compare. Ashby’s fourth step, documentation, becomes Export and acquires a defined structure. Retrieve and Assess are the additions, and they exist because the data supply chain changed, not because the method was wrong.
Standards and qualified material lists. Where a project is governed by a qualified materials list — ECSS, ASME III, MMPDS, an internal approved-materials specification — that list governs. TRACE does not compete with it and cannot override it. Its use in such a project is to document how a candidate was reached and what was rejected on the way, which is information the qualification process does not itself record.
Measurement traceability. TRACE is concerned with the traceability of a record, not metrological traceability in the ISO/IEC 17025 sense. An E5 value backed by a certificate may also be metrologically traceable; the ladder does not assess that, and does not claim to.
Data readiness and TRL scales. The ladder is deliberately shaped like TRL — six levels, higher is stronger, a number you can say out loud in a review. It measures a different thing: TRL describes maturity of a technology, E-levels describe defensibility of a value.
8. Open questions in v0.1
Published rather than hidden, because a framework whose author has no doubts is a marketing document.
- The E2/E3 boundary is contested. A well-documented DFT calculation with an entry ID is in many ways more reproducible than a datasheet value with no method. It sits lower because the ladder measures defensibility in design documentation. Whether that ordering survives contact with computational engineers is genuinely unknown.
- Uncertainty is under-specified. v0.1 requires that reported uncertainty be recorded but does not define how uncertainty propagates through §4.2. Propagating uncertainty and propagating evidence level are different operations and v0.1 only handles the second.
- Formulated materials are poorly served. Polymers, elastomers, composites, concretes, coatings and adhesives are defined by formulation and process history, not composition alone. The provenance fields in §3.2 assume a material identity that formulations do not have. This is a real gap, not an oversight.
- Qualitative requirements (§4.7) resist recording. The rule says what not to do more clearly than what to do.
- Level 3 may be unreachable for any tool built on live third-party databases, since the sources themselves are not versioned. Whether date-pinning is a sufficient substitute for snapshotting is unresolved.
Comments, disagreements and counter-examples belong in the repository’s issues.
9. Licence and citation
Specification and documentation: CC BY 4.0. Reference code: MIT. Both permit commercial use, including by competitors, including in products that score better than Materiascope’s own.
Materiascope (2026). TRACE: an evidence-graded framework for material selection, v0.1. https://github.com/materiascope/trace