On-Premises Edition Acceptance Validation Guide

About this guide

The on-premises album database ships with acceptance-validation documents. This guide explains, for quality assurance / CSV (Computerized System Validation) staff, how to use them.

The bundled validation documents

The distribution archive contains the following three documents. All are fill-in checklists that can be retained as-is as execution records.

Document	Role
`IQ.md` (Installation Qualification)	Evidence that “the right software was installed in the right environment, per procedure”. 7 sections (prerequisites / distribution integrity / site configuration / first boot / network exposure / backup wiring / sign-off)
`OQ.md` (Operational Qualification)	Evidence that “the installed system behaves per specification”. 7 sections (login / navigation reachability / licence state machine / administrator management / backups / audit trail / update readiness)
`RELEASE_NOTES.md`	Version identification — version, archive and container-image hashes (the reference values for integrity checks), change history, and the re-test scope for updates

The overall flow

flowchart TD
    A[Receive the distribution] --> B[Check version and hashes in RELEASE_NOTES]
    B --> C[Install per the Setup Guide]
    C --> D[Run IQ - all items PASS]
    D --> E[IQ sign-off]
    E --> F[Run OQ - all items PASS]
    F --> G[OQ sign-off]
    G --> H[Start production use]

Order matters: do not start OQ until IQ is complete and signed off. OQ is designed on the assumption of a correctly installed system.

Running the IQ

Fill in the header: version (copied from RELEASE_NOTES), site, installer, date
Each row’s “Command / observation” cell contains the exact command to run. Run it, record the output in “Actual result”, and mark PASS with initials when it matches the expected result
Attach evidence of the output (redirected console logs, screenshots, etc.)
If even one item FAILs, do not proceed to OQ — resolve the cause and re-execute the item

Items of particular importance:

§2 Distribution integrity: the archive’s SHA-256 and the loaded image digests must match the values in RELEASE_NOTES. This proves the installation is identical to what the vendor tested
§6.3 Safeguarding the encryption key: off-server storage of encryption.key is confirmed by the operator’s signature

Running the OQ

The OQ verifies specified behaviour by operating the actual screens. It includes creating and deleting a temporary test administrator (oq-tester).

Execute the tests in the documented order (later tests consume the results of earlier ones — e.g. the §1 actions become the test subjects of the §6 audit-trail check)
The licence state-machine tests (§3) temporarily rewrite dates in the database to simulate expiry. Always restore via §3.5 afterwards
Where a test says “note the timestamp”, record it — it is cross-checked against the audit log in §6

Handling deviations

When a result does not match the expectation:

Record the event, cause and resolution in the “Notes / deviations” field at the end
If resolved by a configuration change or re-installation, re-execute the affected items and record PASS
If you judge it to be an error in the document itself, contact Power Office. We will provide a corrected version and our assessment of whether the correction affects test results

Re-validation on updates

You do not repeat the full IQ/OQ for every upgrade. Each version’s RELEASE_NOTES states the “OQ retest scope” (the OQ sections to re-execute for that version). As a baseline, the login flow (§1) and navigation reachability (§2) are always re-executed. On the installation side, the update procedure itself includes IQ-equivalent integrity verification (SHA-256 / digest comparison).

Retaining the records

Keep the completed IQ/OQ and attached evidence per your document-control procedures (system lifetime plus the retention your regulations require)
The audit log is kept indefinitely inside the system (there is no delete function). It is included in the regular backups, so retaining dumps also retains the audit trail

About vendor-side quality assurance (for audits)

Information available for customer audits:

The product is built from the same core library as the hosting edition and quality-controlled as a single code base
Before shipping, the vendor performs a full IQ/OQ rehearsal on a clean environment
Power Viewer itself (the client application) also has a documented pre-release system test plan and specification. The same checklist is executed in full for every release regardless of version, and it includes verifying connectivity to the on-premises server
Distribution integrity is verifiable via SHA-256 checksums (whole archive, individual files, and container images)

For disclosure of specific quality records, please contact Power Office.