Skip to main content

Trust & Safety

ALETHEIA aggregates publicly available chemical hazard classifications and regulatory categorizations — IARC monograph groups, U.S. EPA classifications, EU regulatory listings, California Proposition 65 entries, and comparable sources — and serves them through a programmatic API and a public JSON viewer. The underlying facts are public. The aggregation is not: a single query returns a normalized, cross-referenced view that would otherwise take a researcher hours to assemble by hand.

That aggregation is exactly what makes the service useful to the people it is built for, and it is also the property that warrants a control. This page documents the automated misuse-detection and containment system that runs on every request to the compound endpoints. It has been in production since before this page was written; this page documents it, it does not announce it.

1. Why this system exists

Most substances in a chemical safety database are unremarkable — food additives, cosmetic ingredients, household compounds, industrial solvents. A minority are regulated as precursors: substances controlled because they are inputs to explosives, controlled narcotics, chemical weapons, acute poisons, or radiological materials. These substances have entirely legitimate reasons to appear in a safety reference: the same compound that sits on a control schedule is often also an agricultural input, a household disinfectant, a laboratory solvent, an industrial feedstock, or the subject of a drinking-water standard. A database that omitted them would be useless for the regulatory and occupational-safety work ALETHEIA exists to support.

So the control cannot be "do not carry this data." The control has to distinguish between reference use — which is the overwhelming majority of traffic and must never be impeded — and an access pattern that looks like sourcing rather than research. That distinction is what the system below implements.

2. What is monitored

Every request to a compound record is classified against a watch list organized into five categories of controlled precursor:

The watch list is derived from published control regimes — U.S. DEA List I and List II, EU Regulation 2019/1148 on explosives precursors, ATF explosive-precursor listings, CWC Schedules 1–3, and the Australian Standard for the Uniform Scheduling of Medicines and Poisons. Categories carry an internal severity, and the chemical-weapons and radiological categories are treated as the most severe.

Classification runs on two independent signals: an exact match against registry identifiers, and a case-insensitive pattern match against the compound's name and synonyms, which catches records whose identifier is absent or unlisted. A compound may match more than one category.

What is not monitored. Records outside these categories — the substantial majority of the corpus — are not classified as watched, are not recorded in any session, and cannot contribute to any escalation.

3. The four escalation tiers

Above a baseline clear state (no watched substance accessed at all), the system assigns one of four threat levels. The tier determines the action.

Tier Meaning Action taken
Notice A watched substance was accessed. This is normal research and reference use. None. No flag is raised, no field is redacted, no request is restricted, and no alert is generated.
Warning Repeated access within a single category, or any access touching a highest-severity category. Flagged for review. Responses are redacted (Section 5) and carry a safety-flag response header. The flag is recorded for cross-instance visibility.
Alert Access spanning more than one watched category within the session window. Restricted and flagged. Redaction as above, plus bulk export is blocked, plus the event enters an internal escalation stream for human review.
Critical A sustained, cross-category pattern consistent with sourcing a synthesis pathway rather than consulting a reference. Contained and escalated. The request is refused outright with an HTTP 403. Bulk export is blocked. The event enters the escalation stream for human review.

The tiers are cumulative in effect: every action available at a lower tier also applies at a higher one.

4. How escalation is evaluated

Escalation is evaluated over a rolling session window. Accesses older than the window are pruned and stop contributing, so a tier is a statement about recent behaviour rather than a permanent mark on an account.

Three properties govern the evaluation, and they are the shape of the rule rather than its constants:

The specific numeric thresholds are deliberately not published. See Section 9.

5. Containment actions

Containment is graduated, and it is built to preserve the information a legitimate user needs while withholding the information that would assist misuse.

Field redaction

For a flagged session, compound responses are filtered through an allowlist, not a blocklist. Only fields explicitly designated as safe are returned; anything else is withheld. This ordering is deliberate: under a blocklist, every newly added field would be exposed by default until someone remembered to add it to the list. Under an allowlist, a new field is withheld by default until it has been reviewed.

Preserved for flagged sessions — the public regulatory picture, which is the part a researcher actually needs and which is available from the issuing agencies anyway:

Withheld for flagged sessions — the material whose value is operational rather than informational:

A redacted response is labelled as redacted. It carries an explicit marker and a stated reason, and the response carries a safety-flag header. The system does not silently return a degraded answer while presenting it as complete.

Export blocking

At Alert and Critical, bulk export is refused with an HTTP 403. The export endpoint performs this check before doing any work and independently of the per-request classification, so a flagged session cannot obtain in one bulk download what the per-record redaction withholds.

Outright refusal

At Critical, the compound request itself is refused with an HTTP 403 and a deliberately uninformative message. The response does not explain which behaviour triggered the containment.

Cross-instance flagging and internal escalation

The API runs across multiple serverless regions, so a flag raised on one instance is persisted to shared storage and is visible to the others. Flags are time-limited and expire automatically — containment is a response to recent behaviour, not a permanent sanction.

Alert- and Critical-level events are additionally written to a dated escalation stream for human review. That stream, and the operational counters associated with it, are reachable only through an administrator-authenticated endpoint, and even there the individual escalation records are withheld from the response — the detail is not exposed to any caller, authenticated or otherwise.

6. Privacy of the monitoring itself

A misuse control that creates a surveillance record is a poor trade. This one is built to hold as little as possible:

7. Design properties

Three properties of the implementation are worth stating explicitly, because each was a deliberate choice against an easier alternative.

It fails toward the user, not against them. If a compound cannot be classified for any reason — a malformed record, a missing identifier, a data error — it is treated as not watched. A data problem can therefore never manufacture a false accusation against a legitimate researcher. The cost of that choice is that a classification failure is a missed detection rather than a spurious one, and that is the correct direction for the error to run.

The safety net does not depend on the system it protects. Detection state is held in-process, per instance, with no external dependency. Shared storage is used only to propagate flags between instances. If that shared storage is unavailable, detection continues to operate locally; it does not fail open.

Caching cannot be used to bypass the check. Responses for unwatched compounds are edge-cacheable, which is the substantial majority of the corpus. Responses for watched compounds are explicitly marked non-cacheable, specifically so that the origin executes the detection step on every such request rather than serving a cached copy and skipping it. Error paths and the Critical-tier refusal are non-cacheable for the same reason. If a substance is added to the watch list later, previously cached responses for it are individually purgeable by design.

8. What this system is not

9. What we deliberately do not publish

This page describes the categories, the tiers, the shape of the escalation rule, and the containment actions in full. It deliberately omits three things:

The reason is the same in all three cases: those values are the parameters someone would need in order to calibrate activity to stay below them. Publishing a detection signature is how you convert a control into a checklist for evading it. We would rather this page be honestly incomplete in a way we have named than complete in a way that degrades the control it describes.

Researchers, regulators, platform-safety teams, and auditors with a legitimate need for the omitted detail should contact us directly — see below.

10. Contact

Questions about these controls, requests for detail under a suitable arrangement, or reports of a suspected weakness in them:

Holistic Quality LLC
Lebanon, Ohio
safety@holisticquality.io

Related: Terms of Service · Privacy Policy · Disclaimer · For Regulators · Security contact

↑ Back to top