Method demonstration. This method demonstration uses fictional examples. It does not report client results or independently verified production behaviour.
Keep three kinds of evidence separate
After an authorized campaign change, separate the response to the request, the saved platform state and the subsequent delivery. Each answers a different question. A response can acknowledge work; a readback can show a saved value; later reporting can show what served. None alone proves improved campaign economics.
This is a proposed verification method. It does not claim that James’s Worker project has completed independent validation or already implements every control below. The ongoing Worker-first project retains its documented live, shadow and unresolved boundaries.
Define completion before the action
Specify the authorized account and object, the exact field, current value, intended value, units, timezone and constraints. State how the platform exposes saved state and how long an asynchronous operation may remain pending. Choose a bounded verification deadline from its documented behaviour or an agreed operating limit; there is no universal wait that makes a change reliable.
Record who may restore a setting and under which conditions. Permission to pause does not automatically grant permission to resume, and permission to change one bid does not authorize changing every placement. Keep an immutable record of the intended operation and check for intervening changes before writing.
A public demonstration can use labels such as “test object.” Real account identifiers, placement lists, credentials and raw request logs belong in an access-controlled operational record, not a portfolio page.
Read the response, then read the object
| Observation | What is established | What to do next |
|---|---|---|
| HTTP response says accepted | The request may be queued; completion is not established. | Inspect the documented operation result and saved object within a bounded window. |
| Saved field equals intended value | That field matches at the read time. | Verify identity, units, related scope and whether another writer intervened. |
| One of several objects differs | The operation is only partially verified. | Record each result; do not label the whole batch complete. |
| Timeout or connection loss | The outcome may be unknown rather than failed. | Read before retrying; avoid duplicating an action with an uncertain outcome. |
| State matches but delivery continues | Serving or reporting may lag, or another scope may still be active. | Align event times and inspect the relevant scope; escalate within authorized controls. |
RFC 9110 defines HTTP 202 as acceptance for processing that is not yet complete. Interpret other responses using the endpoint’s documented contract and any per-item result. A successful HTTP response is not a business-performance verdict. Source: HTTP 202 semantics.
Worked example: two requested pauses, one unresolved
Fictional operational example. These labels and times are invented; they are not a production trace. The owner authorized pausing two test objects. The agreed verification deadline is 10:05 UTC, followed by escalation for unresolved state. No automatic resume is authorized.
| Time | Observation | Record |
|---|---|---|
| 10:00 | Pause request submitted for test objects A and B. | Requested; preserve the authorized target state. |
| 10:01 | The endpoint acknowledges the request. | Acknowledged; neither object is yet marked verified. |
| 10:02 | Fresh read shows A paused and B active. | A matches; B pending or inconsistent, not successful. |
| 10:04 | Another documented read still shows B active. | Keep B unresolved. Inspect operation details and concurrent edits. |
| 10:05 | Deadline reached without a verified pause for B. | Escalate B. Report one matched state and one unresolved state; do not resume A. |
Later spend reported for A needs its event timestamp checked. Delivery that occurred before the verified pause can arrive in a later report. Conversely, newly timestamped activity after the expected propagation window warrants investigation. Neither observation should be hidden by the job’s original “success” label.
The example does not establish that a platform accepts this batch format, that five minutes is an appropriate deadline, or that an observed state match is an independent audit. Use the actual API and control contract.
Do not turn uncertainty into repeated writes
Before retrying a timed-out change, inspect the object and any operation record. The first request may have taken effect even if the response was lost. Check whether the exact operation is safe to repeat, whether the endpoint supports a documented idempotency mechanism and whether the target state is still authorized.
HTTP idempotency describes the intended effect of repeated identical requests. It does not make every POST repeatable or protect a stale decision from overwriting a later human change. RFC 9110 cautions against automatically retrying non-idempotent requests without a way to establish safe semantics or that the original request was not applied. Source: idempotent methods and retries.
Use bounded retries and the platform’s backoff guidance. If a conditional update or version check is supported, use it to detect conflicting edits. If not, document that limitation and narrow the automation’s authority. A useful failure result is “unverified, owner notified,” not an endless loop that keeps changing spend controls.
Close with a receipt and a separate performance review
The private action receipt should contain the authorization, object and field, previous and intended values, request time, response or operation reference, read time and observed value, any mismatch, final status and owner. Include the next review and the permitted recovery path. Redact identifiers and secrets before any public example.
Configuration verification ends when the agreed state check is satisfied or explicitly unresolved. Performance evaluation starts with enough post-change exposure and mature outcomes, controlling for other changes. A correct pause or bid update can be operationally successful without improving ROI; this note claims neither a measured uplift nor time savings.
Read the Worker-first case and its remaining validation work, or use the underspend investigation to decide whether a configuration change was warranted in the first place.