refua-regulatory
refua-regulatory is the Refua regulatory workflow and audit package.
It helps teams follow drug regulation processes by turning campaign decisions and execution outputs into verifiable evidence bundles with end-to-end lineage across plans, tool calls, models, datasets, and generated artifacts.
What it provides
- Campaign decision extraction from campaign run outputs.
- Structured decision records (
decisions.jsonl) with deterministic decision IDs. - Model and data provenance capture per campaign decision.
- Lineage graph materialization (
lineage.json) for traceability. - Evidence bundle packaging with checksums (
checksums.sha256). - Integrity verification for audit handoff and compliance workflows.
- Regulatory checklist evaluation with strict and manual-review gates.
- Automatic comprehensive checklist generation during bundle build.
- Structured outputs that support internal regulatory readiness reviews before agency submission.
Install
cd refua-regulatory
pip install -e ".[dev,test]"
CLI
refua-regulatory --help
Build a bundle
refua-regulatory build \
--campaign-run artifacts/kras_campaign_run.json \
--output-dir artifacts/evidence/kras_run_001 \
--data-manifest ~/.cache/refua-data/_meta/parquet/chembl_activity_ki_human/latest/manifest.json \
--extra-artifact artifacts/candidate_run.json
Output bundle layout:
evidence/
manifest.json
decisions.jsonl
lineage.json
checksums.sha256
artifacts/
campaign_run.json
data_manifests/
extras/
checklists/
drug_discovery_comprehensive.json
drug_discovery_comprehensive.md
By default, build auto-generates the drug_discovery_comprehensive checklist.
Build-time checklist controls:
refua-regulatory build \
--campaign-run artifacts/kras_campaign_run.json \
--output-dir artifacts/evidence/kras_run_001 \
--checklist-template core \
--checklist-template fda_cder_ai_ml \
--checklist-strict
Disable checklist generation:
refua-regulatory build \
--campaign-run artifacts/kras_campaign_run.json \
--output-dir artifacts/evidence/kras_run_001 \
--no-checklist
Include machine-identifying provenance fields only when you need them:
refua-regulatory build \
--campaign-run artifacts/kras_campaign_run.json \
--output-dir artifacts/evidence/kras_run_001 \
--include-sensitive-provenance
Verify a bundle
refua-regulatory verify --bundle-dir artifacts/evidence/kras_run_001
JSON mode:
refua-regulatory verify --bundle-dir artifacts/evidence/kras_run_001 --json
Show bundle summary
refua-regulatory summary --bundle-dir artifacts/evidence/kras_run_001
Run a regulatory checklist
Core automated checklist:
refua-regulatory checklist \
--bundle-dir artifacts/evidence/kras_run_001 \
--template drug_discovery_comprehensive \
--strict
FDA/CDER-oriented template (includes manual-review items):
refua-regulatory checklist \
--bundle-dir artifacts/evidence/kras_run_001 \
--template fda_cder_ai_ml \
--output-json artifacts/evidence/kras_run_001/checklist.json \
--output-markdown artifacts/evidence/kras_run_001/checklist.md
Python API
from pathlib import Path
from refua_regulatory import build_evidence_bundle, verify_evidence_bundle
manifest = build_evidence_bundle(
campaign_run_path=Path("artifacts/kras_campaign_run.json"),
output_dir=Path("artifacts/evidence/kras_run_001"),
)
verification = verify_evidence_bundle(Path("artifacts/evidence/kras_run_001"))
print(manifest["bundle_id"], verification.ok)
Data and model provenance behavior
- Data provenance is loaded from explicit manifest paths (
--data-manifest). refua-dataparquet manifests are parsed directly for dataset IDs, versions, source URLs, and SHA256 checksums.- Model provenance is inferred from executed tool outputs and optional CLI overrides (
--model-name,--model-version). - Campaign run IDs are derived deterministically from payload content unless the run payload provides an explicit
campaign_run_idorrun_id. - Hostname and absolute git root are omitted from execution provenance by default; enable them with
--include-sensitive-provenancewhen required for internal audits.
Test
cd refua-regulatory
python -m pytest -q
python -Im build
Notes
- This package records reproducibility evidence; it does not claim biological efficacy.
- Regulatory submission requirements vary by jurisdiction and program type.
Metadata
Release files for refua-regulatory 0.7.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| refua_regulatory-0.7.2.tar.gz | 34.0 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| refua_regulatory-0.7.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 65.4 kB
Release files / refua_regulatory-0.7.2.tar.gz
| Download URL | refua_regulatory-0.7.2.tar.gz |
|---|---|
| Size | 34.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
58b762a44e478af4956cba0f8f4aacd78af450e87b2b94bdf2d90596c89e4a05
|
|
BLAKE2b-256 checksum How to use checksums |
ec17fa7b41ce74291f4f89ae6362cd46c8bba8e4c21aa7972af66d4fbb4ef8b6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
poetry/2.3.4 CPython/3.14.4 Darwin/25.4.0
|
Release files / refua_regulatory-0.7.2-py3-none-any.whl
| Download URL | refua_regulatory-0.7.2-py3-none-any.whl |
|---|---|
| Size | 31.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
15def8038bb13a5bb754d2ee7143120e14c5309ffc30cd17f89188d5ed3272dc
|
|
BLAKE2b-256 checksum How to use checksums |
935b7745c84eb2184ff78e4f2d7629c3bf3ac79a65aedc296df94b0ab07189be
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
poetry/2.3.4 CPython/3.14.4 Darwin/25.4.0
|
Security for refua-regulatory 0.7.2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.