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.

AN ILLUSTRATIVE SCENARIO

A disabled account still has a session

A retailer disables a compromised administrator account and receives a successful response. The response objective, however, is to stop that identity from accessing the order system. A controlled check finds that a previously issued application session still works. The responder follows the approved session-revocation procedure and verifies access again. They record which resources and session types were tested, since one rejected request cannot establish that every possible access path is closed. Legitimate administrator access is also checked to detect unintended disruption.

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