One model for state, work and authority

A useful system model answers a few ordinary questions: who owns this state, who can ask for a change, what happens outside the system, and what remains after an interruption?

Septa connects these questions. Its central unit is a durable responsibility with a checked interface and explicit authority. The pieces become easier to understand when they describe one example.

Begin with an order

In this conceptual example, Checkout owns the progress of an order. Inventory owns stock and reservations. A payment integration connects to an external provider.

Checkout ── reserve request ──▶ Inventory
         ◀─ typed outcome ───
    │
    ├── wait for approval
    │
    └── payment request ──────▶ Native integration ──▶ Provider

This is an architectural sketch, not runtime declaration syntax. The arrows show intended interactions. Each still needs its contract and authority context.

Actors give state an owner

An actor has an identity, state and a mailbox. Handlers consume messages and update the state the actor owns. The state can survive a supported restart because the runtime retains durable history.

In the example, Checkout does not reach into Inventory’s state. It requests a reservation. Inventory can enforce the stock invariant where that state is owned.

Actors can live within one runtime. An actor boundary is a modelling decision; a separate service deployment is an operational decision.

Workflows give progress a place to resume

A workflow suits work moving toward completion: submit an order, wait for approval, then request payment. Durable progress lets execution continue from a supported waiting point after interruption.

An actor can continue receiving requests over time. A workflow can represent a particular operation with a beginning and an eventual outcome. Both rely on recorded state and execution contracts.

Effects expose interactions

Reading time, requesting a reservation or calling an external provider is different from calculating a price from supplied values. A typed effect makes such an interaction visible to checking and execution.

That visibility supports recording and inspection. It does not itself grant permission. Scoped grants and admission checks constrain which capability operation may occur in a particular context.

Identity makes a change specific

Exact code identities connect an implementation with its dependencies. A library update selects different content. Retained evidence can then say which inputs it observed and whether it still applies after the change.

This makes a review more concrete: “Inventory’s reservation contract changed, Checkout consumes this identity, and these tests cover the revised outcome.”

Inspection has three views

Declared communication describes checked possibilities. Permitted communication describes authority in a named context. Observed execution describes what retained evidence records.

The views answer different questions. A declared path may be denied. A permitted operation may never have happened. An observed trace may cover only part of the system’s history.

Together, these distinctions let agents work on small pieces while people understand how those pieces compose. Read effects and authority next.