TITIP-006 Life check
Status Accepted
Version 0.1
Stage 0 — Authority

Purpose

Define life check as Titip’s presence cycle, and define inactive so implementers do not reduce it to last_seen > 90 days.

Life check answers: has the owner confirmed they are present under the policy they configured?

It does not answer: is this person dead?

Decisions

  1. A life-check policy is versioned and immutable once ACTIVE. A change archives version N and activates N+1. The cycle in progress stays on the version that was active when it entered CHECK_DUE.

  2. The prototype default, used by UC-05 and the demo, is:

    frequency: 30d
reminders:
  - after: 0d
    channel: email
  - after: 3d
    channel: email
  - after: 7d
    channel: sms
grace_period: 14d
trusted_verification:
  required: true
  minimum_confirmations: 1
release:
  automatic: false

  3. Frequency is how often a new cycle starts after the owner is ACTIVE, not how long until release.

  4. Channels in the prototype contract are email, sms, push. WhatsApp may be added later behind the notification abstraction. It must not be hard-coded into life-check transitions.

  5. Owner confirmation from any state records a check-in and returns the cycle to ACTIVE. Confirmation must be an explicit action (link or in-app confirm), not merely opening the app. App opens may be shown on the activity timeline and must not satisfy the check by themselves. This stops a stolen device or a background refresh from clearing escalation, and stops silence-or-open from becoming the whole model.

  6. The next check date shown in the product (demo: 21 October 2026) is last confirmation + frequency, displayed in the owner’s calendar. It is not an eligibility date.

Inactive

Inactive means: in the current cycle, state is past CHECK_DUE and the owner has not confirmed.

Inactive is an input to escalation. It is not a release condition. Copy, APIs, and models must not map inactive to dead.

The word must not appear as an evidence code. The evidence code for “owner did not confirm this cycle” is life_check_unconfirmed, emitted when the cycle passes the reminder path without confirmation, not at the first missed hour.

Scheduler

The scheduler must emit domain events and persist attempts. It must not send provider calls itself. Notifications go through the notification module (contracts/events/catalog.md).

Each attempt stores channel, template id, and provider acceptance. Provider acceptance is not owner confirmation.

Simulation

Simulation must use this policy shape and the escalation states in TITIP-007. It must advance on a clock the demo controls (day 0, day 3, day 7, day 21, day 22, day 23) so stakeholders see the same rules as production, without sending real notices or creating real recipient access.

Acceptance