Expected outcomes

A 202 Accepted proves delivery, not success. An expected-outcome rule states the business result that should follow a successful operation ("every accepted payment.settled event produces a ledger-entry within 15 minutes") so Seamward can detect the failures that transport monitoring is structurally blind to.

Anatomy of a rule

A rule has exactly three parts:

Create rules from the integration's Expected outcomes section. Disable a rule to stop it participating in evaluation without losing its history.

Independent mode definitions

A rule belongs to one exact Sandbox or Live connection. Configuration copying creates a disabled definition in the destination and preserves independent evidence and history. Copying a source rule never enables the destination rule or synchronizes later changes.

For automation, list and manage connection rules with a workspace API key. Reads return the connection revision; writes require the exact revision you reviewed and a retained idempotency key. Explicitly enabling a rule affects only that mode connection. A rule with incident history can be disabled, but cannot be detached while those references remain. Retained operation receipts prove a mutation committed; they do not prove its current configuration.

How evaluation works

Seamward evaluates rules against the observations your collector already sends; there is nothing extra to instrument beyond the outcome contract.

1. An observation qualifies as a source when its eventType matches the rule, its outcome was accepted, its status code was below 400, and it carries a sourceEventIdHash.
2. The rule's delay window must fully elapse first. Nothing is ever "missing" before maxDelayMs has passed, so slow-but-fine results do not page anyone.
3. A source is satisfied when a later observation carries the expected businessObjectType and a matching identifier hash. Matching happens entirely on keyed hashes; Seamward never sees the underlying identifier.
4. Unsatisfied sources become a missing-business-outcome incident: "3 ledger-entry outcomes missing after successful payment.settled events". When every source is satisfied again, the incident enters a verification window of at least five minutes, or the rule's longer delay. A sustained healthy window auto-resolves with a recorded recovered reason and timestamp. New missing evidence resets verification.

Evaluation runs when new observations arrive and on a sweep every minute, so a rule whose window expires quietly (no new traffic) is still caught within a minute.

When an approved pull-request repair is involved, the merge event alone is not recovery evidence. The collector reports deployment metadata automatically. Seamward identifies the first observation whose commitSha matches the merged pull request, then evaluates only source and outcome pairs received from that deployment boundary onwards. At least one complete post-deployment pair is required before the sustained verification window begins.

Writing rules that work

• Name the outcome in the language of the team that owns the workflow; the incident summary is built from these names.
• One rule per distinct business result. "Payment settles" and "receipt email sends" are two rules, not one.
• Set maxDelayMs from the workflow's real latency plus slack, not from hope. A window that is too tight creates noise; too loose delays detection.
• The triggering handler must report correlation.sourceEventId and the fulfilling handler must report the matching identifier on its outcome, or nothing can link them.

Boundaries

• Rules evaluate observable facts; they never infer an unrecorded result.
• An unknown correlation stays unknown; it is never counted as confirmed impact.
• Seamward does not retry the business operation or touch your system of record.

Evidence limits

The affected-record count includes every missing source retained for the rule. The incident's inline evidence is a deterministic sample of at most 1,000 records and 8 MiB of compact serialized JSON, including repeated identifiers. totalMissing, sampledRecords and truncated describe the sample. All missing sources remain linked to the incident, including records outside the inline sample. Recovery evaluates every eligible source, so sampling does not change whether an outcome is missing or a verification window succeeds. Evidence pagination and search cover every currently missing linked record. The response's snapshot object describes the inline sample; its paginated total includes all matching current records. Historical links remain after recovery but do not appear as currently missing. Older incidents keep their original timeline until their next reconciliation pass.

Replay datasets and repair generation require the complete current evidence set within the MVP limit of 1,000 fixtures. More than 1,000 returns 409 with replay_evidence_capacity_exceeded, limit and total. The request creates no partial dataset or proposal. Existing dataset selection does not bypass this check. See replay limits.

Next steps

• Detect silent business failures: the full workflow this enables.
• Incidents: what a missing outcome becomes.