Skip to content

Regentry Overview

Regentry turns reviewed analytical evidence into threshold assessments, report drafts, dossier components, and audit-ready export packages.

  • ICH Q3A, Q3B, Q3C, Q3D, M7(R2), Q2(R2), and Q14 support areas
  • FDA, EMA, PMDA, and Health Canada jurisdiction contexts
  • Threshold calculation from dose and impurity context
  • CTD Module 3 report support
  • Human approval and audit trail export

Regentry is built deterministic-first: regulated math and classification come from an auditable, version-pinned rule engine tied to a named guidance revision — LLMs are reserved for narrative, retrieval, and triage and never produce a regulated number. The Phase 0 foundation (moltrace.regulatory.infra) establishes objective, reproducible acceptance evidence from day one: a regulatory metric layer with two zero-tolerance hard gates (calculation-error rate must be 0 and formula coverage 100%), content-addressed rule_set_version / corpus / gold-set provenance, per-run tracking linkable to the model registry, fail-loud schema validation on every structured input (including the SpectraCheck impurity handoff), and a versioned GAMP 5 Appendix D11 validation-document skeleton. The deterministic numeric path is proven byte-identical across repeated runs. (v0.22.0, 2026-06-08)

The five impurity engines (see ICH Guidelines) are exposed as one cohesive capability rather than five separate screens.

  • Unified assessment endpoint. POST /regulatory/impurities/assess takes one drug-product context (dose, route, substance type, treatment duration) plus optional impurity lists and returns one unified report covering Q3A/B thresholds, Q3C residual-solvent limits, Q3D elemental PDEs, M7 mutagenicity class + TTC, FDA CPCA nitrosamine category + AI limit, and the nitrosamine cumulative-risk sum — every number a deterministic computation carrying its regulatory basis and content-hashed rule_set_version. Per-impurity failures degrade to a warnings entry, never a 500, and every response carries human_review_required = true plus a disclaimer. (v0.23.1, 2026-06-09)
  • Dossier-integrated assessments. The dossier assessment endpoints stopped being hollow regex / rule-row lookups and now compute via the deterministic engines: residual-solvent → Q3C and nitrosamine-watch → CPCA (v0.23.2); impurity-risk-register → Q3A/B + M7, sourcing one product dose now carried on the dossier (max_daily_dose_g / substance_type, migration 0013) (v0.23.3); and a net-new …/elemental-impurity-assessment → Q3D, with the dossier also carrying the product route (oral | parenteral | inhalation | cutaneous, migration 0014) because Q3D PDEs are route-dependent (v0.23.4). All five engines now compute behind the dossier, each sourcing the dossier’s product context; tenant rule-rows remain an optional override layer. (v0.23.2–v0.23.4, 2026-06-09)
  • Nitrosamine cumulative-risk rollup. GET /regulatory/dossiers/{id}/nitrosamine-cumulative-risk aggregates every nitrosamine watch on a dossier into one FDA-Rev-2 cumulative verdict (sum(measured / AI limit), which must be < 1), with each watch’s measured_ng_per_day fed into the rollup and non-qualifying watches reported under excluded with a reason — no silent drop. (v0.23.5, 2026-06-09)

Regulatory dossiers are owner-scoped per user — MolTrace has no per-request tenant context, so the boundary is the authenticated user (a system API key or an admin is unrestricted). A non-owner gets a non-leaking 404 (an unowned dossier is indistinguishable from a missing one).

  • Reads (migration 0015). A dossier carries a created_by_user_id owner set at create; a bearer caller reads only dossiers they own, plus their sub-resources and by-child records. Migration 0015_dossier_created_by_user_id adds the column + index and backfills legacy rows from the regulatory.dossier.create audit trail (un-attributable rows stay NULL = system-visible-only). Sibling ?dossier_id= query reads (action-items, notifications, bridges) inner-join the owner so they cannot be an alternate path around the gate. (v0.23.6, v0.24.0, 2026-06-10)
  • Writes. A single require_dossier_access gate (own-or-system/admin, reads and writes alike) guards every POST/PATCH under /regulatory/dossiers/{id}/…, the by-child-id writes (a requirement / action-item / notification mutated by its own id), the cross-module bridge create paths, and the mobile review-decision sync that flips a dossier’s status. A dossier’s project link is validated against the acting user too, so it can’t be linked to another tenant’s workspace project. (v0.23.6, v0.24.1–v0.24.3, 2026-06-10–11)
  • Privileged surveillance. Regulatory surveillance is a privileged platform process: its mutating routes (run + source-watcher create/patch), which fan review action-items and notifications onto every matched dossier across tenants, are admin + system-key only; the GET monitoring reads stay open. (v0.24.4, 2026-06-11)

AI-decision governance (EU GMP Annex 22, draft)

Section titled “AI-decision governance (EU GMP Annex 22, draft)”

An AI-assisted regulatory decision is persisted as a tamper-evident, per-dossier hash chain with a human-in-the-loop (HITL) gate for high-risk decisions. EU GMP Annex 22 is in draft and not in force; these are decision-support governance records, never an “Annex 22 compliant” claim.

  • The decision log. regulatory_ai_decisions (migration 0016) is an append-only table chained per dossier (previous_entry_hash → entry_hash; a HITL review is its own linked row). The API — GET/POST /regulatory/dossiers/{id}/ai-decisions, …/{entry_hash}/review, and …/ai-decisions/verify — records a decision’s model + version, calibrated confidence (constrained to [0,1] so an uncalibrated / NaN value is rejected at the boundary), feature attribution, regulatory basis, and risk level, and verifies the chain by recomputing each row’s content hash and links (DB-level tamper detection). Owner-scoped like the rest of the dossier. (v0.24.7, 2026-06-12)
  • Auto-recording from the request path. The deterministic classifications record their own decisions automatically: a nitrosamine watch records its FDA CPCA categorization (v0.24.8), and an impurity register’s ICH M7 classification and a Q3D elemental assessment each record theirs (v0.24.9). Each is best-effort and in the same transaction — a governance-recording failure is logged and never breaks the underlying assessment — and risk-tiered, so the review queue reflects real criticality (a mutagenic M7 class 1–3, a triggered Q3D Class-1 / limit element, or any potency categorization → high-risk / HITL required). (v0.24.8–v0.24.9, 2026-06-12)

Data-integrity affordances on regulated records

Section titled “Data-integrity affordances on regulated records”

A dossier is a regulated controlled record, so the platform-wide data-integrity hardening lands directly on Regentry workflows:

  • 21 CFR Part 11 e-signatures. A dossier release approval is signed via the dedicated, server-attributed signing path (POST /esignatures/records + the …/verify and …/manifestation reads), with each signature content-bound to the SHA-256 hash of the exact signed record snapshot and the durable signer-name + UTC time-stamp + meaning manifestation embedded in the inspection-package copy. Signing requires a fresh step-up re-authentication (§11.200). Full detail: Compliance → Electronic signatures. (v0.50.0, 2026-06-19)
  • ALCOA+ on controlled records. A regulated change records its why in a queryable reason_for_change column; archiving a dossier-attached controlled record is a soft delete (deleted_at + deleted_by + reason_for_change, retained for the audit trail and retrievable via ?include_deleted=true); and the audit trail is itself an immutable-by-design hash chain. Full detail: Compliance → ALCOA+. (v0.51.0, 2026-06-19)
  • Validation lifecycle + change control (GAMP 5 / CSA). A Regentry release surfaces a regenerable validation package — GET /system-releases/{id}/validation-package — that bundles the traceability matrix + IQ / OQ / PQ-from-CI evidence + change-control state + release signature manifestations into one deterministic artifact, and a CI-evidence ingestion seam (POST /system-releases/{id}/evidence) feeds parsed pytest / coverage into the release’s slots. Once a validation project is approved / archived or attached to an approved release, every child mutation requires a reason_for_change. Full detail: Compliance → Computer system validation. (v0.52.0, 2026-06-20)

Regulatory knowledge corpus and its provenance

Section titled “Regulatory knowledge corpus and its provenance”

A curated corpus of extracted regulatory facts sits behind Regentry’s search surface. It is a provenance system before it is a search index, and three defects in that direction were closed together. The promotion side of the same conveyor — two-person dataset approval through to a canary — is documented in AI Model Lifecycle → Corpus governance.

  • Search stops returning facts a reviewer rejected. search_knowledge filtered on text match and nothing else, so a record someone had explicitly rejected came back beside an accepted one, indistinguishable in the result. The review step existed and a human did the work of rejecting a bad extraction; the search surface then discarded that judgement, and anyone using the corpus to answer a regulatory question was handed refused material as though it were curated. Results now default to accepted-or-unreviewed, every hit carries its own review_status so “nobody has checked this” is never presentable as “someone approved it”, and seeing rejected material takes an explicit opt-in rather than being the convenient default. Unreviewed still returns, because a young corpus would otherwise look empty. Citations are deliberately left unfiltered and the code says so — they have no review status at all, and inventing a default would be guessing at a governance state that was never recorded. (v0.68.3, 2026-08-08)
  • Sources are superseded, never edited. Publication date, DOI and reliability label are exactly the fields a downstream extraction was justified by, so editing them in place left records citing a source that now said something else, with nothing anywhere to reveal the change had happened. A corpus that cannot show what a fact was justified by at the time is not a provenance system. Every change now appends an immutable revision and the predecessor stays readable forever; each extracted record and citation binds to the revision it was actually read from, and a divergence between a record’s revision and the source’s current one is what makes the change detectable at all. The source id keeps meaning the living source, so anything holding one across a change still resolves. Superseding flags, never rewrites: derived records get a review task naming what moved and stay bound to their own revision — auto-re-pointing them would quietly rewrite what they were justified by. Records that predate revisions carry no binding and are flagged too, because “we cannot tell which revision this came from” is not a reason to skip a record, it is the reason it needs a human most. A reliability-label change emits its own audit event, since how far a source is trusted can invalidate every conclusion already drawn from it. Migration 0045 backfills revision 1 for existing sources and deliberately does not backfill the per-record binding, because asserting they came from what the source says now is unknowable — and most likely false precisely where in-place editing already happened. New: GET /knowledge/sources/{source_id}/revisions. (v0.68.4, 2026-08-08)
  • Search matched letters inside unrelated words. The matcher used a raw substring test, so searching the corpus for “ICH” matched which, enrichment and dichloromethane alongside the genuine citation. Tokens are now anchored to a word start rather than a whole word, because full word-boundary matching does not find “Q3A” when searching “Q3” — ‘3’ and ‘a’ are both word characters — which would have stopped reviewers finding Q3A/Q3B/Q3C/Q3D at all. Stated cost: “chlor” no longer finds “dichloromethane”; the leading stem still does. (v0.74.5, 2026-08-30)

A chronological summary of the dossier-era Regentry releases; see the sections above (and ICH Guidelines → Release timeline for the engine library) for substantive detail.

VersionDateHeadline
v0.74.52026-08-30Corpus search anchors tokens to a word start
v0.68.42026-08-08Sources are superseded, never edited (revision binding)
v0.68.32026-08-08Search stops returning facts a reviewer rejected
v0.24.92026-06-12M7 + Q3D classifications auto-record AI decisions
v0.24.82026-06-12Nitrosamine watch auto-records its CPCA AI decision
v0.24.72026-06-12Annex 22 (draft) AI-decision log surfaced on the dossier
v0.24.62026-06-11Readiness reports carry a content hash (provenance)
v0.24.52026-06-11Readiness reports rehydrate (dossier-scoped list read)
v0.24.42026-06-11Surveillance is a privileged (admin/system) process
v0.24.1–v0.24.32026-06-11Dossier writes + by-child + bridge creates owner-scoped
v0.24.02026-06-10Dossier reads are user-scoped (migration 0015)
v0.23.62026-06-10Dossier project link is user-scoped
v0.23.52026-06-09Dossier nitrosamine cumulative-risk rollup
v0.23.42026-06-09Q3D elemental-impurity dossier endpoint + product route
v0.23.32026-06-09Product dose on the dossier; register via Q3A/B + M7
v0.23.22026-06-09Dossier endpoints compute via the engines
v0.23.12026-06-09Unified impurity-assessment endpoint