noCV
ACDC-101 · Specify the change contract

Define the preference change envelope with source position

Practice briefTaskFoundational

The consumer sees a timestamp and payload but cannot distinguish two changes committed in the same millisecond.

Focused work estimate
1h 30m + prerequisites
Priority in the scenario
Medium
Engineering practice
Data contracts · Ordering

Estimated field mix

  • Data engineering60%
  • API design20%
  • Distributed systems20%

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 messaging service builds a read model from database changes. Restarts and schema changes can re-enable preferences that customers disabled.

Setup prerequisites

  • Create synthetic preference records and a replayable local change log.
  • Use adapters or fixtures without provisioning a production broker.

Preceding work

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

Acceptance criteria

  • Include stable source position, record identity and operation.
  • Separate source commit time from consumer receipt time.
  • Validate the envelope version before applying changes.

Implementation constraints

  • Use fabricated positions from a deterministic local log.

Verification to include

  • Parse two same-time changes with distinct positions.
  • Reject an unknown envelope version without moving the checkpoint.

Deliverables

  • Change envelope schema

Rollout and recovery

Publish the contract before consumer rollout; quarantine unsupported versions.

Value of the work

For the engineer: Practice change-feed ordering, snapshots and privacy-preserving deletion.

For the team: Review whether replicated customer preferences remain correct during 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.