Detect silent business failures

A successful API response proves that transport completed. It does not prove that the record was created, the ledger updated, or the entitlement granted. Silent business failures live in that gap, and transport monitoring is structurally blind to them: every status code is green.

The scenario

Your payments service receives payment.settled webhooks and acknowledges each with a 202. Downstream, a worker is supposed to write a ledger entry for every settlement. A deploy introduces a filter bug: settlements from one provider region stop producing ledger entries. Nothing fails: the webhooks are still acknowledged, the worker still runs, the dashboards stay green. Finance notices three weeks later during reconciliation.

Transport success is not business success

Both facts belong in the record. The successful response explains why conventional monitoring stayed quiet; the missing business result explains why it was still an incident. Seamward keeps both by treating them as two observable events that should correlate: the settlement that was accepted, and the ledger entry that should follow it.

Define the outcome

Two things wire this up. First, your handlers report business outcomes and correlation, which they can do because they are where the business context lives:

// The settlement handler: reports what should happen next.return {  statusCode: 202,  eventType: "payment.settled",  outcome: { accepted: true },  correlation: { sourceEventId: event.settlementId },};
// The ledger worker's observation: reports that it happened.return {  statusCode: 200,  outcome: {    accepted: true,    businessObjectType: "ledger-entry",    businessObjectId: entry.settlementId,  },};

Both identifiers are keyed-hashed inside your process; matching happens on the hashes, and Seamward never sees a settlement id.

Second, an expected-outcome rule states the promise in three values:

What Seamward shows you

Nothing is "missing" until the delay window has fully elapsed, so slow-but-fine results never page anyone. Once eligible settlements have no matching ledger entry, an incident opens:

3 ledger-entry outcomes missing after successful payment.settled events

The incident lists each affected source observation with its correlation evidence and updates in place as the count changes. When the bug is fixed and every source is satisfied again, Seamward starts a verification window of at least five minutes, or the rule's longer delay. Sustained recovery resolves the incident with a recorded recovered reason and timestamp; new missing evidence resets verification. Evaluation runs on new traffic and on a sweep every minute, so a window that expires quietly is still caught.

If the repair was delivered in a pull request, Seamward first waits for an observation whose deployed commitSha matches the merged commit. It then requires at least one complete correlated source and outcome pair after that deployment boundary. Historical failures stay attached to the incident while the post-deployment evidence proves recovery.

Investigate a missing outcome

1. Confirm the triggering operation completed and belongs to the expected integration.
2. Check the correlation identifier and the evaluation window.
3. Look for a late, duplicate, or differently correlated result before declaring it absent.
4. Record the affected records and the remediation decision using only supported evidence.

Impact analysis turns the affected sources into a defensible affected set for reconciliation.

Operating boundaries

• Outcome rules evaluate observable facts; they never infer an unrecorded business result.
• Hashed correlation supports matching without exposing the original identifier.
• Unknown or incomplete correlation stays unknown rather than being counted as confirmed impact.
• Seamward does not retry the business operation or modify your system of record.

Related: Expected outcomes for rule mechanics, and Observe webhooks for the outcome contract.