noCV
ACLAIM-101 · Define assignment invariants

Define assignment states and their required database fields

Practice briefTaskFoundational

Rows marked assigned sometimes have no assignee or lease deadline, making recovery ambiguous.

Focused work estimate
1h 30m + prerequisites
Priority in the scenario
Medium
Engineering practice
Data modeling · Check constraints

Estimated field mix

  • Database engineering80%
  • Backend20%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional inspection service assigns review jobs to staff. Polling clients sometimes claim the same job and a disconnected client can finish work after reassignment.

Setup prerequisites

  • Create synthetic jobs and two independent database clients.
  • Use explicit state methods and an injected clock.

Preceding work

No earlier ticket is required. Complete the project setup above.

Acceptance criteria

  • Specify pending, assigned and terminal field invariants.
  • Add checks that reject contradictory state combinations.
  • Keep completion metadata distinct from lease metadata.

Implementation constraints

  • Use migration-backed constraints where practical.

Verification to include

  • Insert each valid synthetic state.
  • Attempt assigned without an assignee or deadline and verify rejection.

Deliverables

  • Assignment schema and constraint matrix

Rollout and recovery

Apply constraints after inspecting synthetic legacy rows; quarantine invalid states before enabling writes.

Value of the work

For the engineer: Practice database concurrency, leases and transactional invariants.

For the team: Review whether assignment authority remains reliable during contention and recovery.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.