Validate deployment and product flows before production

Purpose, scope, and decision authority

This checklist is not a product-qualification statement on its own. It is an evaluation framework that makes visible which flows were exercised for the target release and topology, what evidence was produced, and who made the production decision.

• Scope must include the application image, chart, or source reference; database-migration level; storage type; ingress and TLS model; and identity provider.
• Name the critical user journeys, repository types to be used, and real package clients before testing begins.
• Separate the roles that execute tests, review findings, accept risk, and authorize production in the same record.
• Record every excluded topic with its rationale and production impact; never treat it as implicitly passed.

Evidence-pack preparation

For every check, record the owner, environment, date, input, expected result, and evidence link.

• Freeze in-scope organizations, projects, repositories, formats, clients, and user roles.
• Test packages and SBOMs must not contain production data or secrets.
• Retain correlation, job, and scan identities for both successful and rejected scenarios.
• Redact tokens, cookies, passwords, connection strings, and personal data in screenshots, logs, and exported records.
• Define immutable naming, an access owner, and a retention period for the evidence repository; do not rely only on chat or temporary terminal output.

Environment-readiness gate

Before functional checks begin, verify the identity and dependencies of an environment representative of the target. If the readiness gate does not pass, record later results as conditional rather than production evidence.

• Verify DNS, ingress, the TLS chain, trusted CAs, and time synchronization through both the management interface and package-client path.
• Record PostgreSQL connectivity and migration state together with Local or S3-compatible storage health and usage results.
• Exercise the OIDC, LDAP, or built-in identity path; group and role mappings; and disabled-user behavior against the target configuration.
• Match outbound destinations required by proxy and intelligence flows to the allowlist; record unexpected egress as a failure.
• Capture an empty or known baseline at test start so cache, task, or acceptance records from earlier runs do not affect the result.

Acceptance sequence

1. Run repository creation, Hosted publish, download, restore, and immutable-overwrite rejection.
2. Verify proxy connection, cache, negative cache, Group first-match order, and the anonymous proxy-only boundary.
3. Prove OSV full and incremental tasks, CycloneDX scanning, and PASS, WARN, BLOCK, and NOT_EVALUATED outcomes.
4. Verify risk-acceptance creation, reevaluation, expiry or revocation, and immutable-history behavior.
5. Complete cleanup dry-run, real execution, archive or restore, and storage-transfer checksum controls.
6. Reconcile Audit, Package Usage, Operation, Outbound, and task records with input and output evidence.

Repository and client controls

Exercise every production format and repository type with its real client. Passing one mode for a format does not prove all Hosted, Proxy, and Group behaviors.

• For Hosted, prove authorized publishing, resolution or download, metadata visibility, checksums, and rejection of immutable-version overwrites.
• For Proxy, record first upstream fetch, cache hit, negative-cache duration, upstream outage, and outbound access only to allowed targets as separate results.
• For Group, exercise member order, first-match results, authorization intersection, missing packages, and failure behavior when a member is unavailable.
• If anonymous access is used, verify it remains within the approved proxy-read boundary and does not extend to Hosted publishing or management APIs.
• Attach the client version, endpoint, repository URL, package coordinate, and actual client exit code and output to the evidence.

Security and governance controls

A PASS, WARN, or BLOCK label is not sufficient by itself; reconcile the decision input, scope, user-visible outcome, and immutable history in the same correlation context.

• Run allowed and denied role scenarios at organization, project, and repository scopes with separate users.
• Retain a known CycloneDX input with its checksum and verify that scan, finding, advisory, and policy-evaluation records link to that input.
• Compare PASS, WARN, BLOCK, and, when context is absent, NOT_EVALUATED with client behavior, audit or operation records, and cache or upstream effects.
• For risk acceptance, exercise scope, rationale, reference, actor, and expiry, followed by reevaluation, revocation or expiry, and preservation of history.
• Constrain an API token to the allowed scope and record creation, use, denial, and revocation without writing the token value into any evidence.

Data integrity and recoverability

Do not accept deletion, archive, or storage-change flows only because a task is marked complete. Check metadata, objects, checksums, and recovery behavior together.

• Approve cleanup dry-run candidates before execution and show that out-of-scope artifacts and those protected by retention rules are not candidates.
• After archive and restore, read through the package client and match size and checksum values to the pre-operation baseline.
• For storage transfer, reconcile candidate, processed, failed, and byte counters with source and target inventory, retaining item-level visibility for failures.
• If backup and restore evidence is unpublished, do not treat a filesystem or bucket copy as complete recovery proof; require a common recovery point for PostgreSQL, artifact objects, and raw SBOM data.
• If rollback was not rehearsed, record the impact, manual recovery steps, and decision owner as an explicit evidence gap.

Operations and observability

Every critical scenario needs an operational trace beyond the management screen. The goal is to show not only that the outcome occurred, but that an operations team can observe and explain it.

• Link task-state transitions, retry, lease, or checkpoint information, and item-level failure summaries to the result record.
• Check that actor, time, target, outcome, and correlation fields are consistent across Audit, Package Usage, Operation, and Outbound records.
• Exercise health and readiness signals during dependency failures and document alert thresholds and operational ownership in the organization's monitoring system.
• Sample logs to verify that they do not contain secrets, authorization headers, cookies, SBOM content, or unnecessary personal data.

Finding classification and retest

A failed check must not be deleted or closed only with free text. Link its production impact, reproduction steps, fix reference, and retest result to the original evidence.

• Blocker: data loss or integrity failure, privilege expansion, an unusable critical package flow, or no safe rollback; production cannot proceed.
• High: a gap that is not a blocker but materially affects production safety or operability; it cannot close without explicit risk approval.
• Medium or low: may be considered for conditional acceptance when impact, workaround, owner, and target date are defined.
• Record a retest as a new run of the same test identity, including date, environment differences, and a new evidence link.

Exit criteria

• Every critical flow has happy-path, authorization-denial, validation, and recoverable-failure results.
• Every open item is marked as a gap, not a capability, with an owner, target date, and required evidence.
• Production approval is given only after test scope, rollback decision, and platform owners are signed off.

Evidence-record template

Using the same fields for every test result makes it easier for different teams to rerun evidence and compare releases.

• Test identity, date and time, executor, and approving owner
• Application image, chart, or source reference plus PostgreSQL, storage, and client versions
• Prerequisite, redacted input, repeatable command or action, and expected result
• Actual result, checksum, correlation, task, scan, or audit identity, and evidence link
• For failure, impact, recovery or rollback step, owner, and retest date

Production decision

Summarize results in one closure record; do not present conditional acceptance as full acceptance without evidence.

• Proceed: all critical criteria passed, rollback was rehearsed, and operational owners approved.
• Conditional proceed: only low-impact open items remain, each with a time-bound risk owner and rollback trigger.
• Do not proceed: evidence is missing for data integrity, authorization, recovery, a critical format, or observability.

Post-acceptance record

Retain the approved scope, source snapshot, and topology. Rerun affected checks whenever image or chart, database migrations, storage, ingress, identity provider, client, or policy behavior changes.

Live demo validation — August 1, 2026

The demo session loaded the repository and artifact, intelligence, scan and policy, risk-acceptance, task, audit, package-usage, outbound, storage, proxy, and identity-administration surfaces covered by this checklist in read-only mode. The checklist was not executed end to end under one test identity, and no denial or failure scenarios, checksum chain, recovery or rollback, or signed closure record were produced. The document therefore correctly remains Evaluation guidance.