Skip to main content

CODITECT WO System — Gap Closure Prompt Series

Classification: Internal — Implementation
Date: 2026-02-13
Version: 1.0
Purpose: Systematically close every identified gap, partial, and design-only item across all 56 artifacts
Method: Each prompt produces implementation-ready specifications + code that update existing artifacts

Gap Inventory Summary​

Extracted from all 56 artifacts — every ⚠️ Partial, ⚠️ Design Only, ❌ Gap, and yellow/red status item.

By Severity​

SeverityCountItems
Critical2Credential vault integration, PHI detection scanner
High5§11.70 hash binding, DAG cycle detection, optimistic locking, break-glass access, SIEM streaming
Medium10Partial Master WO, vendor coordination, session mgmt, re-auth flow, access deprovisioning, training integration, policy templates, hash chain integrity, message signing, incident response WOs
Low/Deferred4Experience expiration, batch scaling API, constraint solver, ML optimization

By Domain​

DomainGap CountPrompts
Security & Cryptography4G01–G04
Regulatory Compliance (FDA)4G05–G08
Regulatory Compliance (HIPAA)4G09–G12
Regulatory Compliance (SOC 2)4G13–G16
Operational Resilience4G17–G20
Agent & Vendor Coordination3G21–G23
Data Integrity & Scaling3G24–G26
Cross-Cutting Updates2G27–G28

Total: 28 prompts · Closes all 21+ identified gaps · Updates ~30 artifacts

Dependency Chain​

Phase A — Security Foundation (must go first, other gaps depend on it)
  G01 (Vault) → G02 (Hash binding) → G03 (Hash chain) → G04 (Message signing)

Phase B — FDA Compliance (depends on Phase A for crypto primitives)
  G05 (Re-auth) → G06 (Training) → G07 (Written policies) → G08 (Audit completeness)

Phase C — HIPAA Compliance (depends on Phase A for vault + crypto)
  G09 (PHI scanner) → G10 (Break-glass) → G11 (Session mgmt) → G12 (Integrity corroboration)

Phase D — SOC 2 Compliance (depends on Phases A+C)
  G13 (SIEM streaming) → G14 (Incident response WOs) → G15 (Access deprovisioning) → G16 (Risk/CAPA)

Phase E — Operational Resilience (independent, can run parallel to B/C/D)
  G17 (Optimistic locking) → G18 (DAG cycle detection) → G19 (Partial Master WO) → G20 (Timeout policies)

Phase F — Agent & Vendor (depends on E for locking + DAG)
  G21 (Vendor coordination) → G22 (Vendor portal IQ/OQ) → G23 (Experience expiration)

Phase G — Scaling & Optimization (independent, lowest priority)
  G24 (Batch WO API) → G25 (Schedule constraint solver) → G26 (Resource optimization)

Phase H — Cross-Cutting (runs last, updates all artifacts with gap closures)
  G27 (Artifact gap status updates) → G28 (Dashboard data sync)

Phase A: Security & Cryptography Foundation​

These are blocking dependencies — cryptographic primitives, vault integration, and hash chains are required by FDA §11.70, HIPAA §164.312(c)(2), and multiple downstream gaps.

G01: Credential Vault Integration​

Gap Source: 27-coditect-impact.md line 148 (Critical), 32-tech-architecture-analyzer.jsx GAP_ANALYSIS (yellow), 20-regulatory-compliance-matrix.md line 47

Current State: Job Plans store credentials in job_plans.credentials JSONB field — plaintext in database. Architecture references "integrate with vault" but no design exists. The §11.100(b) re-authentication flow also depends on centralized credential management.

Gap Definition:

  • No vault integration architecture
  • No credential rotation policy
  • No secret reference pattern (secrets stored by value, not by reference)
  • Agent workers have no secure credential retrieval mechanism

Task: Design and specify the vault integration layer.

Deliverables:

  1. Vault integration architecture — TypeScript interfaces + Prisma schema changes:

    • CredentialVaultAdapter interface supporting HashiCorp Vault and GCP Secret Manager
    • Secret reference pattern: job_plans.credentials stores vault://path/to/secret URIs, never plaintext
    • Agent credential retrieval: short-lived, scoped tokens per agent worker per WO execution
    • Rotation policy: automatic rotation with WO-aware grace periods (don't rotate mid-execution)
    • Credential types: system accounts, API keys, database connections, certificate material

  2. Prisma schema changes:

    • Add CredentialReference model (id, vaultPath, credentialType, rotationPolicy, lastRotated, expiresAt, tenantId)
    • Modify JobPlan.credentials from raw JSONB to CredentialReference[] relation
    • Migration strategy: encrypt-in-place for existing data, then migrate to vault references
    • Add VaultAuditEntry model for credential access logging

  3. Agent credential flow:

    Agent requests credential → Orchestrator validates WO context + agent role
    → Vault issues scoped, time-limited token → Agent uses credential
    → Token auto-expires after WO step completes → Audit logged

  4. Part 11 compliance mapping:

    • How vault integration satisfies §11.10(d) — limiting system access to authorized individuals
    • How scoped tokens satisfy §11.100(b) — unique credential per individual action
    • How rotation satisfies §11.10(c) — protection of records against unauthorized access

Artifacts to Update:

  • 13-tdd.md — Add vault integration section to Security Integration
  • 16-prisma-data-model.md — Add CredentialReference + VaultAuditEntry models
  • 17-e-signature-architecture.md — Add vault-backed signature key management
  • 25-agent-orchestration-spec.md — Add agent credential retrieval protocol
  • 27-coditect-impact.md — Change severity from Critical to Resolved in gaps table

Expected Output: Complete vault integration spec with interfaces, schema, agent flow, and Part 11 mapping. All referenced artifacts updated to close the gap.

G02: §11.70 Cryptographic Signature Binding​

Gap Source: 20-regulatory-compliance-matrix.md line 37 (⚠️ Partial), line 40 (explicit gap statement: "2 days estimated effort")

Current State: Architecture specifies "Hash of (WO version + signer_id + timestamp + meaning)" but no hash generation function exists. The ElectronicSignature Prisma model has no signatureHash field. No verification function exists.

Gap Definition:

  • Hash algorithm selected but not specified (SHA-256 mentioned in architecture, not in code)
  • No signatureHash field on ElectronicSignature model
  • No hash generation function
  • No hash verification function
  • No tamper detection mechanism

Task: Implement the complete cryptographic signature binding specification.

Deliverables:

  1. Hash specification:

    // Canonical form for signature hash input
    interface SignatureHashInput {
      workOrderId: string;
      workOrderVersion: number;    // Optimistic lock version
      signerId: string;            // Person.id
      timestamp: string;           // ISO 8601 UTC, millisecond precision
      meaning: SignatureMeaning;   // APPROVED | REJECTED | ACKNOWLEDGED | AUTHORED
      previousHash?: string;       // Chain to previous signature on same WO (if any)
    }

    // Hash output
    interface SignatureHash {
      algorithm: 'SHA-256';
      hash: string;                // Hex-encoded
      canonicalInput: string;      // JSON.stringify of sorted input (for verification)
    }

  2. Prisma schema additions:

    • ElectronicSignature.signatureHash — String, required
    • ElectronicSignature.hashAlgorithm — String, default "SHA-256"
    • ElectronicSignature.canonicalInput — String (stored for reproducible verification)
    • ElectronicSignature.previousSignatureId — Optional self-reference (chain)
    • Unique constraint: one signature per (signerId, workOrderId, meaning)

  3. Implementation functions:

    • generateSignatureHash(input: SignatureHashInput): SignatureHash
    • verifySignatureHash(signature: ElectronicSignature): { valid: boolean, details: string }
    • getSignatureChain(workOrderId: string): SignatureHash[] — returns ordered chain
    • validateChainIntegrity(chain: SignatureHash[]): { intact: boolean, brokenAt?: number }

  4. Tamper detection:

    • On every WO read that includes signatures, verify hash chain integrity
    • If chain is broken → flag as INTEGRITY_VIOLATION → block further transitions → notify admin
    • Integrity violation is an Emergency stopping condition (ref: §9.3 in system prompt)

  5. Guard integration:

    • T5a (PENDING_REVIEW→APPROVED): generate and store signature hash as part of approval
    • T5b (PENDING_REVIEW→REJECTED): same for rejection signature
    • T3 (SCHEDULED→IN_PROGRESS): hash for start acknowledgment signature

Artifacts to Update:

  • 16-prisma-data-model.md — Add hash fields to ElectronicSignature
  • 17-e-signature-architecture.md — Add hash generation/verification section
  • 19-state-machine-with-guards.md — Add hash generation to signature guard actions
  • 20-regulatory-compliance-matrix.md — Change §11.70 from ⚠️ Partial to ✅ Ready
  • 22-rbac-sod-rules.md — Add integrity violation response procedure

Expected Output: Complete cryptographic binding spec that closes the §11.70 gap.

G03: Audit Trail Hash Chain (Chain of Custody)​

Gap Source: 20-regulatory-compliance-matrix.md line 74 (⚠️ Partial), 40-comprehensive-compliance-dashboard.jsx status "partial" on §164.312(c)(2)

Current State: Architecture states "each audit event references previous event hash" but no implementation exists. AuditTrail model has no hash fields. Append-only is enforced by design (no DELETE/UPDATE on audit) but cryptographic verification of non-alteration is missing.

Gap Definition:

  • No hash field on AuditTrail records
  • No chain linking mechanism (each record referencing previous hash)
  • No chain verification function
  • No periodic integrity audit job
  • HIPAA §164.312(c)(2) requires electronic mechanisms to corroborate ePHI not altered

Task: Design the audit trail hash chain.

Deliverables:

  1. AuditTrail hash chain schema:

    model AuditTrail {
      // ... existing fields ...
      entryHash        String    // SHA-256 of this entry's content
      previousHash     String?   // Hash of the immediately preceding entry (null for first)
      chainSequence    Int       // Monotonic sequence number within tenant
      hashAlgorithm    String    @default("SHA-256")

      @@index([tenantId, chainSequence])
      @@unique([tenantId, chainSequence])  // Prevent gaps
    }

  2. Hash generation function:

    • Input: { tenantId, entityType, entityId, action, performerId, performerType, timestamp, details, previousHash }
    • Canonical JSON serialization (sorted keys, no whitespace)
    • SHA-256 → hex-encoded string
    • previousHash of first entry per tenant = "GENESIS"

  3. Chain verification:

    • verifyAuditChain(tenantId, fromSeq?, toSeq?): ChainVerificationResult
    • Walks the chain, recomputes each hash, verifies against stored hash
    • Returns: { intact: boolean, totalEntries: number, verifiedEntries: number, brokenAt?: number, details: string }
    • Performance: streaming verification (don't load all entries into memory)

  4. Periodic integrity audit job:

    • Runs nightly per tenant
    • Verifies entire chain integrity
    • Generates IntegrityAuditReport (stored separately, also hash-chained)
    • On failure: alert admin, flag tenant, block new entries until investigated

  5. Compliance mapping:

    • HIPAA §164.312(c)(2): hash chain provides electronic corroboration mechanism
    • FDA §11.10(e): immutable, verifiable audit trail
    • SOC 2 PI1.1: processing integrity through cryptographic verification

Artifacts to Update:

  • 16-prisma-data-model.md — Add hash fields to AuditTrail
  • 17-e-signature-architecture.md — Reference chain for signature audit entries
  • 20-regulatory-compliance-matrix.md — Change §164.312(c)(2) from ⚠️ Partial to ✅ Ready
  • 25-agent-orchestration-spec.md — Agent actions generate hash-chained audit entries

Expected Output: Complete audit hash chain spec closing HIPAA §164.312(c)(2).

G04: Agent Message Signing & Integrity​

Gap Source: 40-comprehensive-compliance-dashboard.jsx §164.312(e)(2)(i) "Integrity Controls (Transmission)" status "partial"

Current State: Agent message contracts (doc 26) define message types but have no integrity protection. Messages between orchestrator and workers are not signed. No mechanism to detect message tampering or replay.

Gap Definition:

  • No message signing on agent-to-agent communication
  • No replay detection
  • No message integrity verification at receiver
  • HIPAA §164.312(e)(2)(i) requires integrity controls during transmission

Task: Add cryptographic integrity to the agent message protocol.

Deliverables:

  1. Message envelope with integrity fields:

    interface SecureAgentMessage<T extends AgentMessage> {
      payload: T;
      integrity: {
        messageHash: string;        // SHA-256 of canonical payload
        senderId: string;           // Agent node ID
        senderSignature: string;    // HMAC-SHA256 with shared orchestrator key
        nonce: string;              // UUID v4 — replay prevention
        timestamp: string;          // ISO 8601
        sequenceNumber: number;     // Monotonic per sender — gap detection
      };
    }

  2. Key management:

    • Orchestrator generates per-session HMAC key for each agent worker
    • Keys stored in vault (from G01), scoped to WO execution session
    • Key rotation on every new WO assignment
    • No persistent keys — ephemeral per execution

  3. Verification at receiver:

    • verifyMessageIntegrity(msg: SecureAgentMessage): IntegrityResult
    • Checks: hash match, HMAC signature valid, nonce not replayed, timestamp within window (±30s), sequence number monotonic
    • On failure: reject message, log integrity violation, circuit breaker increment

  4. Nonce registry:

    • In-memory bloom filter for recent nonces (fast rejection of replays)
    • Backed by Redis/NATS KV for distributed deployment
    • Auto-expire entries after 60 seconds (message TTL)

  5. Integration with existing message contracts:

    • Wrap every message type in SecureAgentMessage<T> envelope
    • Transparent to agent logic — signing/verification happens in transport layer
    • Update AgentMessageBus interface to handle envelope

Artifacts to Update:

  • 25-agent-orchestration-spec.md — Add message signing to communication protocol
  • 26-agent-message-contracts.md — Wrap all contracts in SecureAgentMessage envelope
  • 20-regulatory-compliance-matrix.md — Close HIPAA §164.312(e)(2)(i)
  • 40-comprehensive-compliance-dashboard.jsx — Update status to "ready"

Expected Output: Secure message protocol closing HIPAA transmission integrity gap.

Phase B: FDA 21 CFR Part 11 Compliance Gaps​

Depends on Phase A vault + crypto primitives.

G05: §11.100(b) Re-Authentication Flow​

Gap Source: 20-regulatory-compliance-matrix.md line 47 (⚠️ Requires Vault)

Current State: Architecture specifies "frontend re-auth prompt; backend validates session + credential" but implementation details are missing. Depends on vault integration (G01) for centralized credential verification.

Task: Specify the complete re-authentication flow for signature events.

Deliverables:

  1. Re-auth trigger points — Every transition requiring e-signature:

    • T3: SCHEDULED→IN_PROGRESS (acknowledgment)
    • T5a: PENDING_REVIEW→APPROVED (approval)
    • T5b: PENDING_REVIEW→REJECTED (rejection)
    • TC: Cancel (when from IN_PROGRESS or later)
    • Define configurable re-auth window: default 5 minutes (if user authenticated within window, skip re-auth prompt but still log)

  2. Re-auth flow specification:

    User clicks "Approve" →
      Frontend checks: lastAuthTime within re-auth window? →
        YES → proceed with signature (log: re-auth skipped, within window)
        NO → modal overlay: "Re-enter credentials to sign"
          → User enters password (or MFA code if MFA enabled)
          → Frontend sends to /api/auth/reauth with session token
          → Backend validates against IdP/vault
          → Success → issue re-auth attestation token (JWT, 5-min TTL)
            → Embed attestation in ElectronicSignature record
          → Failure → log failed attempt → increment lockout counter
            → 3 failures → lock account → alert admin

  3. Prisma additions:

    model ReAuthAttestation {
      id              String   @id @default(cuid())
      userId          String
      method          String   // 'password' | 'mfa_totp' | 'mfa_push' | 'biometric'
      attestedAt      DateTime @default(now())
      expiresAt       DateTime // attestedAt + window
      usedBySignature String?  // Link to ElectronicSignature.id
      ipAddress       String
      userAgent       String
      user            User     @relation(fields: [userId], references: [id])
    }

  4. ElectronicSignature linkage:

    • Add reAuthAttestationId to ElectronicSignature (required for all e-sig transitions)
    • Attestation must be: unexpired, unused (one attestation per signature), same user, same session

  5. MFA support matrix:

    • Password only (minimum)
    • TOTP authenticator app (recommended)
    • Push notification via IdP (Okta/Azure AD)
    • Biometric (WebAuthn/FIDO2) — future, flag as extension point

Artifacts to Update:

  • 17-e-signature-architecture.md — Add re-auth flow section
  • 19-state-machine-with-guards.md — Add re-auth guard to T3, T5a, T5b
  • 20-regulatory-compliance-matrix.md — Change §11.100(b) from ⚠️ to ✅
  • 16-prisma-data-model.md — Add ReAuthAttestation model

Expected Output: Complete re-auth specification closing §11.100(b).

G06: §11.10(i) Personnel Training Integration​

Gap Source: 40-comprehensive-compliance-dashboard.jsx "Personnel Training" status "partial" (auto: 70%)

Current State: Experience entity tracks qualifications and ratings. JobPlan requires minimum competency. But there's no training record model, no training-to-WO validation, no expiration enforcement, and no training completion workflow.

Task: Design the training records integration.

Deliverables:

  1. Training data model:

    model TrainingRecord {
      id              String    @id @default(cuid())
      personId        String
      courseId         String
      courseName      String
      category        TrainingCategory  // SOP, SYSTEM, REGULATORY, SAFETY, TOOL
      completedAt     DateTime
      expiresAt       DateTime?         // null = never expires
      score           Float?            // Pass/fail threshold per course
      passed          Boolean
      certificateRef  String?           // External certificate ID
      verifiedBy      String?           // Person.id who verified
      verifiedAt      DateTime?
      tenantId        String
      person          Person   @relation(fields: [personId], references: [id])
      tenant          Tenant   @relation(fields: [tenantId], references: [id])

      @@index([personId, category])
      @@index([expiresAt])
    }

    enum TrainingCategory {
      SOP           // Standard Operating Procedure
      SYSTEM        // System-specific (e.g., HPLC operation)
      REGULATORY    // GMP, FDA, HIPAA awareness
      SAFETY        // Lab safety, biosafety
      TOOL          // Software tool training
    }

    model TrainingRequirement {
      id              String   @id @default(cuid())
      jobPlanId       String
      courseId         String
      courseName      String
      category        TrainingCategory
      mandatory       Boolean  @default(true)
      minimumScore    Float?
      jobPlan         JobPlan  @relation(fields: [jobPlanId], references: [id])
    }

  2. Guard integration:

    • T2 (PLANNED→SCHEDULED): Verify assignee has all TrainingRequirement records for linked JobPlan
    • If any training expired or missing → block transition with TRAINING_GAP error
    • Experience Matching agent checks training status during staffing proposals

  3. Training gap report:

    • Agent-generated report: for a given WO, list all required training × all candidate assignees → gap matrix
    • Feeds into scheduling decisions

  4. Compliance mapping:

    • §11.10(i): training records prove education/training/experience
    • Audit trail: training verification logged as guard evaluation event

Artifacts to Update:

  • 16-prisma-data-model.md — Add TrainingRecord + TrainingRequirement
  • 19-state-machine-with-guards.md — Add training guard to T2
  • 24-agent-orchestration-mapping.md — Experience Matcher checks training
  • 25-agent-orchestration-spec.md — Add training data to StaffingRequest/Proposal
  • 40-comprehensive-compliance-dashboard.jsx — Update §11.10(i) to "ready"

G07: §11.10(j) Written Policies & Accountability Mapping​

Gap Source: 40-comprehensive-compliance-dashboard.jsx "Written Policies" status "partial" (auto: 60%)

Current State: Tenant-configurable compliance policies mentioned in architecture but no policy template model, no accountability chain definition, no signature meaning enforcement beyond APPROVED/REJECTED.

Task: Design the policy template and accountability system.

Deliverables:

  1. Policy template model:

    model CompliancePolicy {
      id              String   @id @default(cuid())
      tenantId        String
      policyType      PolicyType
      title           String
      version         String
      content         String   // Markdown/HTML policy text
      effectiveDate   DateTime
      expiresAt       DateTime?
      approvedBy      String   // Person.id
      approvedAt      DateTime
      signatureId     String   // ElectronicSignature.id for policy approval
      active          Boolean  @default(true)
      tenant          Tenant   @relation(fields: [tenantId], references: [id])
    }

    enum PolicyType {
      ESIGNATURE_ACCOUNTABILITY  // Who can sign what, consequences of misuse
      CHANGE_CONTROL             // WO lifecycle rules per system category
      ACCESS_MANAGEMENT          // Role assignment, SOD enforcement
      INCIDENT_RESPONSE          // Security event handling
      DATA_CLASSIFICATION        // PHI, confidential, internal, public
      VENDOR_MANAGEMENT          // External vendor WO requirements
    }

  2. Accountability chain:

    • Each ElectronicSignature.meaning maps to a responsibility statement from the active ESIGNATURE_ACCOUNTABILITY policy
    • Signer must acknowledge accountability statement before signing (captured in signature record)
    • Annual re-acknowledgment required (tracked per person)

  3. Policy enforcement in guards:

    • Before any e-signature, verify: active policy exists for tenant + relevant type, signer has acknowledged current version
    • Missing policy → block transition → "POLICY_REQUIRED: No active e-signature accountability policy for this tenant"

  4. Seed data: Default policy templates for each PolicyType covering FDA, HIPAA, SOC 2 requirements.

Artifacts to Update:

  • 16-prisma-data-model.md — Add CompliancePolicy model
  • 17-e-signature-architecture.md — Add accountability linkage
  • 22-rbac-sod-rules.md — Add policy enforcement to role definitions
  • 40-comprehensive-compliance-dashboard.jsx — Update §11.10(j) to "ready"

G08: FDA Compliance Completeness Verification​

Gap Source: Cross-cutting — verify all FDA gaps are closed after G01–G07.

Task: Audit and verify FDA 21 CFR Part 11 compliance completeness.

Deliverables:

  1. Compliance verification matrix — For every §11 sub-section:

    • Requirement text
    • Implementation reference (code, schema, guard, agent)
    • Test case ID (for future IQ/OQ/PQ)
    • Evidence artifact (which document proves compliance)
    • Status after G01–G07 (must be ✅ Ready or explicitly deferred with rationale)

  2. IQ/OQ/PQ test case stubs — For each §11 requirement:

    • Installation Qualification: "Verify [component] is deployed and configured"
    • Operational Qualification: "Execute [scenario] and verify [expected behavior]"
    • Performance Qualification: "Under [load conditions], verify [performance criteria]"

  3. Remaining gaps identification — If any §11 requirement is still not Ready after G01–G07, document explicitly with:

    • Why it's not closeable in this phase
    • What dependency blocks it
    • Target closure date

Artifacts to Update:

  • 20-regulatory-compliance-matrix.md — Comprehensive update of all FDA rows
  • 01-executive-summary.md — Update risk table
  • 02-executive-summary-updated.md — Update risk table

Phase C: HIPAA Technical Safeguards​

Depends on Phase A for vault + crypto.

G09: PHI Detection Scanner​

Gap Source: 20-regulatory-compliance-matrix.md lines 83–89 (explicit "PHI Detection Gap" section, High severity)

Current State: Three identified PHI leakage vectors: WO detail/summary fields, JobPlan work instructions, TimeEntry records. No automated detection exists.

Task: Design the PHI detection and classification system.

Deliverables:

  1. PHI scanner service:

    interface PHIScanner {
      scan(text: string): PHIScanResult;
      scanFields(entity: Record<string, unknown>, fieldPaths: string[]): PHIFieldScanResult;
      classifyRisk(result: PHIScanResult): PHIRiskLevel;
    }

    interface PHIScanResult {
      containsPHI: boolean;
      identifiers: PHIIdentifier[];
      confidence: number;           // 0.0–1.0
      recommendedAction: 'ALLOW' | 'FLAG_FOR_REVIEW' | 'BLOCK' | 'ENCRYPT';
    }

    interface PHIIdentifier {
      type: PHIType;                // MRN, PATIENT_NAME, DOB, SSN, DEVICE_SERIAL, etc.
      value: string;                // Redacted in logs
      position: { start: number; end: number };
      confidence: number;
    }

  2. Detection methods:

    • Regex patterns for structured identifiers (MRN formats, SSN, DOB patterns)
    • NER model (local, small) for patient names and medical terms in free text
    • Device serial number cross-reference against asset registry
    • Configurable per tenant: custom PHI patterns for organization-specific identifiers

  3. Integration points:

    • WO creation/update: scan summary, detail, notes fields
    • JobPlan creation/update: scan workInstructions, safetyPrecautions
    • TimeEntry creation: scan notes field
    • Agent message validation: scan all free-text fields in agent messages before transmission

  4. Response actions:

    PHI detected →
      LOW confidence (< 0.5): Log warning, allow through
      MEDIUM confidence (0.5–0.8): Flag for human review, allow through with banner
      HIGH confidence (> 0.8): Block save, require user to confirm "contains PHI"
        → If confirmed: encrypt field at application layer, mark as PHI-containing
        → If denied: allow through, log user attestation

  5. Prisma additions:

    model PHIScanRecord {
      id            String   @id @default(cuid())
      entityType    String   // 'WorkOrder' | 'JobPlan' | 'TimeEntry'
      entityId      String
      fieldPath     String   // e.g., 'summary', 'workInstructions'
      containsPHI   Boolean
      identifiers   Json     // Redacted identifier list
      confidence    Float
      action        String   // 'ALLOWED' | 'FLAGGED' | 'BLOCKED' | 'ENCRYPTED'
      reviewedBy    String?
      reviewedAt    DateTime?
      scanVersion   String   // Scanner version for reproducibility
      createdAt     DateTime @default(now())
      tenantId      String
    }

Artifacts to Update:

  • 16-prisma-data-model.md — Add PHIScanRecord
  • 20-regulatory-compliance-matrix.md — Close PHI Detection Gap section
  • 25-agent-orchestration-spec.md — Add PHI scanning to agent message validation
  • 13-tdd.md — Add PHI scanner to Security Integration section

G10: HIPAA Break-Glass Emergency Access​

Gap Source: 20-regulatory-compliance-matrix.md line 59 (⚠️ Design Only)

Current State: §164.312(a)(2)(ii) requires emergency access procedure. Architecture says "admin override with enhanced audit logging" but no design exists.

Task: Design the break-glass access mechanism.

Deliverables:

  1. Break-glass flow:

    Emergency declared → Admin activates break-glass for specific WO/system
    → All RBAC restrictions suspended for designated responder
    → Every action logged with BREAK_GLASS flag in audit trail
    → Time-limited: 4-hour window (configurable), auto-expires
    → Post-incident: mandatory review of all break-glass actions
    → Compliance report generated automatically

  2. Break-glass model:

    model BreakGlassSession {
      id              String    @id @default(cuid())
      activatedBy     String    // Admin Person.id
      activatedFor    String    // Responder Person.id
      reason          String    // Minimum 100 chars
      scope           String    // 'TENANT' | 'SYSTEM' | 'WORK_ORDER'
      scopeEntityId   String?   // Specific WO ID or system ID
      activatedAt     DateTime  @default(now())
      expiresAt       DateTime  // activatedAt + window
      deactivatedAt   DateTime?
      deactivatedBy   String?
      reviewedAt      DateTime?
      reviewedBy      String?
      reviewNotes     String?
      tenantId        String
    }

  3. Guard bypass mechanism:

    • Active BreakGlassSession for current user → bypass RBAC guards (not SOD guards — SOD is never bypassed)
    • All transition guards still evaluate but log "BREAK_GLASS_OVERRIDE" instead of blocking
    • Exception: approval signatures still require the designated signer — break-glass grants access to data, not to approve on behalf of others

  4. Post-incident review:

    • Auto-generated report of all actions during break-glass session
    • Mandatory review by a different admin (SOD on break-glass review)
    • Review must be completed within 72 hours

Artifacts to Update:

  • 16-prisma-data-model.md — Add BreakGlassSession
  • 20-regulatory-compliance-matrix.md — Change §164.312(a)(2)(ii) from ⚠️ Design Only to ✅ Ready
  • 22-rbac-sod-rules.md — Add break-glass override rules and SOD protections

G11: Session Management & Automatic Logoff​

Gap Source: 20-regulatory-compliance-matrix.md line 60 (⚠️ Frontend)

Current State: Architecture mentions "session timeout configurable per tenant; signature window timeout" but no specification exists for idle timeout, session persistence, or multi-device management.

Task: Specify the complete session management system.

Deliverables:

  1. Session lifecycle:

    • Login → active session (JWT + refresh token)
    • Idle timeout: configurable per tenant (default 30 min, range 5–120 min)
    • Absolute timeout: 12 hours regardless of activity
    • Signature window: 5 minutes after re-auth (from G05)
    • Grace period: 2-minute warning before idle logoff (frontend toast)

  2. Session Prisma model enhancements:

    • lastActivityAt — updated on every API call
    • deviceFingerprint — browser/device identification
    • maxConcurrentSessions — per tenant config (default 3)
    • On new login exceeding limit → terminate oldest session

  3. Frontend requirements:

    • Idle detection: mouse, keyboard, scroll events reset timer
    • Background tab: check via visibilitychange API
    • Auto-save: persist unsaved form data before logoff
    • Post-logoff redirect: clear state, show "session expired" with re-login link

  4. Compliance mapping: §164.312(a)(2)(iii) automatic logoff satisfied by configurable idle + absolute timeouts with audit logging.

Artifacts to Update:

  • 16-prisma-data-model.md — Session model enhancements
  • 13-tdd.md — Add session management section
  • 20-regulatory-compliance-matrix.md — Change §164.312(a)(2)(iii) from ⚠️ to ✅

G12: HIPAA Compliance Completeness Verification​

Gap Source: Cross-cutting — verify all HIPAA gaps closed after G09–G11 + Phase A.

Task: Same pattern as G08 but for HIPAA. Audit all §164.3xx requirements, verify status, generate IQ/OQ/PQ stubs. Update 20-regulatory-compliance-matrix.md HIPAA section to 100% Ready.

Phase D: SOC 2 Compliance Gaps​

G13: SIEM Integration & Security Event Streaming​

Gap Source: 20-regulatory-compliance-matrix.md line 110 (⚠️ Partial, CC7.3)

Current State: Audit events exist. OTEL tracing exists. But no streaming to external SIEM. No anomaly detection on transition patterns.

Task: Design the SIEM integration and anomaly detection system.

Deliverables:

  1. Event streaming architecture:

    • AuditTrail events → Event Bus (NATS) → SIEM Connector → external SIEM (Splunk/Sentinel/Chronicle)
    • Real-time streaming, not batch
    • Event normalization to CEF (Common Event Format) or OCSF
    • Configurable per tenant: which event types to stream

  2. Anomaly detection rules (built-in, before SIEM):

    • Unusual transition velocity (>10 WOs approved in 1 hour by same person)
    • Off-hours approval activity
    • Failed signature attempts exceeding threshold
    • Agent circuit breaker state changes
    • Token budget exhaustion patterns

  3. Alert integration: Anomaly → alert channel (Slack/PagerDuty/email) + auto-generated investigation WO.

Artifacts to Update:

  • 12-sdd.md — Add SIEM integration to observability section
  • 13-tdd.md — Add SIEM connector specification
  • 20-regulatory-compliance-matrix.md — Change CC7.3 from ⚠️ to ✅

G14: Incident Response WO Generation​

Gap Source: 20-regulatory-compliance-matrix.md line 111 (⚠️ Design Only, CC7.4)

Current State: Architecture mentions "WO system can generate incident WOs from security events" — concept only, no design.

Task: Design the security incident → WO pipeline.

Deliverables:

  1. Incident WO template:

    • Auto-created with: incident type, detection source, affected entities, severity, initial triage notes
    • Pre-populated JobPlan based on incident type (security breach, data integrity violation, access anomaly)
    • Auto-assigned to Security Team or SOC role
    • Regulatory flag auto-set if incident involves PHI or validated system

  2. Trigger sources:

    • Anomaly detection (from G13)
    • Circuit breaker state change (OPEN)
    • Integrity violation (hash chain break from G03)
    • Break-glass activation (from G10)
    • Manual security report

  3. Integration with existing WO lifecycle: Incident WOs follow the same 9-state FSM but with: emergency priority (auto-bypass scheduling queue), mandatory QA review for closure, post-incident documentation requirement.

Artifacts to Update:

  • 18-state-machine-spec.md — Add incident WO type/priority handling
  • 20-regulatory-compliance-matrix.md — Change CC7.4 from ⚠️ Design Only to ✅
  • 24-agent-orchestration-mapping.md — Add incident response agent role

G15: Access Deprovisioning on Termination/Role Change​

Gap Source: 40-comprehensive-compliance-dashboard.jsx CC6.3 "Access Removal" status "partial" (auto: 75%)

Current State: Person entity has status field. But no automatic WO reassignment on deactivation, no orphaned access detection, no deprovisioning workflow.

Task: Design the access lifecycle management system.

Deliverables:

  1. Deprovisioning trigger: Person.status changed to INACTIVE/TERMINATED →

    • All active sessions terminated immediately
    • All assigned WOs in non-terminal states → reassignment queue
    • All future scheduled WOs → reassignment queue
    • Role memberships → audit logged + suspended (not deleted, for forensics)

  2. Reassignment workflow:

    • Experience Matching agent proposes replacement assignees
    • Orchestrator creates reassignment WOs (one per affected WO)
    • Assigner role approves reassignment
    • Original person's audit trail preserved (never deleted)

  3. Orphaned access scanner: Nightly job checks for:

    • Active sessions for inactive persons
    • Role memberships for inactive persons
    • WO assignments to inactive persons
    • Generates compliance report

Artifacts to Update:

  • 16-prisma-data-model.md — Add deprovisioning fields and constraints
  • 22-rbac-sod-rules.md — Add deprovisioning rules
  • 24-agent-orchestration-mapping.md — Add reassignment to Experience Matcher
  • 40-comprehensive-compliance-dashboard.jsx — Update CC6.3 to "ready"

G16: Risk Assessment & CAPA Workflow​

Gap Source: 40-comprehensive-compliance-dashboard.jsx CC9.1 "Risk Mitigation" status "partial" (auto: 70%)

Current State: Priority field and regulatory flag exist. But no formal risk assessment template, no CAPA (Corrective and Preventive Action) tracking, no risk-based approval escalation.

Task: Design the risk assessment and CAPA integration.

Deliverables:

  1. Risk assessment model:

    model RiskAssessment {
      id              String    @id @default(cuid())
      workOrderId     String
      assessedBy      String
      assessedAt      DateTime  @default(now())
      likelihood      Int       // 1-5
      impact          Int       // 1-5
      riskScore       Int       // likelihood × impact
      category        RiskCategory  // SAFETY, COMPLIANCE, OPERATIONAL, DATA_INTEGRITY
      mitigationPlan  String
      residualRisk    Int?      // After mitigation
      signatureId     String?   // E-sig for high-risk assessments
      workOrder       WorkOrder @relation(fields: [workOrderId], references: [id])
    }

  2. Risk-based approval escalation:

    • Risk score ≤ 6: Standard approval (SO only)
    • Risk score 7–15: Enhanced approval (SO + QA)
    • Risk score 16–25: Executive approval (SO + QA + designated executive)

  3. CAPA tracking model: Linked to WO, with root cause analysis, corrective actions, preventive actions, effectiveness verification, closure criteria.

  4. Guard integration: T4 (IN_PROGRESS→PENDING_REVIEW): verify risk assessment exists if WO.regulatory = true.

Artifacts to Update:

  • 16-prisma-data-model.md — Add RiskAssessment, CAPARecord models
  • 19-state-machine-with-guards.md — Add risk assessment guard
  • 40-comprehensive-compliance-dashboard.jsx — Update CC9.1 to "ready"

Phase E: Operational Resilience​

Independent of compliance phases — can run in parallel.

G17: Optimistic Locking Enforcement​

Gap Source: 27-coditect-impact.md line 146 (High: "Already in schema but not enforced at application layer")

Current State: Prisma schema has version field on WorkOrder. But no application-layer enforcement — concurrent edits can silently overwrite each other.

Task: Implement optimistic locking at the application layer.

Deliverables:

  1. Locking mechanism:

    // Every WO update must include current version
    async function updateWorkOrder(
      woId: string,
      updates: Partial<WorkOrder>,
      expectedVersion: number,
      actorId: string
    ): Promise<WorkOrder> {
      const result = await prisma.workOrder.updateMany({
        where: { id: woId, version: expectedVersion },
        data: { ...updates, version: { increment: 1 } }
      });
      if (result.count === 0) {
        throw new OptimisticLockError(woId, expectedVersion);
      }
      return prisma.workOrder.findUniqueOrThrow({ where: { id: woId } });
    }

  2. Conflict resolution strategy:

    • API returns 409 Conflict with current version + diff of conflicting fields
    • Frontend shows conflict resolution UI: "Another user modified this WO. Review changes and retry."
    • Agent workers: auto-retry with exponential backoff (max 3 retries), then escalate to orchestrator

  3. Version field enforcement:

    • Database trigger: reject any UPDATE to WorkOrder that doesn't increment version
    • API middleware: require If-Match: version header on all WO mutations
    • Audit trail: log version on every entry for forensic reconstruction

Artifacts to Update:

  • 13-tdd.md — Add optimistic locking to API specification
  • 16-prisma-data-model.md — Document version enforcement
  • 25-agent-orchestration-spec.md — Add retry logic for lock conflicts
  • 27-coditect-impact.md — Change from High gap to Resolved

G18: Dependency DAG Cycle Detection​

Gap Source: 27-coditect-impact.md line 147 (High: "Need DAG validation on dependency creation")

Current State: WOs can depend on other WOs. No cycle detection — manual dependency creation can create deadlocks (A depends on B, B depends on A).

Task: Implement DAG validation for WO dependency graphs.

Deliverables:

  1. Cycle detection algorithm:

    • On every dependency creation/modification: run topological sort (Kahn's algorithm)
    • If cycle detected → reject dependency creation with clear error: "Adding dependency WO-123 → WO-456 would create cycle: WO-456 → WO-789 → WO-123"
    • Visualization: return cycle path for frontend display

  2. Database constraint:

    • PostgreSQL trigger function implementing DFS cycle detection
    • Runs on INSERT/UPDATE to WorkOrderDependency table
    • Rejects with custom error code for application-layer handling

  3. Cascade impact analysis:

    • getImpactGraph(woId): { directDependents: WO[], transitiveDependents: WO[], criticalPath: WO[] }
    • Before any WO state change: evaluate impact on dependents
    • If blocking a critical path → warn user before proceeding

  4. Agent integration: Scheduler agent runs DAG analysis before proposing schedules. Orchestrator checks DAG before dispatching parallel work.

Artifacts to Update:

  • 12-sdd.md — Add DAG validation to data flow section
  • 13-tdd.md — Add dependency API specification
  • 16-prisma-data-model.md — Add database trigger spec
  • 19-state-machine-with-guards.md — Reference DAG validation in dependency-related guards
  • 27-coditect-impact.md — Change from High gap to Resolved

G19: Partial Master WO Completion Policies​

Gap Source: 01-executive-summary.md line 56 (Medium), 02-executive-summary-updated.md line 111, 27-coditect-impact.md line 151, 32-tech-architecture-analyzer.jsx GAP_ANALYSIS (yellow)

Current State: Master WOs require all children to be terminal before completing. But what happens when one child WO is blocked indefinitely? No policy exists.

Task: Design configurable partial completion policies.

Deliverables:

  1. Policy model:

    model MasterWOCompletionPolicy {
      id              String   @id @default(cuid())
      tenantId        String
      systemCategory  String   // e.g., 'HPLC', 'LIMS', 'MES'
      policyType      PartialCompletionType
      thresholdPct    Float?   // For PERCENTAGE type
      maxBlockedDays  Int?     // For TIME_BASED type
      requiresQAApproval Boolean @default(true)
      requiresRiskAssessment Boolean @default(true)
      tenant          Tenant   @relation(fields: [tenantId], references: [id])
    }

    enum PartialCompletionType {
      ALL_REQUIRED        // Default: all children must be terminal
      PERCENTAGE          // X% of children complete + risk assessment
      CRITICAL_ONLY       // Only critical-path children required
      TIME_BASED          // After N days blocked, allow completion with justification
      EXCEPTION_APPROVAL  // Case-by-case executive approval
    }

  2. Completion guard modification:

    • T6 (APPROVED→COMPLETED) for Master WOs: evaluate against tenant's completion policy
    • If policy allows partial: require additional e-signature + risk assessment (from G16)
    • Blocked children → auto-generate "scope reduction" ChangeItem documenting exclusion

  3. Domain-specific defaults:

    • Pharma/Biotech: ALL_REQUIRED (strictest)
    • MedDev: CRITICAL_ONLY with QA approval
    • Fintech: PERCENTAGE (80%) with risk assessment

Artifacts to Update:

  • 16-prisma-data-model.md — Add MasterWOCompletionPolicy
  • 19-state-machine-with-guards.md — Modify T6 guard for Master WOs
  • 01-executive-summary.md — Change from risk to resolved
  • 27-coditect-impact.md — Change from Medium gap to Resolved
  • 32-tech-architecture-analyzer.jsx — Update GAP_ANALYSIS status to green

G20: Vendor WO Timeout & Escalation Policies​

Gap Source: 27-coditect-impact.md line 150 (Medium), 32-tech-architecture-analyzer.jsx GAP_ANALYSIS (yellow)

Current State: Vendor actions are async. No timeout. No escalation. Stalled vendor WOs block Master WO completion.

Task: Design vendor timeout and escalation policies.

Deliverables:

  1. Timeout policy model:

    model VendorTimeoutPolicy {
      id                String   @id @default(cuid())
      tenantId          String
      vendorId          String?  // null = default for all vendors
      stateTimeouts     Json     // { "IN_PROGRESS": 72, "PENDING_REVIEW": 48 } hours
      escalationChain   Json     // ["ASSIGNER", "SYSTEM_OWNER", "QA"]
      autoRemind        Boolean  @default(true)
      remindIntervalH   Int      @default(24)
      autoCancelAfterH  Int?     // null = never auto-cancel
    }

  2. Timeout monitoring agent:

    • Scheduler agent checks vendor WOs against timeout policy every hour
    • On timeout: send reminder → escalate to next in chain → auto-cancel (if configured)
    • Each escalation step generates audit trail entry

  3. Escalation flow: Vendor WO stalled > timeout → Notify vendor → Wait remindInterval → Notify ASSIGNER → Wait → Notify SO → Wait → Auto-cancel or executive review.

Artifacts to Update:

  • 16-prisma-data-model.md — Add VendorTimeoutPolicy
  • 24-agent-orchestration-mapping.md — Add timeout monitoring to Scheduler
  • 25-agent-orchestration-spec.md — Add escalation message contracts
  • 27-coditect-impact.md — Change from Medium gap to Resolved
  • 32-tech-architecture-analyzer.jsx — Update GAP_ANALYSIS status

Phase F: Agent & Vendor Coordination​

G21: Vendor Coordination Portal Specification​

Gap Source: 11-product-roadmap.md lines 60, 76 (⚠️ Partial)

Task: Design the vendor-facing portal: scoped views (vendor sees only their assigned WOs), limited actions (update execution, submit time entries, upload evidence), secure file upload for IQ/OQ documents, notification system for assignment/reminders/escalation. Define API surface, RBAC scoping rules, and frontend spec.

Artifacts to Update: 11-product-roadmap.md, 13-tdd.md, 22-rbac-sod-rules.md

G22: Vendor IQ/OQ/PQ Document Upload & Validation​

Gap Source: 11-product-roadmap.md line 76 (⚠️ Partial)

Task: Design the validation document management system: upload interface for IQ/OQ/PQ documents, template enforcement (required sections, required signatures), version tracking, link to specific WO and JobPlan, compliance verification agent that validates completeness against §11 requirements.

Artifacts to Update: 11-product-roadmap.md, 16-prisma-data-model.md, 17-e-signature-architecture.md, 24-agent-orchestration-mapping.md

G23: Experience & Certification Expiration Checks​

Gap Source: 27-coditect-impact.md line 152 (Low: "Certifications expire. Need automated expiration checks")

Task: Design the automated expiration monitoring system: nightly scan of all Experience and TrainingRecord entries approaching expiration (30/14/7 day warnings), auto-block WO assignment if expired certification is required, renewal workflow (notification → training → re-certification → WO eligibility restored), integration with Experience Matcher agent.

Artifacts to Update: 16-prisma-data-model.md, 24-agent-orchestration-mapping.md, 25-agent-orchestration-spec.md, 27-coditect-impact.md

Phase G: Scaling & Optimization​

Lowest priority — address after core gaps closed.

G24: Batch WO Creation & Bulk Lifecycle API​

Gap Source: 27-coditect-impact.md line 149 (Medium), 32-tech-architecture-analyzer.jsx GAP_ANALYSIS (yellow: "batch API not designed")

Task: Design bulk APIs for high-volume tenants (100K+ instruments generating preventive maintenance WOs): batch create endpoint (accepts array of WO creation requests, transactional), bulk state transition endpoint (advance multiple WOs in single call with shared guard evaluation), batch scheduling (Scheduler agent optimizes across batch rather than individually), performance targets: 1000 WOs/second create, 500 WOs/second transition.

Artifacts to Update: 13-tdd.md, 24-agent-orchestration-mapping.md, 27-coditect-impact.md, 32-tech-architecture-analyzer.jsx

G25: Schedule Constraint Solver​

Gap Source: 32-tech-architecture-analyzer.jsx GAP_ANALYSIS (red: "No constraint solver — deterministic matching only")

Task: Design a constraint-based scheduling engine: define constraint types (resource availability, maintenance windows, dependency ordering, skill requirements, regulatory hold periods), evaluate solver options (OR-Tools, OptaPlanner via GraalVM, custom greedy + backtracking), integration with Scheduler agent as optional optimization pass (deterministic matching remains the fallback), compliance: solver decisions must be explainable for audit (why this assignee, why this date).

Artifacts to Update: 12-sdd.md, 13-tdd.md, 24-agent-orchestration-mapping.md, 32-tech-architecture-analyzer.jsx

G26: Resource Optimization Learning Loop​

Gap Source: 32-tech-architecture-analyzer.jsx GAP_ANALYSIS (red: "Deferred to V2 — explainability concerns")

Task: Design a V2 resource optimization system that satisfies regulated-industry explainability requirements: historical WO duration analysis (actual vs. estimated, by system category, complexity, assignee), recommendation engine (not ML black-box — rule-based with statistical confidence intervals), explainable output: "Estimated 4.2 hours based on 23 similar WOs for HPLC maintenance by Level 3+ technicians (95% CI: 3.1–5.8h)", feedback loop: actual durations feed back into estimates with exponential decay weighting.

Artifacts to Update: 12-sdd.md, 27-coditect-impact.md, 32-tech-architecture-analyzer.jsx

Phase H: Cross-Cutting Artifact Updates​

Runs last — updates all artifacts to reflect gap closures and syncs dashboard data.

G27: Artifact Gap Status Updates​

Gap Source: All artifacts with ⚠️ or ❌ markers.

Task: After executing G01–G26, systematically update every artifact:

  1. 20-regulatory-compliance-matrix.md — Update the summary table:

    BEFORE: FDA: 14 Ready, 4 Partial → AFTER: FDA: 18 Ready, 0 Partial
    BEFORE: HIPAA: 8 Ready, 4 Partial → AFTER: HIPAA: 12 Ready, 0 Partial
    BEFORE: SOC 2: 8 Ready, 4 Partial → AFTER: SOC 2: 12 Ready, 0 Partial

  2. 01-executive-summary.md + 02-executive-summary-updated.md — Update risk tables: remove "partial completion policies undefined" and "credential management" from risks, add "resolved" status.

  3. 27-coditect-impact.md — Update Gaps & Risks table: all 7 items should show resolution status.

  4. 11-product-roadmap.md — Update vendor coordination items from ⚠️ Partial to ✅ or specific milestone target.

  5. 29-glossary.md — Add new terms introduced by gap closures:

    • Break-glass access, CAPA, chain of custody, constraint solver, credential vault, DAG validation, deprovisioning, hash chain, IQ/OQ/PQ, message signing, nonce, optimistic locking, PHI scanner, re-authentication attestation, risk score, SIEM, training requirement

  6. For each closed gap, add an ADR to 23-architecture-decision-records.md:

    • ADR-008: Vault integration pattern (G01)
    • ADR-009: Audit trail hash chain design (G03)
    • ADR-010: Break-glass access mechanism (G10)
    • ADR-011: Partial Master WO completion policy (G19)
    • ADR-012: Vendor timeout escalation (G20)
    • ADR-013: PHI detection strategy (G09)
    • ADR-014: Optimistic locking enforcement (G17)

Expected Output: All ⚠️ and ❌ markers either changed to ✅ or explicitly deferred with rationale and target date.

G28: Dashboard Data Synchronization​

Gap Source: Dashboards display gap status that must match updated artifacts.

Task: Update all JSX dashboards to reflect closed gaps:

  1. 32-tech-architecture-analyzer.jsx — Update GAP_ANALYSIS array:

    • "Credential Security" → green, "Vault integration implemented (ADR-008)"
    • "Cycle Detection (DAG)" → green, "Kahn's algorithm in DB trigger + API"
    • "Partial Master WO Completion" → green, "Configurable policy per tenant/domain"
    • "Vendor WO Coordination" → green, "Timeout + escalation policies implemented"
    • "PM Batch Scaling (100K+)" → green or yellow with updated detail
    • "Real-time Schedule Optimization" → yellow with V2 target date
    • "ML-based Resource Optimization" → yellow with V2 target date and explainability design reference

  2. 33-wo-unified-system-dashboard.jsx — Update COMPLIANCE_MAP:

    • "Transmission security" → ready
    • Any other partial items → ready with updated implementation text

  3. 40-comprehensive-compliance-dashboard.jsx — Update all requirements data:

    • "Personnel Training" → ready, auto: 95%
    • "Written Policies" → ready, auto: 90%
    • "Authentication Mechanisms" → ready, auto: 95%
    • "Integrity Controls (Transmission)" → ready, auto: 95%
    • "Access Removal" → ready, auto: 90%
    • "Risk Mitigation" → ready, auto: 90%

  4. Update dashboard summary statistics to reflect new compliance posture:

    • Overall readiness: 93% → 98%+
    • Partial count → 0 or near 0
    • Gap count → 0

  5. Verify all dashboard inter-references are consistent — if one dashboard says "partial" for a requirement, no other dashboard should say "ready" for the same requirement.

Expected Output: All 25 dashboards reflect consistent, updated gap status matching the markdown artifacts.

Execution Summary​

Total Effort Estimate​

PhasePromptsComplexityEstimated Hours
A: Security FoundationG01–G04High8–12
B: FDA ComplianceG05–G08High6–8
C: HIPAA ComplianceG09–G12High6–8
D: SOC 2 ComplianceG13–G16Medium4–6
E: Operational ResilienceG17–G20Medium4–6
F: Agent & VendorG21–G23Medium3–4
G: Scaling & OptimizationG24–G26Low3–4
H: Cross-Cutting UpdatesG27–G28Medium4–6
Total28 prompts38–54 hours

Minimum Viable Gap Closure​

If time-constrained, close these 10 gaps first (covers all Critical + High):

G01 (Vault) → G02 (Hash binding) → G03 (Hash chain) → G09 (PHI scanner)
→ G10 (Break-glass) → G17 (Optimistic locking) → G18 (DAG detection)
→ G13 (SIEM) → G27 (Status updates) → G28 (Dashboard sync)

This moves compliance posture from 93% audit ready → ~97% and closes all Critical/High items.

Validation Criteria​

After all 28 prompts complete:

  • grep -c "⚠️" 20-regulatory-compliance-matrix.md → 0
  • grep -c "status.*partial\|status.*gap" 40-comprehensive-compliance-dashboard.jsx → 0
  • grep "status.*yellow\|status.*red" 32-tech-architecture-analyzer.jsx → 0 or 2 (V2 deferred items only)
  • Every gap in 27-coditect-impact.md Gaps & Risks table → has "Resolved" or "Deferred to V2" status
  • All new models have corresponding Prisma schema in 16-prisma-data-model.md
  • All new guards referenced in 19-state-machine-with-guards.md
  • 29-glossary.md includes all new terms
  • 23-architecture-decision-records.md has 7 new ADRs (008–014)

Last updated: 2026-02-13
Maintained by: AZ1.AI Inc. / CODITECT Platform Team

Copyright 2026 AZ1.AI Inc. All rights reserved. Developer: Hal Casteel, CEO/CTO Product: CODITECT-BIO-QMS | Part of the CODITECT Product Suite Classification: Internal - Confidential