Initial CSV / CSA technical audit of BayesPeaQ, beginning with Deviation from Open to Closed and extending to shared GxP platform controls.
Six governed lifecycle states. QC acknowledgement is an Open-stage activity rather than a separate record status.
Approved return-for-rework paths preserve historical records and require renewed review where material scientific content changes.
Code mechanisms exist, but still require formally attributable validation execution.
Defined stages, authorized transitions, accountable work assignments and controlled rework.
Persisted revision checks and transactional record, audit and task writes.
Scientific conclusion context checks and separation between author and reviewer.
Defined meaning, reauthentication, signed revision and governed transition persistence.
Authenticated identity and tenant-scoped record access boundaries.
Encrypted Multi-AZ PostgreSQL with backups, deletion protection and non-public access.
A code-level concern is not automatically a reproduced runtime vulnerability. An evidence gap does not prove a control is absent.
Some generic record-editing paths do not yet demonstrate a complete stage, field and role authorization matrix.
Next action: Enforce one server-side authorization matrix across every write path; qualify denied and permitted actions.
Negative OQ requiredEvidence safety and verification checks should share a single conservative policy across the workflow.
Next action: Require eligible security, integrity and source status consistently for reviews and stage handoffs.
Negative OQ requiredThe initial assessment did not establish a complete approved requirements-to-deployment validation package.
Next action: Build one version-locked dossier with URS, risk assessment, executed tests, deviations, release approval and evidence.
Documentation outstandingCode-change authorization and deployment approval need independently demonstrable enforced controls.
Next action: Require controlled review, immutable release references and verified deployment evidence.
Control review neededA signature dialog should always present the current governed record revision when reopened.
Next action: Refresh review state on every signing session; verify stale-view recovery.
Browser OQ requiredReauthentication and failed-signature recovery need attributable evidence and consistent operator guidance.
Next action: Qualify interrupted signing and retries without allowing an unsigned transition.
Reliability OQ requiredSelected code-pattern checks do not replace executed role-based system qualification.
Next action: Use authenticated browser/API OQ with persisted state and audit assertions.
Test upgrade neededTechnical administration and GxP review rights need clear segregation and denial testing.
Next action: Approve a role matrix and qualify administrative negative cases.
Policy review neededInternal hash-chain checking should be complemented by independently protected retention and assurance evidence.
Next action: Qualify export, preservation, restoration and tamper detection.
Assurance evidence neededResilient database configuration is present; recovery of the complete QMS record/evidence chain still needs an executed drill.
Next action: Test application, database and evidence restoration against RPO/RTO and integrity criteria.
Restore OQ neededEvery deployment, build and approval claim must refer to the same immutable execution and revision.
Next action: Reconcile source, pipeline, artifact, deployment and post-release evidence by execution ID.
Release review neededIntended as an OQ protocol starting point. Each case requires frozen source SHA, real execution evidence, test owner, reviewer and exception status.
| Test | Stage | Qualification objective | Risk | Execution status |
|---|---|---|---|---|
| DEV-001 | Open | Incident record number, time, immutable original report and reporter attribution | High | Proposed · not executed |
| DEV-002 | Open | Unauthorized reporter, identity and tenant spoofing rejection | Critical | Proposed · not executed |
| DEV-003 | Open | Duplicate submission protection and single audit lineage | High | Proposed · not executed |
| DEV-004 | Open | Product, batch and site relationship validation | High | Proposed · not executed |
| DEV-005 | QC acknowledgement | Evidence reviewer independence from original reporter | Critical | Proposed · not executed |
| DEV-006 | QC acknowledgement | Source integrity and changing security-state negative cases | Critical | Proposed · not executed |
| DEV-007 | QC acknowledgement | Exactly one governed acknowledgement; remediation of duplicates | Critical | Proposed · not executed |
| DEV-008 | Open → Triage | Only assigned QC Manager may advance; stale transitions denied | Critical | Proposed · not executed |
| DEV-009 | Triage | Consistent QC disposition and escalation decisions | High | Proposed · not executed |
| DEV-010 | Triage → Investigation | Named CFT notifications, responses and objections | High | Proposed · not executed |
| DEV-011 | Investigation | Notebook can be edited only in active stage and by the proper role | Critical | Proposed · not executed |
| DEV-012 | Investigation | Conclusion evidence and independent scientific review | Critical | Proposed · not executed |
| DEV-013 | Investigation | Scientific rework invalidates stale accepted conclusions | Critical | Proposed · not executed |
| DEV-014 | Investigation | Generic editing cannot bypass later-stage authority | Critical | Proposed · not executed |
| DEV-015 | Impact Assessment | Named Department Head assignment and independent assessment | High | Proposed · not executed |
| DEV-016 | Impact Assessment | Return for rework preserves history and renewal requirements | Critical | Proposed · not executed |
| DEV-017 | QA Review | QA ownership, SOP, evidence and CFT closure prerequisites | Critical | Proposed · not executed |
| DEV-018 | QA Review → Closed | Fresh authentication, signer authority, decision and exact revision | Critical | Proposed · not executed |
| DEV-019 | QA Review → Closed | Two distinct signatures for applicable high-risk decisions | Critical | Proposed · not executed |
| DEV-020 | QA Review → Closed | Atomic closure during concurrent writes and simulated failures | Critical | Proposed · not executed |
| DEV-021 | Closed | Read-only controlled record and preserved history | Critical | Proposed · not executed |
| DEV-022 | Shared controls | Multi-tenant record, evidence, task and export isolation | Critical | Proposed · not executed |
| DEV-023 | Shared controls | Timezone, due-date and daylight-saving behavior | High | Proposed · not executed |
| DEV-024 | Shared controls | Refresh, logout, expiry, retry and interrupted-session handling | High | Proposed · not executed |
Controls that must support every Quality workflow and tenant.
| Area | Current foundation | Qualification required |
|---|---|---|
| Identity & tenant | Server-derived identity and tenant-scoped record access | Run full cross-role and cross-tenant denial tests |
| Electronic signatures | Signed decisions tied to controlled revisions | Execute signer, reauthentication and failure-rollback OQ |
| Audit history | Attributable records with hash-chain checks | Validate independent retention, retrieval and tamper evidence |
| Evidence & data integrity | Source hashes and independent review exist | Unify positive eligibility checks and execute negative OQ |
| Change control | Controlled workflow and release procedures exist | Trace approved requirements to executed release artifacts |
| Runtime & monitoring | Container image pinning and central logs observed | Verify monitoring, immutable build identity and rollback |
| Database & recovery | Encrypted Multi-AZ RDS; backups and deletion protection | Demonstrate documented, whole-system restoration |
| Human use & training | Role-specific workspaces and governed tasks | Execute human-role scenarios and approve operating SOPs |
Risk-based, budget-conscious and accountable to a human Quality approver.
Record the exact deployed frontend and backend revisions, immutable artifacts, tenant configuration and approved intended use.
Unify stage authorization and evidence security-state policy, then run targeted negative tests.
Complete all 24 synthetic, isolated workflow tests; preserve every failure and retest under a new evidence ID.
Demonstrate tenant isolation, signature rollback, audit preservation, timeout behavior, recovery and deployment provenance.
Link requirements to risk controls, test protocols, execution records, exceptions, deviations and immutable release artifacts.
Use independent Quality review for release approval and customer-specific intended-use qualification.
Exit criteria for a specific release, not universal certification.
Assessment methods: read-only review of two repositories and selected AWS service configuration. No authenticated end-to-end qualification, full suite run, restore exercise, penetration test or customer acceptance was performed for this snapshot. Applicable GxP requirements vary by intended use and jurisdiction.
