Spike: scheduled sensitivity changes, like scheduled unpublish

Spike, asked by Arnel on 14 September 2026: can a date and time be set on sensitivity, the way Umbraco schedules publish and unpublish, so an entry (or a field) becomes Hidden at a given moment?

## What exists

- `ScheduledPublishAt` and `ScheduledUnpublishAt` on an entry, set by `PUT /api/contents/{id}/schedule`. `ScheduledContentService` sweeps every minute and applies them through the content writer, so each change is an event (`ContentStatusChanged`, `ContentScheduled`) with an audit trail and change webhooks.
- Entry sensitivity is an event (`ContentSensitivityChanged`), and delivery checks `Sensitivity == Public` at query time, so a change takes effect on the next read.
- Field sensitivity is `PUT /api/content-types/{name}/fields/{field}/sensitivity`, which rebuilds search text in batches. It rebuilds before raising and after lowering, so anonymous search never matches a value it cannot show, and lowering needs `acknowledgeDisclosure`.

## Finding

Feasible. Entry level is small; field level is medium.

**Entry level (recommended first).** Add `ScheduledSensitivity` and `ScheduledSensitivityAt` to the entry and the schedule endpoint, and have the sweeper apply a `ContentSensitivityChanged` through the writer when the time arrives. Delivery, masking, audit and webhooks already react to that event, so the change is live within a minute, plus the renderer's revalidate. About one to two days with tests.

**Field level.** A scheduled field change is a type-wide job, run by the sweeper with the same ordering rules as the endpoint (search text first when raising, definition first when lowering). A scheduled lowering is a disclosure, so it has to be acknowledged when it is scheduled, not when it runs. It is refused on event-sourced types just like the endpoint does. About three days.

**Not recommended: evaluating the date at read time** (for example "Hidden after" checked in every delivery query). It needs no sweeper, but every delivery query, the search text, masking and change events would have to compare dates. A change would also fire no event, so webhooks and caches would not know to purge.

## Worth knowing

- If the goal is "gone from the public site at a date", `ScheduledUnpublishAt` already does it. Sensitivity is for "still published, but only these roles may read it from that date".
- Resolution is the sweep interval, one minute.

## If this goes ahead

Entry level: `Content.ScheduledSensitivity` (nullable level) and `ScheduledSensitivityAt`; schedule endpoint validation (a time in the future, a level different from the current one); a sweeper branch; tests for raise and lower, the audit entry, and a delivery read before and after the time. barakoBrew: a date picker beside the sensitivity control.

## Where it lives

Core: entry sensitivity and the scheduled content sweep.

Start with the Core entry-sensitivity implementation, PUT /api/contents/{id}/schedule, and ScheduledContentService's minute sweep; compare them with the existing sensitivity and scheduling events. Define completion around entry-level scheduling, validation, sweep application, and tests for raising and lowering, audit, and delivery reads before and after the scheduled time.

Written by the indexing model from the issue text.