Locks and cooldowns

Haven has no calendar scheduler. What it has instead is a set of commitment devices: tools where the calm, motivated version of someone constrains what the impulsive version of them can do half an hour later.

They all share the same shape. Strengthening protection is instant. Weakening it costs time, and sometimes a witness.

The disable cooldown#

Switching protection off is not a toggle. It is a request.

1. Access. If a PIN is set — and it is required whenever protection runs — the user must unlock before anything starts.
2. Intent. A reflection screen asks them to name a reason. Choosing "stay protected" here is the outcome the whole mechanism is designed to produce, and it is always available without any friction.
3. Time. The request then waits out a cooldown the user chose themselves. Protection stays fully on for the whole period.
4. Completion. When the period has elapsed, one more deliberate action turns it off. Nothing ever switches off by itself.

Repeated attempts lengthen the wait. Hammering the button in a bad moment makes the next attempt cost more, not less. When that happens the interface says so rather than silently extending it.

A pending request survives closing the app, killing the process, and rebooting: the request and its deadline are stored, and the remaining time and the cancel button are reconstructed on the next launch.

Cancelling a pending request is always allowed with no friction at all. Changing your mind is the good outcome.

If an accountability partner is paired, both the request and the completed disable are reported to them.

The financial hard lock#

Pro. Part of Financial protection.

"I don't want to spend money until a date I choose."

While the lock is active, the guarded money apps are fully closed off — the reflection pause offers no way through — the financial layer cannot be switched off, and guarded apps cannot be un-guarded.

Its commitment semantics:

• A lock can only be set for a moment in the future, and is capped at roughly a year — long enough for any savings goal, short enough to stay sane.
• An active lock can be extended, never shortened and never cancelled. The motivated self decides once; the impulsive self cannot negotiate it back down.
• On the chosen date it simply expires, and the ordinary soft pause takes over.

The recurring spending day#

Pro. Part of Financial protection.

The user picks one fixed spending day — weekly (say, every Friday) or monthly (say, payday on the 25th). On that day the guarded money apps open normally. On every other day they hit the locked screen.

A monthly day beyond a given month's length clamps to that month's last day, so "the 31st" reliably means "the last day of the month".

The commitment: the schedule can only be changed or switched off on a spending day, when everything is open anyway. A blocked moment cannot be negotiated away.

The emergency unlock#

Pro. Part of Financial protection.

Real life does not always wait for a spending day. Once a week, the user can open their guarded apps for a short window — long enough for an urgent payment, too short for a spending spree, and rate-limited so it cannot quietly become the new normal.

Everything derives from a single stored timestamp, so the window and the cooldown can never drift apart. A device clock moved backwards simply leaves the button unavailable until the timeline catches up; it can never produce an accidental permanent unlock.

Whether the button is currently available, and when it returns, is always visible on the financial screens. It is a stated escape hatch, not a hidden one.

Releasing a learned block#

Free.

Overturning a rule the detection engine wrote by itself runs through the same escalating cooldown, when the engine's evidence was strong. Full detail in Self-learning and personal filters.

Summary#