Phase — an architectural approach to building the digital enterprise

The architecture of the cyber-enterprise in the age of AI

About this document

This is a description of Phase — an architectural approach to building information systems intended to automate business. Phase rests on two interrelated ideas: the notion of the digital enterprise, and a mechanism for managing the lifecycle of objects through phase transitions.

Phase is realised through Phase Engine — a software engine that executes the approach: it tracks objects' phases, processes phase transitions, and manages the spawning of child objects and subscriptions. Throughout the text: Phase is the concept and the approach, Phase Engine is its software implementation, and a phase is one of the engine's three primitives.

Phase is intended for teams that build business information systems in an era of ever-growing business automation and AI-agent use: when automation and human participation must be combined at the level of architecture rather than bolted onto a finished solution.

Part I. The digital enterprise

The problem

Business information systems are actively moving from one paradigm to another. The traditional paradigm — the system as a tool that supports a human: a large calculator with memory, where the human makes every decision and the system merely stores data and computes. The new paradigm — the system as an autonomous executor: it drives objects through their lifecycle itself, assigns work to people and agents, and makes routine decisions without human involvement. Human involvement shrinks as the system accumulates data and increases the accuracy of its decisions.

To build systems in the new paradigm, you need an information model that makes this convenient — not as a layer on top of a finished architecture, but as its foundation.

The idea

Treat the enterprise from the very beginning as an automatic cybernetic system — not as a set of people with tools. Automation in it is not the exception but the default; human participation is a deliberate decision where it is genuinely needed.

To describe and program the work of such a system, use a model familiar to human perception and long used in programming: objects that can change their state and perform actions. A contract, an order, an invoice, a client are not rows in a table but objects with behaviour, a lifecycle and relationships. This model is equally clear to a business analyst, a developer and an AI agent.

But an information system operates on informational entities, not on real objects. So the key question is how an informational entity is connected to the real world: what it reflects, how reality affects it, and how it affects reality.

The definition

A digital enterprise is a cybernetic information system that, in the course of its work, strives to achieve the goals set for it by its owners.

A digital enterprise has its own "engine" that acts in two ways: reactively — responding to incoming signals from the real world and to internal events — and actively — initiating actions of its own to achieve goals.

Within a digital enterprise the human is one of the resources it uses in its work, on a par with software agents, integrations and external services.

Digital object models

Twin objects have a concrete counterpart in the real world. Between the model and the real object there is a two-way link through adapters: inbound adapters take events from the real world and update the model; outbound adapters initiate actions in the real world when the model changes. Examples: an Invoice — issued → paid; a Contract — pending signature → signed → in force → closed; an Order — accepted → in assembly → shipped → delivered.

A real-world object can change in two ways: the digital enterprise initiates the change itself through an adapter, or the object changes independently and that change arrives through an adapter and updates the twin. In both cases the twin reflects up-to-date data — as far as the system knows.

Informational objects exist only in the digital environment — they have no twin in the real world. Their lifecycle is entirely closed within the system: a task, an approval card, a report, an agent configuration. The system manages both kinds alike; the only difference is that a change to a twin object is automatically reflected in the real world through an adapter.

Part II. The Phase engine

The problem

The engine must meet two contradictory requirements. On one hand it must be simple and predictable to program — clear to a human developer and to an AI agent. On the other it must be powerful enough to cover all the enterprise's needs: parallel processes, branching, timers, compensations, interaction with the outside world.

The idea: three primitives

All application logic in Phase is described by three and only three primitives — the complete vocabulary with which an engineer programs the activity of the digital enterprise. Everything else — scheduler, adapters, event bus — is engine infrastructure: identical for every object and not programmed for the task at hand.

Phase. An object exists in one of a finite set of phases. A phase is a period of the lifecycle in which the object remains until the exit criterion is met: a condition over fields at which the engine initiates a transition. A phase transition is instantaneous: the field condition is satisfied → the object jumps into the new phase.

Spawning. An object can spawn child objects — automatically on a transition by configuration, or explicitly within a phase by a participant's decision. On spawning, the engine automatically links parent and child by subscriptions in both directions: a child's transition can update a system field of the parent, and the parent's transition a field of the child. This is the synchronisation mechanism: the parent's exit condition can depend on the aggregated state of its children.

Subscription. An object can subscribe to another object's phase: when the source leaves the specified phase, the engine writes a signal into a system field of the subscriber, carrying the full context of the transition. Subscriptions are static (every instance of a type reacts to every instance of the source — an architectural link) or dynamic (created by the engine on spawning, between a concrete parent and child).

Phase Engine guarantees the atomicity of transitions and the serialisation of all changes to an object's fields, whatever their source. Changes are applied one at a time and in order; each is checked against the current values of the fields. Simultaneous work by a human and an agent on one object loses no updates and produces no contradictory transitions.

The core of the engine is deliberately reactive: it responds only to field changes. Active behaviour — scheduled actions, deadline control, periodic analysis — is provided by the scheduler and agents through the same mechanism: the scheduler writes a value into a system field at a set time, an agent updates agent fields — and the engine reacts as it would to any other change.

More on the phase

While in a phase, two modes are possible. Waiting with analysis — the object waits for an external event, but in parallel a human or agent analyses the situation and fills in fields; the transition occurs when the totality of conditions is satisfied. Active work — participants do work inside the phase to bring about the exit condition.

A waiting example: an Invoice — "Awaiting payment". The condition payment_received = true will be satisfied by itself when the bank confirms; in parallel an agent updates non_payment_risk. An active-work example: a Deal — "Negotiating delivery terms", condition terms_agreed = true. In both cases the engine makes no decisions based on time — it reacts only to field changes; the moment of entering a phase is recorded in the audit but is not itself a condition.

Fields and the phase transition

The engine checks transition conditions on every change to any field. Conditions are described as a table: from which phase, under which set of field conditions, into which phase. Rows are read top to bottom; the first match fires.

The condition language

The vocabulary is deliberately closed: a condition is a check, not a computation. The engine does not aggregate and does not call functions. Anything requiring computation is computed by a participant — agent, adapter, scheduler, child object — and recorded in a field. So a condition can always be read aloud, and that reading matches exactly what the engine checks.

Fields in a phase

A field's type determines not only who writes its value during operation, but also who creates the field at design time. Agent and user fields are configured by the engineer — assembling behaviour from a ready vocabulary. System fields are created only by the developer: behind each stands code — an adapter, a scheduler handler, a synchronisation channel. The developer builds the vocabulary of the possible; the engineer assembles behaviour from it.

Tools in a phase

The agent and employee can use tools to obtain information. Tools only read — they change neither object state nor the external world. The only active action besides writing to a field is spawning a child object. To send a letter, start a conversation, create a task is always to spawn an object. There are no traceless actions: any effect leaves a digital trace — a spawned object and a record in the phase journal — and its success or failure becomes part of that object's lifecycle.

Two layers within a phase

The stream of facts — raw signals during the phase, each recorded in the phase journal, an immutable chronicle. The distillate — the object's fields, the best available knowledge of its properties. The engine checks transition conditions against the distillate, not the raw facts. Hence the tempo: a field changes at the tempo of the business, not of signals. A high-frequency stream is distilled by an adapter or agent to a meaningful value. Phase is a model of business tempo; high-speed stream processing is the work of adapters.

The time gap

A digital model is never an instantaneous copy of a real object. Between the moment an event happens and the moment the system learns of it there is always a gap. Phase handles this explicitly: each field holds not just a value but its freshness — when the knowledge was current. The agent and the human know what they stand on: a fresh signal or a three-day-old estimate.

Corrections. A new signal may report that a previous value was wrong. Phase does not rewrite history — a correction is recorded as a new fact beside the original and triggers the ordinary transition mechanism. The audit reads honestly: original signal, decision, clarification, reaction to the clarification.

The digital model is the best available knowledge about the real object, not absolute truth. The system does not pretend to know reality — it knows exactly what it knows and when that knowledge was updated.

Symmetry of participants

A key property of Phase: none of the common process-management systems builds the participation of a human and an AI agent on one and the same mechanism.

An employee and an AI agent change an object's phase through one mechanism — writing to a field. There is no special "human step" and "agent step". Both write a value → the engine checks the conditions → a transition happens or not. A field's type governs only the write right; the transition logic is blind to types.

Full symmetry is achieved when the employee formalises their knowledge — entering it into fields before deciding. Then agent and human work from one informational base, and handing a decision from human to agent becomes possible without loss of quality. As a consequence:

The degree of human participation in an object's lifecycle is configuration, not architecture.

The agent's address

object type × phase → agent configuration

An agent is activated when an object enters the specified phase, and again on every significant event or on schedule. It receives the object's fields, fills in agent fields, finishes. The decision about a phase transition is made by the engine — not the agent. This gives a minimal context, clean responsibility, auditability (every action is tied to an object, phase, configuration version and a context snapshot) and versionability of configurations.

Three primitives cover complex patterns

Parallel approval — spawning several approval cards, each incrementing the parent's counter. Compensation — spawning an object with a compensating lifecycle. Branching — the order of rows in the transition table. Timers — the scheduler writes to a system field at a set time. Deep hierarchy — single-level aggregation: each level aggregates only its own children. Nested stages — either ordinary flat phases, or a child object when the sub-process has its own knowledge. The nesting of states that Phase deliberately rejected is not required.

Part III. What Phase gives you

A single natural view of the business

People think about business in terms of phases long before any information systems. When every significant object has a digital model with phases, a single map of objects in their phases emerges — sales, warehouse, finance, production in one language. "How many contracts are in approval?", "Which invoices are overdue?" are direct queries to the system's state. Each object's history is complete and undeletable.

Speed of the enterprise's reaction

The cascade of phase transitions ensures a fast reaction of the whole enterprise to a single event — without a central coordinator. The reaction time is determined by the depth of the transition chain, not by polling intervals.

Autonomy is tuned iteratively

Any object can start under manual control and move toward autonomy without reworking the architecture. Start with "the agent proposes, the human confirms", and once confidence is built — remove the user field from the transition condition.

Phase as a source of training data

For every agent activation there is context, decision, outcome and human correction — the structure needed to improve agents, appearing automatically with no separate labelling. Data is used to improve instructions, fine-tune the model, and measurably compare agent versions. Phase data is labelled by default — most systems pay for such labelling separately.

Code is predictable for AI agents

Adding an object type is filling in a configuration schema of fixed structure. A limited vocabulary — three primitives, three field types, the transition table — lets an agent work without inventing a wrong pattern. Every configuration has a machine-checkable schema; one that fails is not applied. Programming becomes a closed loop: generate — check — fix — apply.

The lifecycle is verified before launch

The transition table is a mathematical object open to static analysis: one can verify that every phase is reachable, that there are no unintended trap phases, and that safety invariants hold ("an invoice cannot reach 'Paid' if payment has not been received"). Systems with their lifecycle in code cannot do this. Verifiability lets autonomy be expanded on proof, not on trust.

Scale: quantity instead of variety

Phase scales by quantity, not variety. Fifty object types are fifty instances of one pattern, not fifty special cases. Understanding is local: any type is read in isolation. The map of an object's connections is built by the agent from configurations at query time, not maintained by hand.

Part IV. Managing adaptation

Part I described how the enterprise acts. But that is only one management loop. Full management has two. Management within the system — driving objects toward goals within a given structure. Management of adaptation — changing the structure itself when its version stops achieving the goals: setting and revising goals, rebuilding configurations, migrating live objects.

Cybernetics established long ago that a viable system must manage itself as well. The question is by what mechanism. The usual answer is a separate privileged layer outside the model. Phase gives a different answer: the adaptation loop is built with the same three primitives. A goal is a Phase object. A configuration change is a Phase object. The management model is complete — it reaches all the way to the top while remaining one model.

The goal layer: a goal as an object

A goal is an informational object. The owner sets the target value (user field), the analytical loop updates the current value (system field), the agent gives the trajectory estimate (agent field). The goal's phases: formulated → active → achieved, with paths for revision and cancellation. When the estimate drifts past a threshold, the goal moves to "Revision" and spawns corrective objects — initiatives, tasks, experiments. Decomposing a strategy into sub-goals is spawning child goals.

Self-change: a configuration change as an object

The act of changing a configuration cannot be a privileged operation outside the model — otherwise an invoice's movement passes through phases and audit while a change to the transition table happens traceless. The solution: a configuration change is an ordinary Phase object with a lifecycle "proposed → checked → approved → applied" and a compensating rollback object. Checks (static analysis, tests) fill in fields automatically; human approval is a user field in the transition condition. The recursion is finite: the "Configuration change" type is a system one, changed only by updating the engine.

Who adapts the system

The roles that previously programmed the system from the outside — the developer who builds the vocabulary of types and the engineer who assembles behaviour — become participants of the model at the adaptation level. Since a configuration change is a Phase object, they work on it just as an employee works on an invoice. And since participants are symmetric, the same agent stands beside the human: as confidence accumulates it gains ever more authority to change the system itself — along the same curve by which it earned the right to close an invoice without confirmation. There are no figures standing above the model.

Live objects on configuration change

Each object knows which configuration version it lives by. By default an object finishes its lifecycle on its own version — a change affects only new objects. If a change must reach live objects, the migration policy is described in the change object itself and checked statically: every phase holding live objects must be covered by a mapping. A version change is auditable per object.

Recursive scaling: an enterprise as an object

An enterprise itself can be an object inside another enterprise. A holding is a digital enterprise whose resources are subordinate enterprises. The link between levels is the familiar twin-object mechanism: the upper enterprise keeps a digital twin of the subordinate and manages it through adapters. The subordinate's boundary is not blurred but becomes the twin's boundary. A hierarchy of enterprises of any depth is described by the same vocabulary as the lifecycle of a single deal.

The dark enterprise that rebuilds itself

The classic image of automation is the dark enterprise: the shop floor runs without people, yet people outside it control and rebuild it. Phase extends the image one level up: the loop by which the enterprise is rebuilt also gets a tool — the same agent, the same symmetry, the same graduated autonomy.

The boundary of autonomy runs along the nature of the agent: it acts from accumulated knowledge, while the new is brought in by the human. The management loop is closed and runs on its own, deliberately reaching out to the human where it hits the edge of the known. Not a machine instead of people — a machine that uses human wisdom precisely, sparing it on the repeatable and turning to it for the new.

What Phase is not

Not a BPMN engine. BPMN builds a process graph with tokens; Phase builds a network of objects with phases. The unit is an object, not a process.

Not Temporal / Cadence. They orchestrate long processes through code; Phase is declarative — the lifecycle is described by configuration.

Not event sourcing. Event sourcing builds state from a stream of events; Phase stores the phase and fields directly and records snapshots on transitions.

Not a state-machine library. XState and the like provide a tool in code; Phase is a concept at the level of application architecture.

Not a status column with triggers. A status column with handlers gives transitions but not a model: declarativeness, freshness of knowledge, a journal of facts, the agent's address, and spawning and synchronisation as a primitive.

Where Phase grew from

Phase gathers into one discipline ideas with a long history: the digital enterprise inherits from management cybernetics (the Viable System Model); twin objects from the digital-twin line; the Phase object is close to an actor; fields filled by different participants are the "blackboard"; transition conditions are event–condition–action rules; the freshness of fields is bitemporal accounting; the phase lifecycle is the autonomic-computing loop (MAPE-K).

The novelty of Phase is not in the elements — each is decades-proven. The novelty is in the combination: the symmetry of human and agent, autonomy as configuration, and training data as a by-product arise only when these ideas are assembled around a single carrier — an object with a phased lifecycle.

Who it is for

Phase is addressed to teams that build business systems and want a simple, predictable engine convenient for AI coding; integrate AI agents into operational processes and need managed, auditable, gradually expandable autonomy; develop with active use of agents and value explicit patterns without magic; build platforms for business with a clear phase model.

The link to physics

The name was chosen deliberately. In physics a phase transition is an instantaneous jump of a system into a qualitatively new state when a parameter reaches a threshold. Water does not "gradually become ice" — it transitions abruptly at 0 °C. In Phase: an object is in a phase — a period of accumulation in which facts are gathered and the distillate forms; a phase transition is an atomic event when the distillate reaches the threshold. A deal does not move to "Qualified" on the client's first reply — the system accumulates facts until their totality gives grounds.

Phase v1.0 · 2026 · Vadim Soglaev, Andrey Yumashev · CC BY-SA 4.0