A 200 is not a business fact

A four-day production run of a customer-acquisition flow produced 397 journeys, 287 invitations, 158 people who joined a group, and 145 who were still in it days later. Each of those numbers is a different fact, recorded by a different part of the system. A team holding all four can operate the flow. A team holding one number cannot even describe a failure, because every failure looks the same: the call returned.

Four facts, four places to write them

Fact	What it shows	Where it lands	Owner	Failure looks like
Request sent	Your code ran and intended an action	Outbound log with request id and time	Your service	Retry storms, duplicate sends
Platform accepted	An external system acknowledged	Platform response id and status	Integration layer	Accepted, never executed
User completed	The person actually did the thing	Member event or task record	Business owner	Accepted invitations that never became joins
Still retained	It held after time passed	Daily membership snapshot	Business owner and analyst	Joins that decay without anyone noticing

The gap between the second and third fact is usually the largest and the least visible. In the run above, 287 invitations were issued, the platform accepted 228, and 59 were never actually sent because the friend relationship had expired — with no automatic retry. "Accepted" and "sent" were living in the same cell of the same dashboard. That cell was wrong for 59 people, and no error was ever raised.

A timeout is not a negative result

Inviting a person into a group is a non-idempotent side effect. If the request times out or the process exits non-zero, the invitation may already have happened. Retrying blindly produces duplicates or gets the account restricted; not retrying strands the customer. The honest third state is awaiting result: write the intent, then resolve it by reading back member events and a group snapshot.

Three rules follow, and all three are cheap to adopt before the first incident:

1. Write the intent before the call, not after it succeeds. A record written on success cannot describe a failure.
2. Resolve by observation, not by return code. The return code tells you what the platform said, not what happened.
3. Make reconciliation part of the write path, not an analytics job that runs on a different schedule.

The expensive mistake is a mitigation built on the wrong counter. One version auto-paused accounts after repeated retries. The counter measured retry attempts, not distinct customers, so a single stuck request could pause a healthy account and widen the blast radius of the original fault. The correct fix was deleting the feature, not tuning the threshold. Before trusting any automatic brake, ask what it counts and who it punishes.

The four counters a dashboard needs

For every write path, a daily count of sent, accepted, completed, retained — plus the gap that no one has explained. An unattributed gap is an incident, not a rounding error.

Decomposition is what makes a funnel honest. Of the 110 people who never reached the invitation stage, 99 were intentional blocks (cross-system deduplication, or already in a group) and 11 were genuine qualification-query failures. Without that split, the funnel reads as a 28 percent loss, and nobody knows whether to fix code or fix policy. With it, there are exactly 11 things to investigate.

Then there is the control. In the same run, 110 people on the manual path joined at 9.1 percent with a median of 164.84 minutes, against 55.1 percent and 13.88 minutes on the automated path. The author noted that this was not a randomised test and that the control sample was ten people. That sentence is not a weakness in the write-up; it is the line between evidence and a slogan.

Speed and stability are separate facts

A brokerage observability deployment shows the same distinction at a larger scale. Market-open traffic runs at two to five times the normal load. The POC passed; production did not, failing on data-flow stability, metric delay and alert delay — three different facts, three different fixes. The team shipped three versions in two weeks, each with an explicit baseline tied to a different underlying problem, and gave the customer a headroom argument for twenty times the load. The platform accepting requests during the POC never testified about 9:30 in the morning.

The check to run on the next integration

For each write path, fill four lines: fact, storage location, owner, and failure signature. If two facts share one cell — typically a single "success" — you have one fact and one hope.

Then add the sentence that keeps the rest honest: name one thing that would still be a failure even if the API returned 200. If nobody on the team can answer without checking, the metric table is probably counting requests while the business is counting people. And when a gap does appear, the escalation path has to be able to say which of the four facts is missing, not simply that something "failed" — the same discipline applies to the data itself, which is why the write path belongs inside the security boundary discussion rather than after it.