First separate meaning from mechanism

The first move is to turn each business action into a semantic operation: a value that says what the program needs without performing it yet.

GetUser(user-id)
CheckInventory(items)
Charge(payment-id, amount)
CreateOrder(order-id, details)
SendReceipt(order-id)

This is the practical face of algebraic effects. An operation such as GetUser or Charge describes an effect. A handler gives that description an interpretation. One handler may call a database and a payment service. Another may run a deterministic in-memory model. A third may record the intended effects for an audit or a dry run. The foundational work treats effects as algebraic operations, while later work on handlers shows how one computation can be interpreted in different ways ^{[2] [3]}.

A list of commands is not automatically a complete algebraic-effect system. The important architectural step is narrower: make the effect description a plain semantic value, and move execution behind an interpreter boundary.

That boundary fits functional core, imperative shell. The core decides which semantic operations are needed. The shell interprets them against the outside world. The core can now be tested, simulated, replayed, or inspected without pretending that a database or a card network is a pure function.

For graph-shaped programs, the compact formulation is:

$$\text{Program} = \text{Producer Graph} + \text{Effects} + \text{Laws}$$

The producer graph says which values are required and how they are derived. The effects say what may touch the world. The laws say which compositions preserve meaning. An interpreter supplies the concrete mechanisms while respecting all three.

The separation also clarifies what a state machine contributes. A state machine can say that an order moves from created to reserved to paid, and that refunded is reachable only from paid. That is knowledge about legal behavior over time. It does not, by itself, say whether two reads commute, a batch can be regrouped, or a failed charge can be repeated. The machine and the effect laws answer different questions.

async and await are often handwritten schedules

Application code commonly expresses a workflow in the concurrency vocabulary of its host language:

user      ← AWAIT GetUser(user-id)
cart      ← AWAIT GetCart(user)
price-task  ← CREATE-TASK PriceCart(cart)
stock-task  ← CREATE-TASK CheckInventory(cart)
price, stock ← AWAIT GATHER(price-task, stock-task)
order     ← AWAIT CreateOrder(price, stock)

async/await, Promise.all, gather, create_task, futures, and goroutines are valuable runtime tools. In semantic application code, however, they often do something more consequential: they manually choose a schedule. The example states not only that GetCart needs user and CreateOrder needs price and stock; it also chooses where tasks begin, which work overlaps, and where the caller must synchronize.

If those choices follow entirely from the values consumed by each operation, the program can state less mechanism and more meaning:

User      = GetUser(user-id)
Cart      = GetCart(User)
Price     = PriceCart(Cart)
Inventory = CheckInventory(Cart)
Order     = CreateOrder(Price, Inventory)

The input references derive the semantic dependency edges. A producer-graph compiler can compute the reachable subgraph, reject cycles, and expose the ready frontier. A DAG executor can then run PriceCart and CheckInventory together when their effects permit it, without the domain program containing a gather call.

Three kinds of order must remain distinct:

Semantic dependencies belong in the graph. Effect constraints belong in effect summaries and established laws. Execution policy belongs to the executor. A priority, worker count, or resource budget may choose among already sound schedules; it must not manufacture semantic permission.

This yields the more operational formulation:

$$\text{Execution Plan} = f(\text{Graph}, \text{Effect Laws}, \text{Resources}, \text{Policy})$$

The executor's implementation will still contain await, promises, futures, task groups, cancellation scopes, queues, and thread joins. That is where concrete coordination belongs. The claim is not a syntactic ban on async/await across a codebase. It is a semantic test: when synchronization merely restates relationships the graph, effects, and policy already determine, move it out of the domain layer and derive it.

Some synchronization is irreducible. An ordered protocol may make the order itself observable. A stream may require backpressure before another item can be accepted. A transaction may expose one indivisible settlement point. A fallback means “try the second only if the first fails,” not “run both.” A user-visible race may intentionally select the first answer. In those cases the constraint is part of the program's meaning and should remain explicit — preferably as a semantic combinator or graph constraint, and as direct synchronization when no clearer representation exists.

The laws are executable permission

A law is useful when it removes a coordination obligation. It says that two apparently different executions have the same observable meaning inside a stated domain.

Start with a familiar one. Addition of ordinary integers is associative:

$$(a + b) + c = a + (b + c)$$

The law permits regrouping. A sum over a million values can be split into chunks, reduced as a tree, or accumulated as batches, because every grouping has the same mathematical result. Add the identity 0 and an empty chunk also has a meaning. This pair of laws forms a monoid.

The same method applies beyond arithmetic, but every conclusion is narrower than its slogan:

Purity and determinism are related, not identical. A pure function can still return a nondeterministic value if randomness is an explicit input. A function that reads the wall clock implicitly is neither pure nor replayable from its declared arguments. Caching becomes sound only after the cache key contains every fact that can change the answer.

Associativity and identity permit partitioning. They do not promise that parallel execution is faster. The runtime still pays for task creation, communication, memory, and contention. The law establishes semantic freedom; a resource model decides whether to use it.

Commutativity and independence are also distinct. Two increments to the same counter may commute even though they touch the same state. Two reads of separate services may be independent even if their result combination is order-sensitive. Commutativity permits reordering. Independence removes a dependency edge and can permit simultaneous execution.

Idempotence changes the delivery contract. If CreateOrder(order-id, ...) atomically records one result for one stable identifier, delivering the same request twice can be harmless. A raw Charge(amount) call is usually not idempotent. Adding an idempotency key helps only if the receiving system stores the key and result atomically across the same failure boundary as the charge.

Monotonicity and canonical merge are the heart of many conflict-free replicated data types. A join-semilattice merge is associative, commutative, and idempotent. If replicas only move upward in the order and eventually receive the same information, arrival order and duplicate delivery cannot prevent convergence ^[7]. The conditions matter: monotonicity without eventual delivery does not make missing data appear, and a timestamp chosen from unsynchronized clocks is not a canonical merge merely because the field is named updated_at.

Invertibility and compensation must not be collapsed into one promise. An integer increment has an exact inverse: decrement by the same amount. Shipping a parcel has no such inverse. A return shipment may compensate for the business effect, but time passed, postage was spent, and a customer observed the first shipment. Compensation is a new semantic operation with its own failure modes, not algebraic erasure of history.

From possible transformations to one schedule

Laws produce a set of sound transformations. They do not select one execution plan in isolation. A scheduler also needs the dependency graph, the effects that may touch the world, the resources available for this run, and product policy.

In compact form: schedule = f(dependencies, effects, laws, resources, policy). The two decisions inside that function are easier to see separately:

$$\text{sound schedules} = g(\text{dependencies}, \text{effects}, \text{laws})$$

$$\text{schedule} = h(\text{sound schedules}, \text{resources}, \text{policy})$$

The first three arguments constrain what is sound. The final two select what is desirable now. A machine with one core may keep an associative reduction sequential. A payment policy may require stock reservation before charging, even if a compensation exists. A rate limit may serialize two otherwise independent requests. A latency objective may speculate on two pure reads and discard the slower result. None of those choices changes the laws.

This is where the Pythagorean analogy earns its place. A builder does not measure every possible diagonal until one looks plausible. Given a right triangle in Euclidean space and two known legs, the theorem derives the hypotenuse:

$$c = \sqrt{a^2 + b^2}$$

The orchestration version is similar. Dependencies and established laws define the safe shape. Resources and policy choose one point within that shape. The computer derives the schedule instead of asking an engineer to enumerate every interleaving by hand.

The warning is part of the analogy. Writing “right triangle” beside a sketch does not make the theorem applicable. If the angle is not right, the derived length is wrong. Writing commutative or idempotent beside an operation does not make a reordered or repeated execution sound. The premise must be established, and the interpreter must preserve every assumption on which the premise depends.

Consider the order workflow again. GetUser and CheckInventory may run in parallel if their effect summaries prove independence. A pure price calculation can be cached if its complete input includes the price-list version, currency, and rounding rule. Metrics can be batched if their combine operation is associative and has an identity. A receipt can run beside an audit projection after CreateOrder if both depend only on the committed order and neither affects the other.

The laws do not decide whether to reserve stock before charging or charge before reserving. That order expresses business policy and failure economics. If stock is scarce, reserve-first may avoid charging an order that cannot ship. If a reservation expires quickly, charge-first may avoid holding inventory for a payment that will fail. Both schedules can be mechanically valid. The product chooses which loss to prefer.

This division of labor is the point. Engineers specify meaning, laws, and policy. The runtime handles enumeration, placement, batching, and recovery inside the proven envelope.

The same move wears different names

Several areas of computer science approach this design from different sides. They become useful when each keeps its own job.

Functional core, imperative shell supplies the architectural boundary. Pure decisions stay in the core. World-changing actions stay in the shell.

Algebraic effects and handlers give effectful intent a semantic vocabulary. The same Charge operation can be interpreted by production, simulation, audit, or test handlers without changing the program that requested it.

Effect systems summarize which effects an expression may perform. The 1988 work on polymorphic effect systems explicitly used those summaries to discover expression scheduling constraints for parallel machines ^[5]. An effect summary can establish independence only when it conservatively includes every relevant read, write, capability, and region.

Monoids and semilattices state combination laws. Monoids make reduction and partitioning lawful. Semilattice joins make duplicates and arrival order irrelevant under their delivery assumptions. CRDTs turn those merge laws into replicated data types rather than bolting conflict resolution onto an arbitrary mutable object.

Dataflow and incremental computation make dependencies explicit. When an input changes, the graph identifies the affected region. Algebra on changes then determines how much prior work can be reused. Differential dataflow, for example, represents changing collections and extends incremental computation through nested iteration ^[9].

State machines describe legal temporal behavior. They tell the interpreter which operation is admissible from which state and what state follows. Effect laws can then optimize the work within and between those transitions without inventing a transition the machine forbids.

The connection is not that every program needs every term. The connection is that all of them replace hidden procedural knowledge with explicit semantic structure. A small program may need only pure functions and an associative combine. A replicated editor may need semilattices, stable identities, and a state machine. A workflow engine may need effect summaries and compensation contracts. The smallest adequate structure wins.

An annotation is not a proof

The most dangerous implementation of this idea is a catalog of optimistic labels:

@pure
@commutative
@idempotent
@retryable

Those labels can be useful as claims. They are not evidence. A sound system must know why the claim holds, over which inputs, under which observations, and until which boundary changes.

An idempotent card charge needs a stable operation identity, atomic storage of the identity and result, and a service contract that preserves both across timeouts. A commutative pair of account updates may cease to commute when the observable result includes overdraft fees. A pure function ceases to be pure when it reads a feature flag or locale from ambient state. A deterministic serializer ceases to support stable caching when a dependency upgrade changes its canonical byte format.

The observation matters as much as the operation. Two database writes may produce the same final rows in either order while producing different audit logs, notifications, or externally visible versions. Commutativity over final state does not imply commutativity over the whole system trace.

Evidence can take several forms. A type-and-effect system can conservatively rule out shared writes. A property test can search for counterexamples. A model checker can explore reachable interleavings. A canonical representation can make equality decidable. A service contract can define an idempotency boundary. A code review can name a compensation's irreversible residue. No one method proves every law, but every transformation needs a witness appropriate to its claim.

For every law a scheduler is permitted to exploit, property tests are a mandatory proof obligation. They are not a mathematical proof over an infinite domain, but they force the claim to name its generators, preconditions, equivalence relation, and observable boundary, then repeatedly try to falsify it. A declaration without such an executable obligation is documentation, not scheduling authority.

The obligations should be explicit:

commutativity:
  observe(A then B, s) ≡ observe(B then A, s)
associativity:
  (a ⊕ b) ⊕ c ≡ a ⊕ (b ⊕ c)
idempotence:
  observe(A then A, s) ≡ observe(A, s)
monotonicity (state):
  s ≤ s ⊔ delta
monotonicity (function):
  x ≤ y  implies  f(x) ≤ f(y)
determinism:
  run₁(plan, input, trace) = run₂(plan, input, trace)
compensation:
  invariant(observe(A then compensate(A), s))
reordering:
  observe(order₁) ≡ observe(order₂)
  for admitted antichain orders

Purity, cacheability, retry safety, and merge semantics need corresponding properties too. A cache property compares a fresh interpretation with reuse under every declared input. A retry property injects failure before and after the external settlement boundary. A merge suite checks identity, associativity, commutativity, and idempotence independently; the name semilattice must not make any of those tests disappear. Cross-language executors should replay the same generated plans and observation schedules and compare canonical plans, commands, terminal state, receipts, and refusals.

Property testing is strongest when it attacks the boundaries engineers tend to omit: duplicate messages, equal values with different histories, floating-point rounding, partial external success, cancellation racing with settlement, resource-key aliasing, and version changes. A failed property does not mean the operation is useless. It means the declared domain must narrow, the observation equivalence must become honest, or the executor must retain the ordering edge.

This discipline should sound demanding. Handwritten orchestration already depends on the same claims; it merely leaves them implicit. A retry loop assumes idempotence or accepts duplicates. A worker pool assumes independence or accepts races. A cache assumes determinism or serves stale lies. Naming the law does not create the obligation. It makes the existing obligation reviewable.

The honest boundary

Some work resists algebraic freedom. A sequence whose intermediate outputs are the product may be intentionally order-sensitive. A third-party effect may offer no stable identity, transaction boundary, or compensation contract. A shared device may have one physical channel even when requests are semantically independent. Hard real-time work may require a certified static schedule rather than a runtime search. A small workflow may be clearer as five direct calls than as a new effect language.

Three limits are structural rather than incidental. A dependency edge that exists only once a value is known — a conditional fan-out, a runtime-determined batch size, a recursive expansion — cannot be read off a graph before the run. A derived scheduler recomputes the ready frontier per round instead, which is the shape ^[9] gives nested iteration; a system that assumes one static graph will simply be wrong. Cancellation is the second: its scope is lexical in structured concurrency and does not fall out of a dependency order, so a scheduler that speculates must declare whether cancelling a losing branch is observable. Error propagation is the third. Fail-fast and collect-all are different semantics, not different implementations, and the choice belongs in the effect description rather than in whichever combinator the host language supplies.

Laws can also hold only on a subset. Floating-point addition is not associative under ordinary machine rounding. Set union is monotone until deletion enters the model. A database upsert may be idempotent for one key but not for a trigger that emits a new notification on every attempt. The honest design narrows the domain, weakens the permitted rewrite, or keeps the original order.

The goal is not to eliminate orchestration code. The goal is to stop making that code the only place where the system's semantic knowledge lives. Once the operations, laws, dependencies, and policies are explicit, a scheduler can derive what follows, a test can challenge the premises, and a recovery system can replay the same meaning through another interpreter.

That is a more durable division of labor. Humans state intent and invariants. Machines perform the enumeration those invariants make safe.

Lessons

• An operation and its interpreter are separate things. The program can describe an effect without choosing its production mechanism.
• A law is permission for a specific transformation. Associativity frees grouping; commutativity frees order; independence frees overlap; idempotence frees duplicate delivery.
• Monotone canonical joins can converge. They still require an explicit order relation, eventual delivery, and a merge that is associative, commutative, and idempotent.
• Determinism makes caching and replay defensible only when every relevant input is named. Hidden time, configuration, versions, and locale belong in the model.
• Compensation is not inversion. An exact inverse erases a semantic change; a compensation creates a new event that repairs part of the business effect.
• The scheduler derives within a boundary. Dependencies, effects, and laws define soundness; resources and policy select one useful schedule.
• Annotations are claims, not proofs. Every rewrite owes a domain, assumptions, observations, evidence, and an explicit property suite that tries to falsify the claimed law.

Practice

References

1. Edsger W. Dijkstra. “Concern for Correctness as a Guiding Principle for Program Composition.” 1970. — the epigraph and the argument for operations with mathematically useful properties
2. Gordon D. Plotkin; John Power. “Algebraic Operations and Generic Effects.” Applied Categorical Structures 11(1), 2003. — algebraic operations and their equivalence with generic effects
3. Andrej Bauer; Matija Pretnar. “Programming with Algebraic Effects and Handlers.” 2012. — effects as operations and handlers as interpretations
4. Gary Bernhardt. “Boundaries.” Destroy All Software, 2012. — functional core, imperative shell, and values at system boundaries
5. John M. Lucassen; David K. Gifford. “Polymorphic Effect Systems.” POPL, 1988. — effect summaries used to discover expression scheduling constraints
6. Guy E. Blelloch. “Prefix Sums and Their Applications.” Carnegie Mellon University, 1990. — associative scans as a parallel building block
7. Marc Shapiro; Nuno Preguiça; Carlos Baquero; Marek Zawirski. “Conflict-Free Replicated Data Types.” SSS, 2011. — sufficient conditions for state- and operation-based convergence
8. Joseph M. Hellerstein; Peter Alvaro. “Keeping CALM: When Distributed Consistency Is Easy.” 2019. — monotonicity and coordination-free consistent implementations
9. Frank McSherry; Derek G. Murray; Rebecca Isaacs; Michael Isard. “Differential Dataflow.” CIDR, 2013. — composable incremental and iterative data-parallel computation
10. David Harel. “Statecharts: A Visual Formalism for Complex Systems.” Science of Computer Programming 8, 1987. — state, hierarchy, concurrency, and communication in reactive systems

Mangalapilly, Y. J. (2026, August). Don't Orchestrate What You Can Derive. Saṃhitā Notes. https://yesudeep.com/blog/dont-orchestrate-what-you-can-derive/

@online{mangalapilly2026don,
  author  = {Yesudeep Jose Mangalapilly},
  title   = {Don't Orchestrate What You Can Derive},
  journal = {Sa\d{m}hit\=a Notes},
  year    = {2026},
  month   = {August},
  url     = {https://yesudeep.com/blog/dont-orchestrate-what-you-can-derive/},
  urldate = {2026-08-23},
}

Yesudeep Jose Mangalapilly. “Don't Orchestrate What You Can Derive.” Saṃhitā Notes, 2026. https://yesudeep.com/blog/dont-orchestrate-what-you-can-derive/.

TY  - ELEC
AU  - Mangalapilly, Yesudeep Jose
TI  - Don't Orchestrate What You Can Derive
T2  - Saṃhitā Notes
PY  - 2026
UR  - https://yesudeep.com/blog/dont-orchestrate-what-you-can-derive/
Y2  - 2026-08-23
ER  -