Free. Nothing is uploaded. The rules it applies are open, CC BY 4.0.
Why a builder and not a template
A template lets you leave out the inconvenient parts, and the inconvenient parts are the ones that matter six months later. The three most commonly omitted fields are the three a reviewer asks about first: what you rejected and why, what each number rests on, and what the analysis did not examine.
So this refuses to produce a record without them. That is not strictness for its own sake — it is the difference between a document that answers the question and one that only looks like it does.
What it enforces
An asserted number is E0. If you mark a value’s origin as asserted — a figure from a chat window with no citation, a number off a forum — the level locks to E0 and the row tells you it may be recorded as a rejected input but must not satisfy a constraint. This is the rule that does the most work in practice.
A prediction cannot exceed E2. Model output is a hypothesis with an address.
E5 requires a specification or a measurement. A computed value cannot be a design allowable, however good the calculation.
No retrieval date, no level above E3. Databases are revised and datasheets are reissued. A value nobody can date cannot be reproduced.
A sub-E5 value that sizes the part needs a recorded acceptance. Using a datasheet figure as a design allowable is normal and often correct. Doing it invisibly is what turns a judgement into a default — so mark the constraint as a design allowable and the builder will ask you to record the acceptance and what supersedes it.
A record ends with a person. Not a department, not a tool, not a company name.
What comes out
Two formats, from the same input.
A readable record — plain text, fits in a design note, reads correctly to somebody who has never heard of this framework. Constraints, candidates including rejections, every value with its origin, level, source and date, the decision, the acceptances, the limitations, and a validation line at the bottom.
Valid JSON against the record schema, for anyone wanting to store or process
records systematically. It validates offline with trace_validate.py from the repository.
Start from the example
The builder ships with a worked case loaded on one click: a tubesheet for a seawater cooler, three constraints, three candidates, four values.
It is worth loading even if you do not need a record today, because of what it demonstrates. Every value in it is E3. Nothing reaches E5, one value is an E0 that was offered and rejected, and the record still validates. That is the intended result — conformance does not claim your evidence is strong. It claims you can see how strong it is.
The example also carries an acceptance line that most records leave out: the governing strength value is used as a design allowable at E3, accepted explicitly, and superseded the moment the mill certificate for the actual heat arrives.
Where this fits
If you use the research agent, it produces one of these for you. If you work by hand, in a spreadsheet, or in another tool entirely, this builds the same artefact from whatever you already did.
The habit underneath both is the same and is worth more than either: write it down while deciding, not afterwards. The information is free at the moment of decision and expensive an hour later — particularly the rejections, which are the part you will want most and which feel least worth writing.
What this does not do
- It does not check whether your numbers are right. Traceability and correctness are different properties and this measures the first. A fully valid record can describe a bad decision.
- It does not look anything up. You bring the values and the sources; it structures and checks them.
- It does not save. Nothing is uploaded and nothing is stored, so export before you close the tab.
- It does not override a design code. Where ASME, EN 13445, Eurocode or a qualified materials list governs, that governs.