Hugging Face's logo

Spaces:
Flamehaven
/
stem-bio-ai
Sleeping

App Files Community
stem-bio-ai / docs /REGULATORY_MAPPING.md
Codex
sync hf space snapshot
6a1cba7
preview code
|
Raw
History Blame
16.9 kB

STEM-BIO-AI Regulatory Traceability Assistant

Version 1.3.0 (Registry-Driven Structural Audit-Readiness Mapping)

Positioning: STEM-BIO-AI is a pre-audit structural evidence tool. It does not determine legal compliance, regulatory clearance, clinical certification, market authorization, or deployer conformance. It identifies observable technical and governance signals that may support a later formal audit.

Interpretation Rule: This document maps detected evidence classes to regulatory requirement families. The result is a traceability aid, not a compliance verdict.

0. Audit-Ready vs Certified

STEM BIO-AI can support substantial internal runtime/security/compliance readiness work, but that is different from external attestation or certification.

Internal readiness that is realistically in scope

  • runtime and security evidence review
  • control mapping and evidence collection
  • validation-package preparation for electronic records / signature workflows
  • access-control, audit-log, traceability, retention, and change-control gap assessment
  • preparation for independent third-party audit or penetration test

Claims that remain out of scope without external assessment

  • issuance of a SOC 2 report
  • ISO 13485 certification
  • strong claims of 21 CFR Part 11 compliance
  • statements such as independent audit passed

The correct external-facing posture is therefore usually audit-ready, readiness-assessed, or prepared for independent review unless a real outside assessor has completed the relevant work.

1. Regulatory Basis Note for Reports

When this layer is surfaced in Markdown, PDF, or explain-style reports, the regulatory basis should appear as a small boxed note below the traceability section rather than near the main score or tier.

Recommended wording:

Regulatory basis note Aligned to current official source classes as of May 2026: EU AI Act (Regulation (EU) 2024/1689), FDA QMSR, FDA AI-enabled device guidance themes, and IMDRF SaMD/GMLP frameworks. This is a traceability aid, not a compliance or clearance determination.

Presentation guidance:

  • Keep this note to 2-3 lines
  • Use small subdued text (roughly 13-15px in UI surfaces)
  • Render in a visually separate muted box/panel
  • Do not place it adjacent to Final Score or T0-T4

Automation guidance:

  • Treat the report note as a rendered view of docs/regulatory_basis_registry.v1.json
  • Validate that registry against docs/regulatory_basis_registry.schema.json
  • Generate the boxed note from display_note.title, body_line_1, and body_line_2
  • Use sources[*].status, published_date, and effective_date to drive freshness checks and update prompts

2. Confidence Model for Regulatory Mapping

Every mapping in this document should be read with one of five confidence levels:

  • Strong: direct structural evidence aligns with a requirement class
  • Moderate: structural evidence supports part of the requirement
  • Weak-Moderate: structural evidence is meaningful but still largely indirect or only partially structural
  • Weak: only surface or declarative signal exists
  • Not Assessed: outside STEM-BIO-AI scope

This confidence level applies to the mapping relationship, not to legal acceptability.

3. EU AI Act (Regulation 2024/1689)

Mapping of observable signals to high-risk requirement families.

AI Act Article Requirement Family STEM-BIO-AI Evidence Class Observable Evidence Mapping Confidence Boundary
Article 10 Data governance and data quality Data integrity and bias evidence signals IRB/dataset citations, provenance-linked references, quantitative subgroup/bias measurement language, validation-boundary language Weak Detects claim-linked or code-linked evidence of governance intent and subgroup measurement surfaces, but does not verify that the measurements were correctly executed, complete, or regulator-adequate
Article 11 Technical documentation Reproducibility and documentation scaffolding CI/CD, lockfiles, environment manifests, containers, reproducibility sections, runnable examples Moderate Does not establish that technical documentation is complete or regulator-ready
Article 12 Record-keeping / traceability Traceability scaffolding changelogs, hash manifests, model/dataset checksum artifacts, versioned config surfaces, explicit manifests, runtime audit-log schemas, decision-event schemas, override-event schemas Moderate Changelog alone is not runtime logging; deploy-time event logging is outside current scope
Article 13 Transparency / instructions for use IFU scaffolding and claim-boundary signals intended-use language, misuse sections, disclaimer/boundary text, input/output interpretation sections, accuracy/metric headings Moderate Declarative sections do not prove Article 13 completeness
Article 14 Human oversight Control interface signals manual override flags, safe interrupt handling, oversight-oriented CLI/config switches, stop/reverse control points Weak Entry points are not equivalent to operational human oversight procedure; stronger confidence would require role definition, escalation path, override reason capture, and post-hoc review evidence
Article 15 Accuracy, robustness, cybersecurity Safety and failure-behavior signals safe exception handling, silent-mock detection, parser guards, reproducibility artifacts, unsafe subprocess findings Moderate Does not perform runtime performance validation, penetration testing, or cybersecurity assurance

4. IMDRF / SaMD Evidence Families

STEM-BIO-AI can support pre-audit review against common SaMD evidence families, but only at the level of structural readiness signals.

SaMD Evidence Family STEM-BIO-AI Evidence Class Observable Evidence Mapping Confidence Boundary
Clinical claim surface / intended-use signal Stage 1 domain and boundary signals bio/clinical terminology plus explicit intended-use, limitation, and non-clinical-use boundaries Weak This is not clinical validation
Scientific validity signal Claim-linked provenance signals literature, dataset, or benchmark references tied to the specific biological/clinical association being claimed Weak-Moderate Citation presence alone does not prove valid clinical association
Analytical / technical validation signal Domain test and reproducibility signals domain-specific tests, known fixtures, parser guards, environment reproducibility, error handling around domain outputs Moderate Does not prove target-population performance
Clinical-context boundary and traceability signal Risk/boundary disclosure and traceability signals intended-use sections, misuse sections, explicit limitations, dataset provenance, subgroup analysis mention Weak Does not establish that the system achieves intended clinical purpose in a target population

Important: If this document uses the phrase clinical, it refers to claim surface and audit-readiness context, not to proven clinical utility.

5. FDA / GMLP / PCCP-Oriented Readiness Signals

These mappings are included because iterative AI/ML device development often depends on change management and lifecycle evidence.

Framework STEM-BIO-AI Evidence Class Observable Evidence Mapping Confidence Boundary
FDA AI-enabled device software functions Change-control and traceability signals changelogs, versioned configs, hash manifests, release artifacts, benchmark calibration history Moderate Does not establish safety/effectiveness for submission
IMDRF GMLP lifecycle expectations Lifecycle discipline signals reproducibility artifacts, explicit limitations, domain tests, governance memory, advisory trace packets Moderate Does not replace design controls or formal QMS
Predetermined Change Control Plan (PCCP) readiness signal Versioned change evidence benchmark deltas, changelog granularity, manifest changes, explicit model/data version surfaces Weak-Moderate Detects change evidence presence, not PCCP adequacy

6. Evidence Grading vs. Empirical Compliance

To avoid compliance theater, separate the signal from the requirement.

Signal detected by STEM-BIO-AI Requirement Family Alignment Status
Changelog (T3) Record-keeping / change history SCAFFOLDING ONLY. Indicates change tracking discipline, not runtime audit logging
CLI Override / Stop Flag Human oversight INTERFACE SIGNAL ONLY. Indicates a mechanism may exist, not that oversight is procedurally or organizationally adequate
Disclaimer / Intended-Use Section Transparency / IFU DECLARATIVE SIGNAL ONLY. Indicates a boundary statement exists, not that IFU is complete
Silent-mock finding absent Robustness NEGATIVE SIGNAL ONLY. Failure mode not observed by current scanner; does not prove absence under all execution paths
SMILES parser guard present Technical validation hygiene HYGIENE SIGNAL ONLY. Safer parsing surface, not proof of chemical or biological validity

7. New Deterministic Diagnostics and Regulatory Relevance

The proposed deterministic diagnostics strengthen traceability only when described conservatively.

Detector Primary Value Likely Regulatory Relevance Mapping Confidence Boundary
SMILES-DECEPT Detect malformed or suspicious molecular string surfaces, placeholder outputs, and missing parser guards Supports analytical/technical validation hygiene review Weak-Moderate Not a chemical validity or efficacy detector
SILENT-MOCK Detect mock/simulated outputs continuing through functional paths Supports robustness and misleading-output risk review Moderate Does not prove runtime absence of all simulated fallbacks
RUN-TRACE Detect unsafe subprocess construction around bio tools Supports robustness and secure execution review Moderate Initial heuristic taint analysis is evidence-only
TRACE-MANIFEST Detect hash/version/config trace artifacts Supports traceability and change-control readiness review Moderate Artifact presence does not prove procedural retention policy
IFU-DEEP-SCAN Detect richer intended-use and misuse sections Supports transparency scaffolding review Weak-Moderate Structural presence only; does not establish IFU completeness or correctness
SAFETY-INTERRUPT Detect stop/override/safe-state code interfaces Supports human oversight interface review Weak-Moderate Interface presence is not oversight governance

8. Mandatory Warning for Institutional Buyers

STEM-BIO-AI detects the presence of structural evidence and accountability artifacts.

  • T0-T1: insufficient visible scaffolding for serious pre-audit confidence
  • T2-T3: meaningful structural evidence exists, but gaps remain
  • T4: strongest observed structural evidence / audit-readiness signal

T4 is not regulatory approval, clinical certification, market authorization, legal conformity, or deployer approval.

STEM-BIO-AI DOES NOT:

  1. Verify the correctness of clinical or biological data.
  2. Verify runtime behavior under all operational conditions.
  3. Perform live human oversight.
  4. Produce deployer-grade runtime logs.
  5. Establish legal compliance with the EU AI Act, FDA expectations, IMDRF guidance, or ISO 13485 by itself.

Institutional Action Recommendation:
Use STEM-BIO-AI as a pre-audit gate and traceability assistant. Low scores identify missing structural prerequisites. Higher scores indicate that a repository may contain enough observable scaffolding for deeper expert review.

9. ISO 13485:2016 / QMS-Oriented Mapping

STEM-BIO-AI can provide automated structural signals relevant to quality-system review in medical software contexts.

  • 7.3.3 Design and development outputs
    Stage 4 containers, lockfiles, manifests, and reproducibility sections can support evidence of controlled technical output surfaces.

  • 7.3.7 Control of design and development changes
    Stage 3: T3, hash manifests, release notes, and benchmark delta traces can support change-history review.

  • 7.3.9 Control of design and development files
    The MICA memory layer and versioned docs can support design-file traceability signals.

Boundary: These are quality-system support signals, not proof that a QMS is implemented or effective.

10. Recommended Report Output Shape

If regulatory traceability is surfaced in reports, it should remain explicit about evidence type and strength.

  • evidence_strength: quality of the observed repository evidence itself
  • mapping_confidence: confidence that this evidence class meaningfully maps to the cited requirement family

These fields may differ. For example, a strong manifest artifact may still map only weakly to a legal requirement if major operational elements remain out of scope.

{
  "requirement": "EU_AI_ACT_ARTICLE_12_RECORD_KEEPING",
  "evidence_type": "hash_manifest_or_versioned_trace_surface_detected",
  "evidence_strength": "strong",
  "mapping_confidence": "moderate",
  "not_assessed": [
    "legal_compliance",
    "deployer_operational_logging",
    "runtime_event_completeness"
  ],
  "finding_refs": [
    "S4_checksum_files:repo/checksums.txt:001",
    "T3_changelog_release_hygiene:CHANGELOG.md:001"
  ]
}

11. Registry-Driven Rendering Algorithm

The regulatory basis note and source references should be rendered from docs/regulatory_basis_registry.v1.json, not hand-maintained in multiple report templates.

Recommended algorithm:

  1. Load regulatory_basis_registry.v1.json
  2. Validate against docs/regulatory_basis_registry.schema.json
  3. Render the small boxed note from:
    • display_note.title
    • display_note.body_line_1
    • display_note.body_line_2
  4. Use sources[*].used_for to attach source families to:
    • stage-level notes
    • final synthesis
    • machine-readable report metadata
  5. Raise review_required if:
    • as_of is stale relative to the current reporting month
    • a required source family is missing
    • a required source is present only as draft_guidance
  6. Keep the rendered note identical across Markdown, PDF, and explain-text surfaces

Recommended machine-readable basis object:

{
  "regulatory_basis": {
    "registry_version": "stem-ai-regulatory-basis-registry-v1",
    "as_of": "May 2026",
    "review_required": false,
    "source_ids": [
      "eu_ai_act_2024_1689",
      "fda_qmsr",
      "fda_mlmd_transparency_2024",
      "fda_pccp_2025",
      "imdrf_samd_clinical_eval_2017",
      "imdrf_gmlp_2025"
    ]
  }
}

This basis object should remain separate from score computation and formal tiering.

12. Per-Stage Traceability Note Model

Traceability should be attached where the evidence is observed, not only in a final appendix.

Recommended structure:

{
  "stage_traceability": {
    "stage_1": [
      {
        "requirement_id": "EU_AI_ACT_ARTICLE_13",
        "mapping_confidence": "weak",
        "evidence_strength": "weak",
        "status": "signal_only",
        "finding_refs": ["R3_clinical_disclaimer:README.md:001"],
        "note": "Boundary and intended-use language is relevant to transparency scaffolding only."
      }
    ],
    "stage_3": [
      {
        "requirement_id": "EU_AI_ACT_ARTICLE_12",
        "mapping_confidence": "weak_moderate",
        "evidence_strength": "moderate",
        "status": "partially_aligned",
        "finding_refs": ["T3_changelog_release_hygiene:CHANGELOG.md:001"],
        "note": "Change-history scaffolding is present, but runtime log completeness is not established."
      }
    ]
  }
}

Recommended stage attachment policy:

  • stage_1: intended-use, disclaimer, claim-boundary, misuse
  • stage_2r: contradictions, unsupported workflow, repeated limitation signals
  • stage_3: tests, provenance, bias, changelog, governance memory
  • stage_4: reproducibility, manifests, checksums, runtime trace schemas
  • bio_diagnostics: parser guards, silent-mock fallback, subprocess safety, SMILES hygiene

13. Implementation Note

Reports should describe this layer as:

  • Regulatory Traceability Assistant, or
  • Structural Audit-Readiness Mapping

They should not describe it as:

  • compliance certification
  • regulatory approval engine
  • clinical validation engine