Skip to content

Section 13: Build, Deployment, and Release Verification

TECHSPEC-13 — Section 13 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Build Philosophy

A successful build must represent a specific, identifiable version of a program.

The language must distinguish between code that compiles, code that passes validation, and code that has sufficient verification evidence for release.

A successful compilation alone does not establish correctness.

2. Build Requirements

Every build must record:

  • Source file hashes.
  • Compiler version.
  • Language specification version.
  • Runtime or execution target version.
  • Dependency versions.
  • Build configuration.
  • Generated artifact hashes.
  • Verification results.

Rules: - Builds must be reproducible under the same declared environment. - Unresolved dependencies must prevent a validated build. - Failed mandatory checks must prevent a successful validation result. - Build artifacts must be traceable to their source. - Changes to source or dependencies must invalidate affected previous verification results.

3. Build Statuses

The initial language defines four build statuses:

  • DEVELOPMENT: Compilation or implementation is in progress.
  • COMPILED: Source code compiled successfully.
  • VALIDATED: All mandatory static checks and required tests passed.
  • VERIFIED: All explicitly required verification conditions have sufficient recorded evidence.

A build cannot be marked VERIFIED merely because it compiled or passed tests.

4. Release Requirements

Before release, the build must:

  • Compile successfully.
  • Pass all mandatory validation checks.
  • Pass required tests.
  • Have no unresolved mandatory failures.
  • Have no required verification properties left UNKNOWN or UNVERIFIED.
  • Include a complete verification report.
  • Have a recorded artifact hash.

Any exception must be explicitly authorized and recorded. An exception must not silently change a FAILED or UNKNOWN result into a successful verification result.

5. Deployment Integrity

Deployment must use the exact artifact that was validated and approved.

Rules: - Deployment artifacts must match their recorded hashes. - Deployment must not silently rebuild or modify approved artifacts. - Environment-specific configuration must be identified. - Required permissions must be available in the deployment environment. - Deployment failures must be reported. - Rollback must identify the previously deployed artifact.

6. Verification Invalidation

Verification evidence is valid only for the program and environment it actually covers.

The system must invalidate or re-evaluate affected evidence when: - Source code changes. - Dependencies change. - Compiler or verifier versions change. - Build configuration changes. - Relevant runtime or environment assumptions change. - Tests or contracts change.

Unrelated changes should not automatically invalidate all evidence when their independence can be established.

7. Release Verification Report

Every release must include a machine-readable report containing:

  • Build identifier.
  • Artifact hash.
  • Source hash.
  • Compiler and runtime versions.
  • Dependency information.
  • Static analysis results.
  • Contract verification results.
  • Test results.
  • Formal verification results, if applicable.
  • Known limitations.
  • Remaining warnings.
  • Explicitly authorized exceptions.

8. Compiler and Build System Responsibilities

The build system must: - Produce reproducible artifacts. - Record build inputs and outputs. - Enforce mandatory validation gates. - Track verification evidence. - Detect stale verification records. - Verify artifact integrity before deployment. - Prevent unsupported release claims.

9. Design Goal

AI agents must never be able to deploy one version of a program while presenting verification evidence belonging to another.

Every released artifact must have an identifiable history and an honest record of what was actually checked.

Source file: TECHSPEC-13.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.