Art2link ESB can validate a message in two different places, and the difference is the whole pattern.

The first is a schema bound to the message type. It is easy to configure and strict by nature: if the payload does not conform, the message is marked errored and never reaches its subscribers. Full stop. Your only downstream control is port exception handling. This is the right tool when any deviation genuinely is an error, and it is exactly what turns partner drift into an outage.

The second is validation performed inside a pipeline component in the receive pipeline. Here the outcome is yours to decide. The component inspects the payload, judges whether the deviation is tolerable, and chooses what happens next: let the message continue, fail it deliberately, and, in the tolerable case, publish a second message that reports the deviation. Flexible validation lives entirely in this second place. The strict schema is not the mechanism, it is the thing you deliberately do not bind when you want this behaviour.

“Different but it still works” is not a judgement to make by eye. The classification is the heart of the pattern, because in positional and delimited formats such as X12 and HL7 some deviations are harmless and others silently corrupt every field after them. The component’s job is to tell them apart.

Concretely, in an X12 850 the difference is visible in one segment. Take a baseline line-item your map reads as quantity, unit, and price:

PO1*1*10*EA*12.50**VN*ABC123~

Safe. A partner starts populating a trailing product-id pair the standard has always defined but never sent. The added *UP*0079123456 sits past the last element your map touches, so it is simply not parsed and nothing you read changes:

PO1*1*10*EA*12.50**VN*ABC123*UP*0079123456~

Unsafe. Now the partner slips a packaging code into the third position. Every element after it shifts one place, so the price your map expects in the fourth position now reads EA and the quantity-to-price mapping is quietly wrong:

PO1*1*10*CA*EA*12.50**VN*ABC123~

That second one parses cleanly, and it must still fail because it parses. HL7 v2 has the same trap when components are reordered: a patient name that was family^given arriving with the two swapped is a different person on paper, with no error to catch. Baseline, then the corrupting reorder in PID-5:

PID|1||12345^^^HOSP^MR||DOE^JOHN||19800101|M
PID|1||12345^^^HOSP^MR||JOHN^DOE||19800101|M

By contrast, an HL7 partner populating a trailing field that was previously empty, an address in PID-11 the feed never carried before, is the safe, additive case again: the fields ahead of it keep their meaning.

Only the additive, trailing cases are ever accepted. They are provably safe because they cannot move an existing field. Everything that could shift or reinterpret data still fails, and it fails loudly, exactly as a strict schema would. The dangerous cases are listed here not because the pattern handles them leniently, but so the boundary is explicit: accepting an insertion because it happened to parse is precisely the trap this pattern is designed to avoid.

The work lives in a custom pipeline component on the receive pipeline. It compares the incoming instance against the agreed baseline and classifies the deviation. A structural deviation is failed on the spot and carried out to a dead-letter channel for inspection, no different from a strict rejection. A tolerable deviation takes the two-message path: the component lets the original message continue, classified with its normal message type so subscribers pick it up as usual, and it also publishes a second message, a deviation report, onto the bus.

Publishing a companion message from a receive-pipeline component is the same capability the multi-type splitter uses to emit differently-typed messages from one arrival. Here the second message is the out-of-band copy of a wire tap: the primary message flows untouched, and a tap carries a description of what deviated to whoever needs to see it. Keeping the report on the bus, rather than having the component send an email itself, is what keeps this clean. Components classify and publish; they do not deliver. A subscription routes the report onward.

The report is an ordinary message type, say DeviationReport, carrying enough to act on: the partner, the transaction type, what deviated, the offending fragment, the classification, and whether it was accepted or failed. For the accepted 850 above, its body might read:

{
  "report": "DeviationReport",
  "detectedAt": "2026-07-20T14:32:05Z",
  "partner": "ACME-FOODS",
  "transaction": { "standard": "EDI 850", "messageType": "PurchaseOrder", "controlNumber": "0001023" },
  "deviation": {
    "classification": "additive-trailing",
    "verdict": "accepted",
    "segment": "PO1",
    "expected": "PO101-PO107",
    "found": "trailing pair at PO108-PO109 (*UP*0079123456)",
    "fragment": "PO1*1*10*EA*12.50**VN*ABC123*UP*0079123456~"
  },
  "action": "Order published as normal. Confirm with partner whether the UPC pair is now standing, and decide whether PO108-PO109 should be mapped."
}

A structural deviation produces the same shape with verdict set to failed and the classification naming the shift, so the notification tells the team both what changed and what the pipeline did about it. From there nothing is special. A subscription picks the report up and a send port delivers it, an email to the integration team, an activity notification, or both:

{{Message.MessageType}} == "DeviationReport"

Flexible validation is opt-in and targeted, not a default on every port. Turn it on where a partner or a flow has a demonstrated history of drift, and leave strict validation everywhere else. Accepting a deviation is, in effect, a change to the trading-partner agreement made by software, so the default should be strict, and tolerance a decision you make with eyes open. The report-and-decide loop is what makes that decision a human one.

It may look as though this softens fail loud, never drop. It does not, and it is worth being precise about why. Nothing is dropped: a tolerable deviation is accepted and made loud through the report message, and an unsafe deviation still fails exactly as before. This is an application of the rule, not an exception to it, silence is the thing the rule forbids, and this pattern never chooses silence.

The deeper reason it is worth naming as a pattern is economic. Tolerant-reader-with-alerting used to be too expensive to build per integration, so teams either hardened every flow with a heavy canonical model or simply ate the failures. When a pipeline component costs minutes to build, you can instrument exactly the partner, transaction, and scenario where the risk is known, and nowhere else. That shifts integration design from defensive-and-generic to observable-and-specific, and it is a big part of what cheap, purpose-built components change about how integrations are architected.