A claim is a work lock
A claim names a holder and a window. While the window is live nobody else can resolve the row, and when it lapses the row is back in the pool.
The situation
Two reviewers open the same row. The first to start working should hold it, and the second should see that immediately, without the lock outliving a reviewer who walks away.
The recipe
ltc esc claim $ID --duration 30ltc esc claim $ID --duration 30 # same holder: extends, isExtension trueconst res = await lt.escalations.claim({ id, durationMinutes: 30 });A claim sets assigned_to and assigned_until. The status stays pending; the lock exists only while the window is active.
| Row state | Resolve by id |
|---|---|
| Unclaimed | Allowed |
| Live window, held by the caller | Allowed |
| Live window, held by someone else | 409 |
| Caller’s own window, lapsed | 409, re-claim to resolve |
| Someone else’s window, lapsed | Allowed |
The guarantee
The rule applies to every principal, superadmins included: a claim is a work lock, not an authorization scope. It is checked again inside the guarded resolve statement, so a lock that lapses mid-request cannot land a stale resolution. Claiming a row already held by someone else answers 409. See Faceted routing.
Related patterns
Resolving from anywhere
An expired claim is recovery
When a holder walks away, the window lapses and the row is claimable again with no job, no status change and no lost input.
The queue as a market
Availability is a query
A row is held only while its claim window is live. Availability is computed at read time, so no job has to flip a flag back.
Resolving from anywhere
System ingress ignores claims
A person's claim blocks other people resolving by id, while webhooks resolving by signal key or domain key act for the process regardless.
The escalation boundary
Born-assigned hand-off
The next row is created already assigned to a named person, in the same write that creates it. It lands in their list with no claim step.