Disclosure: I work with Hangzhou KARN New Building Materials Co., Ltd., a manufacturer of carboxymethyl starch (CMS) and powdered wallpaper adhesive. This post explains the data-integrity choices behind a public blank template. It is not an independent laboratory report, certificate, or product comparison.
A spreadsheet can look scientific long before its rows are comparable.
This is especially easy to miss with viscosity data. Two cells may contain the same unit, but the underlying measurements can differ in solution concentration, water, temperature, preparation, instrument, spindle, speed, reading time, calibration, torque range, or replicate policy. Sorting those values from high to low creates a tidy table and a weak conclusion.
We wanted a public data structure for textile carboxymethyl starch sample records without publishing fictional laboratory observations. The result is a Version 1.1.0 blank Dataset metadata file, a JSON Schema, and a matching CSV template. A browser-based Textile CMS Viscosity Comparison Record exposes the same method boundary as a printable worksheet.
The most important property of the release is not a field. It is an empty array:
{
"schemaVersion": "1.1.0",
"recordPolicy": {
"datasetState": "blank_template_no_observations"
},
"records": []
}
That empty array prevents a useful schema from being mistaken for measured performance.
Start with identity, not the result
A viscosity value should never become detached from the sample that produced it. The schema therefore begins with provenance fields such as supplier, product or grade reference, batch or lot, sample identity, test date, and source-data reference.
The design question was simple: if someone exports one record, can another reviewer determine which physical sample and source file it belongs to?
If the answer is no, adding more decimal places does not improve the record.
Identity fields also make corrections possible. A laboratory can replace an invalid reading while preserving the reason, source reference, and sample lineage. Without those fields, a corrected spreadsheet may look identical to an altered one.
Treat preparation as part of the measurement
Viscosity does not begin when the instrument starts rotating. It begins when the solution is prepared.
For that reason, the schema requires or recommends fields for:
- solution concentration and its stated basis;
- dry sample mass and water quantity;
- water temperature;
- water source, pH, hardness, or conductivity where relevant;
- addition order;
- mixer, impeller, vessel, speed, and time;
- rest or hydration time;
- preparation deviations.
Not every laboratory needs every optional water-quality field. But the schema must have somewhere to put the information when it matters. Otherwise teams fall back to a free-text note, and free text is difficult to validate, filter, or compare.
The comparison rule is intentionally conservative: records should be compared only when required method fields are present and preparation and measurement conditions are equivalent or explicitly controlled.
Make instrument conditions machine-readable
A single field called method is too vague for reliable comparison. The schema separates the instrument model, spindle or geometry, rotational speed, measurement temperature, reading or stabilization rule, calibration reference, torque or validity range, value, and unit.
This lets validation catch omissions before analysis begins.
For example, a simplified rule can require a positive rotational speed:
{
"rotationalSpeedRpm": {
"type": "number",
"exclusiveMinimum": 0,
"description": "Rotational speed used for the reported reading."
}
}
Validation cannot prove that the selected speed is appropriate for the sample. It can prove that the record did not silently omit it. That distinction is important: schema validation protects structure, not scientific judgment.
Preserve replicates instead of hiding them in an average
The template includes a replicate number and a source-data reference. It also allows method deviations and validity notes to remain attached to the reported value.
A good downstream workflow should keep individual readings visible until a documented rule determines whether they are valid, excluded, or summarized. If the only stored number is an average, reviewers cannot see drift, an outlier, or a reading that fell outside the instrument's useful torque range.
This is why the blank CSV contains more columns than a typical comparison sheet. The extra columns are not decoration. They preserve the path back from a conclusion to the observations that support it.
Encode what must not be compared
Most schemas describe allowed values. This one also publishes explicit comparison prohibitions.
Records should not be ranked as equivalent when:
- required identity or method fields are missing;
- concentration or preparation conditions differ without control;
- measurement temperature, instrument, geometry, speed, or reading rule differs;
- the record fails its own calibration, torque, or validity condition.
These constraints are present in the Dataset metadata as policy, not hidden in a README that may be separated from the data.
That makes the boundary visible to search systems, software agents, and analysts who discover the JSON before they discover the documentation.
Use one schema for JSON, CSV, and human records
Version 1.1.0 keeps the CSV header aligned with the JSON Schema property order. Automated tests verify that every CSV column exists in the schema, required fields remain present, extra properties are rejected, and the Dataset stays at zero observations.
The printable worksheet is not a second data standard. It is a human-facing view of the same questions:
- Which sample is this?
- How was the solution prepared?
- Under which instrument conditions was it measured?
- Where are the replicate and source records?
- Which differences prevent comparison?
Keeping those questions consistent reduces translation loss between procurement, laboratory, quality, and software teams.
An empty public dataset can be the honest release
There is pressure to fill a public table because a populated table looks more valuable. But invented examples can be copied into search summaries, AI answers, procurement documents, or supplier comparisons as if they were measured facts.
For this release, the useful public asset is the structure: field definitions, constraints, citation, version, limitations, and distributions. Real observations should be added only when there is a traceable sample, method, review process, and permission to publish them.
That principle applies beyond textile CMS. If you publish templates for coatings, adhesives, dispersions, slurries, or other method-dependent material data, design the absence of evidence as carefully as the presence of data.
An explicit empty state is not a failed dataset. Sometimes it is the strongest evidence that the publisher refused to manufacture certainty.
Top comments (0)