# QMS Studio Validation Readiness Starter Kit

> **PUBLIC DEMO EVIDENCE IS LIMITED AND UNAPPROVED. PRODUCTION/CUSTOMER FILES ARE TEMPLATES, NOT EXECUTED VALIDATION EVIDENCE.**

- Package format version: `0.1`
- Evidence revision: `2026-08-11.4`
- Current product status: Public synthetic-data demonstration
- Production release status: Not established
- Customer intended-use approval status: Required and not supplied

## What the three public statuses mean

1. **Demo verified** means only that the exact limited and cumulative checks in `public-demo-assurance-protocol-summary.md` support final app source commit `02d2f87ecccfd7c7b0770b0b95df5ff69377242b`, with expanded 68-file scoped source fingerprint `4d8ca26c48468c689edf3c225a48085e275a6905af5ecc55ba73361e1278a24d`. Sites version 21 passed the bounded custom-domain live validator and targeted 1280 x 720 / 390 x 844 px typography browser checks. The current local lint/build rerun was blocked by unavailable dependencies and is not claimed as current-release evidence. Major regulated-assurance areas remain untested or human-gated.
2. **Validation package ready** means the downloadable templates and limited, unapproved demo-assurance records are present, parseable, inventoried, and checksum-reconciled. It does not mean that a controlled production-release supplier package is complete.
3. **Customer approval required** means every regulated use still requires the customer to define intended use and obligations, approve risk and protocol, test the exact release/configuration/environment, resolve deviations, train users, authorize production use, and maintain control through change.

No product validation, production readiness, qualified deployment, customer approval, certification, regulatory approval, legal compliance, or audit outcome is claimed.

## Evidence that can be generated now

The recorded final app release supports limited, objective evidence for:

- relevant source/configuration hashes and a bounded source fingerprint;
- dependency restoration in an isolated clean copy;
- lint and production-build results using a Windows-compatible build command;
- development-server rendering of the validation route and ten principal synthetic demo views;
- representative complaint-search and simulated-signature UI behavior;
- package inventory, JSON/CSV/Markdown structure, SHA-256 reconciliation, archive inventory, and static HTTP availability; and
- explicit recording of failed, blocked, excluded, and not-executed checks.

These records are diagnostic supplier evidence. They were not approved before execution by designated regulated-validation roles or placed in a regulated evidence system.

## Release and live identity

- Final app source commit: `02d2f87ecccfd7c7b0770b0b95df5ff69377242b`
- Final scoped source fingerprint: `4d8ca26c48468c689edf3c225a48085e275a6905af5ecc55ba73361e1278a24d` across the 68-file selection defined in `validation-status.json`; the selection now includes `app/coverage` and `public/fonts`
- Source capture state: clean Git working tree at commit capture; this revision `.4` changes validation-kit evidence only and is outside the scoped app-source fingerprint
- Deployed release: Sites version `21`
- Canonical Sites URL: `https://qms-studio-medical-demo.gentle-lotus-1481.chatgpt.site/`
- Custom-domain live target: `https://qms.bio-consultant.com/`
- Final recorded live check: `2026-08-12T01:25:22.377Z`; the custom target passed 30/30. A current-release canonical-target result was not supplied for this revision.
- Final custom-domain browser QA: desktop 1280 x 720 px and mobile 390 x 844 px; Inter and Source Serif loaded; no horizontal overflow; the mobile assistant launcher measured 56 x 56 px; and the header parent cue was hidden on mobile

The custom domain briefly served a stale/mixed cache state during a predecessor rollout; no cache anomaly was reported for Sites v21. Technical deployment gate `GATE-001` is passed for the recorded final commit, Sites version, primary custom-domain live check, and targeted browser check. Human, customer, regulated-release, and specialist gates remain open. Future changes must be impact-assessed and appropriately retested.

Evidence revision `.4` is the local post-deployment record created from those results. This update does not commit, publish, or redeploy revision `.4`; the live checks establish the final app release and existing package-path availability, not live publication of this revised archive.

## Evidence that cannot be generated or approved here

This package cannot supply or sign:

- an approved supplier intended-use statement, risk acceptance, validation conclusion, anomaly disposition, or release authorization;
- an immutable controlled release ID, production deployment qualification, customer configuration baseline, or production-equivalence decision;
- customer requirements, intended use, regulatory applicability, procedures, user acceptance, deviations, training, or production approval;
- qualified legal, regulatory, security, privacy, AI, accessibility, supplier, or penetration-test conclusions; or
- evidence for real authentication, authorization, audit immutability, signatures, record copies, retention, backup, restore, disaster recovery, monitoring, integrations, migration, performance, or regulated data integrity.

## Current-demo evidence files

- `public-demo-intended-use.md` — Narrow intended use, exclusions, data boundary, simulated-control meaning, approvals, and change triggers.
- `public-demo-assurance-protocol-summary.md` — Risk-based methods, executed results, failures, anomalies, conclusion, and residual gates.
- `public-demo-traceability.csv` — Bounded trace from the demo intended use to selected PRD requirements, risks, controls, tests, results, and gaps.
- `validation-status.json` — Machine-readable baseline, status definitions, checks, anomalies, approvals, residual gates, and prohibited claims.

## Future production/customer templates

The following remain deliberately unexecuted:

- `responsibility-matrix.csv` — Starter allocation of supplier, customer, and shared activities.
- `validation-protocol-template.csv` — Representative production/customer tests with blank result and approval fields.
- `traceability-matrix-template.csv` — Example production/customer links among requirements, risks, controls, tests, and evidence.
- `deviation-log-template.csv` — Blank production/customer deviation and resolution records.
- `validation-summary-report-template.md` — Customer conclusion and approval structure for one exact deployment and intended use.

## Package control files

- `manifest.json` — Package revision, scope, status, inventory, media types, and SHA-256 checksums.
- `qms-studio-validation-readiness-starter-kit-v0.1.zip` — Convenience bundle. Its historical filename is retained because the current validation route links to it; inspect `manifest.json` for the evidence revision.

The manifest excludes a checksum for itself and the ZIP because including either value inside the bundled manifest would create a self-reference or circular bundle dependency.

## Safe use

- Do not enter regulated, confidential, personal, patient, health, customer, complaint, device, investigation, or credential data into the public site.
- The simulated QMS workflow state resets and does not create a regulated record.
- The separately mounted Bio-Consultant assistant uses browser storage and external chat/lead endpoints. It is excluded from the demo-assurance conclusion; do not use it for regulated or confidential information.
- Do not reuse demo screenshots, synthetic records, visible hashes, simulated signatures, or labels such as "approved" and "verified" as production evidence.
- Copy future templates into a controlled document system, assign identifiers/owners/reviewers/approvers, tailor them to the exact intended use and baseline, approve before execution, retain objective evidence, resolve deviations, and document the release decision.

## Suggested customer workflow

1. Define and approve intended use, exclusions, system boundaries, record types, electronic-signature use, AI-supported functions, applicable requirements, and acceptance criteria.
2. Identify the exact release, configuration, environment, integrations, roles, test data, time source, retention, backup, restore, and prerequisite procedures/training.
3. Assess foreseeable failures and risk to product quality, patient safety, record integrity, regulatory reporting, privacy, security, accessibility, and continuity.
4. Decide which supplier evidence can be leveraged and which customer-specific scripted, scenario, exploratory, negative, automated, security, recovery, accessibility, and UAT activities are required.
5. Approve the protocol before execution; record actual results and objective evidence; investigate and disposition deviations through authorized reviewers.
6. Approve or reject the exact configured deployment for the stated intended use and maintain it through monitoring, periodic review, incident handling, and change control.

## Primary public references

- FDA, *Computer Software Assurance for Production and Quality Management System Software* (issued February 3, 2026): https://www.fda.gov/media/188844/download
- FDA, *Quality Management System Regulation — Frequently Asked Questions*: https://www.fda.gov/medical-devices/quality-management-system-regulation-qmsr/quality-management-system-regulation-frequently-asked-questions
- Electronic Code of Federal Regulations, 21 CFR Part 11: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
- FDA, *Part 11, Electronic Records; Electronic Signatures — Scope and Application*: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
- European Commission, EudraLex Volume 4: https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en

These links are orientation only. Qualified reviewers must confirm current applicability and controlling requirements for the customer's products, records, markets, and intended use.