Release coordination

Status: Accepted · Version: 0.1

This directory is how the control plane coordinates product releases and policy versions. It does not ship binaries.

Two meanings of release

Word Meaning
Product release A version of app, web, or backend that is allowed to ship because the specs it implements are accepted here
Controlled release A recipient-scoped delivery of guidance, governed by TITIP-008

Do not mix the words in runbooks without the adjective.

Policy versions

Life-check and release policies are immutable once active.

Policy v3  archived
Policy v4  active

An in-flight escalation keeps the version it started with. Shipping a backend build must not rewrite stored policy documents in place.

When a spec change alters evidence codes, states, or token rules, the spec version in the header is bumped and an ADR is added if the change is cross-cutting. Backend states the spec version it implements in its own README.

What may ship when

Product milestone Must already be accepted here Must not do
Clickable prototype Stage 0 documents, UC-01–UC-06 Real delivery, live tokens
Functional MVP TITIP-002, 003, 005, 006, 010, ADR-002, ADR-006 Eligibility from last_seen
Escalation MVP TITIP-007, ADR-004 Skip trusted-contact verification
Recipient delivery TITIP-008, TITIP-009, ADR-005, release-safety policy Content in email or WhatsApp
AI assistant TITIP-012, AI safety policy Any tool that touches release
Public launch plans/production-readiness.md Launch with the checklist open

Records

Each public launch or first enabling of real delivery gets a short record in this directory, named YYYY-MM-DD-short-title.md, containing:

No record exists yet. Real delivery has not been accepted.

Hold

Any incident that could cause wrongful delivery starts with release.disable=true, then a note in the incident channel, then a record here if the hold lasted beyond the incident. Owners are not locked out of the application.