Release readiness

A release review answers whether one version of your product is ready for its intended users. Start with what should work, define how to check it, record what happened, then let an owner make the release decision. You can do this without AI, screenshots, or an architecture map.

Explore the example release review without creating sample data in your workspace.

Start with what should work

Open a board to enter its product Overview. Use Screens to inspect its images and annotations.

Use Features to describe user outcomes. Release reviews holds candidate reviews.

A feature can have no UI, such as processing a webhook. The API and technical records use capabilities for features and assessments for release reviews.

Add a feature with a name, observable outcome, and accountable owner. For example, Export an invoice could mean that an authorized finance user can download a valid PDF. The outcome gives a reviewer something concrete to check.

The overview starts with the latest candidate, its calculated readiness, validation environment, release target, and separate owner decision. Expand an unresolved item to see what is missing or failed. Open that release review to act on it. Up to three existing screen previews follow the review summary. Choose a preview to open its editor, or View all screens for the gallery.

The feature list includes outcomes outside the latest review and identifies newer definitions. Expand a row for its outcome and scope reason. Its check status covers that feature's own checks for the candidate. Supporting component and screen counts describe declared mappings. They do not prove working behavior.

Architecture is optional supporting context. From a feature, link systems that implement it or existing screen regions that illustrate it. The form keeps this feature selected. Reuse components from the workspace when appropriate. You can also maintain components and dependency relationships together in Architecture. A declared dependency does not create a release requirement or prove that StateBoard observed runtime traffic.

The product Screens gallery works without a release review. Add or reuse an image, then select it to draw regions and link existing features. Screens and their mappings belong to the product. Release views show that shared context with the selected review's feature scope. In the editor, the Screens breadcrumb returns to the gallery. Back to release review restores the review and feature you came from.

Start a release review

Choose New release review after adding features. Give the candidate a readable name and a pinned reference, such as a commit SHA, image digest, or immutable version manifest. This identifies exactly what the results cover. Avoid mutable branches and latest tags.

Set the validation environment, where checks run, and the target deployment environment, where the release should run. Record the intended audience and a versioned configuration reference covering relevant feature flags and permissions. These details keep a passing result tied to its deployment context. Select the release owner and included features.

When a previous review exists, its environments, audience, and configuration appear as editable defaults, with the source review named. Open the context details and confirm them for the new candidate. The candidate name and reference stay empty. StateBoard copies no checks or results. The first review shows all required context fields.

Creation fixes the candidate, environments, audience, and configuration. Start another review when any changes. Scope and checks remain editable, with each change recorded and the revision advanced. Excluding a feature requires a reason and archives its checks. Including it again requires new checks.

A review preserves the feature outcome it started with. If the product outcome changes, Edit scope lets you explicitly adopt the latest definition. Adoption revises the affected checks so earlier results cannot verify the changed outcome. Review the claims and collect fresh observations.

Add a check and record its result

In Overview, expand a feature to see its checks and results. Choose Add check there to keep that feature selected. Its outcome starts the claim. Edit it into the specific behavior you will verify. The form carries the known owner and validation environment forward. A filtered check list also supplies its active category. Describe how to verify the claim and whether it is required. Category, environment, and freshness settings remain available in the form's details.

Every included feature needs at least one required functional check. The default evidence lifetime is 24 hours. Additional integration, UX, data, security, or operational checks can target a feature, linked component, or the entire release. For example, a rollback rehearsal can be a required operational check for the release. A staging result is not production verification: the check must state which environment it expects.

Choose Record result beside a check. Select pass, fail, or inconclusive, then describe what you observed. A supporting URL is optional. Source and observation time remain available in the details. Correct the time if the observation happened earlier. StateBoard assigns a unique manual review reference, so you do not need to invent a run identifier. It records your observation but does not run the check or fetch linked content.

The result is evidence for that exact candidate, context, and check revision. Revising a check preserves its older definitions and results. Only a fresh matching observation for the active revision can satisfy it. CI and agents can append results through REST or MCP.

StateBoard selects the newest matching observation by verification time, with a deterministic tie break. A late-arriving older pass cannot clear a newer failure. A selected failure remains a blocker after expiry. Optional failures remain warnings. Visual shipped, mock, and missing states stay separate from readiness.

Find the view for your task

All destinations use the same release records. The URL retains the selected view and focused check, so colleagues can open the same context. Browser Back and Forward restore that location.

Checks opens the Checks & results page. Operational, security, and data concerns are categories of the same checks. They do not require separate records or another workflow. The older Operations view URL remains supported. A category without checks remains unassessed. More filters contains Include functional checks in the Operations area. Search appears for larger check lists or while a query is active. Filters never change calculated readiness.

The summary shows the first three required findings, with Show all for the rest. Optional warnings have their own disclosure. Select a finding to inspect its exact check. Share its check URL parameter to keep that focus. A category link also retains its selection in the URL and shows a clearable Category chip. Reset filters removes the category while preserving the exact-check link and other URL context.

Component editing starts with this product's linked components. Browse workspace catalog exposes reusable components when needed. A component with no component-specific check can still support a verified feature. These remain separate claims.

View names describe tasks, not permissions. An accountable owner label does not grant access.

API keys follow their effective role. Even an owner-scoped key cannot record a decision or publish or revoke a release review link. Existing visual board links and MCP tools retain their separate behavior.

Record and share a decision

A workspace owner opens Decision and chooses Record decision. Approval is available only when calculated readiness is ready. A held decision can record blockers or gaps at any readiness. Both require a rationale. There is no gate waiver path, and recording approval does not deploy the product.

Select the board screenshots and private supporting images to retain. StateBoard preserves independent image bytes and the reviewed scope, check definitions, evidence, dependencies, visual mappings, evaluation time, and rationale. Later edits, screenshot replacement, and member removal do not rewrite this record. If the assessment changes during review, reload it before recording the decision.

For confidential supporting images, use Supporting review images in the Decision view. These PNG, JPEG, GIF, or WebP files are authenticated and can be up to 25 MB. Existing board screenshot URLs are publicly accessible when known. Making a private retained copy does not undo that exposure.

To share with customers or other people outside the workspace:

1. Open a recorded decision and choose Prepare public review link.
2. Write the public summary and review the public environment and audience labels. Select the outcomes to include and edit their public explanations.
3. Explicitly choose retained images safe to disclose, then create the link. Internal architecture, checks, evidence URLs, run identifiers, member details, and private notes are excluded.
4. Use Revoke under Public review links when access should end. Revocation blocks subsequent page and selected image reads. It cannot retract bytes someone already downloaded.

Release review links show a preserved decision, not the mutable live assessment. Ordinary visual board links still show the full visual board and are managed separately. Boards with release history cannot be deleted through ordinary board deletion. Archive reusable records when they are no longer needed.

Submit evidence through REST

Use an editor-scoped API key and fetch the active assessment first:

curl -H "Authorization: Bearer $STATEBOARD_API_KEY" \
  "$STATEBOARD_API_BASE/api/releases/RELEASE_ID"

The response includes assessment, checks, evidence, product, and readiness. Use assessment.revision for expectedRevision, the chosen check's id and revision, and its expected environment. Copy candidateRef, audience, and configurationRef exactly from the assessment.

For example, save this payload as evidence.json, replacing the IDs, revision numbers, context, run details, and observedAt with the result you actually verified. observedAt is the verification time in Unix milliseconds, not the upload time.

{
  "expectedRevision": 7,
  "checkId": "CHECK_ID",
  "checkRevision": 2,
  "candidateRef": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "environment": "staging",
  "audience": "Finance pilot",
  "configurationRef": "billing-config-v3",
  "result": "pass",
  "summary": "An authorized finance user downloaded a valid invoice PDF.",
  "source": "billing-ci",
  "runRef": "pipeline-184-attempt-1",
  "eventId": "pipeline-184-invoice-pdf-attempt-1",
  "observedAt": 1791878400000,
  "referenceUrl": "https://ci.example.test/runs/184"
}

curl -X POST -H "Authorization: Bearer $STATEBOARD_API_KEY" \
  -H "Content-Type: application/json" --data-binary @evidence.json \
  "$STATEBOARD_API_BASE/api/releases/RELEASE_ID/evidence"

A successful submission returns the updated assessment workspace, including calculated readiness. Repeating the same event identity and payload with the same source and credential preserves the original evidence record, even when its submitted assessment revision is now older. Reusing that identity for different data returns 409. For a new event, a stale assessment or check revision returns 409. Refresh and review the new definitions before retrying. A mismatched candidate, environment, audience, or configuration returns 400, as does a malformed payload. Insufficient permissions return 403.

Evidence is append-only and attributed to the member and credential that submitted it. StateBoard records the result supplied by the producer. It does not run the test or automatically trust that result as proof of other claims.

Read freshness and history

The live assessment recalculates evidence expiry as time passes. Use Refresh release review to see changes submitted by another person or tool. Updating a board or receiving an old result does not refresh its verification time.

Recorded decisions remain historical assessments. Their reviewed date and evidence deadline distinguish the preserved result from current verification. A later passing result or expired check does not rewrite the earlier review. Public reviews make the same distinction. Remote evidence links can change or disappear, so retained summaries and selected media form the preserved baseline.

StateBoard assesses explicit claims. A contract pass verifies that contract, and declared dependencies explain potential impact. Neither automatically verifies an entire business outcome. Keep the required checks aligned with the release your team actually intends to approve.