Updated 22 July 2026
Sending a correction
Corrections are the most valuable thing anyone gives this project, and they are also the easiest thing to send badly. One rule decides everything: a change must name the document it came from.
The citation rule
We cannot verify a number by looking at it. We can only verify it by opening the same document you opened. So every submission needs the document title, the year, the edition or issue, and the table or page where the figure sits. If the source is a standard, the designation and the year of that edition are enough.
This applies to corrections of our mistakes too. If we transcribed 2.4 where the handbook says 2.0, tell us which handbook and which table - otherwise your correction and our error are indistinguishable, and we will have to find the document ourselves before we can act.
Template
Email to data@cindercore.dev, plain text, one block per field changed:
record: CC-0202
field: rul_t05_c
current: (empty)
proposed: 1620
source: Refractory Practice for Basic Steelmaking, 3rd ed., 2011,
table 7.4, p. 212
method: ISO 1893, specimen 50 mm cube, 0.2 MPa load
note: the same table gives 1580 C for the resin-bonded variant;
this record is the pitch-bonded one, so 1620 applies
submitter: initials or a name you want credited, or "anonymous"
Several blocks in one message are fine and in fact easier to review than several messages. If you have more than about ten changes, send a CSV instead and run the validator over it first.
Proposing a new record
- Check it does not exist under another name.
cinderq filter --family <family>prints the whole family in one screen, and aliases are searched too. - Fill the five required fields:
name,family,max_service_c,max_service_atmosphere,source_ids. Leaveid,confidenceandupdatedto us. - Use the generic grade description, not a trade name. "high-alumina 70% Al2O3, phosphate bonded" is a record; a product name is an alias at best.
- Run
cinderq validateuntil it prints no errors. Warnings are worth reading but will not block a submission. - Send the file with the citations for every populated field.
New sources are welcome on their own, even with no records attached. A good document with twenty usable grades in it is worth more to the dataset than twenty single values.
What gets turned down
- Marketing literature with no test conditions. A brochure claiming 1 800 °C without saying continuous or peak, oxidising or reducing, cannot be normalised. This is the most common rejection by a wide margin.
- Screenshots and unsourced tables. We have received spreadsheets of excellent-looking numbers with no provenance at all. There is nothing we can do with them.
- Values from an unstated temperature. A conductivity with no reference temperature is not a conductivity, and
k_ref_cexists precisely so this is never silently guessed. - Averaged or interpolated figures presented as measurements. If you computed it, say so, and it will be stored with
k_methodofcalculatedand medium confidence at best.
A rejection is not a judgement about the number. Plenty of correct values sit outside the dataset because the paperwork around them is missing.
What happens next
Submissions are acknowledged by hand, usually within a few days. Review is done by the maintainer who did not receive the mail, and consists of pulling the cited document and checking the figure, the arithmetic and the confidence flag.
A single-field correction with a clean citation typically lands in the next minor release. A batch of new records takes longer, because adding grades usually exposes a question about where the family boundary runs, and those questions are discussed rather than decided quickly. Two recent examples: the castable additions in v1.6.0 took seven weeks from first mail to release, and the thermal shock field split in v1.5.0 took most of a spring because it changed the schema.
If three weeks pass with no reply, send the message again - two people in evenings means mail does occasionally get buried, and a nudge is never unwelcome.
Credit and licensing of submissions
Contributors are listed by release in the changelog, under whatever name or initials they ask for, including none. There is no contributor agreement to sign: by sending data you confirm that you are passing on published facts and that you are happy for them to be redistributed under the dataset licence described on the licence page.
Do not send anything confidential. Internal test reports, customer trial data and unpublished batch certificates are exactly the kind of material this project must stay away from, however interesting the numbers are. If a figure is not in a document that someone else could obtain, it does not belong here.