Delivery

The three parts prove the three risks are closed: G checks prove the record graph holds, verified scenarios prove each behavior through the public boundary, and S checks prove the code matches the records where a qualified reader exists. A release missing any part ships with that risk unjudged. litespec model check --release makes the release-readiness findings block, so the gate is a command.

A reimbursement release shows green G checks, every scenario verified, and green S checks on the .NET reader.

Checked bylitespec model check --release blocks on use-case-unverified.

Marked checkable: the tool named here checks it.

A product that cannot recreate its schema, back up its data, and restore from backup holds customer data it cannot recover. Repeatable setup plus a tested restore turns recovery from a hope into a rehearsed procedure.

Reviewed forWhich releases lack repeatable schema setup, backup instructions, or a tested restore? Look at the recovery evidence beside the release.

Marked guidance: a reviewer answers this question.

Operators cannot keep a product they cannot see: liveness and readiness signals drive restarts and traffic, and trace-correlated diagnostics connect a failure to its cause. Secrets stay outside source control because a committed secret is a published one.

Reviewed forWhich releases lack health signals, trace diagnostics, or secrets outside source control? Look at the operating evidence beside the release.

Marked guidance: a reviewer answers this question.

CI, tested deployment and rollback paths, current limits, and the runbooks those limits name make every release repeatable and every failure recoverable. Without them, each deployment improvises and each incident starts from scratch.

Reviewed forWhich releases lack current CI, deployment, rollback, limits, or runbooks? Look at the delivery evidence beside the release.

Marked guidance: a reviewer answers this question.

Build, test, contract, security, journey, schema, backup, deployment, readiness, diagnostics, smoke-test, and rollback results together show the artifact works and can be operated. A missing kind is evidence nobody produced.

Reviewed forWhich records lack a result for a listed evidence kind? Look at the evidence list on each release record.

Marked guidance: a reviewer answers this question.

Limits, alerts, runbooks, known conditions, and skipped checks tell the maintainer what to watch, what to run, and what remains unverified after release. Without them, the release hands over an artifact with no operating instructions.

Reviewed forWhich records lack limits, alerts, runbooks, conditions, or omissions? Look at the readiness list on each release record.

Marked guidance: a reviewer answers this question.

A release record binds evidence to one artifact, so a product with no artifact yet has nothing to record in one. The readiness record instead states what proves the product may take data: dated rehearsals, green gates, and a rehearsal owner who owns the backup and restore rehearsal.

Reviewed forWhich pre-release consumers lack dated rehearsals, green gates, or a rehearsal owner? Look at the readiness record beside the project.

Marked guidance: a reviewer answers this question.

A persistence change reaches production data, so the reviewer needs to see exactly what the database will do before it runs. The schema artifact shows that: the Marten schema plan and document transformation, or the generated EF Core migration with its SQL. Listing every destructive operation with its reason forces the author to name data loss where every reader sees it.

Reviewed forEach persistence change carries a schema artifact with every destructive operation and its reason.

Marked guidance: a reviewer answers this question.

When a new advisory names a component and a version range, the team must answer one question fast: does any running release contain it. Without a component inventory beside the artifact, that answer means rebuilding the dependency graph of a commit somebody has to find first. NIST SP 800-218 states the practice, and the frozen lockfile the build resolved is what the inventory is generated from. OSV-Scanner matches dependencies against OSV.dev advisories and Gitleaks scans for leaked secrets, so advisories and secrets each have one evidence tool.

The build job that produces the artifact generates the inventory from the same frozen lockfile. It stores the inventory beside the artifact, under the release version.

Reviewed forThe supply-chain report shows scan, pin, inventory, and license evidence with an exception for each unhandled high-severity advisory.

Marked guidance: a reviewer answers this question.

The intent diff names what moved, while the preview shows it rendered, with the changed records readable beside their neighbors. The reader clicks from the comment into the preview for full context.

Reviewed forThe pull request links a book preview built from the change.

Marked guidance: a reviewer answers this question.

Staging tests prove something about the artifact they ran against. When production deploys a fresh build from the same branch instead, it ships code the tests never saw, because the branch may have moved between the two builds. Promoting the one tested artifact through staging and production keeps the tested code and the shipped code identical.

Reviewed forThe staging and production deployments reference the one artifact the release job passed.

Marked guidance: a reviewer answers this question.

The default branch is the source every environment deploys from, so an unreviewed or unchecked commit there reaches production with no further review. Requiring the jobs table entries, a reviewed pull request, and a clean merge state keeps every commit on the branch reviewed and verified. A direct push or a bypassed check is permitted only during a documented repository recovery action.

Reviewed forThe default branch settings require the jobs-table entries, a reviewed pull request, and a clean merge state.

Marked guidance: a reviewer answers this question.

The bypass permission exists so a recovery can proceed when the gates cannot run. A recovery nobody wrote down is indistinguishable from a habit, so the next reviewer cannot tell which commits on the branch were reviewed. The record names the actor, the reason, and the admitted change, which is the attribution NIST SP 800-218 states for the same event.

The record is the recovery decision itself where one exists. A bypass smaller than a decision takes a dated entry in the operations log at .litespec/behavior/operations/log/.

Reviewed forEach bypass entry in the operations log or recovery decision names its actor, reason, and admitted change.

Marked guidance: a reviewer answers this question.

The release job reruns the table's jobs by name, and the branch protection settings require them by name. When a consumer renames a job or moves its checks elsewhere, those references point at a job that no longer exists, and the gate stops checking without failing. Fixed names and responsibilities keep every reference resolving to the checks the table states.

Reviewed forThe consumer workflows use the job names and responsibilities the jobs table states.

Marked guidance: a reviewer answers this question.

The requirement's measure is the agreed target, and the alert is the one place it is enforced at runtime. A measure that says two seconds and an alert that fires at five drift apart silently, because nobody re-reads the alert when the requirement changes. Comparing the numbers is a coarse check, since a measure is prose, so it advises rather than blocks.

requirement/expense-submission.month-end-submissions measures "at least 99 percent within two seconds", and its alert's expression compares the 0.99 quantile against 2.

Checked bylitespec model check reports alert-threshold-drift (level A) for an alert rule whose own text carries none of the decimal numbers its requirement's measure names.

Marked checkable: the tool named here checks it.

A drill rehearses a procedure against a running deployment, and a harness measures from outside: neither is a test, and neither runs in the test job, so their outcome lives only in a terminal or a pasted note that no tool reads. Writing each run as a small result file in Proof gives the quality requirement the same evidence a measured check gives it, under the same check name, with the date it ran and the value it saw.

Claimwick's month-end load harness writes .litespec/proof/checks/2026-11-20-month-end-load.json holding "check": "month-end-load", "passed": true, "value": "99.4 percent acknowledged within two seconds", and "ranOn": "2026-11-20", and requirement/expense-submission.month-end-submissions names month-end-load in its check.

Reviewed forWhich drill or measuring harness runs lack a check result file naming the requirement's check under paths.checkResults? Look at the harness run records beside the files under paths.checkResults.

Marked guidance: a reviewer answers this question.

A backup is only as good as its restore: without a named owner, a schedule, a retention bound, encryption, a location, a restore command, and recovery objectives, nobody knows what is kept, who restores it, or how much loss is accepted. Writing all seven down before production data arrives leaves nothing to decide during the incident.

Reviewed forThe release documentation states backup owner, schedule, retention, encryption, location, restore command, and recovery objectives.

Marked guidance: a reviewer answers this question.

Backups fail in ways only a restore reveals: a missing key, a wrong permission, a dump the new version cannot read. Rehearsing on representative data before production data arrives finds those failures while they cost nothing. The first restore attempt is the wrong time to learn the backup cannot restore.

Reviewed forThe operations log holds a restore rehearsal on representative data before the first production data.

Marked guidance: a reviewer answers this question.

A repeatable deployment names everything it ships: a versioned artifact, declared configuration, a schema step, readiness checks, and a passing release job. Deploying from an uncommitted tree or a mutable branch reference makes the deployed content unknowable afterwards, because the same reference points at different code a week later. Named inputs let any deployment be repeated and any incident be traced to its exact content.

Reviewed forEach deployment names versioned artifacts, declared configuration, a schema step, readiness checks, and a passing release job.

Marked guidance: a reviewer answers this question.

Rollback is written during the incident if it is not written before it, and an incident is the worst time to work out which artifact was live, which command restores it, and whether the schema still fits. Stating the previous artifact reference, the command, the configuration and schema compatibility, the data recovery condition, and the expand-and-contract sequence keeps each answer ready. For a container release the runbook names the previous image digest, which names one immutable image where a tag alone could have moved since the release went out. Rollback is a required runbook, so litespec/ext/delivery#exercise-every-runbook-before-release rehearses it.

Reviewed forThe rollback runbook states its artifact reference, command, compatibility, data condition, and expand-and-contract sequence, and the previous image digest for a container release.

Marked guidance: a reviewer answers this question.

A recurring job with nothing to do is quiet, and a recurring job that stopped is quiet too. Without a liveness signal that pages a person on silence, the two stay indistinguishable until somebody notices the missing output. Liveness turns a quiet job from an observation into an alarm.

Reviewed forEach recurring job reports liveness that pages a person on silence.

Marked guidance: a reviewer answers this question.

Each declared field answers one failure mode:

• An alert with no owner waits for somebody to adopt it.
• An alert with no threshold or evaluation window fires on noise.
• An alert with no severity waits in the wrong queue.
• An alert with no runbook asks its receiver to invent the response.

Declaring all five before production makes each alert answerable the first time it fires.

Reviewed forEach baseline alert declares owner, threshold, window, severity, and runbook.

Marked guidance: a reviewer answers this question.

Five failures end a release when nobody observes them: readiness that never recovers, HTTP errors the code did not expect, a slowing release flow, a lost database, and a deployment that failed partway. Naming them as the minimum coverage keeps a team from declaring alerts only for the failure it just survived.

Reviewed forThe baseline alerts cover readiness failures, unexpected HTTP errors, release-flow latency, PostgreSQL outages, and failed deployments.

Marked guidance: a reviewer answers this question.

A declared severity with no destination is a label: every alert arrives in the same place, and the page that wakes somebody is read beside the one that can wait. Routing each severity to its destination with an expected response time separates the page from the ticket, which is the separation Prometheus alerting practice states. The limits page declares the routing beside the generated inventory.

A two-severity inventory routes page to the on-call destination with a stated response time, and ticket to the queue reviewed each working day.

Reviewed forEach severity states its destination and expected response time on the limits page.

Marked guidance: a reviewer answers this question.

A runbook is a claim until somebody runs it: steps go stale, commands change, permissions lapse. A dated rehearsal in the operations log proves each required runbook still works against the current system. The restore rehearsal is the one litespec/ext/delivery#exercise-a-restore-before-the-first-production-data requires.

Reviewed forEach required runbook carries a dated rehearsal in the operations log.

Marked guidance: a reviewer answers this question.

OpenSLO files state objectives as code, and Sloth validates them in CI and compiles them into Prometheus recording rules and burn-rate alerts. OpenTelemetry supplies the signals the objectives read, as litespec/quality/operations#emit-correlated-diagnostics states. Sloth and OpenTelemetry are free and maintained under Apache-2.0, and availability stays evidenced in production only.

Reviewed forThe OpenSLO files pass Sloth validation with their generated alerts loaded.

Marked guidance: a reviewer answers this question.

The book states intent while dashboards show production truth, and the link joins them: a reviewer clicks from the objective to the numbers behind it. Copying numbers into the page instead would freeze production truth at commit time.

Reviewed forEach production objective in the book links its dashboard.

Marked guidance: a reviewer answers this question.

The bill of materials (SBOM) is the computed list of what ships, so it is the one place a pin can be checked against instead of trusted. A version that drifted from its pin carries advisories and behavior the release never reviewed. The bill is generated, so the fact stays written once, and a record per package would rewrite hundreds of facts on every update.

Claimwick's bill of materials sits at .litespec/proof/sbom/api.spdx.json, the project file names that folder in paths.sbom, and a direct pkg:nuget/Marten at a version other than the manifest pin is reported.

Checked bylitespec model check reports dependency-version-drift (level S) for a direct package whose version differs from its manifest pin.

Marked checkable: the tool named here checks it.

A copyleft or commercial license binds the product the day the package ships, and a license nobody accepted is found at an audit rather than at the change that brought it. Listing the accepted licenses once, and naming any other on the admitting decision, keeps the license choice a decision with a person's name on it.

Claimwick accepts MIT, Apache-2.0, and BSD-3-Clause in dependencies.licenses, so a direct package under AGPL-3.0-only that no decision admits is reported.

Checked bylitespec model check reports dependency-license-unknown (level S) for a direct package whose license the project does not accept and no admits entry names.

Marked checkable: the tool named here checks it.

Build tooling has no place in a runtime image: each compiler and package cache widens the attack surface of every deployment. Multi-stage builds leave that tooling in the build stage. A pinned base-image digest fixes the exact reviewed base, so a rebuild months later starts from the same bytes.

Reviewed forWhich release images miss multi-stage builds or pinned base-image digests? Look at the Dockerfiles.

Marked guidance: a reviewer answers this question.

A compromised application process inherits the rights of its runtime user. A non-root user confines the attacker to what that user may touch. Root would hand over the whole container.

Reviewed forWhich release images run their application as root? Look at the Dockerfiles and image configuration.

Marked guidance: a reviewer answers this question.

Every file in the runtime image ships to every replica and waits for an attacker to read it. Copying only the files the application needs keeps the image small to transfer and to inspect. Each extra file is cost with no runtime purpose.

Reviewed forWhich runtime images carry files outside the declared runtime manifest? Look at the image file listing beside the declared runtime manifest.

Marked guidance: a reviewer answers this question.

Source, tests, package caches, and local configuration serve the build and never the running application. Carrying them into production leaks internals to anyone who pulls the image. Secrets stay out under litespec/quality/security#keep-secrets-out-of-tracked-and-observable-data.

Reviewed forWhich runtime images contain source, tests, package caches, or local configuration? Look at the runtime image contents.

Marked guidance: a reviewer answers this question.

Connection strings, OIDC settings, exporter endpoints, and secrets differ by environment. Supplying them outside the image lets one image serve every environment. Baking them in would rebuild and re-test the image for each environment it enters.

Reviewed forWhich connection strings, OIDC settings, exporter endpoints, or secrets live inside the image? Look at the deployment manifests.

Marked guidance: a reviewer answers this question.

One immutable image deploys unchanged into staging and production. Environment values baked into the image break that promise: the tested bytes and the deployed bytes differ. External values keep the image identical everywhere it runs.

Reviewed forWhich release images contain environment-specific configuration? Look at the release image contents.

Marked guidance: a reviewer answers this question.

New application replicas expect the schema their release reviewed. The release job applies those schema changes before traffic shifts, under litespec/backend/persistence#control-production-schema-changes. Traffic first would send new code against an old schema.

Reviewed forWhich releases shift traffic before the reviewed schema job runs? Look at the release job order.

Marked guidance: a reviewer answers this question.

Several replicas can start at once, each running its own startup. Schema work in startup then runs concurrently, without the release job's review and ordering. Startup reads the schema the release job prepared and changes nothing.

Reviewed forWhich application replicas alter the production schema during startup? Look at the replica startup paths.

Marked guidance: a reviewer answers this question.

New replicas need time to load before they serve: a replica that receives traffic mid-startup fails its first requests. The controller starts them, waits for readiness, and only then shifts traffic. Readiness proves the new version serves before it becomes the version.

Reviewed forWhich deployments shift traffic before new replicas reach readiness? Look at the deployment controller behavior.

Marked guidance: a reviewer answers this question.

An image that builds can still fail where it runs: routing, configuration, and data differ from the build machine. Running the release's recorded end-to-end suite after traffic shifts tests the deployed path itself. The release record names the suite, so the check runs the same tests every release.

Reviewed forWhich releases skip the recorded end-to-end suite after traffic shifts? Look at the release evidence.

Marked guidance: a reviewer answers this question.

A read-only filesystem and dropped capabilities shrink what a compromised process can do next: no writes outside declared paths, no privileged calls it never needed. The limits apply where the application permits them. Each kept capability is an action an attacker inherits.

Reviewed forWhich deployments keep a writable filesystem or unnecessary capabilities where the application permits the limits? Look at the deployment manifests.

Marked guidance: a reviewer answers this question.

Declared writable paths name the mutable storage the application needs, and CPU and memory bounds as setting records cap what one deployment may consume. The bounds protect the node's capacity from one hungry replica. The declarations also tell the next reader what the application was sized for.

Reviewed forWhich deployments miss declared writable paths or CPU and memory setting records? Look at the deployment manifests beside the setting records.

Marked guidance: a reviewer answers this question.

The platform stops a container by signaling its entry process. An application running as PID 1 receives that signal and shuts down on purpose. A wrapper that swallows the signal leaves the platform waiting until it kills the container mid-work.

Reviewed forWhich containers run something other than the application as their entry process? Look at the image entrypoints.

Marked guidance: a reviewer answers this question.

Stopping a replica interrupts its in-flight requests and Worker operations. A grace period longer than the measured stop time lets that work finish or record a safe interruption. A shorter period kills work the system then has to reconcile.

Reviewed forWhich deployments set a shutdown grace period no longer than measured request or Worker stop time? Look at the deployment manifests beside the measured stop times.

Marked guidance: a reviewer answers this question.

Container filesystems vanish with their replicas, so a log file inside the container dies with the evidence it holds. Standard output and standard error hand each line to the platform's log collection. The platform then keeps logs past the life of any one replica.

Reviewed forWhich containerized applications write logs somewhere other than standard output or standard error? Look at the application logging configuration.

Marked guidance: a reviewer answers this question.

The platform recreates replicas at will: deploys, scaling, and node failures each replace containers with fresh ones. Mutable data kept inside the container filesystem dies with its replica. External storage keeps the data alive across every recreation.

Reviewed forWhich mutable data lives inside a container filesystem? Look at the application storage design.

Marked guidance: a reviewer answers this question.

Source, revision, version, and created-time labels in the OCI standard form connect each image to the commit and release that produced it. An incident responder reads the running image's labels and opens the exact source. Images without labels force that join through guesswork.

Reviewed forWhich release images miss OCI source, revision, version, or created-time labels? Look at the built images.

Marked guidance: a reviewer answers this question.

The release record stores the deployed digest, not just the tag. A tag can move to a newer image after release, while the digest names the exact bytes that went out. The digest makes the deployed artifact reproducible and the rollback target exact.

Reviewed forWhich release records store only an image tag with no deployed digest? Look at the release records.

Marked guidance: a reviewer answers this question.

A generated-at field or a build-time comment changes the OpenAPI document and generated clients on every build. The diff then reports change where no contract changed, which buries real breaks. Contracts carry version identity instead of build time.

Reviewed forWhich published OpenAPI documents or generated clients contain a build timestamp? Look at the generated contracts.

Marked guidance: a reviewer answers this question.

A frontend build produces a browser bundle that anyone may download. Public build-time configuration belongs there, while server-only runtime secrets travel through mounts or runtime injection instead. The build distinguishes the two classes so each value lands in its own delivery.

Reviewed forWhich frontend builds mix public configuration with server-only secrets? Look at the frontend image build.

Marked guidance: a reviewer answers this question.

Secret mounts and runtime injection hand secrets to the build without writing them into a layer. Nothing secret then persists in the image history. A pulled image reveals its layers to anyone, so image history stays free of secrets.

Reviewed forWhich frontend secrets travel outside mounts or runtime injection? Look at the frontend image build.

Marked guidance: a reviewer answers this question.

ARG values, copied environment files, and image layers all persist into the image history. A secret delivered through any of them stays readable to anyone who pulls the image. Secrets stay out of layers under litespec/quality/security#keep-secrets-out-of-tracked-and-observable-data.

Reviewed forWhich frontend image builds use ARG, copied environment files, or image layers for secrets? Look at the frontend image builds.

Marked guidance: a reviewer answers this question.