Get started
Break technical evaluation into verifiable steps
Validate format, topology, security, and operational responsibilities independently from product claims.
Evaluation order
Each step should produce an explicit scope and evidence list for the next discussion.
- Inventory package clients and repository modes.
- Map the application, PostgreSQL, storage, identity, and network topology.
- Exercise access, proxy security, policy, and audit scenarios.
- Record backup, recovery, upgrade, and support gaps.
Freeze scope before starting
Record the test environment and acceptance matrix before execution so results remain comparable.
- Organization, project, repository type, format, real client, and client version
- Application image and chart reference, PostgreSQL version, storage type, and network topology
- Test users, roles, access-policy scope, and the secret source to be used
- Expected PASS, WARN, or BLOCK result, client outcome, and audit or task identifiers to collect
Evidence pack
Scenario evidence must not consist only of a screenshot. Combine repeatable input, timestamp, expected and actual results, and relevant system records under one test identity.
- Authorization denial, validation failure, and recoverable-failure results alongside the successful path
- Checksum or digest for the artifact or SBOM and a safe test copy of the source file
- Correlation, task, scan, policy-evaluation, and audit identifiers
- Owner, required evidence, target date, and production impact for every open item
Decision standard
Do not accept a capability only because its happy path works. In-scope clients, authorization boundaries, failure behavior, rollback plan, and operational ownership must be approved together. Any item without evidence remains a gap rather than an acceptance.