Make a read-back prove the intended change
Design declared HTTP action verification around operation-specific evidence rather than generic endpoint health or pre-existing state.
A successful GET after a write does not automatically verify that write. The read-back needs to match evidence that the intended operation created. Otherwise an unrelated existing record can make a failed or missing write look confirmed.
Anlyon's declared action verify rule performs a GET on the action's own host, checks the expected status and evaluates configured JSON matches. A confirmed grade means that rule matched. The strength of the business claim depends on the rule you designed.
Start from the success condition
Write a sentence such as: "The provider record for operation X contains target Y and value Z." Then identify the read endpoint and fields that support it. If the API exposes only a generic health endpoint, that endpoint cannot establish the operation's result.
| Weak check | More useful evidence, when available |
|---|---|
| Service returns 200 | Operation-specific record exists |
| Resource has desired value | Record also identifies the intended operation |
| Latest item looks similar | Stable correlation ID matches |
| Request was accepted | Provider's completed result matches the required state |
A provider may not expose all of this evidence. State the resulting limitation rather than inventing a stronger verification claim.
Account for delayed visibility
An immediate mismatch may mean the provider has not exposed the write yet. It does not necessarily mean the write failed. For unknown outcomes, unsuccessful read-back remains uncertainty; the write is not automatically repeated.
Test a match, a mismatch, a read timeout and a response lost after the write. Check whether the read URL can still be constructed without the write response. If it cannot, document the operator recovery route.
Keep the rule maintainable
Review changes to response shapes and provider semantics. Avoid matching volatile presentation fields when stable identifiers exist. Do not call the rule an independent audit of the whole workflow: it checks the specific condition you configured.
Use the declared action reference, verification after a lost response and receipt grades.