TITIP-003 Trusted contacts

Purpose

Define how an owner nominates someone to help distinguish silence from a real problem, without giving that person the owner’s vaults.

Decisions

1. A trusted contact is created only by owner invitation. The product must not infer contacts from the address book and mark them trusted.
2. Invitation states are INVITED, ACCEPTED, REJECTED, REMOVED. Only ACCEPTED contacts count toward minimum_confirmations.
3. Acceptance is not identity verification. Verification is a separate step before a confirmation can become evidence. Prototype verification may be a confirmed channel (the contact proves they control the invited email or phone). Stronger identity proof is an alpha requirement, not a reason to skip the state in the contract.
4. The contact must be able to accept, reject, set a notification channel, and read a short responsibility statement. The statement must say they do not receive vault contents by accepting.
5. Removal and replacement are owner actions. Removal must be audited. A cycle already in TRUSTED_CONTACT_VERIFY keeps the policy version it started with; if removal drops available contacts below minimum_confirmations, the case must not invent confirmations. It waits or is held for review. It must not skip verification.
6. Being a trusted contact does not assign any vault. Being a recipient does not make someone a trusted contact. The demo wife holds both roles as two records.

Verification before evidence

A confirmation must not be stored as trusted_contact_confirmed evidence unless:

• the contact status is ACCEPTED
• the contact’s channel is verified
• the confirmation is tied to a specific escalation cycle id
• the contact was shown which owner and which cycle they are confirming

One contact confirming twice does not count as two contacts.

Prototype policy default

trusted_verification:
  required: true
  minimum_confirmations: 1

Owners may raise minimum_confirmations. They must not set required to false in the prototype or the first real-release version. Making verification optional is a future policy version, not a silent default.

Responsibility copy

The invitation must be understandable without opening a vault. Indonesian prototype copy may be:

Iman menunjuk Anda sebagai trusted contact.

The responsibility text must cover: you may be asked to confirm that the owner has not responded; confirming does not give you their documents; you can reject.

Out of scope

• Trusted contacts editing assets or release rules.
• Paying or legally appointing the contact. Titip does not make them an executor.

Acceptance

• UC-02: owner adds at least two trusted contacts; one may also be a recipient.
• A rejected or removed contact cannot produce evidence.
• Audit events exist for invite, accept, reject, verify, remove (TITIP-010).