TITIP-008 Release policy
Status Accepted
Version 0.1
Stage 0 — Authority

Purpose

Define when Titip may create a release candidate, what that candidate contains, and why the first versions do not auto-deliver.

Life check decides that conditions may have been met. Release policy decides whether a case is eligible. Delivery, specified here as rules and implemented later, decides what is given to whom. Delivery must not widen what this policy allowed.

Decisions

  1. release.automatic must default to false. The prototype and the first production release must not ship a path where eligibility sends vault access with no reviewer.
  2. When eligibility evidence is complete, the system creates a release candidate (a release case in CANDIDATE). It does not email vault contents.
  3. Real delivery requires manual_review_approved on that case (ADR-005).
  4. Simulation creates a case in SIMULATED with the same per-recipient decisions, watermarked, with no access token that vault will honour.
  5. A global hold (release.disable=true) blocks transitions to real delivery. It does not block owner login, editing, or life-check confirmation (policies/release-safety.md).
  6. Policy edits archive the old release policy version. Open cases keep the version they were created with.

Release case

A case belongs to one owner and one policy version. It lists one decision per assigned active vault:

Field Meaning
Vault Which container
Recipient The assigned person only
Status RELEASABLE or HOLD
Reason Present when HOLD (age rule, suspended vault, missing identity)

Demo:

Release case
  Owner: Iman
  Vault Insurance            → spouse   RELEASABLE
  Vault Property             → spouse   RELEASABLE
  Vault Business continuity  → partner  RELEASABLE
  Vault Personal message     → child    HOLD (recipient age >= 18)

The spouse’s package must not include business continuity. The partner’s package must not include insurance. The child receives nothing while the rule holds.

Case states

CANDIDATE → IN_REVIEW → APPROVED → DELIVERED
                     ↘ REJECTED
                     ↘ HELD
CANDIDATE → SIMULATED
State Real recipient access
CANDIDATE No
IN_REVIEW No
SIMULATED No
HELD No
REJECTED No
APPROVED Tokens may be issued
DELIVERED Only inside token scope and expiry

APPROVED and DELIVERED must not be reachable in the prototype build. The prototype ends at SIMULATED.

What a notice may say

Only that information is available, plus a link that is short-lived, single-purpose, revocable, and recipient-bound. The link is specified in TITIP-009. The prototype must not send that link to a real person.

Acceptance