Integration contracts are implicit
Systems depend on each other through assumptions that are not clearly documented, versioned, or enforced.
- Where you see this
service integrationsbatch exchangesevent-driven systemsfrontend-backend boundaries
- Not necessarily a problem when
- a short-lived internal prototype is intentionally informal and low-risk
- Often mistaken for
- it works now, so the contract is effectively clear
- Time horizon
- near-to-medium-term
- Best placed to act
producer ownerAPI/event governance owner
The signal
What you would actually notice
Implicit contracts break silently, make upgrades risky, and create expensive coordination failures.
Field observation
Consumers and producers rely on behavior that is assumed, inferred, or learned through incidents rather than explicit agreements.
Also observed
- Do not change that field, another team might rely on it.
- We never documented that, but yes, consumers expect it.
Primary reading
What it usually indicates
Most likely underlying patterns when this signal shows up. Not a diagnosis, a starting hypothesis.
Usually indicates
Most likely underlying patterns when this signal shows up.
- weak API or event governance
- hidden dependency on implementation details
- poor ownership of integration surfaces
Stakes
Why it matters
Implicit contracts break silently, make upgrades risky, and create expensive coordination failures.
Inspection
What to check next
Deliberate steps to confirm or disconfirm the primary reading above. Not a checklist. An order of inspection.
- API specs
- contract tests
- consumer dependency inventory
- incident history
Diagnostic questions
Questions to ask the team, or yourself, before concluding anything.
- What exactly is guaranteed here?
- Which behaviors are consumers relying on informally?
- How would a new team know the contract?
Progression
Under the signal
Where this pattern tends to come from, what's holding it up, and where it goes if nothing changes.
Leading indicators
What tends to show up first.
- breaking changes are found late
- consumer teams discover assumptions through production behavior
- versioning is ad hoc
Common root causes
What is usually sitting under the signal.
- fast-moving teams
- missing producer-consumer governance
- weak documentation and versioning
Likely consequences
What happens if nothing changes.
- fragile integrations
- late-stage failures
- coordination churn
Look-alikes
Not what it looks like
Patterns that can be mistaken for this signal, and 'fix' attempts that make it worse.
- it works now, so the contract is effectively clear
Anti-patterns when responding
Responses that feel sensible and usually make the underlying pattern worse.
- calling it internal so it does not need a contract
- assuming tests in one repo prove a contract across repos
Context
Context and ownership
Where this signal surfaces, who sees it first, who can actually act, and how much runway there usually is before escalation.
Where it shows up
- service integrations
- batch exchanges
- event-driven systems
- frontend-backend boundaries
Who sees it first
Before it escalates.
- integration teams
- consumers
- support during breakages
Who can move on it
Not always the same as who notices it.
- producer owner
- API/event governance owner
near-to-medium-term
How much runway there usually is before the signal hardens into the underlying pattern.
AI impact
AI effects on this signal
How AI-assisted and AI-driven workflows tend to amplify or hide this signal.
AI amplifies
Ways AI tooling tends to make this signal louder or more common.
- AI can generate consumers quickly against inferred contracts, increasing hidden dependence on unstated behavior.
AI masks
Ways AI tooling tends to hide this signal, so it keeps growing under the surface.
- Generated client code makes implicit contracts feel official.
Relationships
Connected signals
Related failure modes, decisions behind the signal, response playbooks, and neighboring red flags.