EFL-OSR-2025-001 / IPM APPLICATION
Abstract
Operational software is usually evaluated through availability, performance, fault tolerance and recovery. These measures describe important properties, but they say less about a problem we repeatedly encounter once a system begins interacting with infrastructure beyond its immediate control: the application may continue running while its ability to determine what actually happened starts to deteriorate.
A remote request can complete without its response returning. Local and external state can temporarily disagree. A process can stop after an operation has crossed an external boundary but before its result has been recorded locally. In these situations, the problem is partly computational and partly informational. The system has to continue from a state it can only observe incompletely.
This note applies the Informational Persistence Model (IPM) to that class of problem. IPM describes persistence through four interacting dimensions: operational intensity (η), informational complexity (K), correction capacity (c), and structural decoupling (S), related through the persistence coefficient Φ = (c·S)/(η·K).
Our interest here is practical. We examine what those dimensions mean when software has to preserve state, interpret incomplete outcomes and recover across local and external boundaries. The analysis suggests that operational continuity depends as much on preserving the right information as it does on keeping individual components available.
1. A system can be running and still be losing coherence
Architecture diagrams describe systems at their most cooperative.
A request enters an application, validation occurs, state changes, another service is contacted and a response completes the sequence. This representation is useful because it tells us how the operation is supposed to progress. It becomes less descriptive when the environment stops cooperating.
Take a relatively ordinary external submission. The application constructs a request, validates the required information, stores some local state and sends the request to another system. The connection then disappears before a response is received.
At that moment, the local application does not necessarily have an error in the conventional sense. It has several plausible histories.
The request may never have reached the remote system. It may have arrived and been rejected. Processing may still be underway. It may also have completed successfully while the response was lost somewhere on the return path.
A timeout does not distinguish among these outcomes. It establishes something much narrower: the expected response was not observed within the interval allowed by the caller.
This distinction becomes important as soon as the application has to decide what to do next. Recording the operation as failed may be incorrect. Repeating it may be unsafe. Waiting indefinitely is rarely acceptable either.
What has deteriorated is the system’s knowledge of its own operation.
IPM gives us a useful way to examine what happens from there.
2. Informational persistence in software
Within IPM, persistence concerns the ability of a system to preserve useful informational structure while it remains subject to activity, complexity and error.
Applied to software, this requires us to look beyond durable storage.
A database can be perfectly healthy while an application no longer knows how two records relate to an external operation. Conversely, a temporarily disconnected application may retain enough local state to reconstruct exactly what remains to be completed when connectivity returns.
We encountered this distinction repeatedly while examining operational workflows involving remote services. The most useful state was often quite small: an operation identifier, validated input, the last state established locally, an external reference when one existed, and an explicit indication that the remote outcome had not yet been established.
Preserving those elements changed the recovery problem substantially.
The application no longer had to reconstruct its history from a generic error message or infer what might have happened from the current database state. It had a record of the point at which certainty ended.
This suggests a more useful engineering criterion than simply asking whether data was persisted: does the surviving information allow the operation to be understood later?
Sometimes the answer requires more state. Quite often it requires less state, but better chosen state.
3. The IPM dimensions
IPM represents persistence through four interacting dimensions:
η — Operational intensity
The pressure associated with processing information and sustaining activity.
K — Informational complexity
The structure, state and dependency relationships that must remain coherent.
c — Correction capacity
The ability to detect, validate and correct error before it produces further operational consequences.
S — Structural decoupling
The extent to which disturbance can remain local rather than propagating through the larger system.
Their relationship is expressed through:
Φ = (c · S) / (η · K)
For the purposes of software architecture, Φ is useful first as a reasoning instrument. We do not need to pretend that every application already has universally comparable numerical values for η, K, c and S. The model becomes useful before that point because it forces characteristics normally discussed in isolation into a common persistence problem.
Consider what happens when an application acquires another external integration.
The new integration adds capability, but it also introduces authentication state, another protocol, new failure conditions, perhaps an external identifier and rules governing when local and remote information can be considered consistent. K has changed.
Whether that additional complexity materially reduces persistence depends partly on the rest of the architecture. If the integration is isolated and optional, its unavailability may affect one operation. If ordinary application behavior assumes that it is continuously available, the same interruption can travel considerably farther.
The integration itself has not become less reliable in the second architecture. Its consequences have changed.
That difference is what S helps us reason about.
4. What actually increases K?
It is tempting to associate informational complexity with codebase size. In operational systems, that can be misleading.
A transaction may carry a local identifier, an external identifier, a processing status, a signed representation, an acknowledgement and a later reconciliation state. None is particularly complicated on its own. The difficulty lies in preserving the relationships among them.
Imagine that the remote acknowledgement is received but the process stops before the local status is updated. On restart, two individually valid pieces of information now describe apparently different realities.
The engineering problem is not solved by storing more copies of either state.
We need to know which observation is authoritative for the decision being made, what transition was already completed and whether repeating the operation can produce another external consequence.
This kind of complexity appears quickly in otherwise modest applications. Payment gateways, electronic signature services, identity providers, tax systems and synchronization APIs all create portions of operational state whose authoritative representation may live somewhere else.
The practical cost of an integration therefore extends beyond making the API call. Every external boundary can add states the local architecture must be capable of interpreting.
We have found it more useful to reduce this burden through explicit boundaries and ownership than through aggressive simplification of the software itself. A larger architecture with well-defined state ownership can present a smaller persistence problem than a compact application in which several components implicitly depend on one another.
5. Correction while context still exists
Correction capacity, c, includes mechanisms that software teams often discuss under different headings.
Validation is one of them, but correction begins before and continues beyond input validation. Schema checks, duplicate detection, reconciliation, consistency checks and verification against an authoritative source all contribute to the system’s ability to prevent an incorrect state from acquiring additional consequences.
Timing matters here.
Suppose an identifier is structurally valid but refers to a different entity than the operation expects. Detecting that condition at the boundary is relatively cheap. Discovering it after the identifier has been accepted by several downstream processes turns the same error into a reconstruction problem.
External systems add another complication: successful transport tells us little about semantic success.
An HTTP exchange may complete normally while the application-level operation is rejected. A response may be valid XML or JSON while carrying information that contradicts local assumptions. Authentication can succeed against an endpoint that is nevertheless inappropriate for the operation being attempted.
Flattening all of those conditions into success and error makes implementation simpler for a while. It also removes distinctions that become valuable during diagnosis and recovery.
We therefore treat correction capacity partly as a question of how long the architecture retains enough context to recognize that something has diverged.
That is a different property from merely having exception handling.
6. The external boundary changes the problem
A local process can be instrumented extensively. Once execution crosses into infrastructure controlled by another organization, observability becomes asymmetric.
This is routine in modern software, but its consequences deserve more attention.
Consider an integration in which several failures produce visibly similar behavior to the caller. An incorrect endpoint might return a protocol error. Another route might terminate the connection. A temporary service problem may produce an HTTP 500 without a useful body. A valid request might be processed remotely even though the connection fails before confirmation reaches the application.
From the user’s perspective, each may initially look like “the service didn’t work.”
For recovery purposes they are very different observations.
The protocol error tells us that communication occurred and gives us information about how the remote system interpreted the request. A connection reset tells us something about transport but potentially very little about application processing. A structured rejection can sometimes establish conclusively that the business operation did not occur.
The amount of uncertainty remaining after each event is different.
This matters because software frequently allows its user-facing error model to become its internal evidence model. Several distinct technical conditions are translated into the same message and, eventually, into the same stored state.
Once that happens, information useful to later reasoning has already disappeared.
7. Unknown is occasionally the correct state
This problem became particularly clear when considering operations that have external consequences.
Assume a request has been sent and no conclusive response is available. The application has evidence that an attempt occurred but insufficient evidence to classify its outcome.
There is a strong temptation to convert that situation into one of the states the rest of the application already understands. Usually that means FAILED.
Doing so can make the workflow easier to implement. It can also make a subsequent retry dangerous.
An explicit unresolved state gives us more options. The operation can be verified against an authoritative source. Automatic retry can be suspended. An operator can see that intervention may be required. If later evidence establishes the result, reconciliation can close the state without reconstructing the original operation from logs.
There is an important practical limit here. Representing every imaginable uncertainty would increase K rapidly and make the application difficult to operate. We are interested in uncertainty when it affects the safety or meaning of the next action.
A missing decorative resource does not need an epistemic state machine.
An external financial, fiscal or signed operation might.
That distinction is architectural rather than philosophical.
8. S and the question of what has to stop
Structural decoupling becomes visible when a dependency disappears.
During architecture work we often ask whether a service is required. A more revealing question is: what exactly has to stop when this service is unavailable?
The answers are frequently broader than the actual business requirement.
Suppose a remote service provides reference information that changes infrequently. Querying it during every transaction guarantees freshness, but it also makes every transaction dependent on the service’s immediate availability.
Maintaining an appropriate local representation changes that dependency. Ordinary processing can continue while synchronization becomes a separate concern.
The trade-off is real. Local data introduces freshness rules, update mechanisms and another state relationship to maintain. K may increase even while S improves.
This is precisely why an IPM analysis cannot reduce architectural decisions to slogans such as “offline-first is better” or “local state is safer.” Either design can fail badly if its correction mechanisms are inadequate.
For EventFlow’s operational systems, we generally favor preserving useful local capability where correctness permits it. Final authoritative actions may remain online operations. Preparation, validation, local state management and unrelated capabilities often do not need to inherit the same restriction.
The boundary has to be discovered rather than assumed.
9. Recovery requires a record of what mattered
After an interrupted operation, infrastructure recovery is often the easy part. The network returns. A process restarts. The database is reachable again.
Then somebody has to determine where the operation was left.
This is where indiscriminate logging and deliberate operational persistence diverge.
A large log may contain enough information to reconstruct an event manually, but that does not mean the application can safely resume it. Recovery benefits from state that was designed to survive: stable identity, the input that was actually accepted, relevant transition information, external references and an indication of what had or had not been confirmed.
How much should be retained depends on the operation.
During our work we have used the idea of a minimum sufficient operational record as a practical test. The record should be small enough that persistence does not become another source of uncontrolled complexity, while retaining enough information to answer three questions after interruption:
- What had already been established?
- What remained unresolved?
- What actions are now safe?
Those questions tend to expose missing state quickly.
They also reveal unnecessary state. If a piece of persisted information cannot contribute to reconstruction, verification or a subsequent operational decision, its value deserves examination.
10. Architectural changes move several variables at once
The interaction among η, K, c and S becomes most useful when evaluating apparently beneficial architectural changes.
A queue is a good example.
Introducing one between two services can prevent temporary unavailability from stopping the caller. That improves isolation and can increase S. The queue also creates additional state: delivery status, retry behavior, ordering, acknowledgement semantics and perhaps dead-letter handling. K rises.
Whether persistence improves depends on how those new responsibilities are handled.
Retries show the same dual behavior. With stable operation identity and appropriate idempotency, they can contribute to recovery. Without those properties, retries can multiply external consequences.
Redundancy can increase availability while introducing synchronization states that were absent from the simpler architecture.
Caching can remove an external dependency from a critical path while creating questions about freshness and invalidation.
None of this makes queues, retries, redundancy or caching undesirable. It shows why evaluating them individually is insufficient.
Φ forces us to ask what else moved when we changed the architecture.
In practice, this has proved more useful than treating resilience mechanisms as items on a checklist.
11. From model to engineering practice
The most immediate application of IPM in software engineering is not numerical optimization. It is architectural interrogation.
When reviewing an operation, we can trace where information originates, which transformations matter, where authoritative state resides and which boundaries introduce conditions the local system cannot directly observe.
At some point in that review, a few questions usually become uncomfortable.
- If this dependency disappears now, what still works?
- If execution stops after this call, can we determine tomorrow whether the operation happened?
- If the remote system and our database disagree, which one are we prepared to trust, and for what?
- Can this retry produce a second real-world consequence?
- Are we storing this state because recovery needs it, or simply because it was convenient to persist?
Those questions do not map neatly into four independent boxes labelled η, K, c and S. Real architectures do not behave that cleanly. A decision intended to improve one dimension often changes another.
That interaction is precisely the point of the model.
IPM provides a vocabulary for discussing those trade-offs without pretending that reliability can be isolated from complexity or that redundancy automatically produces persistence.
12. Closing observation
Operational systems rarely fail in the clean sequence represented by a failure diagram.
More often, conditions degrade unevenly. One dependency becomes slow. A response disappears. State diverges temporarily. An operation reaches a remote system while its local process loses track of the outcome. Everything else may continue functioning.
The difficult part is deciding what the software still knows.
This is where informational persistence becomes useful as an engineering concept. It directs attention toward the information and relationships that must survive changing conditions, while IPM provides a broader framework for examining the pressure created by activity and complexity against the corrective and structural mechanisms available to contain it.
There is no implication that a persistent architecture will continue every operation indefinitely. Some actions must stop when an authoritative service is unavailable. Some uncertainty cannot be resolved locally. Some state should deliberately expire rather than persist.
The engineering objective is more modest and, in practice, more demanding: preserve enough coherence that interruption does not force the system to guess about its own history.
When that property exists, recovery has something reliable to work with.
When it does not, restoring infrastructure may only restore access to an ambiguous state.
Document record
Document ID: EFL-OSR-2025-001
Title: Informational Persistence in Operational Systems
Document type: Technical Research Note / IPM Application
Category: Operational Systems Research
Publication year: 2025
Institution: EventFlow Labs
Language: English
Revision: 1.0