Confirm the Business Outcome

Everything in this guide so far is machinery. The map, the contracts, the states, the taxonomy, the reconciliation, the alerts. All of it exists to keep the machinery honest, and none of it tells you whether the business result occurred.

The first guide in this pillar wrote that result down: a qualified inbound request results in a booked conversation with the right seller, or a recorded reason why not. This chapter asks the closing question. Across the systems on your map, can you count how many reached that result?

If the answer is no, everything upstream is a very well-instrumented machine of unknown value.

Two things make it answerable. The outcome has to be recorded in a system on the map, by something on the map, and not in a person's inbox. And the recording has to survive the crossing: if the conversation is booked in a calendar tool that is not on your map, then the outcome is not confirmable and the map has a hole in it.

The build order

The last thing this guide teaches, and it goes here because readers consistently do it in exactly the reverse order.

First, write the contract, the ownership rules, and the read and write boundaries, before any interface exists. Second, build a minimal end-to-end slice with no external dependency, to prove the shape works before anything can fail for reasons outside your control. Third, add asynchronous execution, the state lifecycle, retries, and audit. Fourth, add the external adapters, behind mocks. Then the interface, then admin controls, then observability, then reconciliation and backfill.

The reverse order is: build the interface because it demos well, wire it to the live external system because mocks feel like extra work, and discover the state lifecycle by having incidents. That path works, and it costs roughly one rebuild.