Admissible Transition ​

In Realith, a transition is not simply a data change and not simply a new message in the log. A transition is an admissible transformation of a structurally defined object.

That is why a new version cannot be considered current merely because someone signed it, sent it, or recorded it later than others.

What makes a transition admissible ​

For a transition even to be able to claim a change of current state, it must be compatible at minimum with the following layers:

• the structure version to which the object corresponds;
• the properties of that structure;
• the applicable contour;
• permissions for the action;
• the admissibility policy;
• the causal line of the object.

This is what distinguishes a transition from a simple data mutation.

Transition is not the same as event ​

An event may report that something happened. But in Realith, transition has a narrower and stricter meaning.

A transition is a step that:

• rests on a distinguishable prior version or on an admissible primary creation;
• is compatible with the structure of the object;
• does not destroy causal continuity;
• may change the active version;
• is capable of affecting canonical current state.

Therefore, not every event is a transition.

What a transition may do ​

Depending on the structure and the environmental regime, a transition may:

• create a new object;
• create a new version of an existing object;
• extinguish a former active version as the current basis;
• produce a derived object;
• change the object's relations;
• launch a separate conflict-resolution line.

But in all cases it must remain a step of the model rather than just a technical record.

If a transition is not constrained by structure and causal discipline, Realith once again turns into an ordinary event-first system where current state is derived locally.

For Realith that is unacceptable. Here the network must distinguish not merely a flow of what happened, but admissible steps in the change of the object's line.