Reviews and quality

Is this release ready, and where is it?

Deliver shows each release candidate's exact revisions and builds, the Quality results for those revisions, readiness gates that never pass on missing evidence, the approvals your policy asks for, and where the release was deployed and who can use it.

Deliver (the bar), then Overview, Release candidates, Readiness, Releases, Environments, Deployments or Evidence.

A release candidate

Open one from Release candidates. The page has these parts:

• Readiness: each gate with Passed, Failed, Blocked, Not asked for or Waived, and why. Missing evidence is Blocked, never Passed. Skipped tests are never a pass. A re-run of one layer is not a full regression.
• Scope: what is in this release (its code is in these revisions), excluded (with a reason), partly in, missing (approved but not here) or in conflict.
• Quality: the runs Quality Intelligence recorded for exactly these revisions. Each opens the run itself; Deliver keeps no copy of test results.
• Approvals: one per role your policy names (for example Engineering and Release manager). You approve exactly what you read: if anything material changes afterwards, your approval stops counting and the page says why.
• Builds: one row per repository: revision, build, CI run, artifact digest, and whether an outside system reported it or a person attested it.
• Target and notes: where the release is going, its notes, its known issues.
• Evidence: the trace matrix (requirement → work → build → quality → deployment), deployments, availability and waivers.
• Activity: everything recorded about it, newest first.

Builds and deployments from your tools

Your CI posts each run to POST /v1/delivery/builds with an organisation key:

• GitHub Actions, Azure Pipelines and GitLab CI send their own run JSON; any other CI uses the generic record
• the record names the repository and the full commit SHA

Your deployment tool posts to POST /v1/delivery/deployments, naming the revisions it deployed.

Both are recorded as reported by an outside system. A release manager can attest one when it names exactly the release's revisions. A record naming other revisions is shown as contradicting the release, and readiness fails.

Deployed is not available

After a deployment, record who can use the release (Evidence › Availability): everyone there, or a flag, a region, a cohort, a plan or a percentage (through the API). Until then the release is deployed, not available.

Yavaren does not deploy and does not control your rollout. Record what your own system did. Health is unknown until something reports it.

Waivers

An admin may waive one failed or blocked gate, for example for a hotfix. A waiver records:

• a reason
• a scope
• a risk
• an expiry of at most 90 days

The gate shows Waived, with who waived it and until when. Scope, evidence integrity and approvals cannot be waived.

Incidents

Record an incident against a deployment, or let your incident tool post it. The incident page walks back to the release, its stories and requirements, and lists what was missing, for example a story with no test evidence. It then proposes follow-up work. You choose which proposal becomes an item on the board. Nothing is created or changed by itself.