One source. Several interfaces. The same meaning.

Consider a simple product question

Imagine a fictional service with a plan priced at $49 per month, available in two markets, with a stated effective date. The pricing page displays it. An API returns it. An assistant uses it to answer a buyer’s question.

If each consumer independently decides which price, market or date applies, the brand now has several interpretations of one offer. A polished interface cannot resolve that disagreement.

Decide upstream; present at the interface

A clearer design resolves the applicable information once, then gives each consumer the same defined result. The page can explain it, the API can structure it, and the assistant can use it within its permitted scope.

This does not mean every surface has identical wording. It means the amount, currency, applicability and effective date remain attached to the answer. Presentation changes; the underlying decision does not.

Make failure a designed state

Now suppose the source cannot be refreshed. The system needs an explicit rule for whether the existing information remains usable, needs a date label, or must be withheld. Leaving that choice to whichever consumer happens to render first creates inconsistent experiences.

These are the kinds of boundaries I explore through my independent publishing and interface work: what the source establishes, what a consumer may use, and how to check the result people actually receive.

1. Define the source, applicable audience and meaning of each field.
2. Separate source freshness from connection health.
3. Test the same example across consumers, including missing and outdated information.
4. Check the delivered response as well as the implementation.