# 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.

```json
{
  "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:

```json
{
  "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:

```json
{
  "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`