An API Cannot Tell You Who Has Influence

Two Order Management features call the same Payments endpoint. They use the same schema, service credential, and provider-managed release process.

The first feature needs a reversal_reason. Orders raises the request, Payments accepts it into quarterly planning, and a Payments owner commits to a compatibility window.

The second feature asks for another Orders-specific field. Payments declines it as outside the product roadmap. Orders decides that the generic refund status is adequate for its support view and accepts the cost of adapting when the provider contract changes.

The integrations can produce nearly identical code. Their organizational relationships are different.

Before naming either relationship, ask a question the API cannot answer:

What can the downstream cause the upstream to plan differently for this interaction?

That question separates a Customer/Supplier relationship from Conformist. A second decision—whether the integration is worth its dependency—opens Separate Ways. None of these labels can be read from an arrow.

Customer influence appears in planning

The synthetic first case is Customer/Supplier because an Orders priority enters Payments planning and produces an inspectable upstream commitment. Orders does not control the Payments roadmap, and every request need not win. The defining evidence is narrower: downstream priorities factor into upstream planning for this interaction.

That is the distinction in Eric Evans’s DDD Reference. Context Mapper’s Customer/Supplier reference makes the same point and warns that a generic upstream/downstream relationship is not automatically Customer/Supplier.

An open ticket does not establish that relationship. Neither does an account manager’s acknowledgement, an invitation to a planning meeting, or a contract test maintained by the consumer. Those artifacts may help coordination, but none proves that the upstream planned differently.

The useful evidence is a decision trail:

Orders request
    ↓
Payments planning decision
    ↓
named Payments owner
    ↓
delivery or compatibility commitment

The commitment should have limits. “We support this field in v1 until the recorded migration date” says more than “Payments listens to Orders.” It also makes the reversal visible: if Orders priorities stop entering planning or the compatibility commitment disappears, the current label needs review.

Calling Orders a customer because it sends HTTP requests confuses transport direction with planning influence. A client can be completely powerless over the server it calls.

Conformist is a deliberate downstream choice

The synthetic second case uses the same API mechanics, but Orders has no negotiated planning influence. Payments owns the roadmap and releases the generic contract unilaterally. That fact alone does not make Orders a Conformist.

Conformist also requires a downstream decision: the upstream model is adequate for the downstream’s current purpose, and the downstream accepts the cost of adopting it. In the example, a generic refund status is enough for a read-only support view. Orders chooses not to introduce a translation model for a distinction it does not need.

That can be the honest design. A local type which repeats the provider’s language would add mapping work without protecting a different decision.

The choice stops being credible when the upstream model distorts downstream policy. If Payments adds reversed but Orders cannot decide whether reversal reopens an order, creates debt, or requires manual recovery, adopting the provider enum is no longer harmless conformity. The downstream needs an explicit translation decision, such as the anti-corruption layer described in the previous article.

This yields a stricter test than “the downstream has no influence”:

No planning influence
        +
Upstream model is adequate here
        +
Downstream accepts adaptation cost
        =
Credible Conformist relationship

If model adequacy is unknown, the relationship is unknown. If adequacy is contradicted, Conformist is the wrong label. Context Mapper’s Conformist reference places the role on the downstream and explicitly rejects combining it with Customer/Supplier.

Separate Ways is a value decision, not a failure

Suppose Product proposes a customer-facing lookup for refund reversals. Customer Operations reviews the expected outcome and decides that it does not currently justify a new runtime and on-call dependency. The accepted alternative is manual escalation to Finance.

That synthetic case is Separate Ways because a named business owner has accepted the consequence of not integrating. The decision is not that the API is awkward. It is that the present value does not pay for the coordination and operational coupling.

This distinction rules out several convenient mislabels:

• Payments denied access, so Orders gave up.
• The endpoint is temporarily unavailable.
• Nobody has capacity this quarter.
• Ownership remains disputed.
• The integration sits indefinitely in a backlog.

Those are constraints or unresolved decisions. Calling them Separate Ways turns neglect into architecture.

The non-integrated path still has dependencies. Customer Operations relies on a manual Finance escalation, with its own response time, ownership, and failure modes. “No API call” does not mean “no relationship.” The decision avoids runtime, data-copy, release, and shared on-call coupling while retaining human coordination.

A reversal condition keeps the choice honest. A compliance requirement, material workload increase, or owned self-service outcome could justify the dependency later. Until that evidence appears, Separate Ways remains a current business decision rather than a permanent judgment about either team.

Unknown is better than an attractive fiction

Real evidence often conflicts. Orders may say its priorities enter Payments planning while Payments says it only accepts requests through the normal product queue. A diagram cannot resolve that disagreement.

Do not choose the label which makes the relationship sound healthier. Record it as unclassified and ask for the missing evidence:

Did the Orders priority enter Payments planning?
Who owned the upstream decision?
What commitment, refusal, or value decision followed?

The evidence request needs an owner too. Otherwise “unknown” becomes another permanent label. In the reproduction, Order Architecture owns the request for the next planning record and named Payments decision owner.

A generic upstream/downstream relationship can also be accurate when the direction of model influence is known but the organizational contract is not. Specific terminology is useful only when the evidence supports the added meaning.

Classify the interaction, not the teams

One pair of teams can have several relationships at once. Orders may influence Payments planning for a committed cancellation contract, conform to a generic reporting API, and deliberately avoid a proposed reversal lookup.

“Orders is a Payments customer” is therefore too broad. Record the interaction, current state, observation date, evidence, and accepted dependencies:

These are as-is labels. A desired planning agreement belongs in a proposal, not in the current context map. Otherwise the map hides the very power problem it is supposed to expose.

Operational ownership belongs beside the label. Customer/Supplier accepts runtime and compatibility dependency backed by a negotiated commitment. Conformist accepts runtime dependency and unilateral provider change. Separate Ways avoids those dependencies but retains the cost of its manual workflow. The relationship name is shorthand for that decision, not a substitute for it.

The fixture tries to lie in sixteen ways

The companion synthetic reproduction keeps the API identical for the Customer/Supplier and Conformist controls. Four cases contain 17 observations with explicit dispositions, decision owners, dependency inventories, rule traces, and reversal conditions. No numeric score chooses a label; a missing defining condition fails the classification.

Sixteen isolated counterfactuals try to infer influence from HTTP, a ticket, a meeting, or a contract test; accept unilateral planning as Customer/Supplier; call an inadequate model Conformist; turn denied access or an outage into Separate Ways; erase an owner or reversal condition; apply a global team label; add a weighted score; orphan evidence; and resolve contradictory accounts with the more attractive answer. All sixteen fail.

The evidence reproduces from archived commit 3018557f549de3c3ddcfed22d0b2f3ee8987b5c1. That proves the rules classify the recorded synthetic cases consistently. It does not prove how a real planning meeting worked, whether a dependency is worthwhile, or which person had influence. Those claims still require organizational evidence.

The next time a context map says Customer/Supplier, Conformist, or Separate Ways, leave the arrow alone for a moment. Find the planning decision, the model decision, or the business-value decision behind it. If none exists, the honest label is not hidden in the API. It is still unknown.