Verixa Phase-1 — New SOP from Scratch (URS-12)

WF#1 Flow #1 · brand new document · v1 · no parent · WP-6 core build · 2026-06-01
Foundation flow for WF#1 (Document Control). This deliverable covers creating a brand new SOP from scratch — the foundational create-author-release path. A companion flow (Verixa_Phase1_SOP_Authoring_Review_Release_Flow.html) shows the version-bump path (revising an existing SOP). The two together cover both ways a document arrives at effective state in Phase-1.
Scenario. Verixa pilot tenant is onboarding their QC laboratory. They have an undocumented sample-receipt process — historically handled via lab notebooks, no formal SOP. Lakshmi (SOP Author) drafts SOP-QC-027 v1 — "Sample Receipt and Chain of Custody at QC Laboratory" from scratch (no prior version, no parent document). Priya (QA Lead) and Vikram (Process Engineer) review with comments; Lakshmi iterates; Anita (Doc Approver) signs release with WP-4 substrate-verified e-sig. SOP becomes effective as v1.
✓ Create brand-new SOP (no parent document) ✓ Server-mints document ID (URS-12 numbering) ✓ Optional template selection (basic) ✓ Author from blank canvas ✓ WP-6 persist+hash content ✓ Standard review + iteration loop ✓ Release with WP-4 substrate e-sig ✗ DocGen template engine — Phase-2 ✗ Import from Word with full redline — deferred (manual upload IN)
(no record) → draft (v1) → under_review ↺ draft (iteration) → effective (v1)
See
Click
Fill
Decide
Sign
Done
DOC
Workflow · Document Control / SOP — New Document Path (URS-12)
Parts 1–6 · 22 steps · Lakshmi, Priya, Vikram, Anita
L
Lakshmi — SOP Author (creating new doc)
quality_leaddocument_authorsite=Chennai · practice=GMP
Part 1 · Create
1
Click
Open Documents module → + New Document
Different button from "+ New Version" (which clones from existing). + New Document creates v1 from scratch with no parent.
Behind the scenes
documents:create permission gate. Form schema returns blank — no parent_document_id pre-fill. ID will be minted server-side based on practice + module taxonomy.
2
Decide
Pick a starting point
Blank canvas ✓
Start with empty body; build sections from scratch. Standard headings inserted automatically.
✓ Selected — fresh process needs custom structure
Practice template
Pre-filled with GMP/GCP/GLP standard sections (Purpose, Scope, Responsibilities, Procedure, References).
For typical SOPs
Upload Word doc
Upload existing .docx as starting draft. Phase-1 manual conversion; Phase-2 will add round-trip redline.
For migration cases
Behind the scenes · creation modes
Three creation modes in Phase-1: blank, template, upload. Pilot supports basic versions of all three.

Templates available in Phase-1 (5 + blank):
  • Standard SOP — Purpose · Scope · Responsibilities · Procedure · References · Revision History (default; practice-specific compliance footer for GMP/GCP/GLP/GDP/GVP)
  • Work Instruction (WI) — Purpose · Tools · Steps · Expected Outcome · Troubleshooting
  • Test Method (TM) — Purpose · Sample Prep · Equipment · Procedure · Calculations · Acceptance · References
  • Form Template — Field definitions · Validation rules · Approval block (for log forms, checklists, batch-record forms)
  • Protocol Template — Objective · Scope · Acceptance Criteria · Procedure · Deviations · Approval (validation/qualification protocols)
Phase-2 additions: Risk Assessment, APQR, Audit Report, Training Material, Regulatory Submission templates.

Upload formats whitelisted (3):
  • .docx — Microsoft Word (Open XML). Primary format. Converted to internal HTML+JSON on upload (best-effort: headings + paragraphs + basic tables preserved; images extracted as attachments).
  • .pdf — read-only attachment; not editable in Verixa (for legacy reference docs only).
  • .txt — plain text for lightweight migration.
Out of Phase-1: .doc (legacy binary), .odt, .rtf, .html, .md.

Upload validation rules:
  • Max file size: 25 MB (larger uploads rejected with 413 FILE_TOO_LARGE)
  • MIME-type check + extension match server-side (prevents .exe renamed .docx)
  • Anti-virus scan on every upload before persistence
  • Macros stripped from .docx on upload (VBA security boundary)
  • Track-changes / Word comments dropped on convert (Phase-2 round-trip would preserve)
  • Complex layouts (text boxes, SmartArt, columns) may not render — flagged to author for cleanup
Out of Phase-1 (Word interop): round-trip Word edit with redline tracking, Word comment preservation, full layout fidelity, DocGen parameterised template engine.
3
Fill
Fill document metadata + scope
Document type *
SOP
Module / Area *
QC Laboratory
Title *
"Sample Receipt and Chain of Custody at QC Laboratory"
Description
"Procedure for receipt of physical samples at QC, log entry, chain of custody, and quarantine pending testing."
Practice *
GMP
Document ID
SOP-QC-027 (auto-minted: SOP + module + next sequential)
Version
1 (auto)
Owner department
QC Laboratory · Chennai
Scope
site=Chennai · all products tested at QC
Linked records (optional)
N/A — no source CAPA, deviation, or finding
Behind the scenes · ID minting + classification
Server mints SOP-QC-027 race-safe. ID format: {doc_type}-{module}-{sequential}. Module taxonomy validated against tenant module_options (URS-08 master data). For a brand new SOP (no source), no revision_classification needed; revision_classification applies only to versions ≥2.
4
Fill
Author from blank canvas
SOP-QC-027 v1 · DRAFT
Sample Receipt and Chain of Custody at QC Laboratory
Author: Lakshmi · Practice: GMP · Effective: TBD · Created from scratch
1. Purpose

Defines the procedure for receipt of physical samples at the QC laboratory, including logging, chain-of-custody documentation, and quarantine pending testing assignment.

2. Scope

Applies to all in-process samples, finished product samples, and stability samples received at the QC laboratory at site Chennai.

3. Responsibilities

QC Receiving Analyst — performs receipt, logging, chain-of-custody. QC Supervisor — reviews daily receipt log. Manufacturing Operator — initiates sample transfer with paperwork.

4. Procedure

4.1 Sample arrival — operator hands sample to QC Receiving Analyst with batch-record reference and sample identifier...
4.2 Logging — record in QC-LOG-021 (Sample Receipt Register) with timestamp, batch, sample type, analyst initials...
4.3 Chain of custody — sample placed in QC receipt bay with custody tag QC-TAG-001 attached...

(more sections still being drafted — Lakshmi continues)

Behind the scenes · WP-6 build (the headline fix)
WP-6 build moment. Today (dev-vimal-audit-2) authored content is dropped at DocumentAuthoring.tsx:31 — rich-text editor state isn't persisted. WP-6 fixes this: persist content on save + auto-save every 30s + compute content SHA-256 hash (documents.content_hash). Without WP-6, Lakshmi loses her work on every page reload — the single biggest pilot blocker.
5
Click
Save Draft
✅ "SOP-QC-027 v1 saved as draft. Content persisted with hash. Auto-save active."
Behind the scenes
State (no record) → draft. Server inserts documents row, persists body, computes content_hash, captures author + timestamp. Audit: DOCUMENT_CREATED · DOCUMENT_DRAFT_SAVED.
6
Click
Submit for Review
Modal asks for reviewer assignments.
7
Fill
Pick reviewers + submit
Submit SOP-QC-027 v1 for Review
Required reviewers *
Priya (QA Lead) · Vikram (Process Engineer)
Reviewer eligibility
document_reviewer + scope match + ≠ Lakshmi (SoD-12-01)
Review due date
+7 days
Notes to reviewers
"New SOP formalising QC sample receipt. First version — please review carefully for completeness."
Behind the scenes · DIRECT NAMED routing (not broadcast)
State draft → under_review. SoD-12-01 reviewer-picker enforcement.

Key distinction: document review uses direct named assignment, NOT the broadcast pool pattern used for deviation/finding triage.
  • Eligible candidates at Chennai (shown in picker): Priya · Vikram · Karan · Deepika · (any others with document_reviewer at site)
  • Lakshmi picks 2: Priya + Vikram
  • Notifications fire ONLY to picked reviewers: 🔔 Priya · 🔔 Vikram
  • Karan and Deepika get NOTHING — they're eligible but were not selected
Audit: DOCUMENT_SUBMITTED_FOR_REVIEW with named recipient list (not pool fan-out). Compare to deviation triage which broadcasts to all qa_reviewer at site simultaneously and uses first-claimer-wins.

Why direct named for review: author knows which expertise the document needs (QA for compliance · process engineer for technical accuracy · QC for analytical methods). Broadcast pool would ping the wrong people.
Lakshmi waits for review feedback.
Hand-off ▶ Direct named notifications to Priya + Vikram only · Karan + Deepika not pinged
P
Priya — QA Lead (Reviewer)
quality_leaddocument_reviewer
Part 2 · Review (QA)
8
See
Notification + opens draft
📋 "New SOP-QC-027 v1 ready for your review. Due 8-Jun."
9
Fill
Adds inline comment on §3 (Responsibilities)
Comments on §3
Priya2026-06-02 14:08 OPEN
@ §3 — Responsibilities
Missing role: who handles after-hours samples? Stability samples can arrive nights/weekends. Need an after-hours custody chain.
10
Click
Click Request Changes
✅ "Requested changes from Priya. Lakshmi notified."
V
Vikram — Process Engineer (Reviewer)
quality_leaddocument_reviewer
Part 3 · Review (Process)
11
Fill
Adds comment on §4 (Procedure)
Comments on §4
Vikram2026-06-02 15:42 OPEN
@ §4.3 chain of custody
Add a §4.4 — what happens if QC receipt bay is full or unavailable? Need a fallback chain. Also: missing reference to forms QC-LOG-021 and QC-TAG-001 in §6 References.
12
Click
Click Request Changes
✅ "Requested changes from Vikram. 2/2 reviewers requesting changes."
L
Lakshmi — addressing comments
document_author
Part 4 · Address comments
13
Fill
Edit document — address both
  • §3 updated: added "After-hours QC Receiving — Shift Lead handles in absence of QC Receiving Analyst; custody log entry includes shift-handoff sign-off"
  • §4.4 added: "Bay full — secondary quarantine cabinet in QC sample prep; custody tag transferred with bay log entry"
  • §6 References — added QC-LOG-021 and QC-TAG-001
14
Click
Reply to each comment + Mark Resolved
Priya2026-06-02 14:08 RESOLVED
@ §3 Responsibilities
Lakshmi (reply): Added after-hours Shift Lead handling. Resolved.
Vikram2026-06-02 15:42 RESOLVED
@ §4.3
Lakshmi (reply): Added §4.4 fallback + §6 references. Resolved.
15
Click
Re-submit for Review
✅ "Re-submitted. Reviewers notified to re-check."
V
Both reviewers — approve
document_reviewer
Part 5 · Approve
16
Sign
Priya signs Approve WP-4
Substrate-verified e-sig. {Priya: 'approved'}
17
Sign
Vikram signs Approve WP-4
Substrate-verified e-sig. {Vikram: 'approved'}
18
See
All approved → release_due_date calculated + routed to Anita
✅ "All reviewers approved. Release due date: 2026-06-09 (5 business days). Routed to Anita."
Behind the scenes · release_due_date calculation
Server fires at last_reviewer_approved event:
  • Reads tenant config: tenant_settings.document_approval_window_business_days
  • Falls back to platform default if tenant hasn't overridden
  • Computes: release_due_date = now + window_days (skipping weekends; no holiday awareness in Phase-1)
  • Persists to documents.release_due_date
  • Emits DOCUMENT_READY_FOR_RELEASE event with the deadline in payload
Audit: DOCUMENT_RELEASE_DUE_DATE_SET with computed value + source (default vs tenant-config).
⚙ Tenant admin configures the release approval window
In Phase-1, the release approval window is a single tenant-wide value applied to ALL document types and practices. Tenant admin sets it once; per-practice or per-document-type granularity is Phase-2.
Where the admin configures it
/admin/settings → Document Control → Approval Windows
Setting
Document approval window
Description
Business days allowed for document approver to sign release after document becomes ready
Type
integer (business days)
Platform default
5 business days
Current tenant value
5 (using default)
Override input
[ 5 ]
Valid range
1–30 business days
Audit on change
TENANT_SETTING_CHANGED with before/after + reason + e-sig
Configuration model
GranularityPhase-1Phase-2
Single tenant-wide value✅ IN — 5 days for ALL docsStill supported
Per-practice (GMP / GCP / GLP / GDP / GVP)❌ OUT✅ IN
Per-document-type (SOP / WI / TM / Form / Protocol)❌ OUT✅ IN
Site holiday calendar awareness❌ OUT — Mon–Fri only✅ IN
Severity-based urgency override❌ OUT✅ IN
Answer to "is it 5 business days for all approvals?": In Phase-1, yes — single value, applied to all document approvals (SOP, WI, TM, Form, Protocol regardless of practice). The tenant admin can change the value (1–30 business days range) but can't yet differentiate by document type. That granularity comes in Phase-2.
A
Anita — Document Approver (release authority)
quality_leaddocument_approver
Part 6 · Release
19
See
Notification + pre-release checklist
🔔 "SOP-QC-027 v1 ready for release approval. Due 2026-06-09 (5 business days)."
All reviewers approved
✓ Priya · Vikram (substrate-verified)
All comments resolved
✓ 2/2
Release due date
2026-06-09 (5 business days · tenant default)
Content hash
b2e8c1...9a4f (SHA-256)
Document type
SOP, new (v1, no parent)
SoD pass
✓ Anita ≠ Lakshmi (author), ≠ Priya/Vikram (reviewers)
Behind the scenes · how Anita got notified (broadcast pool)
Trigger chain:
  • Vikram's Approve click fires server-side gate evaluation: all_reviewers_approved AND all_comments_resolved
  • Both true → emit DOCUMENT_READY_FOR_RELEASE event
  • URS-30 subscriber resolves recipient pool: holders of document_approver Authority Profile + scope ∩ document.scope + active status
  • Pool at Chennai = Anita + QA Head (if separate) + designated deputy — typically 1–3 people
  • Fan-out to all pool members simultaneously; first-claimer-wins (Anita opens first → marked release-approval owner; others see "claimed by Anita")
Routing pattern note: review used direct named (author picks); release uses broadcast pool (system fans to qualified approvers). Pool is small so it often looks direct, but architecturally it's broadcast.

Escalation reality in Phase-1 (honest):
  • ✅ Initial broadcast notification — IN
  • ⚠️ Basic "overdue" reminder (single re-ping) — partial
  • ❌ Multi-tier escalation chain (t+24/48/72 to QA Head / Site Head / Founder) — Phase-2 config, NOT in pilot
  • ❌ Escalation to higher authority on unresponsive pool — Phase-2
Only the Critical-deviation reportability clock is wired with multi-tier escalation in Phase-1 (per DEC-16-26 — regulatory hard-stop). Document approval, CAPA closure, Finding triage all get basic notification only.

Operational workaround for pilot: if Anita is unresponsive, the tenant needs a manual process — daily QA stand-up reviews open queues, or a weekly digest of stale items. Phase-2 will wire the multi-tier escalation engine.

Pre-release gate (server-computed, this screen): Same release gate as version-bump path — content + signature + comment checks are identical regardless of whether v1 or vN. Only difference: no superseded_target to flip.
20
Sign
Sign release WP-4
Controlled Approval — Release of SOP-QC-027 v1
Signing as
Anita · document_approver
Meaning
Approval — release for use (v1)
Effective date
2026-06-15 (7-day grace)
Reason
"New SOP formalises QC sample receipt; reviewer comments addressed; aligned with site practice."
Password
••••••••••
MFA
829471
Sign & Release ▶
21
See
State flips → effective (v1)
under_review → effective (v1)
No prior version to supersede — this is the first effective version.
✅ "SOP-QC-027 v1 effective from 15-Jun-2026. Distribution + training cascade triggered."
Behind the scenes · cascade fires (same as v2+ release)
Audit: DOCUMENT_RELEASED · DOCUMENT_EFFECTIVE. WP-2 event spine fires:
· document_effective → distribution fan-out (next flow)
· sop_effective_for_training → URS-28 training trigger
· No supersede event — v1 has no parent
v1 content immutable post-release; distribution + read-ack tracking continue dynamically.
DONE · New SOP-QC-027 v1 effective. Authoring flow complete.

New document (this flow) vs Version-bump (companion flow) — what's actually different

AspectNew document (v1)Version-bump (v4 of existing)
Entry button+ New Document+ New Version from existing doc
Parent documentNone — parent_document_id IS NULLLinked to v3
Starting contentBlank / template / Word uploadv3 content cloned as starting body
Document IDServer mints new ID (e.g. SOP-QC-027)Same ID, version increments (v3 → v4)
Revision classificationN/A (no prior to compare)Admin / Minor / Major (Major triggers URS-13 CC)
Linked recordsOptional — usually standaloneTypically linked to source CAPA/finding/deviation
Review processIdentical — same SoD + comments + iterationIdentical
Release processIdentical — same WP-4 substrate e-sigIdentical
State at releasev1 → effectivev4 → effective; v3 → superseded
Cascade fireddocument_effective (no supersede event)document_effective + supersede event
Most of the workflow is identical. The differences are concentrated in creation (Part 1) and release cascade (Part 6).