Class of Problems: Applicability Criteria ​

The applicability of Realith must be determined not by the name of an industry, but by the type of architectural insufficiency in the existing environment.

The minimal class of problems for which the Realith architecture makes sense at all is defined here.

Basic class of problems ​

The minimal applicability criterion looks like this:

1. there is an addressable object, not merely a flow of messages;
2. the object has a line of versions and transitions;
3. further coordination depends on the current recognized configuration;
4. the object passes through several independent subjects;
5. there is no acceptable single center of interpretation to which all parties are willing to delegate meaning unconditionally.

The insufficiency of an ordinary platform ​

If the entire process genuinely belongs to one owner of the environment, a centralized system is usually simpler and cheaper. Realith is needed not where everything can be assembled into one internal cabinet, but where such centralization already changes the very nature of coordination.

In other words, Realith is needed not for “automation in general,” but for inter-subject coordination around one and the same object.

The insufficiency of a single event log ​

An ordinary event log is good at fixing the sequence of what happened. But that is not enough when several parties need not merely to know history, but to have a shared answer to the question:

What is currently considered the valid state of the object?

If without this answer the process cannot continue, a derived result cannot be issued, readiness cannot be recognized, action cannot be constrained, or responsibility cannot be shifted, then Realith becomes architecturally appropriate.

Applicability formula ​

In its most compressed form, Realith is appropriate where the object already requires not only a log of the past, but also a shared architectural basis for the next step.