# Release Assurance: IVV and IVVQ

> Status: Version-specific
> Documentation baseline: v4.10.0
> Strategy approved: 29 September 2026

SysWarden distinguishes the assurance required for an intermediate release
from full qualification of a new generation. This page explains the policy
introduced for the v4.10.0 transition and future generations. It is not a
release verdict and does not change the historical stable v4.04.3 procedures.

## The two assurance tracks

**IVV** means **Integration, Verification and Validation**. Intermediate
`Patch`, `Minor` and `Major` releases require it. The release decision covers
the exact candidate, CI and security results, package authenticity,
installation and update behavior, and regressions selected through documented
change-impact analysis.

**IVVQ** means **Integration, Verification, Validation and Qualification**.
Version-specific `Upgrade` plans, including v5.00.0 LTS and v6.00.0, require
the complete qualification plan: supported native profiles, lifecycle,
migrations, HA endurance, performance, protected acceptance and verified
restoration.

These are SysWarden's engineering assurance tracks, not external certification
claims. Neither term promises freedom from defects.

## Exact auto-versioning terminology

The following version-specific arithmetic examples all start from v0.00.0:

| Main release PR prefix | Version example | Assurance required |
| --- | --- | --- |
| `Patch :` | Version-specific example: v0.00.1 | IVV |
| `Minor :` | Version-specific example: v0.01.0 | IVV |
| `Major :` | Version-specific example: v0.10.0 | IVV |
| `Upgrade :` | Version-specific example: v1.00.0 | IVVQ |

`Major` advances the middle component to its next multiple of ten. It does
not increment the first component. `Upgrade` increments the first component
and resets the other two. Version-specific example: v4.xx.y to v5.00.0 is an `Upgrade`.
This is the project's explicit versioning scheme; generic use of the word
"major" must not replace it.

Preserve the recognized prefix in the first line of the resulting commit on
main. Classification follows the original validated version transition,
including across later corrective commits. A corrective PR cannot downgrade
an `Upgrade` to IVV. The LTS label and a development estimate do not select the
track or grant acceptance.

## What remains mandatory for an intermediate release

- Bind checks to exact source revisions, build inputs and package digests.
- Pass applicable CI, security and functional regression checks, including
  positive and negative tests of changed protections and shared dependencies.
- Cover affected installation, service lifecycle, update and recovery paths.
- Preserve native package signatures and verify the signed tag, immutable
  release manifest, Sigstore identity and final asset digests.
- Retain failed attempts, unresolved limitations and verified restoration.
- Complete the protected acceptance required by the selected release policy.

Long endurance campaigns are selected by impact and the release's claims for
an intermediate release. They are not automatically repeated for every
correction. A change to the HA mechanism or an observed regression can still
require new native HA work. IVV is not permission to waive a blocking defect.

Historical evidence remains bound to its original commit and artifacts. An
explicit continuity assessment may retain relevant evidence or justify a
targeted replay. It must never silently relabel an old pass as a new result.
The same applies to documentation-only changes: source and payload continuity
must be established before evidence is admitted to a release decision.

## v4.10.0 and implementation status

The v4.10.0 `Major` transition completed protected IVV acceptance and was
published on 1 October 2026. The [protected run](https://github.com/duggytuxy/syswarden/actions/runs/36853355288)
accepted all twelve checks, preserving each evidence set's original candidate.
The tested product is `8c3405758a9b369924f466d12652e99d3a84dc56`; the signed
publication commit is `3cc06b62d42b5adadc46fc9a252fece5adf670c1`.

All twelve [public release files](https://github.com/duggytuxy/syswarden/releases/tag/v4.10.0)
were downloaded and verified independently, including their original GitHub
provenance attestations. The maintainer signed the exact checksum manifest
using Sigstore identity `laurent@data-shield.eu`; see
[Rekor entry 3035233768](https://search.sigstore.dev/?logIndex=3035233768).

The original protected publisher failed on a private-draft metadata read using
GitHub's published-only tag endpoint. The owner explicitly approved recovery
with the already verified draft ID. All frozen content, tag, protection and
snapshot checks were retained; only the metadata read endpoint changed. Public
downloads and signatures were reverified. The failed workflow remains recorded
as failed. This bounded exception does not change normal publication policy.

This is an intermediate IVV validation, not full IVVQ. The historical HA
endurance runs retain their original candidate; the current HA replay is
functional. Native traffic evidence is IPv4, with IPv6 list and kernel-state
checks. The private APK 3 qualification-bundle update path is outside the plan.
Historical deployment runbooks retain their v4.04.3 boundary; later source
builds do not inherit this release verdict.

[PR273](https://github.com/duggytuxy/syswarden/pull/273) introduced the release
classification. [PR280](https://github.com/duggytuxy/syswarden/pull/280) supplied
the protected intermediate acceptance producer and independent consumers.
The [dated policy source](https://github.com/duggytuxy/syswarden/blob/048a690e989dc731f757494ba6ca62d4ab730b4d/docs/maintainers/RELEASE_VALIDATION_POLICY.md)
remains the classification reference. Frozen qualification contracts and
historical verdicts are preserved.