Skip to main content

Pilot Go-Live Validation Procedures

Purpose: Define final acceptance criteria, execution steps, evidence collection, and rollback plan for the EQMS MVP pilot on a single VM using Docker Compose.

Audience: QA lead, system administrator, and business owner.

Scope: End-to-end validation of critical workflows, environment readiness, non-functional checks, and rollback readiness.

1. Entry Criteria​

  • Pre-deploy checklist completed (docs/operations-checklists/pre-deploy.md)
  • Post-deploy validation completed (docs/operations-checklists/post-deploy-validation.md)
  • Backup/restore drill plan ready (docs/operations-checklists/backup-restore.md)
  • Stakeholders confirm pilot scope, users, and data governance

2. Test Environment Details​

Record below for traceability:

  • Compose file digest: docker/docker-compose.prod.yml (commit SHA)
  • Backend image digest:
  • Frontend image digest:
  • DB version (Postgres):
  • Secrets file: docker/.env.prod (checksum recorded offline)
  • Date/time of deployment:
  • Tester(s) and role(s):

3. Acceptance Criteria (Functional)​

Mark each with Pass/Fail and attach evidence.

3.1 Authentication and RBAC

  • Admin login successful; /auth/me returns expected role
  • Standard user login successful
  • Auditor access read-only; write attempts 403
  • Permission boundary tests (user cannot approve; admin/QA can)

Evidence: Screenshots or API responses; logs (redacted).

3.2 Document Control

  • Upload document (PDF) and verify metadata
  • Download returns exact file (hash or size match)
  • Update document metadata or revision (if allowed by role)
  • Approval flow including e-signature (if implemented) completes
  • Audit trail contains entries for upload/update/approval

Evidence: Upload/download hashes; audit trail entries; screenshots.

3.3 Search

  • Search returns relevant results for known keywords
  • Open result navigates to correct document detail

3.4 Training

  • Admin/QA assigns training to a user
  • User sees and completes training; completion timestamp recorded
  • Dashboard reflects completion

3.5 Deviations and CAPA

  • Create deviation, update fields, change status
  • Create CAPA from deviation
  • Update CAPA actions; close if authorized
  • Audit trail accurately reflects actions

3.6 Electronic Signatures

  • Signature capture recorded and linked to approval event
  • Insufficient permissions correctly rejected

4. Non-Functional Acceptance​

4.1 Availability and Health

  • docker compose ps shows healthy for db/backend/frontend
  • Backend /health returns healthy
  • External uptime monitor (if configured) green for 24h observation window

4.2 Performance (Smoke)

  • With ~5 concurrent users, latency remains acceptable for core tasks
  • No OOMKilled or container restart loops in logs

4.3 Security Sanity

  • BACKEND_CORS_ORIGINS set to correct host(s); browser shows no CORS errors
  • No secrets present in logs (spot check)
  • SECRET_KEY is non-default and stored securely

4.4 Email

  • SendGrid SMTP configured; test email delivered

4.5 Backups

  • Nightly pg_dump scheduled (dry-run verified)
  • Uploads/chroma volumes included in host-level backup plan

5. Evidence Collection​

Attach or link:

  • Screenshots of UI flows
  • API responses (sanitized)
  • Hash comparisons for document download
  • docker compose ps output and service logs excerpts
  • Uptime chart (if available)
  • Backup job output/log snippet

6. Deviations During Validation​

Log any issues discovered, with severity, impact, and resolution or workaround. Must be resolved or accepted by business owner prior to go-live.

IDDescriptionSeverityOwnerStatusResolution

7. Rollback Plan​

Triggers:

  • Healthcheck failures persisting beyond 15 minutes
  • Authentication or critical workflow failure without workaround
  • Data corruption indicators
  • Stakeholder decision due to high-severity issues

Rollback Steps:

  1. Compose down current stack:
    • docker compose -f docker/docker-compose.prod.yml down
  2. Restore previous known-good images:
    • Use recorded image digests or tags; docker pull and pin in compose if needed
  3. Restore data if required:
    • DB: psql restore from last good dump
    • Volumes: restore uploads/chroma from backup snapshot
  4. Compose up known-good stack:
    • docker compose -f docker/docker-compose.prod.yml up -d
  5. Validate minimal health and login
  6. Record incident details and notify stakeholders

8. Exit Criteria and Sign-Off​

  • All functional acceptance items passed
  • Non-functional checks meet baseline
  • Backups and rollback plan verified
  • Open issues documented with agreed risk acceptance
  • Business owner sign-off

Sign-Off:

  • QA Lead:
  • System Admin:
  • Business Owner:
  • Date:

9. Post-Go-Live Monitoring Window​

  • Duration: 24–72 hours
  • Actions:
    • Monitor /health and application logs
    • Verify scheduled backups executed
    • Collect user feedback
  • Exit: Close pilot validation and proceed to routine operations or iterate on fixes/enhancements