Review an artifact change from both producer and consumer sides

An artifact can satisfy its producer's new format while breaking the assumptions of someone who reads it. Discuss both sides before changing an output contract. This fictional practice exercise uses an invented status report and two consumer versions. The compatibility record belongs in an existing project document; no Kiguri export, integration, or deployment capability is implied.

Define each side before proposing the change

The old producer writes status as pending or complete. The proposed producer replaces pending with needs_review and keeps complete. Both producer versions intend the first value to mean unfinished review.

The old consumer has a faulty but explicit rule: pending means unfinished, and every other value means finished. The proposed consumer explicitly recognizes pending and needs_review as unfinished, complete as finished, and any unknown value as unresolved. Record those interpretations rather than assuming consumers understand a renamed word. Include required fields and any relevant missing-value rule. Compatibility depends on observed or agreed consumer behavior, not on how reasonable a label sounds.

Work through the version pairings

Use synthetic reports and write one record for each pairing, with producer version, consumer version, supplied value, interpreted meaning, and finding. Old producer with old consumer reads pending as unfinished and complete as finished. That pairing behaves as intended for the two specified values.

New producer with old consumer reads needs_review as finished. The new report can be structurally valid while its meaning is wrong for this consumer. Old producer with new consumer reads pending correctly. New producer with new consumer also reads needs_review correctly. Together these four pairings form a small compatibility matrix even when written as four prose entries rather than a table.

Do not collapse the result into the new format works. One important pairing demonstrably fails the fictional contract.

Separate acceptance from interpretation

A consumer may accept a file without preserving its intended meaning. In this example, the dangerous pairing does not reject the new label; it confidently classifies unfinished work as finished. That makes a successful open operation inadequate as a compatibility check.

Add a synthetic unknown value, paused, to inspect the limits. The proposed consumer leaves it unresolved under its explicit rule. The old consumer incorrectly calls it finished. Keep this finding attached to the consumer assumption. Do not generalize from the exercise to real software whose handling of unknown values has not been inspected.

Agree a conditional transition path

The responsible owners might choose to retain pending until the affected consumer recognizes both labels, then introduce needs_review. Alternatively, they might keep the original value and change only its human explanation. State the conditions and who must confirm them. Updating the producer first is not safe merely because the new producer passed its own field checks.

Identify consumers the group has not examined. A reviewed pairing cannot establish compatibility for an unknown reader or a differently configured version. Keep that uncertainty visible, and route any actual rollout through the established approval process. A conversation about a contract does not authorize changing an interface.

Recheck the pairing that originally failed

Repeat the new-producer and previously old-consumer case after its proposed rule is clarified or revised in the fictional model. Confirm that needs_review remains unfinished and that unknown values do not become completed work by default. Preserve the version assumptions beside the result. The useful artifact is a traceable pairing record and a conditional change plan, with failures and unchecked consumers still visible.