DEV Community: kent-tokyo

How you pass molecules to an LLM matters: features I built into my Rust cheminformatics library after reading recent arXiv papers

kent-tokyo — Sat, 27 Jun 2026 04:52:25 +0000

Introduction

Simply passing a SMILES string into an LLM prompt is not enough to make the model reason correctly about molecular structure.

Take aspirin: its SMILES is CC(=O)Oc1ccccc1C(=O)O. A chemist can read it, but an LLM has to parse which atom is bonded to which from a flat string — putting it at a disadvantage on structure-understanding tasks.

Reading recent arXiv papers, three directions emerge for addressing this:

Better molecular representations: use a format more explicit than SMILES
Richer context: pass property data and similar molecules alongside the structure
Role separation: let LLMs judge and explain; hand calculations to deterministic tools

I've been building chematic, a cheminformatics library written in pure Rust with Python, WASM, and MCP support. It handles molecule parsing, property calculation, similarity search, 3D generation, and more. This article covers the features I added with these three directions in mind.

1. ChemicalJSON: explicit graph representation

Motivation

The arXiv paper "Molecular Representations for Large Language Models" (May 2026) asks what a "good" molecular representation looks like for an LLM.

It introduces MolJSON and benchmarks it against five common formats — SMILES, IUPAC name, InChI, and others. The results show that explicit graph representations outperform compressed string formats on structure-understanding tasks. On a shortest-path reasoning benchmark with GPT-5, MolJSON reached 98.5% accuracy vs. 92.2% for SMILES and 82.7% for IUPAC names.

SMILES compresses molecular structure into a string, so an LLM must implicitly parse "which atom bonds to which." An explicit JSON with an atom list and bond list makes that structure directly readable.

Implementation

mol = chematic.from_smiles("c1ccccc1")  # benzene

# convert to explicit graph JSON
cjson = mol.to_cjson()

# reconstruct from JSON
mol2 = chematic.from_cjson(cjson)

The output looks like this:

{
  "atoms": [
    {"index": 0, "element": "C", "aromatic": true},
    {"index": 1, "element": "C", "aromatic": true},
    {"index": 2, "element": "C", "aromatic": true},
    {"index": 3, "element": "C", "aromatic": true},
    {"index": 4, "element": "C", "aromatic": true},
    {"index": 5, "element": "C", "aromatic": true}
  ],
  "bonds": [
    {"begin": 0, "end": 1, "order": "aromatic"},
    {"begin": 1, "end": 2, "order": "aromatic"},
    {"begin": 2, "end": 3, "order": "aromatic"},
    {"begin": 3, "end": 4, "order": "aromatic"},
    {"begin": 4, "end": 5, "order": "aromatic"},
    {"begin": 5, "end": 0, "order": "aromatic"}
  ]
}

The fact that c1ccccc1 represents six carbons in a ring is implicit in the string but explicit in the JSON. LLMs and AI agents can reference the structure directly in this form.

chematic implements ChemicalJSON rather than MolJSON itself, but the intent is the same.

2. Molecule context: describe / review / report

Motivation

The arXiv paper "MolE-RAG" proposes a way to improve LLM-based molecular property prediction. Instead of passing only a SMILES string, it passes property descriptors, structural alerts, and structurally similar known compounds as inference-time context — applying the RAG (Retrieval-Augmented Generation) idea to molecular reasoning. Results show up to 28-point ROC-AUC improvement over a SMILES-only baseline.

Implementation

mol.review() returns a text summary of a molecule:

mol = chematic.from_smiles("CC(=O)Oc1ccccc1C(=O)O")  # aspirin
print(mol.review())
# MW: 180.2, LogP: 1.31, TPSA: 63.6, HBD: 1, HBA: 3
# Rotatable bonds: 3, Aromatic rings: 1
# Drug-likeness: Lipinski pass
# Alerts: none (PAINS, Brenk)
# QED: 0.56

Field glossary:

MW (molecular weight) / LogP (lipophilicity) / TPSA (topological polar surface area) / HBD/HBA (hydrogen bond donors/acceptors): physicochemical properties
Lipinski pass: whether the molecule meets Lipinski's Rule of Five for oral bioavailability
PAINS / Brenk: structural alert filters that flag substructures known to cause false positives in drug discovery screens
QED (Quantitative Estimate of Drug-likeness): drug-likeness score from 0 to 1

mol.describe() returns a more detailed text description. chematic.molecule_report(mol) generates an HTML report.

Embedding in an LLM prompt

Including this summary in the prompt lets the LLM reference real property values while generating a response:

mol = chematic.from_smiles("CC(=O)Oc1ccccc1C(=O)O")
context = mol.review()

prompt = f"""
Answer the question below about the following molecule.

Molecule info:
{context}

Question: Evaluate the oral absorption potential of this compound.
"""

Compared to passing only SMILES, the LLM can now reason explicitly: "LogP 1.31 suggests moderate lipophilicity" and "Lipinski pass indicates likely oral absorption." This is the library-side counterpart to MolE-RAG's "what to pass" question.

3. ECFP4 / Tanimoto / LSH: similarity search

Motivation

To implement MolE-RAG's idea of "add structurally similar molecules to context," you need fingerprint computation and similarity search.

A molecular fingerprint encodes a molecule's substructures as a bit vector. ECFP4 is the standard approach, using substructures within a 2-hop radius of each atom. Molecules with similar structures produce similar fingerprints.

Implementation

aspirin = chematic.from_smiles("CC(=O)Oc1ccccc1C(=O)O")
ibuprofen = chematic.from_smiles("CC(C)Cc1ccc(cc1)C(C)C(=O)O")

# compute fingerprints and similarity
fp1 = aspirin.ecfp4()
fp2 = ibuprofen.ecfp4()
sim = chematic.tanimoto(fp1, fp2)  # Tanimoto coefficient: 0.0 (unrelated) to 1.0 (identical)

# pairwise Tanimoto matrix for a collection (parallelized in Rust)
matrix = chematic.bulk.tanimoto_matrix(mols)

# approximate nearest-neighbor search with LSH (Locality Sensitive Hashing)
index = chematic.SimilarityIndex(mols)
similar = index.query(aspirin, k=10)  # 10 molecules most similar to aspirin

The Tanimoto coefficient is the standard similarity metric in drug discovery. LSH enables fast approximate nearest-neighbor search over large compound libraries.

Using it in a RAG pipeline

Similarity search can serve as the retrieval step in a RAG pipeline, adding known compounds similar to the query molecule as context:

# build an index from a known compound library
library = [chematic.from_smiles(s) for s in known_compounds]
index = chematic.SimilarityIndex(library)

# retrieve similar compounds and build context
query = chematic.from_smiles("CC(=O)Oc1ccccc1C(=O)O")
similar = index.query(query, k=5)

context = "\n".join([
    f"Similar compound {i+1}:\n{mol.review()}"
    for i, mol in enumerate(similar)
])

ECFP4 computation, Tanimoto matrices, and LSH indexing all run on the Rust side, so calling from Python stays practical even for libraries of several thousand molecules.

4. MCP server: calling chemistry tools from an LLM

Motivation

The arXiv paper "ChemToolAgent" shows that for specialized chemistry tasks like reaction prediction and compound screening, calling external tools outperforms having a general-purpose LLM handle everything directly. "ChemMCP" is the MCP-compatible toolkit released alongside that work.

The design principle: don't make the LLM do chemistry calculations. Let the LLM judge and explain; hand the math to deterministic tools.

Implementation

chematic ships a built-in MCP (Model Context Protocol) server. Any MCP client — Claude Desktop, Cursor, etc. — can call chematic's chemistry tools directly from an agent.

{
  "mcpServers": {
    "chematic": {
      "command": "chematic",
      "args": ["mcp"]
    }
  }
}

Representative tools:

tool	description
`calc_properties`	MW, LogP, TPSA, HBD/HBA, etc.
`smarts_match`	SMARTS substructure matching
`pains_check`	PAINS alert detection
`generate_3d`	3D coordinate generation (MMFF94 force field)
`tanimoto`	Tanimoto similarity
`admet_profile`	ADMET (absorption, distribution, metabolism, excretion, toxicity) prediction

Full list of 15 tools in the README.

In practice

With the config above, you can ask Claude Desktop chemistry questions in plain English:

User: Give me the ADMET profile for aspirin (CC(=O)Oc1ccccc1C(=O)O)

Claude: [calling chematic:admet_profile...]
        Absorption (A): LogP 1.31, TPSA 63.6 — within the range for oral absorption.
        Distribution (D): Moderate protein binding predicted.
        Metabolism (M): Likely metabolized by CYP2C9.
        Excretion (E): Renal excretion predicted as primary route.
        Toxicity (T): No PAINS alerts. No Brenk alerts.

The LLM doesn't compute anything itself — it calls admet_profile, receives a deterministic result, and uses that to generate the explanation. This eliminates the hallucination risk of an LLM making up property values.

Summary

Problem	Implementation
SMILES is too implicit for LLMs	ChemicalJSON (`mol.to_cjson`)
Need to pass molecule context as a bundle	`describe` / `review` / `report`
Need similar molecules for RAG context	ECFP4, Tanimoto, LSH
Don't want LLMs doing chemistry math	MCP server (15 tools)

chematic aims to be a foundation for this direction — pure Rust, with Python, WASM, and MCP interfaces.

A separate article on 3D generation and force fields (MMFF94 / DREIDING) is coming.

Repository: github.com/kent-tokyo/chematic

References

Molecular Representations for Large Language Models (May 2026)
MolE-RAG: Molecular Structure-Enhanced Retrieval-Augmented Generation for Chemistry (June 2026)
ChemToolAgent: The Impact of Tools on Language Agents for Chemistry Problem Solving (November 2024; ChemMCP is the toolkit released with this paper)

Building a Computer-Aided Synthesis Planning Engine in Pure Rust

kent-tokyo — Sun, 21 Jun 2026 09:34:20 +0000

I've been building renkin, a retrosynthesis engine in Pure Rust. You give it a target molecule as a SMILES string and it tries to find synthesis routes back to commercially available starting materials.

https://github.com/kent-tokyo/renkin

Background

Retrosynthesis is how organic chemists plan a synthesis: instead of asking "how do I make this?", you ask "what reaction could have produced this, and where do those precursors come from?" — working backwards from the target until you reach things you can actually buy. renkin automates that search.

SMILES is a text notation for molecular structure. Aspirin is CC(=O)Oc1ccccc1C(=O)O. That's what you pass in.

Search design

The straightforward approach — try every applicable reaction rule at every intermediate — runs into combinatorial explosion fast. A single molecule can match hundreds of rules, they apply recursively to every precursor, and the space grows exponentially. I needed something smarter.

AND-OR tree

Retrosynthesis search has a structure that doesn't fit standard graph search well. At any step, you can choose between reactions (either A or B works — an OR), but each reaction requires all its precursors simultaneously (AND). Standard graph search conflates these two, which messes up the cost accounting. renkin models the space as an AND-OR tree and searches it accordingly.

A* with SA Score

For the A* heuristic, I use the SA Score (Synthetic Accessibility Score) — a 1–10 number for how synthetically accessible a molecule is, where lower is easier. The idea is that lower SA Score intermediates are more likely to show up in building block catalogs, so steering the search in that direction tends to find better routes. It worked reasonably well in practice.

Beam search

For large molecules, even the AND-OR + A* combination can get out of hand. Beam search caps the candidates per step at N, which makes the computation predictable at the cost of some precision.

Reaction rules

Rules are written in SMARTS (a pattern language for chemical structures). The current set has 314:

31: hand-crafted rules for the most common reaction types — amide bond formation, esterification, Suzuki coupling, and similar
283: automatically extracted from the USPTO reaction database using rdchiral

The hand-crafted ones tend to be cleaner but don't cover much ground. The auto-extracted ones add coverage but come with noise. Template frequency weighting — giving higher priority to rules that appear more often in USPTO — turned out to be the biggest single factor in accuracy.

Benchmarks

USPTO-50k (4,907-molecule test set) is the standard evaluation for retrosynthesis tools. Here's how the numbers changed as I added each piece:

Configuration	Solved	Rate	Rules	depth	beam
v0.1.0 initial (hand-crafted only)	366/4907	7.5%	31	3	50
+ auto templates (top-300)	1363/4907	27.8%	222	3	50
+ depth=5, top-500 templates	2315/4907	47.2%	314	5	50
+ beam=100	2688/4907	54.8%	314	5	100
+ template frequency weighting	~3484/4907	~71%	314	5	100

The ~71% in the last row is confirmed on 100 molecules, not the full 4,907 — take it as a directional figure.

Comparison with other tools (same train/test split):

Tool	Method	USPTO-50k
renkin	A* + AND-OR tree	~71% (approx.)†
GLG	—	58.0%
LocalRetro	Neural network	53.4%
AiZynthFinder	MCTS	45–53%
Retro*	AND-OR tree search	44.3%
ASKCOS	MCTS	41%

† renkin's figure is from a 100-molecule sample; other tools used the full 4,907. This comparison still needs more work — I haven't verified whether the number holds at full scale.

The jump from template frequency weighting alone was larger than I expected. It's the thing I'd add first if starting over.

Why Pure Rust

renkin is built on chematic, a Pure Rust cheminformatics library I wrote earlier.

https://github.com/kent-tokyo/chematic

That means SMARTS matching, molecular graph operations, and SA Score calculation are all in safe Rust, no FFI. cargo build is enough, and it compiles to WebAssembly (~500 KB). For parallel rule application, renkin uses rayon — including a WASM-compatible build that runs through Web Workers, though that path hasn't had as much testing yet.

Usage

Python

pip install renkin

import renkin

result = renkin.find_routes(
    "CC(=O)Oc1ccccc1C(=O)O",  # aspirin
    depth=5,
    max_routes=3,
)

for route in result["routes"]:
    for step in route["steps"]:
        print(f"  {step['target']} -> {' + '.join(step['precursors'])}  [{step['rule']}]")

CLI (Rust)

cargo install renkin

renkin --target "CC(=O)Oc1ccccc1C(=O)O" --depth 5 \
    --templates data/templates_extracted.smi

JavaScript / Node.js

npm install renkin

import init, { find_routes } from 'renkin';

await init();
const result = JSON.parse(find_routes("CC(=O)Oc1ccccc1C(=O)O", 5, 3, 0));

What's left

314 rules aren't enough for complex molecules like natural products — success rates drop there. I want to try pulling more templates from sources beyond USPTO.

Scoring routes by step count, yield, and cost (rather than just solved/not-solved) is also on the list. And a browser UI for stepping through the AND-OR tree is in progress.

Retrosynthesis engine "renkin":
https://github.com/kent-tokyo/renkin

The cheminformatics library underneath, "chematic":
https://github.com/kent-tokyo/chematic

Building chematic: Why I Wrote a Pure-Rust Cheminformatics Library from Scratch

kent-tokyo — Fri, 19 Jun 2026 09:34:51 +0000

I'm building chematic, a cheminformatics library in pure Rust, from scratch. Here's why I started, and what kept tripping me up along the way.

How it started

"I just want to run RDKit in the browser" — that was it.

RDKit.js exists. But the WASM binary is over 30 MB, and building it requires cmake, clang, and the Emscripten SDK. CI kept breaking, Docker images bloated, and every deploy meant setting up the build environment again. Too much overhead for what I wanted to do.

I tried OCL.js (OpenChemLib) too, but it's Java code transpiled via GWT, so the API feels Java-shaped and TypeScript types don't come out cleanly.

That's when I thought: what if I just wrote it in pure Rust? At the time, I figured a few weeks would be enough.

Why I imposed the pure-Rust constraint

I didn't set "no FFI" as a rule from the start. But as I kept writing, I could see that allowing one exception would cascade.

Take InChI. The official IUPAC implementation is in C, and reimplementing it correctly in pure Rust isn't realistic. The moment I said "I'll use FFI just for this," cmake and Emscripten dependencies would come back. Better to draw the line early. No FFI, no unsafe, no random number generation. Those three constraints went in first.

That "InChI is out" decision would come back to bite me from the outside.

Getting to 15 crates

I started with a single crate. As files multiplied and compile times grew, I split out chematic-core and chematic-smiles first. Every time a new feature landed, I carved it out, and now there are 15 crates.

chematic-core       → atom/bond/molecule primitives, kekulization
chematic-smiles     → OpenSMILES parser, canonical SMILES writer
chematic-perception → ring perception (SSSR), aromaticity
chematic-mol        → MOL/SDF file I/O
chematic-depict     → 2D SVG rendering (CPK colors, SMARTS highlighting)
chematic-chem       → 70+ descriptors, pKa prediction, ADMET profiling
chematic-fp         → 6 fingerprint types (ECFP, MACCS, MAP4, etc.)
chematic-smarts     → SMARTS parser, substructure search (VF2)
chematic-ff         → force field implementations (UFF, DREIDING, MMFF94)
chematic-3d         → 3D coordinate generation (ETKDG), conformer handling
chematic-rxn        → reaction SMILES/SMIRKS parser
chematic-wasm       → JavaScript/TypeScript WASM bindings
chematic-iupac      → IUPAC name generation (25+ compound classes)
chematic-mcp        → MCP server for AI agents (14 tools)
chematic            → umbrella crate integrating everything

The trickiest part was the dependency graph. chematic-perception (ring perception) depends on chematic-core, but the kekulization code inside core needs ring perception results. To break the cycle, I put the kekulization interface in core and the implementation in perception. Not the cleanest design, but it works for now.

Getting stuck on the SMILES parser

"SMILES is a simple notation, so parsing it should be simple" — wrong. The OpenSMILES spec has enough ambiguity that for edge cases I ended up looking at RDKit's behavior and using that as the reference.

The first wall was branch handling. Writing a recursive-descent parser for deeply nested structures like C(CC(N)CC)(=O)O made stack management awkward. I rewrote it as an iterative implementation with an explicit stack.

Implicit hydrogen was also quietly painful. SMILES usually omits hydrogens and calculates them from valence. That calculation is more complex than it looks — atom type, charge, and valence model all interact — and when I ran ChEMBL molecules through it, mismatches kept showing up and I had to fix them multiple times.

Getting stuck on kekulization

Kekulization is the conversion of aromatic SMILES (lowercase atoms like c1ccccc1) into explicit single/double bond form (C1=CC=CC=C1).

It's a bipartite graph maximum matching problem, and the algorithm itself is well-known. What I didn't anticipate was scale: for large fused ring systems like porphyrins and natural products, the matching search blows up exponentially. I only noticed this when I ran the full ChEMBL dataset — molecules over MW 5000 were timing out.

Atoms with only two adjacent aromatic bonds have a unique solution for which bond gets the double bond. Processing those first and reducing the graph before running the matching fixed the timeouts for large molecules. That fix went into v0.4.6.

Fingerprint determinism

The thing that caught me in the ECFP (Morgan algorithm) implementation was atom traversal order.

Rust's HashMap randomizes its seed by default (HashDoS mitigation). So when traversing molecular graph atoms via a hash map, the order changes every run — same molecule, different bit vector. The symptom was "Tanimoto similarity varies between runs," and it took a while to track down.

I switched to sorting all atoms by atomic number, degree, charge, and isotope mass before computing, and replaced AHashMap with IndexMap for deterministic ordering. Setting the no-random-numbers constraint upfront probably saved me from shipping a "works for now" implementation and hitting the reproducibility bug later.

Fighting the borrow checker in CIP

CIP (Cahn–Ingold–Prelog) rules determine R/S for stereocenters and E/Z for double bonds. Assigning priority to an atom requires the priorities of its neighbors, which requires their neighbors, and so on — a recursive dependency.

Understanding the algorithm wasn't the hard part. Getting it past the borrow checker was. Holding the graph as Rc<RefCell<Node>> caused other issues; I tried an Arena pattern too. Eventually I settled on a flat Vec<Atom> with AtomIdx (usize newtype) for indirection. No need to hold &mut and & simultaneously during traversal, so the borrow checker was happy. Took a few days, but once this pattern clicked, I used it for other algorithms too.

ChEMBL full validation

Mid-development, unit tests would pass completely while the parser crashed on specific ChEMBL molecules.

The causes were roughly three kinds: SSSR count mismatches on rare fused ring systems, hydrogen valence miscalculations from non-standard SMILES, and the kekulization timeouts mentioned above. None of these were cases I would have thought to write unit tests for — they only surface when you run real data.

Eventually I parsed all 2,897,819 molecules from ChEMBL 37 without a failure. In the RDKit compatibility benchmark on 5,000 molecules, HBA (H-bond acceptor) count agreement reached 99.98%, and aromatic ring count agreement hit 95.6% — the remaining gap comes from differing treatment of fused N-heterocycles.

Issue #11: dropping InChI

On June 16, 2026, an external issue came in:

"100% errors on InChI generation vs IUPAC reference InChI"

Even benzene produced the wrong connectivity block. The root causes identified were: InChI's own canonical numbering algorithm (different from Morgan ordering) wasn't implemented, spurious stereochemistry layers were being added to molecules without stereocenters, tautomer and mobile-hydrogen normalization was missing, and the InChIKey hash conversion diverged from spec — not isolated bugs, but a design-level failure.

InChI's spec is effectively defined by the IUPAC C library implementation. Reimplementing that correctly from scratch in pure Rust, without following the C library, isn't realistic. I'd expected this moment when I banned FFI, so I deleted chematic-inchi and documented InChI/InChIKey as an unsupported limitation.

WASM binding design

I use wasm-bindgen to expose Rust functions to JavaScript. For complex return types, wasm-bindgen can't pass Rust types directly, so I serialize to JSON via serde_json and call JSON.parse() on the JS side.

const desc = JSON.parse(get_descriptors_json(mol));
console.log(`MW: ${desc.mw}, TPSA: ${desc.tpsa}, LogP: ${desc.logP}`);

It's not suited for high-frequency computation, but chemistry calculations don't typically need that, so it hasn't been a bottleneck. TypeScript type definitions are auto-generated by wasm-bindgen, so IDE autocomplete works.

Where Rust actually helped

Not all of it was painful.

BondOrder is an enum, so calling "count double bonds" on an un-kekulized aromatic molecule is a compile error. In C++ that silently returns a wrong value.

The 3D force field implementations (UFF, DREIDING, MMFF94) were also written without a single line of unsafe. Translating the math into safe Rust was more straightforward than I expected.

Current state

v0.4.6 (June 19, 2026) is the latest release. 1,991 tests pass across the workspace. The WASM binary is ~550 KB after wasm-opt, available as an npm package (@kent-tokyo/chematic).

Recent additions include pKa prediction, ADMET profiling, BOILED-Egg passive permeability classification, and an MCP server (14 tools) for AI agent integration. The live demo runs all of it client-side in WASM.

https://kent-tokyo.github.io/chematic/

https://github.com/kent-tokyo/chematic

5 Features That Make chematic Stand Out as a Pure-Rust Cheminformatics Library

kent-tokyo — Fri, 12 Jun 2026 14:44:42 +0000

I'm building chematic, a pure-Rust cheminformatics toolkit. Every library worth using—RDKit, OpenBabel, CDK—requires C/C++ at its core. chematic targets RDKit-level coverage with zero FFI: compiles to WASM, native binaries, and everything in between, without a single line of C or C++.

chematic
Try the live demo
Source

Pure Rust — Reproducible and Instant Builds

Pure-Rust implementation means chematic compiles to identical binaries on any system—Linux, macOS, Windows, CI/CD pipelines, Docker containers—with zero configuration. No cmake, no pkg-config, no "works on my machine" surprises.

[dependencies]
chematic = "0.1"

Compare with the typical RDKit setup:

# RDKit setup
$ brew install cmake boost eigen
$ pip install rdkit
# 5-10 minutes of C++ compilation, system-dependent

# chematic setup
$ cargo add chematic
$ cargo build --release
   Compiling chematic v0.1.89
    Finished `release` profile ... in 4.23s

No cmake version mismatches, no missing nasm, no Boost library conflicts. Advantages:

CI/CD reliability — builds don't break due to system library drift
Containerization — minimal layer dependencies, smaller Docker images
Cross-compilation — compile for Linux/macOS/Windows/WASM from a single Rust toolchain
Embedded systems — deploy to constrained environments without external build tools

WebAssembly as a First-Class Target

chematic exports 137 JavaScript functions via the npm package @kent-tokyo/chematic. The demo at https://kent-tokyo.github.io/chematic/ shows 8 feature tabs (2D Viewer, Similarity, Molecular Report, Reaction, SAR Analysis, 3D Viewer, Gallery, Dynamics), all running client-side in pure WASM.

Embed cheminformatics directly in web applications:

const mol = parse_smiles('CC(=O)Oc1ccccc1C(=O)O');
const descriptors = get_descriptors_json(mol);     // {mw: 180.15, logp: 1.19, tpsa: 63.6, ...}
const scaffold = murcko_scaffold(mol);
const fragments = brics_fragments_json(mol);

Benefits:

Interactive lead optimization — real-time descriptor updates as users draw structures
Offline-first tools — no backend server, no SaaS fees, no internet required
Collaborative chemistry — embed in Jupyter notebooks, Observable, or design tools
Instant feedback — sub-millisecond property calculations in the browser

Feature Flags for Modularity

chematic ships with 10 optional feature flags: smiles, perception, mol, depict, fp, chem, smarts, rxn, threed, inchi, iupac. Use the full omnibus flag for everything.

Practical effects:

WASM bundle size shrinks with every unused feature
Compile time drops when excluding heavy modules like 3D or fingerprints
Embedded targets can skip unnecessary functionality

3D Coordinate Generation and Force Field Minimization in Pure Rust

3D cheminformatics requires distance geometry for initial embedding, force field parameterization, and structure optimization. chematic implements three force fields—UFF, DREIDING, and MMFF94—entirely in Rust.

The pipeline:

Generate 3D coordinates via distance geometry
Embed into conformer ensemble
Minimize geometry using selected force field
Prune similar conformers by RMSD
Optionally run short molecular dynamics (300 K, Berendsen thermostat)

You can also compute shape descriptors (principal moments of inertia, normalized principal ratios, asphericity) and export to PDB or XYZ format. This same 3D engine powers the demo's 3D Viewer and Dynamics tabs.

Drug Discovery Pipeline in ~20 Lines

The typical workflow compresses into a few method calls:

// In a single Rust binary:
// - 70+ molecular descriptors (MW, LogP, TPSA, Fsp3, exact mass, aromatic ring count, etc.)
// - Drug-likeness filtering
// - Standardization (tautomers, salts, charges)
// - Stereochemistry handling (R/S and E/Z assignment, isomer enumeration)
// - BRICS fragmentation for lead optimization
// - Fingerprints (ECFP, FCFP, MACCS, AtomPair, Torsion)
// - SMARTS and substructure search

All linked statically. All open source. No external services.

Fingerprints and Similarity-Based Screening

Fingerprints encode molecules as bit vectors for bulk similarity comparison and identification of structurally related compounds. chematic implements six fingerprint algorithms in Rust:

ECFP and FCFP — circular fingerprints (radii 2, 4, 6)
MACCS — 166-bit key set (MDL standard)
AtomPair and Torsion — environment-based structural bits
TopoPF — RDKit-style topological path fingerprint

The demo's Similarity tab shows all six with their Tanimoto scores. Use cases:

Virtual screening — find actives from a library of millions
Scaffold hopping — discover chemically novel analogs
Compound clustering — group similar leads for follow-up synthesis
Hit triage — prioritize candidates by structural diversity

2D SVG Molecular Depiction

chematic generates publication-quality SVG output with:

CPK atom coloring (carbon gray, oxygen red, nitrogen blue, etc.)
Substructure highlighting for SMARTS matches
Reaction scheme visualization with arrow flow
Stereochemistry wedges — proper depiction of wedge/dash bonds
Customizable styling — line width, font, colors

The 2D Viewer tab renders every molecule as SVG, with live SMARTS-based highlighting. This eliminates the need for external rendering tools or server-side chemistry services.

3D Interactive Viewer and Molecular Dynamics

chematic includes a full 3D viewer powered by WebGL (via Three.js). The demo's 3D Viewer tab offers:

Multiple display modes: Stick, Ball & Stick, Spacefill (van der Waals surface)
Interactive rotation and zoom — drag to rotate, scroll to zoom
Real-time molecular dynamics — short MD runs at 300 K with live coordinate updates
Conformer ensemble support — explore multiple low-energy structures
PDB/XYZ export — save optimized 3D structures

Use cases:

ADMET prediction — shape-based descriptors from 3D coordinates
Protein-ligand docking — preparation and validation
Lead optimization — visual inspection of 3D conformations
Educational use — visualizing stereochemistry and molecular motion

Where to Start

Live demo: https://kent-tokyo.github.io/chematic/ — try all 8 tabs now in your browser

Get the code:

crates.io: https://crates.io/crates/chematic
npm: npm install @kent-tokyo/chematic
Repository: https://github.com/kent-tokyo/chematic (contributions welcome)
Docs: https://docs.rs/chematic/0.1.89/chematic/

I released v0.1.89 in June 2026. The library has 1,521 passing tests. The goal is feature parity with RDKit, achievable purely in Rust without compromising performance or safety.

If you're building cheminformatics tools in Rust, exploring serverless drug discovery pipelines, or shipping molecular analysis to the browser, try chematic. Feedback and contributions on GitHub are welcome.

Building chematic: A Pure-Rust Cheminformatics Library for WebAssembly

kent-tokyo — Sun, 07 Jun 2026 08:52:37 +0000

Many cheminformatics tools, including RDKit and Open Babel, are written in C or C++. When they are used from JavaScript, they are often compiled through Emscripten or exposed through generated bindings. That works, but it usually brings a larger native toolchain into the build and makes package size a constant concern.

What happens if you remove all C and C++ from that stack?

That is the idea behind chematic. I wrote a cheminformatics library from scratch in pure Rust and published it as a WASM-backed npm package. The optimized core WASM artifact is about 550 KB in my release build. The Rust side is Cargo-based; npm packaging still uses the usual WASM binding and optimization steps.

Why Pure Rust?

Cheminformatics algorithms are complicated. Ring perception in molecular graphs, stereochemistry assignment, fingerprint generation: all of these rely heavily on careful graph manipulation. Existing C++ libraries are powerful and deeply validated, but I wanted this project to keep the memory-safety boundary auditable across the whole stack.

Rust was attractive for exactly the opposite reason.

Native Fit for WASM

Rust's WASM support is integrated into the standard toolchain. The wasm32-unknown-unknown target ships with Rust, and cargo build --target wasm32-unknown-unknown is enough to produce a WASM artifact.

For the Rust crates themselves, there is no need for OS-specific native dependencies or C/C++ build scripts. The JavaScript package still has a packaging step, but the chemistry implementation does not depend on an external native library.

Memory Safety as a Constraint

chematic uses no unsafe Rust. That is not just a policy. It is a design constraint.

When working with complex data structures such as molecular graphs, I wanted the implementation to stay inside Rust's normal safety model. I relied on the ownership system and borrow checker, and implemented all operations inside safe Rust.

Reproducibility and Determinism

For fingerprint calculation, the same molecule must always produce the same bit vector. chematic uses fixed atom-environment ordering, stable serialization, fixed-width FNV-1a hashing, and avoids randomized hashers.

The goal is deterministic fingerprints across platforms and runtime environments, which makes similarity scores reproducible and easier to test.

Turning Zero FFI from a Choice into a Rule

FFI to C or C++ libraries is useful, but once it is allowed, exceptions start appearing:

"InChI needs a C library."
"This optimization should be written in C."
"This one dependency is too convenient to avoid."

chematic forbids FFI itself. rdkit-sys, openbabel-sys, cc, bindgen: none of them are used. That constraint keeps the implementation coherent and makes the dependency boundary easier to reason about.

The Shape of `chematic`

The project is organized into 13 Rust crates:

chematic/
├── chematic-core       -> basic atom, bond, and molecule types; kekulization; zero dependencies
├── chematic-smiles     -> OpenSMILES parser and canonical SMILES writer
├── chematic-perception -> ring perception (SSSR) and aromaticity detection
├── chematic-mol        -> MOL/SDF file format reading and writing
├── chematic-depict     -> 2D SVG depiction with CPK colors and highlights
├── chematic-chem       -> 40+ molecular descriptors: MW, LogP, TPSA, and more
├── chematic-fp         -> 7 fingerprint types, including ECFP and MACCS
├── chematic-smarts     -> SMARTS parser and substructure search using VF2
├── chematic-3d         -> experimental 3D coordinate generation and force-field minimization
├── chematic-rxn        -> reaction SMILES/SMIRKS parser
├── chematic-wasm       -> WASM bindings for JavaScript and TypeScript
├── chematic-iupac      -> IUPAC name generation in pure Rust, without network access
└── chematic            -> umbrella crate integrating the full set

At the moment, all 933 tests pass. I also ran a ChEMBL 37 validation pass over 2,897,819 molecule records. In that pass, the checked SMILES inputs parsed successfully and satisfied the validation checks used by the test harness.

Implementing the Algorithms

Here are some of the core chemistry-specific algorithms and how they were implemented.

Ring Perception (SSSR)

Benzene rings, naphthalene rings, and many other molecular properties depend on ring structures. Detecting those rings from a molecular graph is the job of SSSR: the Smallest Set of Smallest Rings.

A general graph library such as petgraph can compute cycle bases, but chemistry has stricter definitions of what counts as a ring. Those definitions do not always match the generic graph-theory answer.

chematic implements an algorithm specialized for chemical requirements. SSSR is not unique for every graph, so the target is not "the one true ring set." The practical goal is stable behavior that matches the selected chemistry test cases and RDKit-style expectations used by the project.

Kekulization

When aromatic molecules such as benzene are represented in SMILES, alternating single and double bonds must be assigned. This process is called kekulization. For many common aromatic systems, the implementation can be formulated as a matching problem over the molecular graph, with explicit failure handling for cases that cannot be assigned consistently.

// Input:  SMILES "c1ccccc1" (benzene, aromatic notation)
// Output: "C1=CC=CC=C1"   (Kekule form with alternating single and double bonds)

Rust's type system helps prevent invalid kekulization states from leaking through the API. It does not make chemistry errors impossible, but it does make illegal intermediate states harder to represent accidentally.

CIP Stereochemistry

CIP rules, the Cahn-Ingold-Prelog rules, determine R/S configuration for chiral centers and E/Z configuration for double bonds. The priority assignment algorithm is complex: each atom receives a priority, that priority can depend on its neighbors, and the effect propagates recursively through the graph.

The current implementation covers the subset needed by the library's stereochemistry tests, including common tetrahedral and double-bond cases. More obscure CIP edge cases, such as advanced pseudoasymmetry handling, should be treated as an area for continued validation rather than a solved claim.

ECFP Fingerprints (Morgan Algorithm)

ECFP fingerprints convert the local environment around atoms into hashed identifiers, which are then used to calculate molecular similarity. The algorithm runs for multiple rounds, expanding each atom's neighborhood information and hashing it at every step.

chematic canonicalizes input order before calculation and uses a fixed-width FNV-1a hash. The important property is not the hash function alone, but the combination of stable ordering, stable serialization, and no randomized hashing. As a result, the same molecule should produce the same bit vector every time.

Scope and Packaging Tradeoffs

This is not a replacement for RDKit. RDKit has decades of chemistry validation and a much broader feature set. The tradeoff in chematic is narrower scope in exchange for a pure-Rust implementation and a smaller WASM-oriented package.

The numbers below are intended as project-level packaging context, not a benchmark. WASM and npm sizes vary depending on build options, exported APIs, JavaScript glue, compression, and optimization settings.

Item	chematic	RDKit.js / Open Babel style stacks	OCL.js / Indigo-style stacks
Native dependency in the chemistry core	None	Usually yes	Depends on project
WASM/package size profile	Small optimized core artifact in my build	Often larger because mature native libraries expose broad functionality	Usually depends heavily on exported feature set
Build model	Cargo-based Rust crates plus WASM packaging	Native build toolchain plus generated bindings	Project-specific
Feature coverage	Focused subset implemented in Rust	Much broader, especially RDKit	Broader in some areas, different scope in others
InChI/InChIKey	No, out of scope	Often available	Often available

The standard/reference InChI implementation is written in C. I chose not to wrap it because that would violate the no-FFI constraint. chematic documents InChI/InChIKey support as out of scope.

Instead, it covers many use cases through canonical SMILES, Murcko scaffolds, and molecular graph isomorphism.

Use Cases

This library is useful in places where a lightweight browser-side cheminformatics implementation is more important than full RDKit parity:

Browser-side chemical database filtering: fingerprint similarity and descriptor filters that can run directly on an end user's machine.
Prototype screening UIs: Lipinski rules, QED, SA score, and other descriptors calculated from a web interface without a backend round trip.
Teaching and visualization workflows: molecule parsing, depiction, and experimental 3D generation for interactive demos.
Lightweight SAR exploration: extracting simple chemical-change patterns in desktop or browser applications.

Development Progress

chematic was developed in phases, from Phase 1 for the foundation to Phase 15 for extended functionality. It is now at v0.1.32 and still actively maintained.

Phase 1-6: core functionality: parsing, ring perception, descriptors, fingerprints, and RDKit compatibility
Phase 7-9: extended descriptors and diversity selection: EState, VSA, SA score, MaxMin, and Butina
Phase 10-15: mutable APIs, 2D stereochemistry, reaction formats, and IUPAC naming

At each stage, I repeated compatibility testing against ChEMBL. The ChEMBL 37 validation pass covered 2,897,819 molecule records and checked that the input structures used by the harness could be parsed and processed without failing those validation checks. This should be read as parser and pipeline validation, not as proof that every descriptor or stereochemistry result is scientifically equivalent to RDKit.

Limitations

The main limitation is scope. chematic is designed around a no-FFI pure-Rust constraint, so it intentionally does not expose everything available in mature cheminformatics systems.

InChI and InChIKey are out of scope because wrapping the reference implementation would require FFI.
3D coordinate generation and force-field minimization are useful for demos and exploratory workflows, but they should not be treated as production-grade molecular modeling validation.
CIP stereochemistry support covers the common cases tested by the project, but rare edge cases need more validation.
RDKit compatibility is a testing target for selected behavior, not a claim of full RDKit equivalence.

Current Status and Demo

Live Demo

Descriptor calculation, fingerprint similarity, drug-likeness rules, a 3D viewer, reaction schemes, and more run in the browser through WASM:

https://kent-tokyo.github.io/chematic/

JavaScript and TypeScript Usage

npm install @kent-tokyo/chematic

import init, {
  parse_smiles, get_descriptors_json, brics_fragments_json,
  enumerate_stereo_isomers_json, tanimoto_ecfp4
} from '@kent-tokyo/chematic';

await init();

const mol = parse_smiles('CC(=O)Oc1ccccc1C(=O)O'); // aspirin
console.log(mol.molecular_weight()); // ~180.16
console.log(mol.qed());              // drug-likeness [0,1]

// Get multiple descriptors at once
const desc = JSON.parse(get_descriptors_json(mol));
console.log(`MW: ${desc.mw}, TPSA: ${desc.tpsa}, LogP: ${desc.logP}`);

// BRICS fragmentation for decomposing molecules
const frags = JSON.parse(brics_fragments_json('CC(=O)Oc1ccccc1C(=O)O'));
console.log(`Fragment count: ${frags.length}`);

// Stereoisomer enumeration
const isomers = JSON.parse(enumerate_stereo_isomers_json(parse_smiles('C(F)(Cl)Br')));
console.log(`Possible stereoisomers: ${isomers.length}`);

// Fingerprint similarity for screening
const caffeine = parse_smiles('Cn1cnc2c1c(=O)n(c(=O)n2C)C');
const aspirin = parse_smiles('CC(=O)Oc1ccccc1C(=O)O');
console.log(`Similarity: ${tanimoto_ecfp4(caffeine, aspirin).toFixed(3)}`);

More than 100 WASM API endpoints are exposed, and TypeScript definitions are generated automatically, so IDE completion works out of the box.

Rust Usage

[dependencies]
chematic = { version = "0.1.32", features = ["smiles", "fp", "chem"] }

use chematic::smiles::parse;
use chematic::fp::ecfp4;

let aspirin = parse("CC(=O)Oc1ccccc1C(=O)O").unwrap();
let caffeine = parse("Cn1cnc2c1c(=O)n(c(=O)n2C)C").unwrap();

let similarity = ecfp4(&aspirin).tanimoto(&ecfp4(&caffeine));
println!("Similarity: {:.3}", similarity); // ~0.4

Testing

All 933 unit tests pass. The ChEMBL 37 validation pass over 2,897,819 molecule records also completes successfully under the parser and pipeline checks described above.

That does not just mean "the code compiles." It means the implementation has been tested against a large real-world chemical database. The reported WASM binary size is measured for the optimized core artifact after wasm-opt; compressed transfer size is smaller, while npm package size depends on generated JavaScript and TypeScript files.

chematic implements a focused set of chemical information processing features, from molecular representation to similarity calculation and experimental 3D structure generation, using pure Rust and Rust's native WASM support.

It is still under active development.

https://github.com/kent-tokyo/chematic

What I Do Before Letting Claude Code Touch Web App Design

kent-tokyo — Wed, 03 Jun 2026 13:23:08 +0000

Claude Code writes code well, but "make it look nice" as a standalone instruction produces inconsistent results. Anthropic's best practices guide recommends separating exploration and planning from implementation, and using screenshots as verification signals rather than eyeballing the code. I extended that principle to the entire design process. Here is the sequence I use.

Before writing any code

Starting with code means design changes become code changes. If you decide later that you want a different layout, you end up dismantling components that are already written.

I do two things before touching code.

Get the spec in Markdown

Write a list of all screens in this app and the UI elements each screen needs.
No code yet.

Claude Code writes out the screen inventory, per-screen elements, and data flow in prose. Deciding the layout direction here — sidebar or not, fixed header or not — reduces "actually, let's change this" iterations later.

Get the component tree as text

Based on the screen layout, write the parent-child relationships between components as a tree.
Include the props each component receives and the state it holds.

Keep the output as text, not code. Reviewing the structure before implementation makes it easier to trace later why things ended up the way they did.

Build the design system first

Before creating a single component, lock in the rules for color, typography, and spacing.

Create the base of a design system with these constraints:
- Framework: Tailwind CSS
- Color palette: primary in blue, include grayscale
- Font: system font
- Define as CSS custom properties

No component code yet.
Create only tailwind.config.ts and globals.css.

Skipping this leads to hardcoded color values scattered across components. Unifying text-blue-500 to text-primary everywhere afterward is tedious.

Without Tailwind, CSS custom properties work as a substitute:

:root {
  --color-primary: #2563eb;
  --color-surface: #f8fafc;
  --spacing-base: 0.25rem;
}

Once the design direction is settled, I put it in DESIGN.md.

DESIGN.md follows a format open-sourced by Google Stitch, readable by Claude Code, Cursor, Copilot, and other agents. The structure has two layers:

---
colors:
  primary: "#2563eb"
  surface: "#f8fafc"
typography:
  base: "16px"
  scale: 1.25
spacing:
  unit: "4px"
components:
  library: "shadcn/ui"
---

## Design rationale

Primary color is blue for trust. Colors are chosen to meet WCAG AA contrast ratio (4.5:1 minimum for text on background).
Responsive is mobile-first, using only the `md` breakpoint.
Reference design: Stripe dashboard (high information density, minimal whitespace).

The YAML frontmatter holds machine-readable tokens (color, font, spacing). The Markdown body holds the rationale — the "why" behind each value. Agents fill in edge cases from the rationale when tokens alone are not enough.

Add @DESIGN.md to CLAUDE.md to have Claude Code reference the design direction across sessions. No need to repeat it in every prompt.

Prompts for creating components

Design instructions land better when they say "what to reference" rather than "how it should look."

Less effective

Make it modern and clean.

Claude Code's "modern" and your "modern" are different things.

More effective

Build this in a style close to shadcn/ui's Card component.
Use rounded-lg for border radius, shadow-sm for shadow, p-6 as the base padding.

Design like the Stripe dashboard — high information density,
minimal whitespace, small font sizes.

Naming a reference directly reduces variation in the output. Using shadcn/ui or Radix UI component names directly works for the same reason.

Specify interaction states from the start

Specifying only the default state leaves hover, disabled, and error states undefined. Listing all states up front avoids "the disabled state doesn't look right" fixes later.

Create a Button component. Implement all of these states:
- default: primary color background, white text
- hover: slightly darker (darken 10%)
- disabled: grayed out, cursor-not-allowed
- loading: replace text with a spinner, non-clickable

For form input fields, specify the error state (red border, error message visible) at the same time.

Dark mode

Decide at the start whether to build dark mode in from the beginning or handle it later. Asking for dark mode after the fact means rewriting all the hardcoded light-mode values.

Add dark mode support using Tailwind's dark: classes.
The CSS variables in DESIGN.md already have both light and dark definitions. Reference those.

Feedback loop

Once a component is working, I give feedback based on screenshots rather than reading through the code. The official best practices guide covers this pattern too: compare a screenshot against the target design and iterate from there.

I use /run to start the server, then use a screenshot tool (the frontend-design skill or Playwright MCP) to capture the screen before giving feedback.

Take a screenshot of the current home screen.
The header is too tall. Set it to h-16.
Bring the navigation font size down to text-sm.

Packing too many changes into one instruction makes it hard to check what changed. I aim for two or three visually verifiable changes per round.

Responsive checks follow the same flow.

Take a screenshot at mobile width (375px).
The cards are probably still displaying side by side.
Fix them to stack vertically on mobile.

When regressions happen

After enough iterations, "fixing one thing broke another" will come up. Asking Claude Code to compare the previous screenshot to the current state helps narrow down the cause.

Compare the previous screenshot to the current screen.
List any changes that happened unintentionally. No fixes yet.

Understanding the cause before applying a fix avoids repeating the same patch cycle.

Things that kept going wrong for me

The drift problem bit me the most: "change the header font" would come back with the entire layout reorganized. Now I add an explicit boundary to any scoped change.

Change only the font size in the Header component.
Do not touch the layout or colors.

I also tried generating all components in one pass a few times. It produced a lot of code quickly, but I'd invariably find structural issues only after everything was already built on top of that foundation. Building one component, confirming it, then moving on turned out to be faster overall even though it felt slower.

Vague feedback is the other thing that stalls progress. "The overall balance is wrong" is not a prompt Claude Code can act on. Taking a screenshot and naming specifics — "the left column is too wide relative to the right," "the font sizes look inconsistent between cards" — gets an actionable result.

The full sequence looks like this:

1. Get the spec in Markdown
2. Get the component structure as text
3. Build the design system (tailwind.config / globals.css)
4. Implement components one at a time
5. Review screenshots and iterate

Skipping steps 1 to 3 and jumping into implementation consistently led to more rework later. Getting the structure right before writing code produced fewer revisions, at least in my experience.

Japanese SDS vs EU and US

kent-tokyo — Sat, 30 May 2026 07:50:45 +0000

The EU operates under CLP Regulation — its own implementation of GHS — while the US is mid-transition to OSHA HazCom 2024, based on GHS Revision 7. Japanese SDSs aligned to JIS Z 7253:2019 diverge from both in ways that go beyond wording: classification criteria differ, mandatory fields are missing, and some sections require a full rewrite rather than any form of translation.

Comparison of Requirements Across Three Regions

Region	Standard	Language	GHS Base	Key Characteristics
Japan	JIS Z 7253:2019	Japanese	Revision 6 (Revision 9-aligned :2025 edition to be issued December 2025)	National standard with some hazard categories not adopted
EU	CLP Regulation (EC) No 1272/2008	Official language of the destination member state	Independent implementation referencing GHS	REACH registration number and UFI required
US	OSHA HazCom 2012→2024	English	Revision 3→Revision 7 (transition in progress)	OSHA PEL, ACGIH TLV, and NIOSH REL listed together

The UK operates its own GB CLP after Brexit (retained EU CLP law), diverging from EU CLP over time. Canada introduced WHMIS 2015 (GHS Revision 5 base) and updated it to a GHS Revision 7/8 base in December 2022. This article focuses on the EU and US.

EU CLP and Its Relationship to GHS

CLP Regulation does not adopt a specific GHS revision. It operates as an independent regulation that references GHS — the GHS revision number does not map directly to CLP.

Harmonised Classification (Annex VI): Annex VI of CLP lists harmonised classifications decided by ECHA for specific substances. Where a harmonised classification exists, it applies by mandate — a supplier's self-classification cannot override it. These harmonised classifications do not always align with JIS classifications.

New Hazard Classes: Commission Delegated Regulation (EU) 2023/707 (in force April 2023) and Regulation (EU) 2024/2865 (in force December 2024) introduced hazard classes that do not exist in GHS:

Endocrine disruption (ED Category 1 and 2): human health
Endocrine disruption (ED Category 1 and 2): environment
Persistent, Bioaccumulative, and Toxic (PBT / vPvB)
Persistent, Mobile, and Toxic (PMT / vPvM)

None of these classes exist in JIS Z 7253 or HazCom.

Transition Schedule (as of May 2026):

Substances first placed on the market from 1 May 2025 onward: new hazard classes apply
Existing substances (in the supply chain): grace period until 1 November 2026
Mixtures first placed on the market from 1 May 2026 onward: new hazard classes apply
Existing mixtures (in the supply chain): grace period until 1 May 2028

Mixtures first entering the EU market from May 2026 already require compliance with the new hazard classes.

US HazCom 2024 Transition

On 20 May 2024, OSHA published the final rule for HazCom 2024, updating the Hazard Communication Standard to align with GHS Revision 7. In January 2026, OSHA extended the compliance deadlines to allow time for regulatory guidance preparation.

The main changes include a new category for desensitized explosives, revised H-statement and P-statement text, and additional SDS requirements.

Compliance deadlines are phased and differ by role — manufacturers, importers, distributors, and downstream users have separate timelines. Check OSHA's official source for the current deadlines.

Note: HazCom 2024 deadlines were revised by OSHA's January 2026 extension notice. Current effective dates are listed at OSHA HazCom effective dates.

Classification Differences

Consider Acute Toxicity Category 5 (oral LD50: 2,000–5,000 mg/kg):

Region/Standard	Acute Toxicity (oral) Category 5	Notes
Japan (JIS Z 7253)	Not adopted	Treated as not classified
EU (CLP)	Not adopted	Independent decision from GHS
US (HazCom 2012/2024)	Optional (not mandatory)	Manufacturer's discretion

Japan, the EU, and the US are aligned in not mandating Category 5, which differs significantly from China (GB 30000.1-2024).

Categories and classes where adoption diverges:

Hazard Class	Japan	EU	US
Acute Toxicity Category 5	Not adopted	Not adopted	Optional
Skin Irritation Category 3	Not adopted	Adopted	Optional
Aspiration Hazard Category 2	Not adopted	Adopted	Optional
Endocrine Disruption (ED)	None	Categories 1 & 2 (from 2023)	None
PBT / PMT	None	Yes (from 2023)	None

The EU adopts Skin Irritation Category 3 and Aspiration Hazard Category 2. Substances listed as not classified in a Japanese SDS may require classification under EU CLP.

Where Translation Fails

Of the 16 SDS sections, a handful can be carried over with translation; most require re-evaluation against local standards.

Section	Translatable?	Reason
Section 2 — Hazard Identification	No	EU harmonised classification applies by mandate; HazCom 2024 classification criteria differ
H-statements and P-statements	No	Text changes between GHS revisions
Section 3 — Composition/Ingredient Information	Verify	EU requires REACH registration number and EC number
Section 8 — OEL Values	No	OSHA PEL, ACGIH TLV, NIOSH REL, and EU OELVs are separate values
Section 15 — Regulatory Information	No	Translating "Industrial Safety and Health Act (労働安全衛生法)" yields a law name that does not exist in EU or US regulatory frameworks
Section 1 — Emergency Contact	Verify	EU: UFI required. US: local emergency contact number required
Sections 4–7, 9–12	Mostly yes	Physical data and procedures are largely transferable, though Section 11 must align with Section 2

Some typical problems when applying a straight translation:

Action	What appears in the SDS	Problem
Translate Section 15 "労働安全衛生法" to English	Industrial Safety and Health Act	This law does not exist in EU or US regulatory frameworks
Translate H302 "飲み込むと有害" to English	Harmful if swallowed	HazCom 2024 has revised the text of some H-statements
Carry over Japanese control concentrations (管理濃度, mandatory administrative exposure values under Japan's Industrial Safety and Health Act) as-is	50 ppm (Japan 管理濃度)	OSHA PEL, ACGIH TLV, and NIOSH REL are separate values
Translate "Skin irritation: not classified" to English	Not classified	EU CLP classifies some of these substances as Category 3
Omit REACH information	(no entry)	EU requires REACH registration number and UFI

Do not translate H-statement and P-statement text

Translating the Japanese text of H302 ("飲み込むと有害") into English may not match the official HazCom 2024 wording. Look up the H- or P-statement number and use the official text from the destination country or region. Because HazCom 2024 revised some H-statements and P-statements, the GHS Revision 3 text used in HazCom 2012 SDSs cannot simply be carried forward.

Section 15 requires a complete rewrite, not a translation

"Industrial Safety and Health Act" — the literal English rendering of 労働安全衛生法 — does not correspond to any EU or US statute. For EU SDSs, list REACH Regulation, CLP Regulation, and the implementing legislation of the destination member state. For US SDSs, list the OSHA Hazard Communication Standard (29 CFR 1910.1200), TSCA, and SARA Title III.

Section 8: OEL Comparison

Region	Reference Standard	Metric	Legal Force
Japan	Control concentrations (管理濃度, mandatory administrative exposure values, appended to Industrial Safety and Health Ordinance); JSOH (Japan Society for Occupational Health) recommended values	TWA equivalent	Control concentrations are mandatory
EU	EU Occupational Exposure Limit Values (OELVs); national OELs of individual member states	TWA, STEL	Most EU OELVs are indicative (non-binding health-based values); Binding OELVs (BOELVs) are mandatory minima. Member states must establish national OELs at least as strict as BOELVs.
US	OSHA PEL (29 CFR 1910 Subpart Z)	TWA	Mandatory (many values date to 1971 and have rarely been updated)
US	ACGIH TLV (American Conference of Governmental Industrial Hygienists)	TLV-TWA, TLV-STEL	Not legally binding (widely used as the practical standard)
US	NIOSH REL (National Institute for Occupational Safety and Health)	TWA, STEL	Not legally binding

US SDSs in practice list all three — OSHA PEL, ACGIH TLV, and NIOSH REL — together. Many OSHA PELs date to 1971 and are well below current health risk assessments. Japanese control concentrations and JSOH recommended values cannot be substituted for any of these.

For EU SDSs, confirm both the EU OELVs and the national OELs of the destination member state. EU OELVs set the floor; individual member states may set stricter values.

EU-Specific Requirements

REACH Registration Number

Substances registered with ECHA under REACH are assigned a registration number (format: 01-XXXXXXXXXX-XX-XXXX), which goes in Section 3. Japanese chemical manufacturers cannot register directly under REACH, but the number obtained by the EU importer or Only Representative must be confirmed and included in the SDS.

An SDS without a confirmed registration number prevents EU downstream users from fulfilling their regulatory obligations.

UFI (Unique Formula Identifier)

The UFI links a mixture's composition to the notification submitted to the Poison Centre. Under Regulation (EU) 2017/542, UFIs are required — phased in from 2021 — on SDSs and labels for hazardous mixtures. UFIs are generated using the ECHA tool. Japanese SDS formats have no equivalent field.

Extended SDS (eSDS)

When a substance requires a Chemical Safety Assessment (CSA) under REACH, an Exposure Scenario must be attached to the SDS — producing an extended SDS (eSDS). The receiving party must review the attached scenarios to confirm their conditions of use fall within the documented scope.

US-Specific Requirements

California Proposition 65

California's Safe Drinking Water and Toxic Enforcement Act of 1986 (Prop 65) requires warning labels for products containing listed carcinogens or reproductive toxins above specified thresholds. For products sold in California, note applicable Prop 65 substances in Section 15 and add the required warning on product labels.

SARA Title III

The Superfund Amendments and Reauthorization Act (SARA) Title III requires facilities to report storage and releases of certain hazardous chemicals to the Local Emergency Planning Committee (LEPC). Section 15 should note the applicable sections: Section 302 (EHS list), Section 304, Section 311/312, and Section 313 (TRI reporting).

TSCA

Section 15 should indicate whether each substance appears on the TSCA Section 8(b) Chemical Substance Inventory.

Localization Requirements by Section

Sections that always require localization

Section	Changes Required
Section 2 — Hazard Identification	Apply CLP harmonised classification (EU); apply HazCom 2024 classification criteria (US)
Section 3 — Composition/Ingredient Information	REACH registration number and EC number (EU); confirm TSCA inventory listing (US)
Section 8 — Exposure Controls/Personal Protection	Replace with EU OELVs and destination member state OELs (EU); list OSHA PEL/TLV/NIOSH REL (US)
Section 15 — Regulatory Information	Rewrite for REACH/CLP (EU) or OSHA HazCom/TSCA/SARA (US)

Sections frequently requiring changes

Section	Changes Required
Section 1 — Identification	UFI (EU); local emergency contact number
Section 13 — Disposal Considerations	Local legislation: EU Waste Framework Directive (WFD), US RCRA, etc.
Section 14 — Transport Information	UN numbers are shared, but DOT (US) and ADR (EU road) have different notation requirements

Checklists

Checklist: Japanese SDS → EU SDS

Section 1: Is a UFI included? (required for hazardous mixtures)
Section 1: Is the emergency contact number valid in the destination member state?
Section 2: Where Annex VI harmonised classification exists, is it applied?
Section 2: Has the substance been checked against the new hazard classes in (EU) 2023/707 and (EU) 2024/2865 (endocrine disruption, PBT/PMT)?
Section 3: Is the REACH registration number included?
Section 8: Are OEL values based on EU OELVs and the national OELs of the destination member state?
Section 15: Are REACH Regulation, CLP Regulation, and the destination member state's implementing legislation listed?
Language: Is the SDS in the official language of the destination member state?

Checklist: Japanese SDS → US SDS

Section 2: Is the classification done under HazCom (2012 or 2024) criteria?
Section 8: Are all three standards — OSHA PEL, ACGIH TLV, and NIOSH REL — listed?
Section 15: Are OSHA Hazard Communication Standard (29 CFR 1910.1200), TSCA, and SARA Title III (where applicable) listed?
Section 15: For products sold in California, are applicable Prop 65 substances noted?
Language: Is the SDS in English?
HazCom 2024 transition: Have the current OSHA compliance deadlines been confirmed?

Summary

"GHS-based" is the common thread, but classification systems, mandatory content, applicable law, and update obligations differ across regions.

As of May 2026:

EU: CLP has its own classification system. The 2023 regulatory updates — (EU) 2023/707 and (EU) 2024/2865 — added new hazard classes including endocrine disruption. Mixtures first entering the EU market from May 2026 must comply. The main differences from Japanese SDSs are the REACH registration number and UFI requirements, and the mandatory application of harmonised classification.
US: Transition to HazCom 2024 (GHS Revision 7 base) is ongoing. OSHA extended the compliance deadlines in January 2026 — check the OSHA website for current dates. The practice of listing OSHA PEL, ACGIH TLV, and NIOSH REL together in Section 8 remains unchanged.
Japan: JIS Z 7253:2025 (aligned to GHS Revision 9) is due for mandatory enforcement by 2030, with a periodic review obligation in effect since 2023.

A translated Japanese SDS is missing the REACH registration number, UFI, and harmonised classification for EU use — and the OSHA-required OEL entries and SARA/TSCA information for US use. Working from a Japanese source, the localization work typically exceeds the translation work.

Cheminformatics Databases in 2026: PubChem, ChEMBL, Regulatory Inventories, and API Access

kent-tokyo — Wed, 27 May 2026 12:42:44 +0000

When you try to pull chemical structure or bioactivity data via API, every database has its own endpoint design, its own license terms, and its own coverage. Research DBs, national regulatory inventories, and Snowflake as of May 2026.

Research DB Overview

DB	Contents	API	Bulk Download	License
PubChem	Compounds, bioactivity, toxicity, patents	REST	✓ (FTP / PUG Download)	Public domain
ChEMBL	Drug bioactivity	REST + Python SDK	✓ (TSV / SDF / SQL, FTP)	CC BY-SA 3.0
RCSB PDB	Protein 3D structures	GraphQL + REST	✓ (FTP / rsync)	CC0
DrugBank	Drug info, DDI	REST (registration required)	Suspended	CC BY-NC 4.0
ZINC	Purchasable compounds, 3D	None	✓ (SDF / SMILES, FTP)	Free
BindingDB	Binding affinity (Ki, IC50, etc.)	Limited REST	✓ (TSV, Excel-readable)	CC BY 4.0
UniChem	Cross-DB ID translation	REST	—	Free

PubChem: The First Stop

PubChem (NCBI) holds 119 million compounds and 295 million bioactivity records (NAR 2025), aggregating from over 1,000 sources including ChEMBL and DrugBank. Public domain.

# Compound name → CID
curl "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/aspirin/cids/JSON"
# CID → SMILES
curl "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/cid/2519/property/IsomericSMILES/JSON"
# InChIKey → CID
curl "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/inchikey/BSYNRYMUTXBXSQ-UHFFFAOYSA-N/cids/JSON"

Rate limit: 5 requests/sec, 400 requests/min. For tens of thousands of records or more, use PUG Download (up to 250,000 records per request) or FTP.

PubChem aggregates from many sources, so conflicting values for the same compound are common. For IC50 data specifically, ChEMBL's curated records are more reliable.

ChEMBL: The Standard for ML Data

ChEMBL (EMBL-EBI) is a manually curated bioactivity database extracted from medicinal chemistry literature. It includes unit normalization and activity classification for IC50, Ki, and EC50 values, and has become the standard training data source for ML models.

As of ChEMBL 36 (September 2025): 2.878 million compounds, 24.27 million activity records.

from chembl_webresource_client.new_client import new_client

molecule = new_client.molecule
m = molecule.get('CHEMBL25')
print(m['molecule_structures']['canonical_smiles'])

activity = new_client.activity
for a in activity.filter(target_chembl_id='CHEMBL205', standard_type='IC50')[:5]:
    print(a['molecule_chembl_id'], a['standard_value'], a['standard_units'])

Full DB downloads are available via FTP in SQLite, MySQL, and PostgreSQL formats. pip install chembl-downloader handles reproducible retrieval.

CC BY-SA 3.0. Derivatives must be released under the same license.

RCSB PDB: Protein 3D Structures

RCSB PDB holds 254,000 experimentally determined structures (204,000 X-ray, 34,000 cryo-EM, 14,000 NMR). Fully open (CC0), with complete bulk download via FTP.

The GraphQL API lets you fetch structure info, ligands, and citations in a single request.

import requests
query = """{ entry(entry_id: "1ATP") {
  struct { title }
  rcsb_entry_info { resolution_combined }
} }"""
resp = requests.post("https://data.rcsb.org/graphql", json={"query": query})
print(resp.json()["data"]["entry"]["struct"]["title"])

Cryo-EM structures have grown past 34,000 over the past few years, with large complexes and membrane proteins increasingly represented. AlphaFold 3 released source code and weights for non-commercial use between November 2024 and February 2025, enabling complex structure prediction for proteins, DNA, RNA, and small molecule ligands. AlphaFold DB (4.5 million users) predicted structures are accessible in parallel via RCSB.

DrugBank, ZINC, BindingDB

DrugBank covers 11,891 drug entries — 4,563 approved, 6,231 investigational — plus 1.41 million drug-drug interactions (DrugBank 6.0, 2024). Indications, mechanisms, metabolism, and DDI data are all included, making it the typical starting point for drug repurposing research.

⚠️ As of May 2026, academic dataset downloads are suspended (distribution method update in progress). API access continues.

ZINC22 is a virtual screening resource: approximately 55 billion 2D compounds and 5.9 billion 3D docking-ready compounds (official figures). No REST API — access is via FTP or the web GUI. Primarily used with UCSF DOCK and AutoDock.

BindingDB has 3.2 million protein–small molecule binding affinity records (Ki, IC50, Kd, etc.). The TSV download opens directly in Excel and shows up often in DTI benchmark sets.

UniChem handles ID translation only — ChEMBL ID, PubChem CID, InChIKey, DrugBank ID, and more. Any multi-DB pipeline will need it.

# UniChem 2.0 API (POST form recommended; v1 GET is legacy-compatible)
curl -X POST "https://www.ebi.ac.uk/unichem/api/v1/compounds" \
  -H "Content-Type: application/json" \
  -d '{"type":"inchikey","compound":"BSYNRYMUTXBXSQ-UHFFFAOYSA-N"}'

Japanese Databases (Free Only)

DB	Contents	API	Bulk DL	License
KEGG COMPOUND	Metabolites, drugs, pathway integration	REST (free for academic)	Text format	Academic free / commercial paid
SDBS (AIST)	NMR/IR/MS spectra	None	Not available (50/day limit)	Non-commercial free
NITE-CHRIP	Japanese regulatory info (CSCL, ISHL, etc.)	None	Partial list	Free
Nikkaji RDF (NBDC)	3.6M compounds from Nikkaji	Bulk DL (SPARQL)	RDF/TTL only	CC BY 4.0

KEGG COMPOUND integrates 19,572 pathway-registered compounds and 12,826 drugs with genomic and disease data. The REST API supports compound lookup, pathway cross-referencing, and BRITE hierarchy traversal. Commercial use requires a license via Pathway Solutions.

# Fetch compound by C number
curl "https://rest.kegg.jp/get/C00031"
# Convert KEGG compound IDs to ChEBI IDs
curl "https://rest.kegg.jp/conv/chebi/compound"

SDBS (AIST) covers approximately 34,600 compounds with manually curated spectral data (FT-IR, EI-MS, ¹H NMR, ¹³C NMR). High reliability due to expert curation, but no API and a 50-spectra-per-day download limit.

NITE-CHRIP provides cross-searchable regulatory information for approximately 300,000 substances under Japanese law (CSCL, ISHL, Poisonous and Deleterious Substances Control Act, etc.). Updated every two months. GHS classification lists are partially downloadable; the Excel format is sold separately by CIRS Group.

Nikkaji RDF (NBDC) is the RDF release of the Japanese Chemical Substance Dictionary (Nikkaji). Over 3.6 million compounds, CC BY 4.0 — the only Japanese DB that allows commercial bulk download. SPARQL access required.

Regulatory Databases by Country

Chemical substance inventories and regulatory DBs from various jurisdictions.

DB	Region	Coverage	API	CSV/DL	English
ECHA CHEM	EU	C&L: 350K substances	Not available	✓ (Open Data Portal)	Yes
eChemPortal	OECD	Multi-country	Unconfirmed	—	Yes
EFSA OpenFoodTox	EU	7,880 substances	Yes	✓ (Zenodo)	Yes
NCIS	Korea	Full KECL	Unconfirmed	—	Yes
CCISS	China (3rd-party)	IECSC 47K substances	None	—	Yes
DSL	Canada	28K substances	None	✓ (CSV/XLSX)	Yes
AIIC	Australia	40K substances	None	✓ (spreadsheet)	Yes
NITE-CHRIP	Japan	300K substances	None	Partial	Yes

EU: ECHA CHEM

ECHA CHEM is run by the European Chemicals Agency and is the largest public chemical DB. It covers the C&L Inventory (4,400+ harmonized classifications, 7 million+ industry self-classifications) and REACH registration data (physicochemical, toxicological, and ecotoxicological test results). Relaunched in January 2024, with the C&L module integrated in May 2025. Bulk data is available from the ECHA Open Data Portal.

An official REST API is not yet available (announced as a future feature).

eChemPortal (OECD) provides a single search interface across regulatory DBs from ECHA REACH, the US EPA, Japan's NITE-CHRIP, and others. It covers 27,000 REACH-registered substances and over 1.3 million endpoint records.

EFSA OpenFoodTox is a toxicological evaluation dataset for 7,880 food-relevant substances (food additives, pesticides, contaminants, etc.). Accessible via the Open EFSA API and downloadable through Zenodo.

China: CCISS / IECSC

China's chemical inventory is the IECSC (现有化学物质名录), maintained by MEE (Ministry of Ecology and Environment). It covers 47,000 substances, but the official site is Chinese-only.

The practical entry point is CCISS (a free tool by CIRS Group), which provides an English-language interface for searching IECSC by CAS number or English name. It is not official, but update frequency and accuracy are reliable. For anyone who cannot read Chinese, CCISS is effectively the only access point.

Korea: NCIS

NCIS (National Chemical Information System) is the official DB run by the National Institute of Environmental Research (NIER). It covers KECL (Korea Existing Chemicals List) for K-REACH compliance, hazardous chemical lists, and GHS classification data. It is one of the few Asian government chemical DBs with an English interface.

Canada and Australia

Canada's DSL (Domestic Substances List, 28,000 substances) is available as CSV/XLSX from the Open Government Portal.

Australia's AIIC (Australian Inventory of Industrial Chemicals, 40,000 substances), maintained by AICIS, is published in spreadsheet format twice a year. Neither has an API; bulk download is the only programmatic option.

Snowflake Marketplace

There are no free chemical structure DB listings.

Major chemical structure DBs such as PubChem and ChEMBL are not available as Data Shares on the Snowflake Marketplace. Commercial listings like IQVIA (clinical and prescription data) and DrugPatentWatch (patent data) exist, but they do not contain molecular structure data.

Snowflake works as a platform rather than a data source for chemistry:

RDKit can be installed as a Snowpark Python UDF, making fingerprint calculation and similarity search available as SQL
ChEMBL and PubChem data are loaded via FTP download and Snowpark ingestion as the standard workflow
AWS terminated its S3 hosting of ChEMBL, so FTP is now the standard retrieval method

# RDKit via Snowpark Python UDF
from snowflake.snowpark.functions import udf
from snowflake.snowpark.types import StringType

@udf(return_type=StringType(), input_types=[StringType()])
def canonical_smiles(smiles: str) -> str:
    from rdkit import Chem
    mol = Chem.MolFromSmiles(smiles)
    return Chem.MolToSmiles(mol) if mol else None

As of May 2026, there is no indication that PubChem or ChEMBL are participating as Snowflake Data Shares.

CAS Number Search

CAS numbers (e.g., 50-78-2 for aspirin) are the practical cross-DB identifier. API support varies by database.

DB	CAS Search	Method
PubChem	✓	REST API (treated as compound name)
ChEMBL	✓	Python SDK (synonym filter)
KEGG	✓	REST API
UniChem	✓	POST API (cross-reference)
ECHA CHEM	✓	Web UI only (no API)
NITE-CHRIP	✓	Web UI only
NCIS (Korea)	✓	Web UI only
CCISS (China)	✓	Web UI only
DSL (Canada)	✓	Web UI + CSV download
AIIC (Australia)	✓	Web UI + spreadsheet

PubChem

CAS numbers can be passed directly as compound names.

# CAS number → CID
curl "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/50-78-2/cids/JSON"

# CAS number → SMILES, molecular weight, and formula in one request
curl "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/50-78-2/property/MolecularFormula,MolecularWeight,IsomericSMILES/JSON"

ChEMBL

CAS numbers are stored in ChEMBL's synonyms table.

from chembl_webresource_client.new_client import new_client

molecule = new_client.molecule
results = list(molecule.filter(molecule_synonyms__synonym='50-78-2'))
if results:
    m = results[0]
    print(m['molecule_chembl_id'])
    print(m['molecule_structures']['canonical_smiles'])

KEGG

The KEGG REST API accepts CAS numbers directly in the find endpoint.

# Search KEGG compounds by CAS number
curl "https://rest.kegg.jp/find/compound/50-78-2"

# Returns TSV like: C01405\t50-78-2
# Then fetch details by C number
curl "https://rest.kegg.jp/get/C01405"

The find endpoint also accepts compound names, molecular formulas, and molecular weight ranges.

Bulk CAS → SMILES via PubChem

For pipeline use, the PUG REST POST endpoint handles batch conversion.

import requests

cas_list = ['50-78-2', '64-17-5', '7732-18-5']  # aspirin, ethanol, water

resp = requests.post(
    "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/property/IsomericSMILES/JSON",
    data={'name': '\n'.join(cas_list)}
)

for prop in resp.json().get('PropertyTable', {}).get('Properties', []):
    print(prop['CID'], prop['IsomericSMILES'])

PubChem treats CAS numbers as chemical names. One CAS number can map to multiple CIDs (salts, hydrates, stereoisomers) — if you get multiple results, take the first CID or filter by InChIKey.

Data Quality

A 2025 EPA paper flagged the propagation of incorrect CAS numbers and stereochemical information across multiple databases. PubChem aggregates from many sources, so conflicting values between them are common. For publications or regulatory submissions, check the primary source — literature or experimental data.

Sources

Cheminformatics in Rust in 2025-2026: What Exists, What Doesn't, and Why

kent-tokyo — Mon, 25 May 2026 13:07:26 +0000

RDKit has been the dominant cheminformatics library since its open-source release in 2006. It is written in C++, wrapped in Python, and has accumulated nearly two decades of validated chemistry: SMILES and SMARTS parsing, multiple fingerprint types, 2D coordinate generation, 3D conformer generation, MMFF94 and UFF force fields, a PostgreSQL cartridge. Most cheminformatics pipelines assume it is present.

In mid-2026, Rust's answer is rdkit-sys — bindings to RDKit's C++ CFFI interface — and a collection of pure-Rust crates that stalled in 2020-2021.

What exists in 2025-2026

Crate	Type	Latest	Status
rdkit-sys	C++ FFI to RDKit	0.4.12 (Oct 2024)	Maintained
openbabel	C++ FFI to Open Babel	0.5.4 (Jan 2025)	Maintained
chemcore	Pure Rust	0.4.1 (Feb 2021)	Unmaintained
purr	Pure Rust (SMILES parser)	0.9.0 (Mar 2021)	Unmaintained
smiles-parser	Pure Rust (SMILES parser)	0.4.1 (Nov 2020)	Unmaintained
cosmolkit	Pure Rust (new attempt)	0.2.3 (May 2026)	New, unproven

The pattern in the pure-Rust column is consistent: implementations hit a wall around 2020-2021 and stopped. The active work is FFI bindings to existing C++ tools. A new attempt (cosmolkit) appeared recently with an ambitious scope — SMILES, SDF, conformers, molecular graphs — but with under 800 downloads it is too early to evaluate.

SMILES parsing is solved. The rest is not.

Parsing a SMILES string is a context-free grammar problem, and Rust handles those well. purr implements the full OpenSMILES specification. smiles-parser does the same. Both work. Neither has had a release since 2020-2021.

The problem starts after parsing.

A SMILES string like c1ccccc1 (benzene) uses lowercase atoms to indicate aromaticity. To do anything useful — calculate molecular weight, count implicit hydrogens, check valence — you need to convert it to a Kekulé structure: alternating single and double bonds. This is kekulization, and it is a constraint-satisfaction problem on the molecular graph.

chemcore, the most complete pure-Rust attempt, has supported kekulization since its initial release (v0.1.x, June 2020). A benchmark published alongside v0.3.1 in October 2020 showed it handling edge cases that RDKit cannot. But kekulization is one step. What chemcore does not have: fingerprints, 2D coordinate generation, SMARTS matching, or stereochemistry. The last release was February 2021. Getting past kekulization turned out not to be the finishing line.

Aromaticity: no agreed definition

Even with kekulization in place, aromaticity perception is harder than it looks — partly because aromaticity itself has no single agreed-upon definition in cheminformatics.

Hückel's rule — 4n+2 π electrons — works for monocyclic systems. For polycyclic aromatics and heteroaromatics, implementations diverge. Daylight's original SMILES aromatic model differs from RDKit's model, which differs from CDK's. An algorithm that kekulizes correctly under one model may fail under another.

Any pure-Rust toolkit that wants to produce output compatible with RDKit-generated SMILES needs to match RDKit's aromaticity behavior exactly, not implement some variant of Hückel. That requires reading RDKit's source code and testing against its outputs. It is months of work before any of it is visible to end users.

2D coordinate generation: not attempted

Every cheminformatics toolkit ships 2D depiction — you cannot work with molecules you cannot see. The layout problem is harder than it looks.

RDKit ships its own 2D depiction engine (rdDepictor) and also integrates Schrodinger's CoordGen library because rdDepictor alone produces clashing depictions for complex ring systems. Two tools are needed because neither is sufficient alone. CoordGen works by matching known ring scaffold templates and running iterative geometry optimization for everything else.

No pure-Rust crate has attempted 2D coordinate generation. Getting it right requires ring perception, a library of scaffold templates, and an optimization pass to resolve clashes. It is a multi-month project, and the output is still wrong until enough templates are added.

Substructure search: the graph is not the chemistry

petgraph (v0.8.3, 377M total downloads) provides VF2-based subgraph isomorphism and is actively maintained. VF2 is the standard algorithm for this — roughly an order of magnitude faster than Ullmann on typical molecule-sized graphs. The graph infrastructure exists in Rust.

SMARTS matching, which is how substructure search works in cheminformatics, requires more than graph isomorphism. A SMARTS pattern [#6;r6] means "a carbon atom in a 6-membered ring." Matching it requires: parsing SMARTS syntax, knowing which atoms belong to which rings, and matching node attributes with chemical semantics — atomic number, formal charge, aromaticity flag, implicit hydrogen count.

Connecting petgraph's isomorphism to a chemistry-aware molecular graph is exactly the glue code that no published Rust crate provides.

Why bindings are the rational choice

RDKit's changelog goes back to 2006. The codebase contains 200+ molecular descriptors, MMFF94 and UFF force fields with their respective validation papers, an ETKDG 3D conformer generator that uses torsion angle statistics from the Cambridge Structural Database, and a PostgreSQL cartridge for large-scale screening. The Python ecosystem wraps all of this: chembl_webresource_client for ChEMBL API access, PandasTools, scikit-learn integration for ML on fingerprints.

rdkit-sys exposes a fraction of this via RDKit's CFFI interface. Choosing bindings over a rewrite is not a concession. It is what you do when you look at how much chemistry is embedded in that C++ code and how long it took to get there.

What changed in 2024-2025, and what 2026 adds so far

2024-2025: rdkit-sys had three releases in 2024, the last in October, and moved into the rdkit-rs/rdkit monorepo. openbabel (Rust bindings) released 0.5.4 in January 2025 — it exposes Open Babel's OBSmartsPattern, which matters if you need substructure search without pulling in RDKit.

2026: The only 2026-specific addition is cosmolkit (v0.2.3, May 2026, 778 downloads). It claims an ambitious scope — SMILES, SDF, conformers, molecular graphs, "AI-ready workflows" — but it is too new to evaluate. Whether it addresses aromaticity perception and 2D layout, the parts that stopped every earlier attempt, is not clear from the current documentation.

As of this writing, nothing else has shipped in 2026. The structural gap between Rust and Python cheminformatics is the same as it was in 2025.

The actual hard part

The challenging problems in cheminformatics are not Rust-specific. Ownership and lifetimes will slow you down on day one; aromaticity will block you on month three. The chemistry fundamentals — aromaticity perception, 2D layout, stereochemistry, substructure matching — require domain knowledge that does not come from a Rust tutorial.

RDKit did not get where it is because C++ is better than Rust. It got there because a team of chemists and programmers spent two decades solving specific, hard chemistry problems. Whoever builds the Rust equivalent will need to solve the same problems.

I have been working around these gaps while building chem-wasm-lens, a pure-Rust molecular analysis library targeting the browser via WebAssembly. Restricting scope — no SMARTS, no full stereochemistry — made it possible to ship. But restricted scope is different from a general-purpose toolkit, and that distinction matters.

Rust in 2025-2026: From 'Most Loved Language' to Core Infrastructure

kent-tokyo — Sun, 24 May 2026 04:38:04 +0000

Rust has held the top spot in Stack Overflow's "most admired language" survey since 2016, nearly without interruption. But what happened in 2025 is no longer just about popularity polls. Rust is quietly but steadily becoming the language that underpins critical infrastructure.

"Experimental" Status Removed from the Linux Kernel

In December 2025, at the Kernel Maintainers Summit held in Tokyo, Rust's status in the Linux kernel was elevated from experimental to an officially recognized implementation language.

As LWN.net reported, the outcome was unambiguous: "The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay." Maintainer Steven Rostedt noted there was zero pushback in the room. About five years after Linus first suggested the possibility in 2020, the matter was settled.

Rust code in the kernel currently stands at around 25,000 lines (compared to 34 million lines of C) — still a small share — but the subsystems adopting it are steadily expanding.

Rust Code Running in Production

Major components using Rust in the kernel today:

PHY drivers — network physical layer
null block driver — test block device
Android Binder driver — kernel-side implementation of Android's IPC mechanism
Apple AGX GPU driver — for Apple Silicon, via the Asahi Linux project
Nova GPU driver — for NVIDIA Turing-generation hardware (RTX 20 / GTX 16 series)

The Nova driver is architecturally interesting. It is split into two crates: nova-core (hardware initialization and communication) and nova-drm (Linux DRM API implementation), using an adapter pattern that maps different bus types — PCI, platform, USB — to the same types. Note that as of early 2026, full enablement is still in progress; development is ongoing.

Why Rust is Well-Suited for the Kernel

The majority of kernel driver bugs stem from memory safety issues: NULL pointer dereferences, use-after-free, buffer overflows, data races. In C, the only mitigation is "write carefully." Rust eliminates these classes of bugs at compile time, by construction.

Greg Kroah-Hartman has stated that Rust drivers are safer than their C counterparts, and this is exactly why. The 25,000-line figure is small, but it also means Rust is replacing the parts where "bugs would have been guaranteed if written in C."

The Technical Story Behind `async closures`

Among the stabilizations in 2025, async closures (Rust 1.85) were a deeper change than they appear.

What was wrong with the old workarounds?

Previously, writing an "async closure" looked like this:

// The closure couldn't borrow captured variables inside the Future.
// You had to either move ownership in, or wrap with Arc<Mutex<T>>.
let data = vec![1, 2, 3];
let f = |x: i32| {
    let data = data.clone(); // clone required
    async move { data[x as usize] }
};

The problem with |x| async move { ... } was that the returned Future could not borrow captures from the closure itself. Because the Future has a different lifetime from the closure, you had no way to pass references — you had to either move ownership or clone.

The `AsyncFn` Trait Hierarchy

The async closures introduced in Rust 1.85 come with a new trait hierarchy internally: AsyncFn / AsyncFnMut / AsyncFnOnce.

AsyncFnOnce
  └─ AsyncFnMut
       └─ AsyncFn

This mirrors the existing Fn* traits, but with a critical difference: the Future returned by an async closure can borrow from the closure itself (lending).

let data = vec![1, 2, 3];

// Rust 1.85+: the Future can borrow data directly
let f = async |x: usize| { data[x] };

// Usage at function boundaries
async fn apply<F: AsyncFn(usize) -> i32>(f: F, x: usize) -> i32 {
    f(x).await
}

This works because AsyncFnMut's CallRefFuture associated type is designed to propagate the &mut self lifetime into the Future. Just as FnMut returns &mut self to the caller, AsyncFnMut lets the Future hold that lifetime.

`let chains` — Quietly Important

Also stabilized in 2025, let chains (Rust 1.88, Rust 2024 edition only) look simple but are significant: you can now freely combine if let patterns and ordinary bool conditions with &&. Using this requires edition = "2024" in Cargo.toml.

// before: forced to nest or introduce temp variables
if let Some(user) = get_user(id) {
    if user.is_active() {
        if let Some(role) = user.role() {
            println!("{}", role);
        }
    }
}

// after: flatten conditions and pattern matches on one line
if let Some(user) = get_user(id)
    && user.is_active()
    && let Some(role) = user.role()
{
    println!("{}", role);
}

The same syntax works in while let and match guards, visibly reducing nesting depth throughout a codebase.

Safety Certification: A New Frontier

In December 2025, Ferrous Systems obtained IEC 61508 SIL 2 certification from TÜV SÜD for a subset of Rust's core library, under Ferrocene 25.11.0.

What is IEC 61508?

IEC 61508 is an international standard for functional safety of electrical, electronic, and programmable electronic safety-related systems. SIL (Safety Integrity Level) 2 corresponds to a "probability of dangerous failure of 10^-7 to 10^-6 per hour" — the level required in safety-critical domains such as aerospace, medical devices, industrial machinery, and automotive.

Historically, the de facto standard for safety-critical embedded systems has been C/C++ with MISRA. Rust achieving this level of certification means it has officially stepped into the domain where functional safety is required — not just systems programming for general use.

MISRA C 2025 Addendum 6

The same year, MISRA C 2025 Addendum 6 was published: an assessment of how MISRA C rules apply to Rust. The conclusion is that many existing C-specific rules are simply not applicable to Rust — the compiler enforces them by construction via the ownership model. This document also lays the groundwork for a future Rust-specific MISRA rule set.

Production Adoption Approaching 50%

According to JetBrains' State of Rust Ecosystem 2025, roughly half of surveyed organizations are now using Rust in production in non-trivial ways — a significant jump from around 38-39% in 2023.

Microsoft has started rewriting low-level Windows components in Rust, and Google, Amazon, and Meta have each introduced it into OS-level systems.

An Unexpected Fit for the LLM Era

In an era dominated by generative AI, Rust is being reassessed in an unexpected way.

LLM-generated code contains mistakes. Rust's compiler returns those mistakes immediately and concretely as build errors. The type system and borrow checker enumerate the mistakes an AI made — before the code ever runs.

error[E0502]: cannot borrow `data` as mutable because it is also borrowed as immutable
  --> src/main.rs:8:5
   |
6  |     let r = &data;
   |             ----- immutable borrow occurs here
7  |     println!("{}", r);
8  |     data.push(4);
   |     ^^^^^^^^^^^^ mutable borrow occurs here

The tight feedback loop — "if it compiles, memory safety is guaranteed" — is well-suited for pair programming with an LLM. Fixing Rust compile errors has higher reproducibility than debugging Python runtime errors.

The Biggest Concern: Adoption May Plateau

The State of Rust Survey 2025 found that the top concern is not a technical one.

"Not enough adoption in the tech industry" came in first at 42.1% (narrowly ahead of "the language is getting too complex" at 41.6%).

The learning curve remains steep and unresolved. Some feel the language itself is growing more complex over time. In early-stage startups where velocity is critical, Rust's upfront cost is real.

That said, this concern is also the voice of people who want to use Rust more but see adoption lagging. The fact that technical concerns did not dominate the top of the list suggests Rust has reached a meaningful level of maturity.

Summary

In one sentence: as of 2026, Rust is in the early stages of a shift from "the language people love" to "the language people need."

Linux kernel — Experimental status removed. Real drivers like Nova and Apple AGX are running.
async closures — The AsyncFn trait hierarchy lets Futures borrow from their enclosing closure.
let chains — Flatten if let + bool conditions, reducing nesting without temp variables.
Ferrocene / IEC 61508 — Rust now has a formal foothold in safety-critical domains.
LLM compatibility — The compiler becomes a clear feedback loop for AI-generated code.
Top concern is adoption speed — Technical concerns have receded; ecosystem breadth is now the focus.

Sources:

Open-source SDS tooling for Japanese MHLW compliance: the gap nobody filled

kent-tokyo — Sat, 23 May 2026 01:34:49 +0000

In March 2025, Japan's Ministry of Health, Labour and Welfare (MHLW) published a structured JSON schema for Safety Data Sheet data exchange. The schema covers roughly 200 deeply nested fields and is intended to standardize how SDS information moves between chemical management systems.

Most SDS tooling was not built for this.

What makes Japan's SDS requirements different

Japan's SDS requirements come from two laws: the Industrial Safety and Health Act (ISAH, 労働安全衛生法) and the Chemical Substances Control Law (化審法). Both mandate SDS for regulated chemicals, with format requirements governed by JIS Z 7253 — Japan's implementation of the UN Globally Harmonized System (GHS).

JIS Z 7253 follows the standard 16-section GHS structure. In principle, any GHS-compliant SDS satisfies the content requirements. What makes Japanese compliance distinct is a digital layer: the MHLW schema specifies how SDS content should be structured as machine-readable data, with field-level granularity that PDF documents cannot capture.

How GHS looks different by country

GHS uses a "building block" approach — each country adopts the elements it chooses. The result is that the same GHS-aligned document varies by jurisdiction:

Country/Region	Standard	GHS basis	Notable difference
Japan	JIS Z 7253:2019	GHS Rev. 6	MHLW digital schema; revised to GHS Rev. 9 in Dec 2025
United States	OSHA HazCom 2012	GHS Rev. 3	Updated to GHS Rev. 7 in 2024
European Union	CLP Regulation	GHS-aligned	Stricter on environmental hazards
China	GB 13690-2009	GHS Rev. 4 equivalent	Moving to GB 30000.1-2024 (GHS Rev. 8), mandatory from August 2025
Taiwan	CNS 15030	GHS-aligned	—

Japan-specific regulatory fields

The MHLW schema includes fields with no equivalent in EU REACH or US OSHA HazCom formats. These are the main reason international SDS tooling does not cover the schema out of the box:

Law	Example fields	What they capture
Chemical Substances Control Law (化審法)	`CaSCL.ClassificationStatus`, `CaSCL.RegistrationNumber`	Regulatory classification and registration numbers under this law
Industrial Safety and Health Act (安衛法)	`ISHAct.PublicationOfName`, `ISHAct.Notification`	Name disclosure and notification obligations
Poisonous and Deleterious Substances Control Law	`ControlledSubstancesAct.Applicability`	Whether the substance is classified as poison, deleterious, or specific poison
PRTR Law	—	Chemical release and transfer reporting obligations

Section 15 (Regulatory Information) is the most complex section in the schema — it contains separate subsections for each of these laws, each with its own field structure.

Why this matters now: the 2022 law revision

The MHLW published the schema in 2025, but the driver was a 2022 amendment to the Industrial Safety and Health Act. The amendment shifted Japan's chemical substance regulation from a prescriptive model (government designates specific hazardous substances) to an autonomous management model (companies assess and manage risk themselves).

The practical impact:

Enforcement date	Change
April 2023	Shift to autonomous management model — all substances with confirmed GHS hazard classifications brought progressively into scope
April 2024	SDS must now specify concentration ranges numerically (not just qualitatively)
April 2025	Protective equipment mandatory for substances with skin/eye hazards
April 2027	Risk assessment obligations expand to all regulated substances

With risk assessment coverage expanding significantly, companies need to process SDS data faster and more accurately. Manual PDF entry does not scale. The JSON schema is the infrastructure layer for automating this.

Where existing tools stop

Commercial SDS platforms

The major SDS authoring platforms — Sphera, EcoOnline, Chemwatch, Verisk 3E — have broad international coverage. Japanese is typically a supported output language. What they do not provide, as far as I have found, is export to the MHLW JSON schema. They produce Word or PDF output in the correct section structure, which satisfies the document requirement but not the structured data exchange requirement.

Japanese-market products like SDS Meister and SmartSDS support MHLW JSON output, but their PDF-to-JSON conversion coverage is limited — they are primarily SDS authoring tools, not bulk conversion tools for incoming supplier documents.

Open-source options

Tool	Language	MHLW JSON	PDF → JSON	Approach
sds_parser	Python	No	Yes	Regex, per-manufacturer rules
tungsten	Python	No	Yes	Rule-based, English-only
sds-converter	Rust	Yes	Yes	LLM-based extraction

sds_parser and tungsten solve a different problem: extracting SDS data in English, for specific known manufacturer formats. Neither targets the MHLW schema.

The format inconsistency problem

Even within JIS Z 7253-compliant documents, format varies by manufacturer:

Source of variation	Example
Section heading labels	"2. 危険有害性の要約" (JIS Z 7253) vs "2. Hazard(s) identification" (OSHA HazCom) vs "第2部分危险性概述" (GB/T 16483) — all mean the same thing
Section order	The 16 sections can appear in any order the manufacturer chooses
Concentration notation	"≥95%", "1〜5%", "約100%", "企業秘密" (trade secret) all need different handling
Language mixing	Japanese SDS documents regularly contain English chemical names and CAS numbers

A rule-based parser must enumerate every variant. In practice, manufacturer-specific headings add another layer of variation on top of the standard differences.

The schema itself

Two properties of the MHLW schema are worth knowing before implementing against it.

Section 3 (composition) is the hardest part

Section 3 stores component information as a repeating array. Each component object has nested fields for chemical identity, concentration range, and hazard classification. The same data appears differently depending on whether the source document covers a pure substance, a mixture, or a trade secret formulation.

{
  "Composition": {
    "CompositionAndConcentration": [
      {
        "ChemicalIdentity": {
          "CASNumber": "64-17-5",
          "ISHActNotificationNumber": "2-396"
        },
        "ConcentrationRange": {
          "ConcentrationRangeFrom": 95.0,
          "ConcentrationRangeTo": 100.0,
          "ConcentrationRangeUnit": "%"
        },
        "TradeSecretFlag": false
      }
    ]
  }
}

Typos locked into v1.0

The schema contains field name errors that are now part of the specification:

HumanExposureAndEmergencyMeasuress  ← trailing double-s
TestGuidline                        ← missing 'e' (not Guideline)
Desclaimer                          ← transposed letters (not Disclaimer)
gazetteNo                           ← lowercase first character

Correcting these would break all existing implementations, so they cannot be fixed in v1.0. An implementation that normalizes these to standard English spellings will fail schema validation.

sds-converter

I built sds-converter to address the MHLW schema gap. It handles both directions: PDF/DOCX/XLSX to MHLW JSON, and MHLW JSON to a JIS Z 7253-compliant Word document.

The core approach: rather than enumerating format variants with rules, the tool passes raw section text and the corresponding MHLW schema fields to an LLM and asks it to map values. The LLM handles heading label variation naturally. The output is validated against the schema before writing.

cargo install sds-converter

# PDF → MHLW JSON
sds-converter to-json --input input.pdf --output output.json

# MHLW JSON → JIS Z 7253 Word document
sds-converter to-docx --input output.json --output result.docx --lang ja

The LLM backend is pluggable — Claude, GPT, Gemini, Mistral, Groq, or local models via Ollama. A --quality flag adjusts cost versus accuracy for batch workloads.

Known limitations:

Issue	Status
Scanned PDFs without a text layer	Not supported — requires upstream OCR
Section 3 tables with merged cells	Extraction sometimes fails on complex DOCX layouts
Precision fields mixed with "not measured" entries	Occasional type errors in Section 9 output

These are open problems, not design decisions.

The open gap

The MHLW schema represents a real need for anyone handling chemical compliance in Japan at volume. Commercial tools cover the authoring side; the bulk conversion of incoming supplier PDFs to structured data has no open-source solution targeting this schema — other than sds-converter, which I developed and which is the only implementation I am aware of.

The repository is open. Contributions on the extraction side — particularly Section 3 table handling — are welcome. If you work in cheminformatics or chemical compliance and have approached the MHLW compliance problem differently, I would be interested to hear it.

sds-converter: Converting Safety Data Sheets to MHLW Standard JSON with Rust and LLMs

kent-tokyo — Fri, 22 May 2026 23:09:11 +0000

Background

Safety Data Sheets (SDS) are mandatory documents for every chemical product — solvents, adhesives, industrial gases, cleaning agents. Every manufacturer that supplies a hazardous chemical must provide one. In Japan, the governing standard is JIS Z 7253, which defines 16 sections covering chemical identity, hazard classification, first aid, storage, transport information, and more.

The Ministry of Health, Labour and Welfare (MHLW) published a standard JSON schema in March 2025 for electronic SDS data exchange between chemical management systems. The schema has roughly 200 deeply nested fields covering all 16 sections.

The problem is that real SDS documents don't arrive structured to this schema.

Why SDS documents are hard to parse

Even two documents both compliant with JIS Z 7253 will differ in ways that break rule-based parsers:

Section order — manufacturers arrange the 16 sections freely within the standard
Field labeling — the same data appears under different headings across JIS Z 7253, GHS/OSHA HazCom, GB/T 16483, CNS 15030, and company-specific layouts
Value representation — "≥99.5%", "99.5% or higher", "approximately 100%" all mean the same thing
Language mixing — Japanese SDS regularly embed English chemical names and CAS numbers mid-sentence
Implicit information — section 9 (physical/chemical properties) often has half its fields missing because manufacturers only fill in what's relevant to their product

The MHLW schema compounds this: it has intentional typos that must be reproduced exactly. HumanExposureAndEmergencyMeasuress ends in double-s. TestGuidline is missing an e. Desclaimer has transposed letters. These are in the official spec, and validation fails if you "fix" them.

To handle SDS from international manufacturers (GHS/OSHA format) or Chinese suppliers (GB/T 16483 format) in the same pipeline, you'd need separate parsers for each format. Writing and maintaining those is impractical. I built sds-converter to handle this with an LLM instead.

The 16 sections

#	Schema key	JIS Z 7253 section
1	`Identification`	Chemical identity and company information
2	`HazardIdentification`	Hazard identification
3	`Composition`	Composition / information on ingredients
4	`FirstAidMeasures`	First-aid measures
5	`FireFightingMeasures`	Fire-fighting measures
6	`AccidentalReleaseMeasures`	Accidental release measures
7	`HandlingAndStorage`	Handling and storage
8	`ExposureControlPersonalProtection`	Exposure controls / personal protection
9	`PhysicalChemicalProperties`	Physical and chemical properties
10	`StabilityReactivity`	Stability and reactivity
11	`ToxicologicalInformation`	Toxicological information
12	`EcologicalInformation`	Ecological information
13	`DisposalConsiderations`	Disposal considerations
14	`TransportInformation`	Transport information
15	`RegulatoryInformation`	Regulatory information
16	`OtherInformation`	Other information

Installation and quick start

cargo install sds-converter

# PDF → MHLW standard JSON
export ANTHROPIC_API_KEY=sk-ant-...
sds-converter to-json --input input.pdf --output output.json

# MHLW JSON → JIS Z 7253-compliant Word document
sds-converter to-docx --input output.json --output result.docx --lang ja

# Schema validation
sds-converter validate --input output.json

# Extract raw text (no LLM call — useful for debugging)
sds-converter extract-text --input input.pdf

Supported input: PDF, DOCX, XLSX, TXT.

How the conversion works

Step 1: Text extraction

Text is pulled from the PDF or DOCX file. Use extract-text to inspect exactly what gets sent to the LLM — useful when extraction quality is lower than expected.

Note: Encrypted PDFs and scan-only (image) PDFs are not supported — text extraction requires selectable text.

Step 2: Parallel LLM extraction

The 16 sections are split into two groups and extracted with two parallel LLM calls, halving per-file latency:

GROUP_A (sections 1–9): identification, hazard, composition, first aid, fire fighting, accidental release, handling, exposure, physical properties
GROUP_B (sections 10–16): stability, toxicology, ecological, disposal, transport, regulatory, other

Results from both calls are merged. Sections skipped in the first pass are automatically retried. HTTP rate-limit responses (429/529) trigger exponential backoff retries (2s → 4s → 8s, up to 3 attempts).

Step 3: JSON output

The merged result is written as MHLW SDS data exchange format v1.0 JSON.

LLM backend and quality settings

Choosing a provider

# OpenAI GPT (gpt-4o-mini by default)
sds-converter to-json --input input.pdf --output output.json \
  --provider openai --api-key $OPENAI_API_KEY

# Google Gemini (gemini-2.0-flash by default)
sds-converter to-json --input input.pdf --output output.json \
  --provider gemini --api-key $GEMINI_API_KEY

# Local LLM via Ollama (any OpenAI-compatible endpoint)
sds-converter to-json --input input.pdf --output output.json \
  --provider local --base-url http://localhost:11434/v1 \
  --model llama3.2 --api-key dummy

`--provider`	Default model	Environment variable
`anthropic`	`claude-haiku-4-5-20251001` (low/medium) · `claude-sonnet-4-6` (high)	`ANTHROPIC_API_KEY`
`openai`	`gpt-4o-mini`	`OPENAI_API_KEY`
`gemini`	`gemini-2.0-flash`	`GEMINI_API_KEY`
`mistral`	`mistral-small-latest`	`MISTRAL_API_KEY`
`groq`	`llama-3.3-70b-versatile`	`GROQ_API_KEY`
`cohere`	`command-r-plus`	`COHERE_API_KEY`
`local`	`llama3`	`LOCAL_LLM_API_KEY` (optional)

Quality preset

--quality controls both the model and how much text is sent to the LLM per call:

`--quality`	Model (Anthropic)	Max text fed to LLM	Use case
`low`	claude-haiku-4-5	15,000 chars	Speed/cost priority
`medium` (default)	claude-haiku-4-5	30,000 chars	Balanced
`high`	claude-sonnet-4-6	60,000 chars	Accuracy priority

At high, the full document text including the later sections (transport information, regulatory) is included. Use --quality high when complete 16-section coverage matters.

Batch mode

sds-converter to-json \
  --input-dir ./pdfs/ \
  --output-dir ./json/ \
  --lang ja \
  --concurrency 4

Validation

validate checks structural completeness of the extracted JSON and returns warnings without hard-failing — partial results are still usable.

sds-converter validate --input output.json

Examples of what it checks:

Section 1: no product name (TradeNameJP or TradeNameEN)
Section 1: SupplierInformation missing
Section 2: neither Classification nor HazardLabelling extracted
Section 3: CompositionAndConcentration list is empty

When using the library, convert_to_json returns a (SdsRoot, Vec<String>) tuple — the warnings are surfaced inline.

Output JSON structure

{
  "Datasheet": {
    "IssueDate": "2024-03-31",
    "SDS-SchemaVersionNo": "1.0"
  },
  "Identification": {
    "TradeProductIdentity": {
      "TradeNameJP": "Sample Product"
    },
    "SupplierInformation": {
      "CompanyName": "Sample Corp",
      "Phone": "03-0000-0000"
    }
  }
}

The full schema covers all 16 JIS Z 7253 sections with ~200 fields. The official spec and developer manual are on the MHLW website (Japanese).

Using as a library

[dependencies]
sds-converter-core = "0.1"

PDF → JSON

use sds_converter_core::{
    converter::{AnthropicBackend, LlmConfig},
    convert_to_json, ConvertConfig, Language,
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let backend = AnthropicBackend::new(
        std::env::var("ANTHROPIC_API_KEY")?,
        LlmConfig::default(),
    );
    let config = ConvertConfig {
        source_language: Some(Language::Japanese),
        output_language: Language::Japanese,
        ..Default::default()
    };
    let (sds, warnings) = convert_to_json(
        std::path::Path::new("input.pdf"), &backend, &config
    ).await?;
    for w in &warnings { eprintln!("WARN: {w}"); }
    std::fs::write("output.json", serde_json::to_string_pretty(&sds)?)?;
    Ok(())
}

JSON → Word document

use sds_converter_core::{convert_from_json, ConvertConfig, Language, SdsRoot};

fn main() -> anyhow::Result<()> {
    let sds: SdsRoot = serde_json::from_str(&std::fs::read_to_string("output.json")?)?;
    let config = ConvertConfig {
        output_language: Language::Japanese,
        ..Default::default()
    };
    convert_from_json(&sds, std::path::Path::new("result.docx"), &config)?;
    Ok(())
}

Custom LLM backend

use sds_converter_core::{LlmBackend, SdsError};

struct MyBackend;

impl LlmBackend for MyBackend {
    async fn complete(&self, system: &str, user: &str) -> Result<String, SdsError> {
        // Call your LLM API, return the raw JSON string response
        todo!()
    }
}

Language support

Language	`--lang`	Source standard	Output DOCX headings
Japanese	`ja`	JIS Z 7253	JIS Z 7253
English	`en`	GHS/OSHA HazCom	GHS Rev.10 / ISO 11014
Simplified Chinese	`zh-cn`	GB/T 16483-2012	GB/T 16483-2012
Traditional Chinese	`zh-tw`	CNS 15030	CNS 15030

Comparison with alternatives

Open-source

	sds-converter	sds_parser	tungsten
Language	Rust	Python	Python
AI/LLM	Yes (pluggable)	No (regex)	No (rule-based)
MHLW JSON	Yes	No	No
Bidirectional	Yes (↔ DOCX)	No	No
Multilingual	ja / en / zh-CN / zh-TW	Limited	English only

Commercial (Japan)

	sds-converter	SDS Meister	SmartSDS	Dr.EHS Chemical
AI	Yes (your API key)	No	Yes (translation)	AI-OCR
MHLW JSON	Yes	Yes	Yes	Yes
PDF → JSON	Yes	No (authoring only)	Partial (JP only)	Yes
Open-source	MIT/Apache-2.0	No	No	No

sds-converter is the only open-source tool that supports the MHLW schema, runs entirely locally, and handles the full round-trip.

Crate structure

sds-converter-core — library. LLM extraction, DOCX generation, MHLW schema types.
sds-converter — CLI binary. to-json, to-docx, validate, extract-text subcommands.

Feedback welcome, especially on section 3 component table extraction and non-Japanese document accuracy.

https://github.com/kent-tokyo/sds-converter

DEV Community: kent-tokyo

How you pass molecules to an LLM matters: features I built into my Rust cheminformatics library after reading recent arXiv papers

Introduction

1. ChemicalJSON: explicit graph representation

Motivation

Implementation

2. Molecule context: describe / review / report

Motivation

Implementation

Embedding in an LLM prompt

3. ECFP4 / Tanimoto / LSH: similarity search

Motivation

Implementation

Using it in a RAG pipeline

4. MCP server: calling chemistry tools from an LLM

Motivation

Implementation

In practice

Summary

References

Building a Computer-Aided Synthesis Planning Engine in Pure Rust

Background

Search design

AND-OR tree

A* with SA Score

Beam search

Reaction rules

Benchmarks

Why Pure Rust

Usage

Python

CLI (Rust)

JavaScript / Node.js

What's left

Building chematic: Why I Wrote a Pure-Rust Cheminformatics Library from Scratch

How it started

Why I imposed the pure-Rust constraint

Getting to 15 crates

Getting stuck on the SMILES parser

Getting stuck on kekulization

Fingerprint determinism

Fighting the borrow checker in CIP

ChEMBL full validation

Issue #11: dropping InChI

WASM binding design

Where Rust actually helped

Current state

5 Features That Make chematic Stand Out as a Pure-Rust Cheminformatics Library

Pure Rust — Reproducible and Instant Builds

WebAssembly as a First-Class Target

Feature Flags for Modularity

3D Coordinate Generation and Force Field Minimization in Pure Rust

Drug Discovery Pipeline in ~20 Lines

Fingerprints and Similarity-Based Screening

2D SVG Molecular Depiction

3D Interactive Viewer and Molecular Dynamics

Where to Start

Building chematic: A Pure-Rust Cheminformatics Library for WebAssembly

Why Pure Rust?

Native Fit for WASM

Memory Safety as a Constraint

Reproducibility and Determinism

Turning Zero FFI from a Choice into a Rule

The Shape of chematic

Implementing the Algorithms

Ring Perception (SSSR)

Kekulization

CIP Stereochemistry

ECFP Fingerprints (Morgan Algorithm)

Scope and Packaging Tradeoffs

Use Cases

Development Progress

Limitations

Current Status and Demo

Live Demo

JavaScript and TypeScript Usage

Rust Usage

Testing

What I Do Before Letting Claude Code Touch Web App Design

Before writing any code

The Shape of `chematic`

The Technical Story Behind `async closures`

The `AsyncFn` Trait Hierarchy

`let chains` — Quietly Important