Operations and rules

An operation is a single action a process can take on a record — matching an invoice to a purchase order, posting a payment, closing a ticket. Every operation in a definition has a rule attached to it, and the rule decides what happens when an agent tries to perform that operation.

An attempt is settled along two axes. First, whether the caller is allowed to make it at all. Then, what the rule does with it.

• Completes automatically. The operation runs and the result is recorded. This is the outcome for anything routine and within the limits you set.
• Waits for a person. The operation is held until someone approves it. Nothing happens until that decision is made.
• Is refused. The operation does not run. The attempt and the reason are recorded, and nothing about the record changes.

Which outcome applies is stated in the definition and depends on the operation and the situation — an invoice under a threshold might complete automatically, while the same operation on an invoice over that threshold waits for approval. Both are the same operation with different rules attached to different conditions.

Who is allowed to try

Before any of that, a definition can say who may perform an operation at all.

An operation can require a role, so that only an administrator may run it. This is common on the mutations in a process — starting a review, publishing a result, correcting a record — while the reads beside them stay open to everyone who can see the workspace. Read access to a queue is usually wider than the right to act on it.

Records carry the other half. A record can be owned by the person it concerns, so that each person sees their own and nobody browses everyone else's — and ownership can be widened for a specific role, letting a manager read what the individual owns without opening it to the whole organization. This is a property of the record, not a filter the agent is asked to apply, so an agent working on behalf of one person cannot reach another person's records by asking differently.

Together these decide whether an attempt is even considered. A caller without the role, or reaching for a record they do not own, is refused before the operation's own rule is consulted.

Refusals say what happened

A refusal is not a generic denial. An operation declares the specific ways it can fail, and each one is a named case that carries the details of what went wrong — the record was not in the state the operation expected, someone else changed it first, the caller was not the person responsible for it.

That matters when you are reading a record afterwards or handling the outcome in your own system: the reason is a specific, documented case rather than a message you have to parse. A single process typically declares dozens of these across its operations.

Enforced before execution, not followed by the agent

The rule is checked by the platform before the operation runs. It is not an instruction handed to the agent that the agent then chooses to follow. The agent does not see a rule and decide to comply with it — the platform checks the rule and only lets the operation proceed if it passes.

This is the distinction that makes delegation to an agent different from delegation to a script that might have a bug, or a person who might make an exception under pressure. An agent cannot pay above a limit, skip an approval, or post the same invoice twice, because those are not choices available to it. The check happens outside the agent, at the point where the operation would take effect.

Blocked is a normal outcome

A refused operation is not a failure and not an error to be debugged. It is the rule working as intended. If an invoice arrives without a purchase order and the rule requires a match before payment, refusing the payment is the correct outcome, not a malfunction.

Reading a record with a blocked operation should feel the same as reading one that completed cleanly: it tells you what was attempted, what the rule required, and why the attempt did not go through. See Reading the record for what that looks like in practice.

Only what is defined exists

An agent can call the operations named in the definition, and nothing else. If an operation was never defined, it is not something the agent can reach for — there is no generic action, no way to compose one on the fly, no fallback that lets it approximate what is missing. If a process needs a new operation, that operation has to be added to the definition first. See Revising a definition.

This is what makes the set of things an agent can possibly do fully knowable in advance: it is exactly the operations listed in the definition, each carrying the rule that governs it.