The mapping decision missing from the diagram

Four boxes can conceal a large assumption

File, parse, import, done is an attractive diagram until the supplier code matches two catalogue items. Where does that row go? If there is no branch for it, the developer, operator and reviewer must each supply a missing rule. Under the contract here, importing has to wait for the ambiguity to be resolved. The drawing needs to explain that decision rather than simply arrange the intended verbs in a straight line.

A simple overview can be useful without showing every implementation detail. The trouble starts when its straight line makes the difficult conditions appear unnecessary. One reader may choose the first match, another may retry, and a third may assume validation happened somewhere outside the picture. Giving the unresolved row a truthful destination prevents those three plausible interpretations from becoming three different implementations of the same drawing.

The original example here uses four synthetic rows and a deliberately incomplete happy-path line. A corrected downloadable diagram includes the actual mapping gates, with a complete visible text equivalent and a small executable branch model. The purpose is to make one business decision inspectable, rather than draw the entire integration’s infrastructure in a more decorative arrangement.

Decide what one arrow means

For this contract, the input is one row with a supplier code. A missing code must be held as missing. A present code is looked up against the catalogue mapping. Zero exact matches means hold as unmapped; one match makes the row eligible for remaining validation; more than one means hold as ambiguous. Neither an empty field nor an ambiguous result authorises choosing a catalogue item.

An arrow needs a defined relationship: here, the next permitted step under a stated condition. A network connection, copied data and completed business action would each mean something different. Using one arrow for all of them can make a drawing appear complete while leaving its decisions unclear. For this mapping gate, label the code-presence and match-count conditions before adding the downstream infrastructure.

“Eligible for remaining validation” is a less satisfying endpoint than “Done”, but it describes what this gate has actually decided. Finding one catalogue match does not validate every other field or perform the import. Let the picture stop at that intermediate result and point towards the next process. A modest endpoint gives the next reader a firmer handoff than borrowing completion from work the diagram has not yet explained.

For missing, unmapped and ambiguous rows, the held states should remain distinct in the application model. They need different resolutions: supply the code, create an approved mapping or resolve competing mappings. A single error box may be enough for a high-level overview, but a recovery diagram should retain the difference. Otherwise a retry instruction can repeat an unchanged ambiguity while appearing to follow the process.

Walk real-shaped specimens through the drawing

The ambiguous row, R17, contains supplier code S17 and finds two catalogue items, C11 and C12. The lookup succeeded; the mapping decision did not. Choosing the first result would make the import depend on list order: reverse the candidates and the selected item changes without any better evidence. The other rows isolate different questions. R18 has code S18 and one match, C18, so it can continue validation. R19 lacks a code and must not start a lookup. R20 supplies S20 but finds no match. Holding each unresolved row for its particular reason preserves the decision the straight line left out.

The downloadable branch model gives each of those inputs a route without calling a supplier API or executing an import. Change the candidate count for R17 and follow the destination in the rule and diagram together. Moving from two matches to one should change eligibility for validation; it should not skip the remaining checks and declare the row imported. That distinction is easy to lose when a drawing uses done for every successful intermediate step. Keep its endpoint aligned with the actual decision the gate makes.

Walking the four rows through the original line shows where it runs out. Three reach parsing without a permitted next destination. R18 has a unique match but reaches done without its remaining validation. Different colours or box shapes would not repair either omission. The drawing needs the conditions that separate these cases and endings that describe the work actually completed at each branch.

A counterexample can improve the picture further. If a supplier code intentionally supports several target items under a defined allocation rule, “more than one means ambiguous” would be the wrong contract. The diagram should then show the allocation rule and its prerequisites. A clear drawing does not make a business rule correct; it makes the rule visible enough that somebody can challenge it before implementation.

Make the equivalent text carry the same reasoning

W3C’s complex-image guidance explains that substantial visual information needs a short identifying description and a fuller text representation of the essential information. [1] For this diagram, “supplier import process” is too little. The useful equivalent names the missing-code gate, the exact match-count branches and the meaning of the eligible state. A reader should be able to route R17 without seeing the arrows.

The HTML resource places those rules as an ordinary ordered list below its SVG, then provides the four input/result cases in a table. The text is visible to everyone. It also gives a narrow-screen reader another route through the information when small diagram labels are inconvenient. This is an authored accessibility provision, not a claim that every browser or assistive-technology combination was exercised.

W3C’s alternative-text decision tree makes purpose important: an image carrying complex information needs that information available, while a purely decorative image has another treatment. [2] Do not mark this diagram decorative merely because the surrounding page already looks explanatory. Check whether the prose actually contains its conditions and outcomes. A short caption announcing that a workflow is simple does not reproduce the rule.

Meaning should not depend only on colour or position. Label the branches with missing, zero, one and more than one; label the held states in words. A reader following the paths should not need to remember that a particular shade meant uncertainty on an earlier figure. Styling can reinforce the relationships once the relationships are stated, rather than supply a private legend the person must decode.

Use less drawing when it explains more

A process diagram and a decision table offer different strengths. The drawing can show the order of checks; the table can make conditions and outcomes easier to compare. Here, the table immediately exposes that missing code and zero matches are not the same state. Keeping both is useful because they answer different reading questions, not because an article needs another image to interrupt the text.

Choose the picture for the decision its reader has to make. Procurement may need to know that unresolved mappings are held. An implementer needs the exact branches, while an operator needs the authorised way to resolve each held state. One enormous architecture picture can make all three readers search harder for those answers. A smaller drawing with its rule and examples beside it often leaves less to guess, even though it contains less of the infrastructure.

Keep the picture and the rule under review together. If the implementation starts permitting a new mapping state, update the examples and text equivalent as well as the arrows. A beautifully exported image can outlive the contract it once described, especially when its source is separated from the documentation. Retain an editable source or a small rule fixture so another person can make an accurate change without redrawing it from memory.

R17 can now stop without an arbitrary choice between C11 and C12. R19 needs a code; R20 needs a mapping; R18 still needs the rest of validation. Keep those distinctions in the text equivalent as well as the arrows, so another reader can challenge or apply the rule without seeing the image. Each branch tells the next person whether to supply a code, approve a mapping, resolve competing matches or continue validation.