# enterprise-integration — encoded integration judgement

The **judgement anchor** for xMesh on an enterprise integration engagement. `camel-dryrun` grounds
whether a route *runs*; this grounds what an experienced integration architect **looks for** and
**asks next** when the work stops.

It exists because the hard part of enterprise integration is not moving data — that is engineering.
And it is not all about meaning either: meaning is the *tractable* half, because it can be formally
captured as an ontology. What actually stalls a programme is that blockers cut across the whole
organization — **no single function owns them, and none of them close alone**. An agent cannot
resolve a blocker by inspecting data; it has to know **which question to put to which owner**.

Two decades of enterprise integration (banking, government, healthcare) reduced to the operational
form an agent runs on: per blocker, the **signals** that identify it and the **questions** that
close it.

## The rules that govern every blocker

1. **Detect from the run, never from assumption.** A blocker is recorded where the work actually
   stopped — not where a model predicts one might be.
2. **Flag, don't assert, without grounding.** Where a blocker needs client policy the run does not
   have, emit `potential <blocker> — requires review` and name the field. A confidently-asserted
   regulatory finding we cannot substantiate is worse than no finding.
3. **The set below is a prior, not a limit — never force a fit.** The blockers catalogued here are
   the ones that recur; they are offered to speed recognition, not to bound it. A real run surfaces
   blockers in whatever functions the work touches, and the next engagement will hit ones nobody has
   written down. See *When it isn't one of these* below — that path is the important one.
4. **The agent proposes; the owner decides.** Nothing enters the map until its owner signs it off,
   with lineage: who said what it means, and on what evidence.

## Blockers, by the function that owns them

Recorded as `{ blocker, function, owner, what_closes_it, status, evidence_ref }`.

---
### Business

**Stakeholders** — *each party onboards separately and never aligns*
**Look for:** the work needs a decision only an owner can make and no owner is registered for that
field, domain or decision. Also: a named owner without the mandate to actually decide, and fields
whose owner has left — the most common silent blocker.
**Ask next:** Who signs off what this field *means* — not who maintains the table, who is
accountable? · If they are unavailable, who inherits that authority? · Is there a decision this
person cannot make alone, and who else must be in the room?
**Closes when:** an accountable owner is named and confirmed.

**Business process** — *each line of business defines the same term differently*
**Look for:** both sides use one term under different rules. The tell is a lifecycle or status
concept — "active customer", "closed", "completed" — each defined against its own process. It
surfaces as a *persistent, un-reconcilable disagreement between two owners about a definition*, not
as a data error.
**Ask next:** What event makes this true in your process, and what event ends it? · Is there a state
your side recognises that theirs does not — pending, suspended, in arrears? · If the definitions
stay different, which governs downstream, and who decides that?
**Closes when:** a canonical definition is agreed, or the difference is made explicit and mapped.

---
### Engineering

**Infrastructure** — *the work can't reach the system, or isn't permitted to touch it*
**Look for:** network path, credential, scope or approval missing. Directly observable — the access
attempt fails.
**Ask next:** Is this missing, too broad, or simply not approved yet? · What is the approval path,
and its realistic elapsed time? · Can a scoped read satisfy the work without the broad grant?
**Closes when:** scoped, approved access exists. *In a bank or government this is usually the
longest pole — record the elapsed time, not just the outcome.*

**Interface** — *no interface exposes the data the work needs*
**Look for:** the data exists and is reachable in principle, but nothing exposes it — no API, no
export, no supported query path. Also the partial cases that look solved and are not: an interface
that omits fields the work needs, that cannot carry the volume or frequency required, that is
batch-only where the work needs near-real-time, or that is vendor-owned and needs a change request.
**Ask next:** Is there an existing export or API that already carries these records? · If not, what
is the supported path — file export, direct read, vendor change request — and who approves it? ·
What volume and frequency does it support? · Is the contract versioned, and who owns breaking
changes?
**Closes when:** an export contract is agreed and owned.

**Delivery & idempotency** — *a retry double-posts, or a record is silently lost*
**Look for:** at-least-once transport landing on a non-idempotent endpoint; no idempotency key or
natural business key to dedupe on; retry semantics undefined; fire-and-forget acknowledgement, so
loss is invisible rather than reported. The subtle case: a *legitimate* duplicate (two genuinely
identical payments) that the target cannot distinguish from a resend.
**Ask next:** If we send the same record twice, what happens — rejected, deduped, or posted twice? ·
Is there an idempotency key, or a natural business key we can use? · How would you know today if a
record was lost in transit? · Can two identical records be legitimate, and how do you tell that from
a resend?
**Closes when:** an idempotency key and retry semantics are agreed.

**Failure handling & replay** — *a failed record has nowhere to go and no way back*
**Look for:** no dead-letter destination — failures logged and discarded; no replay path once the
cause is fixed; a poison record that blocks everything behind it; no reconciliation of what was sent
against what landed, so a shortfall is never noticed.
**Ask next:** When a record fails, where does it go and who looks at it? · Once the cause is fixed,
can it be replayed — and is replay safe, given the idempotency answer? · Who is accountable for the
failed set: source, target, or ops? · How do you reconcile sent against landed?
**Closes when:** a dead-letter destination and a replay procedure are agreed and owned.

**Consistency & ordering** — *partial failure leaves the two systems disagreeing*
**Look for:** no transaction boundary spanning the two systems, where records must land together but
cannot; no compensation defined for a half-completed exchange; out-of-order arrival where order is
semantically load-bearing (create before update, status transitions that cannot go backwards);
parallelism or partitioning that breaks per-entity ordering.
**Ask next:** Must these land together, or can they land independently? · If the second write fails
after the first succeeded, what should happen — compensate, retry, or accept the divergence? · Does
order matter for these events, and is it guaranteed per entity? · Who reconciles the two sides when
they diverge, and how often?
**Closes when:** the consistency boundary and compensation behaviour are agreed.

---
### Data

**Data preparation** — *data fails the target's rules on arrival*
**Look for:** format, nullability, range, character-set or duplicate failures, or a validity rate
materially below what the target requires.
**Grounding required:** the target's validation rules. Without them, flag for review — do not
assert a quality failure.
**Ask next:** What does the target reject outright versus accept-and-warn? · Is the source expected
to be clean at this point, or is cleansing a step we have not seen? · Who owns remediation — the
source system, or a pipeline in between?
**Closes when:** cleansing/normalization is agreed and owned.

**Mapping** — *a field's meaning has no counterpart on the other side*
**Look for:** the source and target owners cannot settle a field. Four recurring shapes: *no
counterpart* · *no crosswalk* (codes that should correspond do not — `07` vs `SUSPENDED`) · *no
reliable key* (records cannot be matched) · *no confirmed meaning* (only the owner can say what it
is). Watch for the errors that survive testing and fail in production: identifier ambiguity (is
`cust_ref` the customer, the account, or the contract?), minor units (pence vs pounds), timezone and
date-vs-datetime, money precision and rounding.
**Ask next:** Is this identifier unique, and unique across what scope? · What is the full code list,
including values you no longer issue but still hold? · Which side wins when both are populated and
disagree? · Is this field ever reused for a second purpose?
**Closes when:** both owners confirm the mapping and it is signed off.

---
### Risk & legal

**Regulatory** — *regulated fields need enrichment before they can be used*
**Look for:** the work touches regulated data — PII, special-category, records under retention —
without the required approval or control in place.
**Grounding required:** the client's regulated-field list and approval requirements. Without them,
emit `potential regulatory blocker — requires review` and name the field. Never assert a breach.
**Ask next:** Is this field classified, and by whom? · Does this use fall inside the existing lawful
basis, or is it a new purpose? · Is a DPIA or equivalent required before we proceed?
**Closes when:** the risk owner confirms the control or approval.

**Data sovereignty** — *the data can't leave its jurisdiction*
**Look for:** the work would cross a jurisdiction boundary policy forbids — including the
non-obvious paths: processing location, AI-provider region, backup and DR targets, and support
access from another region.
**Grounding required:** the client's residency and cross-border rules. Without them, flag for review.
**Ask next:** Which jurisdictions govern these records? · Does "processing" include inference by a
model hosted elsewhere? · Can the work run in-region, or must the field be restricted or
pseudonymised?
**Closes when:** legal confirms an in-region path or a restriction.

## When it isn't one of these

This is the path that matters. The catalogue above is what we have seen; the next engagement will
stop somewhere nobody wrote down. Recognising a blocker we already named is the easy case —
**finding one we did not is the most valuable thing a run produces**, because it is precisely what
no pre-built map contained. Treating the catalogue as the taxonomy would rebuild the failure this
whole approach exists to avoid: a map drawn before the work, blind to what the work actually hits.

So when a stop does not fit:

1. **Do not force it.** Never file a novel blocker under the nearest catalogued one — that hides it,
   and the hiding is the damage. A stop misfiled as "Mapping" is a lost finding.
2. **Name it plainly**, in the customer's own vocabulary, as what went wrong — not in ours.
3. **Record the same shape as any other:** what was observed (the signal), the function that owns
   it, the owner, what would close it, and the evidence reference. If the owning function is not
   one of the four above, name the new function too — the functions are illustrative, and a run can
   surface blockers owned by procurement, vendor management, audit, or a party outside the
   organization entirely.
4. **Derive the question.** The catalogue gives questions for known blockers; for a new one, ask the
   question that identifies the *owner* and the *decision* — "who is accountable for this, and what
   would have to be true for it to be resolved?" That pattern generalises to blockers we have never
   seen.
5. **Escalate it as a finding in its own right**, flagged as novel. The operator interprets it, and
   it goes in the register alongside the rest.

**A blocker that recurs earns its place.** When the same novel blocker appears across engagements,
it is promoted into the catalogue with its signals and questions — and its detection maturity
declared honestly, starting at flag-for-review. The catalogue is meant to accrete from the gaps the
work exposes, which is the same mechanism the mesh uses everywhere else: the ontology grows from
what the work actually hit, not from what someone predicted in advance.

## Grounding, and what we do not yet detect

**Observable from the run, or from putting the questions above to the owners:** Stakeholders,
Business process, Infrastructure, Interface, Delivery & idempotency, Failure handling & replay,
Consistency & ordering, Mapping — the mesh already models ownership and admission, agents already
flag what they cannot settle, and access and interface failures are direct evidence. Note the three
delivery/consistency blockers surface by **asking**, not by automated detection: an observational
engagement never writes, so it cannot observe a double-post or a lost record directly. Detect them
from the owners' answers, and mark them accordingly — never claim to have observed a failure we
did not cause.

**Requires client policy grounded into the run:** Data preparation (target validation rules),
Regulatory (regulated-field list), Data sovereignty (residency rules). Until that grounding is
supplied, flag for review and say why.

This split is published to customers as a per-blocker **detection maturity** gradient, and the
evaluation licence binds the evaluation to exactly that published state. Keep this file and the
published gradient in step — if detection improves, the page moves first, then this file.

## How an agent uses this

1. Run the real work. Stop where it stops.
2. Identify the blocker using the **look for** signals; record the function that owns it.
3. Identify the owner — the person whose knowledge covers that field or decision.
4. Put the **ask next** question to that owner (or their grounded agent), and cross-check the answer
   against the counterpart owner across the boundary.
5. Where two grounded agents disagree and cannot reconcile, do not pick a winner — record it
   unsettled, with both readings, and escalate to the owners.
6. Sign-off and lineage as per rule 4 above.

The agent proposes. The owner decides. That boundary is not a limitation of the product — it is the
claim: meaning belongs to the people who hold it.