The Algorithmic SOP: Why a Procedure Needs Decisions and Exceptions

«Open the email. Review the document. Prepare the response. Send.»

That can be a useful instruction. But it doesn't adequately describe a professional process if we want a person, an AI, or both to execute it consistently.

The reason is simple: real work doesn't just fail at the steps. It fails in decisions, incomplete information, and exceptions.

A procedure shouldn't only document the happy path

If the procedure only works when all data is complete, there are no contradictions, and no one has doubts, we have documented the least critical part of the job. An operational procedure needs to make clear what outcome it seeks, what decisions change the route, what situations require stopping or asking for help, and what minimum evidence allows us to know that the important control occurred.

Why I use the expression «algorithmic SOP»

I use «algorithmic SOP» as a methodological term to distinguish a merely narrative procedure from one sufficiently explicit to coordinate human and AI-assisted work without hiding critical decisions within a prompt. The word «algorithmic» does not mean converting an office into code: it means that, where a condition changes what should happen, that condition should not depend solely on tacit knowledge.

Four Public Tests

1. Result: Do we know how to recognize when the process ended well?
2. Decision: Are the route's turning points visible, or is judgment needed?
3. Exception: Does the procedure know when not to simply proceed as usual?
4. Control: Can we demonstrate that the material checks occurred before the relevant effect?

The procedure also protects portability

When critical logic lives outside the prompt and the specific model, changing providers or models is much less traumatic. An SME doesn't need to turn every task into twenty pages: it needs to document what changes results, risks, or responsibilities.