Foundations

Action Principle

The common shape of governed O2A operations — inputs, preconditions, effects, cascades, and corrections.

Action principle

Every governed O2A operation shares the same shape. An Action Type names a business operation, declares the object it acts on and the inputs it needs, states the preconditions that must hold before it can proceed, and fixes the effects it guarantees once it succeeds. It may also trigger cascades — further operations the standard requires — and in every case it must preserve O2A's invariants.

How It Works

The Action Type vocabulary the O2A standard defines is closed — only the standard can add, rename, or redefine a standard action, and an implementation's operation with the same semantic scope must be understood as that standard action even if its local command name differs. An implementation may still add custom actions for local product, integration, or extension behaviour. A custom action must be qualified under a distinct namespace so it cannot be confused with a standard one, and it must stay compatible with O2A's invariants: it cannot weaken an invariant, bypass a standard precondition, or redefine a standard action's effects.

Statements

The following statements fix the action contract precisely.

  • An Action Type names a governed business operation.
  • An Action Type has a target entity, required input, precondition, and effect.
  • An Action Type can have cascades.
  • An Action Type preserves O2A invariants.
  • A custom action extends behaviour under a distinct namespace.
  • A custom action remains compatible with O2A invariants.

Why It Matters

This common contract is what makes actions portable. Because the meaning lives in inputs, preconditions, effects, and cascades rather than in any particular command or API, two different implementations can both be conformant as long as they honour the same shape. It also gives implementations a defined seam for extension: local behaviour can be added without eroding the shared standard.