Integrity
Throttles and breakers sit outside the track record. A Pool can cap claims a day and open holds, and pause offers to a member whose declines or late releases run past a share. A pause is never scored, and a refusal never is.
How does a Pool keep one member from hoarding work or churning through it, without punishing a member for saying no?
A track record is outcomes only. Limits are a separate brake, and they never write to it:
| Limit | What it does | What it never does |
|---|---|---|
claims: '<n>/day' | stops a member's claims for the day once they reach it | count against their tier |
open: <n> | stops new claims while they hold that many Tasks | release a Task they already hold |
declines: '<pct>' | pauses offers to a member whose declines pass that share of their recent Tasks, until the owner lifts it | touch the track record, take back pay, or refuse a Task they hold |
late_releases: '<pct>' | in a work register, pauses offers to a member who gives back that share of their claimed windows after notice | count a release before notice, a client's cancel or a moved window |
A decline stays paid and the client's to direct. What a limit does is slow offers, never judge the work. The member reads which limit paused them, and when it lifts.
A member who declines is exercising the judgment the step is there for. Scoring it would teach members to sign what they shouldn't. So a decline is paid like an attestation, never scored, and only a pattern past the Pool's own declines share pauses offers, as a signal for the owner to read, with the member told why.
| Key | Written | Left out | Does |
|---|---|---|---|
limits | { claims?: '${number}/day'; open?: number; declines?: Pct; late_releases?: Pct } | none | Throttles and breakers, kept outside the track record. |