A vendor master is rarely one simple record

Expose the competing constraints

Separate supplier identity, onboarding, payment, risk, regional, and partner context so each consumer sees an explicit, qualified contract. Vendor context spans identity, onboarding, commercial, payment, risk, and regional records. Different systems may remain authoritative for different parts of that contract. For A vendor master is rarely one simple record, the first useful artifact is a bounded statement of the consumer outcome, the current dependency, and the decision owned by enterprise architect.

What must be explicit

Start with the two inputs shown in the decision aid: Focus: vendor data and Audience: enterprise architect. Then identify the system that remains authoritative, the consumer that relies on the result, and the exception that would make the design unsafe or misleading.

The expected scope output is A bounded problem and named owner. That output is specific enough for an owner to accept or reject. It also prevents vendor data from becoming a label for unrelated work.

Test where the boundary should sit

Vendor context spans identity, onboarding, commercial, payment, risk, and regional records. Different systems may remain authoritative for different parts of that contract. Data quality becomes actionable when a consumer can see ownership, freshness, provenance, conflict policy, and known gaps. A copied record with no qualification often moves the uncertainty rather than resolving it. The boundary for this review is business API accelerators, with data quality treated as the change under evaluation.

Review point	What to record for vendor data
Consumer promise	The fields, operation, freshness, and failure behavior the consumer can rely on
Source authority	The system responsible for each material value or action
Qualification	The limits, provenance, policy, and exceptions that must remain visible
Change control	The owner, version rule, test evidence, and consumer notification path

A diagram is useful only when it makes these decisions inspectable. For A vendor master is rarely one simple record, reviewers should be able to follow a request from the consumer boundary to each dependency and back to the qualified result.

Keep exceptions visible

The design is incomplete until a team owns access, change, failures, review evidence, and retirement. The 360 contracts are starting points, not a fixed catalog or one universal endpoint. Each implementation must reflect the customer's sources, semantics, consumers, and policy. Assign the operating decision to data leader and use stable as the review condition captured in the article scenario.

In the review for A vendor master is rarely one simple record, the tradeoff record should name access ownership, monitoring evidence, failure handling, and the retirement path. If one team owns the consumer contract while another owns a source dependency, the handoff and escalation path need to be written down. This matters most when the decision spans more than one system or consumer.

Questions for the design review

• Which consumer outcome makes vendor data worth standardizing or governing?

• What material source difference would be hidden by the proposed business API accelerators boundary?

• Which evidence lets data leader distinguish a contract failure from a source failure?

• When data quality changes again, which consumers should remain insulated and which must be notified?

• What condition would cause the team to reject this approach and choose a narrower design?

For A vendor master is rarely one simple record, a useful review can end with a qualified no. The aim is to make the decision, dependency, and ownership clear enough that another team can understand what was chosen and why.