When an output requirement changes the wrong part of the product

A developer’s question brought us back to a decision about two optional reference fields.

The fields held internal seller and buyer identifiers. They belonged to our shared data model, but a country-specific configuration had removed them from the accepted input schema because they weren’t needed in the external submission.

I had expected optional fields in the shared model to remain available across countries. Reviewing the decision showed why that expectation no longer held: a rule about the output had also changed what the product could accept.

The identifiers still had a purpose inside the platform. They could connect incoming data to internal records, even though the external recipient had no use for them. Removing them from the input schema prevented integrations from supplying those references through those fields.

That was the distinction we needed to resolve. Excluding a value from one submission did not, by itself, justify excluding it from the product.

The revised decision was to keep the identifiers optional at input and require their preservation through mapping, storage, and responses. They would continue to be omitted from the external submission. Nothing about that output needed to change.

There was another possibility behind the discussion: using these references in a future workflow that could create catalogue entries automatically. I wanted to preserve room for that idea, but accepting an identifier did not settle how automatic creation should work. That needed its own product decision.

I asked for the revised position to be recorded in the canonical documentation, with the earlier rationale retained so we could trace the change. The record was updated with a dated amendment explaining which part of the original decision was superseded.

The documented outcome was a clearer requirement for implementation. This account stops there; it does not establish that the change was deployed or that the proposed catalogue workflow was built.

The question I would now ask before removing a field is straightforward: who uses this value elsewhere in the product? The external submission answers only part of that question.