Postcondition, in practice

What it means

A postcondition states what must be true after an action for its objective to count as achieved. In security operations, that state should be checked using evidence that is meaningfully independent of the command's acknowledgement. An application programming interface (API) can accept a request while work is still pending, or a setting can change without affecting an existing session. Defining the postcondition before acting makes the required check explicit. Results may be verified, failed, or unknown; preserving the unknown state is safer than inventing success when the necessary evidence cannot be obtained.

The idea at a glance / Automation

Check the intended effect independently.

An account-disable acknowledgement does not close an existing application session in this example. A scoped behavioral check exposes the gap.

Synthetic ManifestDesk keeps its own sessions. Before acting, Nora defines the goal: S86 must not read M86, while legitimate S87 must retain its read. U86 and U87 initially have that permission. The directory disable blocks new directory sign-ins, but does not automatically end S86. Session labels are safe references, not usable cookies.

READ THE PICTURE

Compare acknowledgement and effect

The directory returns HTTP 200, yet S86 still reads M86. Nora then revokes S86 at ManifestDesk. Retesting refuses S86 with 401 while legitimate S87 still receives Dock 8. The original manifest stays unchanged.

Keep in mindThe verified result covers S86 and S87 on GET /manifest/M86 at the stated checks. It does not prove that every session, token, application, or later sign-in path is closed. Original M86 stays unchanged; no human attribution or removal of earlier disclosure is established.

Read the complete example

Compare acknowledgement and effect. The directory returns HTTP 200, yet S86 still reads M86. Nora then revokes S86 at ManifestDesk. Retesting refuses S86 with 401 while legitimate S87 still receives Dock 8. The original manifest stays unchanged. On the fictional 2026-09-30 record, Nora observes U86 disabled at 09:00. At 09:01, GET /manifest/M86 using the previously issued S86 returns HTTP 200 with {"dock":"Dock 8"}, demonstrating that the intended S86 read refusal does not hold. ManifestDesk checks its own server session store and resource permission; directory state is not rechecked on each existing-session request in this configured example. Nora revokes S86 in that store at 09:02, while the browser still holds its old cookie reference. At 09:03, the same scoped request with S86 returns HTTP 401 with no manifest content; a separate S87 request returns HTTP 200 with the original {"dock":"Dock 8"}. The higher-level goal is checked through these actual modeled access results, separately from the successful directory change. Revoking S86 does not erase M86 or revoke S87. The controlled model has no other token or sign-in paths; real systems require their own scope and checks. No live service or compromised account is involved.

The verified result covers S86 and S87 on GET /manifest/M86 at the stated checks. It does not prove that every session, token, application, or later sign-in path is closed. Original M86 stays unchanged; no human attribution or removal of earlier disclosure is established.

Diagram references: NIST SP 800-63B-4: separate application sessions · OWASP: server-side Session Management

AN ILLUSTRATIVE SCENARIO

A directory success and a surviving session

Nora defines the controlled goal before acting: S86 must lose its M86 read while legitimate S87 keeps it. A successful directory disable leaves the separate ManifestDesk session S86 active, and an independent read returns Dock 8. After server-side S86 revocation, that read is refused with 401; S87 still receives the unchanged manifest. The result verifies these two session/resource checks, not every token, application, or later access path.

Put it to work

Before acting, state the intended outcome, affected resources, deadline, and observable evidence. Separate the requested configuration change from the business or security effect it is supposed to achieve.
Choose an independent readback or safe behavioral test and define its limitations. Include existing sessions, propagation delays, and dependent systems when they affect the outcome; avoid tests that expose real sensitive data.
Record the action acknowledgement and verification result separately. If the check fails or remains unknown, stop unsupported follow-on actions and escalate or reconcile within a defined budget.

A response check, expressed as pseudocode

request disable(account)
observe access_state(account, target_application)

if access_state == denied:
    record verified, with scope and time
else if access_state == allowed:
    record failed and escalate
else:
    record unknown and reconcile within budget

How to check your work

In a controlled exercise, make the action return success while delaying its effect. Confirm the workflow waits for or reports the actual postcondition, keeps unknown distinct from success, and records the scope and time of the independent check.

Connect the ideas

Retry budget
A limit on how often automation may repeat an action, especially when the previous outcome is uncertain.
Evidence
A record you are willing to cite in a decision, with enough provenance to explain what it can prove.
Session
State linking multiple requests; an authenticated session associates later requests with a previously authenticated identity until it expires or is revoked.

Postcondition