Regime Awareness: Capability Development Across Four Field Cases

From Operational Control to a Domain-Agnostic Framework

Overview

This field case reconstructs the engineering trajectory behind the present Regime Awareness proposal: a closed-loop architecture intended to detect observable loss of compatibility with a declared operating regime and to support bounded changes in buffers or capacity before surface-level failure. Whether it detects such loss reliably, early enough and at acceptable cost is an empirical question addressed by the H1–H3 validation programme. The present abstraction was reconstructed retrospectively from four engineering mandates in transport logistics, institutional fintech, enterprise transformation and process intelligence. The mandates were not prospective tests of the current theory; they supplied design patterns and failure modes from which the present hypotheses were later formulated. What follows is a technical reconstruction of the control patterns that recurred across these mandates and that now converge into a domain-agnostic framework for regime-aware control in constrained systems. How to read the chronology. The dates below identify production mandates reconstructed from project records; they are not dates on which the present Regime Awareness vocabulary or theory had already been established. GEPLAN, xSeil, Phylon and the later enterprise work were distinct implemented systems. Their continuity is a retrospective engineering claim developed in the phase narratives below; the current formal statement is documented in Minimalistic Regime-Aware Early Warning Systems, while current institutional uses are listed under Research Contributions. Independent validation remains separate from this field evidence.

Evidence vs. Validation

The work presented here is grounded in production-grade implementations: operational logistics at Experiencias Xcaret, an institutional fintech liquidity mandate, and application rationalization integrated with JUBAP.Net Process Mining™ capabilities at Richemont and Cartier. These implementations provide engineering provenance for several components later included in the framework. Because the current framework was formalized retrospectively and the cases were not evaluated under a common pre-specified protocol, they do not yet establish the framework’s viability, comparative performance or generalizability. The framework is not presented as a finished theory. The current role of the Tegrity.AI Circle is to challenge, validate, formalize, and generalize this capability—transforming a family of engineered solutions into a coherent, domain-agnostic reference architecture suitable for research, benchmarking, and broader operational adoption.

Phase 1 (2006) — Enterprise Portfolio Control: JUBAP.Net GEPLAN™

Origin and Problem Class

The first formalized mandate, initiated in 2006, addressed enterprise-scale capacity and portfolio governance under constrained resource environments. JUBAP.Net GEPLAN™ was designed as a planning and control layer capable of monitoring structural stability across large interdependent application and process portfolios. The foundational insight was that capacity signals in enterprise systems are not static metrics but dynamic indicators whose meaning shifts with accumulated load, interdependency density, and systemic coupling—requiring a control architecture that could interpret state rather than merely aggregate it.

Phase 2 (2016) — Transport Logistics: Propagation-Aware Planning Under Hard Constraints

The Origin Problem Class

The mandate at Experiencias Xcaret, Latin America’s largest integrated tourism operator, managing seven theme parks and roughly 500 hotels, with approximately 12,000 passengers transported daily, presented a constrained resource allocation problem with an unusual combination of properties that rendered standard routing and scheduling approaches inapplicable. Fully committed demand with zero flexibility. Reservations were sold through a distributed reseller network with no pre-sale capacity validation; by the time demand reached the planning engine, every commitment was already fixed in time, location, and service type, and could not be renegotiated or rejected. NP-complex combinatorial structure. Each decision resolved as a joint passenger × vehicle × route assignment, with the engine evaluating on the order of 60 million feasible configurations per assignment under live operational constraints. High propagation sensitivity. Each assignment consumed seats, time windows, and route structure, reshaping the feasible space for all subsequent decisions, such that a single local change could trigger system-wide cascades. Dynamic, non-fixed objectives. The effective cost of violating punctuality, vehicle policy, fuel, or occupancy constraints was not static; it shifted continuously as a function of accumulated delays, fleet readiness, and global network state. Multiple tier-one logistics providers had concluded that the problem did not fit existing operational models; no out-of-the-box solution was available.

Architectural Response: JUBAP.Net xSeil™ as a Logistics Operating System

JUBAP.Net xSeil™ was not built as a narrow vehicle-routing solver but as a full logistics operating platform structured across several operational layers. An integration and normalization layer ingested and cleansed fragmented inputs from reservation systems, GPS telemetry, and operational sources, explicitly rejecting inconsistent data such as duplicate hotel names, invalid vehicle identities, or reservations lacking valid configurations. A fleet readiness layer tracked maintenance state, workshop conditions, operational roles, and real availability of each unit, ensuring that planning decisions were grounded in actual fleet capacity rather than static inventories. A planning and optimization layer generated scenarios across more than one hundred operational rules, balancing load factor, punctuality, directness, transfer structure, rental usage, and policy constraints. A real-time monitoring layer fused GPS telemetry with mobile field execution, closing the loop between planned routes and actual movement, boarding, and punctuality. A dynamic adjustment layer managed estimated times of arrival, dynamic route-sheet updates, transfer-center coordination, reassignments, and copiloto logic for target cruising speed. A managerial intelligence layer provided dashboards and reports for punctuality by unit, route, driver, hotel, and destination, exposing stability and service-level behavior to management. The stack was implemented on Linux/POSIX with Python 3, Django, PostgreSQL, Redis Cache, and Android/iOS clients, designed for approximately 250 concurrent users under mission-critical operating conditions.

Core Control Mechanisms

Three mechanisms emerged within this platform that later generalized into the Regime Awareness Capability.

Mechanism 1: Fragility as a Capacity Signal

A propagation-likelihood proxy was defined as Fₚ = P(A) × P(P | A) = P(A ∩ P) where A denotes a local anomaly and P denotes downstream propagation. If a separately reported propagation probability Pₚ is not explicitly conditional on A, substituting Pₚ for P(P | A) would require an independence assumption and should not be done without justification. Because probability alone does not represent consequence severity, an operational risk quantity should additionally include loss, for example R = E[L | A ∩ P] × P(A ∩ P), with its estimation assumptions stated. The critical design choice was behavioral: when F increased, the system did not attempt more aggressive optimization; it switched from optimization to protection, introducing slack through rented units, time buffers, and reduced coupling between routes. Capacity was treated not as an output of optimization, but as a precondition for safe operation.

Mechanism 2: Dynamic Internal Pricing of Objectives

Instead of fixed weighted sums, each objective was represented through demand and supply functions over a state-pressure variable: D_i(x) = a_i + b_ix
S_i(x) = c_i − d_ix with a quadratic extension near critical regions: D_i(x) = a_i + b_ix + e_ix²
S_i(x) = c_i − d_ix − f_ix² The internal price of each objective was obtained by solving D_i(x) = S_i(x), recomputed before each planning cycle. When accumulated delays increased the marginal cost of punctuality, the mechanism automatically raised its internal price and deprioritized secondary objectives such as fuel minimization or stop reduction—in terms that dispatchers and managers could interpret operationally.

Mechanism 3: Stability Partitioning and Decision Memory

Reservations were organized into cooperative groups—sets of compatible assignments that could safely be optimized together—and then partitioned into low-propagation clusters whose local resolution was unlikely to destabilize the rest of the network. The system resolved these clusters sequentially from most stable to most entangled, progressively locking in useful structure and shrinking the active search space. Decision memory stored previously evaluated trip patterns, cluster configurations, and allocation structures, transforming part of the combinatorial search into informed retrieval with local adjustment under time pressure. A Global Utility metric governed stopping: the search halted when a solution crossed a sufficient utility threshold, favoring satisficing under propagation risk over pursuit of a theoretical global optimum that was operationally infeasible.

Phase 3 (2018) — Institutional Fintech: Signal Architecture for Regime Change

Proposed Structural Correspondence

Retrospective engineering analysis identified a partial structural correspondence between the liquidity-control mandate and the xSeil framework: both can be represented as constrained allocation over a changing network. This shared representation is a transfer hypothesis. A formal isomorphism would additionally require specified structures and a bijective map that preserves the relevant operations and relations.

• Vehicle seat capacity → liquidity pools
• Passenger assignments → liquidity allocations
• Routing and timing constraints → transfer, settlement, and reserve constraints
• Structural slack in routes → liquidity reserves and safety buffers
• Reassignments under perturbation → liquidity stress propagation
• Operating regimes in logistics → market and liquidity regimes

Under this proposed mapping, feasibility, constraint satisfaction, propagation dynamics and the efficiency–antifragility trade-off have plausible counterparts. This supports a transfer hypothesis: the two systems may belong to a broader class of nonlinear allocation problems under propagation risk.

Why Standard Predictive Models Were Insufficient

In the fintech context, relevant signals were not directly observable and required months of data acquisition and signal discovery before modeling could begin. Early-warning indicators from nonlinear dynamics—variance increase, rising autocorrelation, critical slowing down—provided a theoretical foundation but proved insufficient in noisy, partially observable, context-dependent environments. In the deployed setting, the available modelling approach did not provide the component-level traceability and low-latency reassessment required to determine which factors remained operationally admissible after a suspected regime change. This limitation motivated an explicit representation of component provenance and validity. It is not a claim that all black-box, drift-aware or explainable-ML methods require full retraining.

JUBAP.Net Phylon Neural Networks™: Signal Architecture and Proto-Agent Framing

The engineering response was the JUBAP.Net Phylon Neural Networks™ architecture, centered on the notion of a phylon as a functional unit with a defined objective and an evaluable contribution to a global outcome. A phylon combines the role of a predictive feature with that of an explicit, traceable unit: each records its composition, influence graph, and historical contribution across regimes. The architecture is hierarchical:

• Level 1: raw phylons capturing local stress, coupling, propagation potential, and structural asymmetries
• Level 2: teams of Level-1 phylons retained only when combinations increase robustness beyond individual contributors
• Level 3+: super-teams of teams, capturing interaction effects invisible at lower levels

To maintain robustness in non-stationary environments, all signals are transformed into discrete distributions rather than treated as continuous variables, simplifying relationships, improving interpretability, and stabilizing behavior across regime transitions.

Regime Change Response: The Dual-Attractor Mechanism

The critical operational property is the behavior under regime shift. Suppose the network monitors 400 phylons and 40 begin to exhibit distributional patterns inconsistent with the current regime. Because every node contains its full composition recipe in a structured representation, the network can immediately compute two attractors without retraining: Attractor A — stable regime persistence. Constructed by pruning all nodes dependent on the 40 outlier phylons, retaining a subnetwork based on the remaining 360 stable phylons—representing the hypothesis that the anomaly is transient and the previous regime will reassert itself. Attractor B — regime transition. Constructed by amplifying the influence of the 40 outlier phylons, representing the alternative stable configuration toward which the system would evolve if these signals define a new operating regime. With relatively few new data points, the system can determine which attractor’s predictions align more closely with observed reality, providing actionable early warning with minimal data and without full retraining cycles.

Phase 4 (2023) — Enterprise Rationalization: JUBAP.Net GEPLAN™ and JUBAP.Net Process Mining™

Third Cross-Domain Extension

Beginning in 2023, within a large-scale Application Portfolio Management and rationalization program at Richemont and Cartier, the framework was extended to enterprise transformation supported by JUBAP.Net Process Mining™ capabilities and platforms including Celonis, Signavio, SAP, and Salesforce. A similar candidate correspondence was observed:

• Seats and vehicle capacity → application and microservice capacity
• Passenger assignment → process instance routing over applications and services
• Routing constraints → SLA, sequence, and dependency constraints in process flows
• Structural slack in transport → functional redundancy, alternative execution paths, and latent headroom
• Cascade of reassignments → rework, backlog accumulation, and SLA-breach propagation

APM and JUBAP.Net Process Mining™ are not separate perspectives but complementary projections of the same system: APM provides the structural graph of resources and dependencies, while Process Mining reconstructs dynamic execution trajectories and effective couplings between steps. Neither alone is sufficient to understand how the system reacts when capacity is removed and shocks propagate.

Control Layer and Fragility Derivative as Stopping Signal

JUBAP.Net GEPLAN™ introduces a regime-aware control layer that sits on top of APM and Process Mining as an external analytical engine implemented in Python, consuming process telemetry via APIs, enterprise workflows, action flows, and agentic execution layers. The sensor layer reads Process Mining outputs as continuous telemetry, extracting queue growth, cycle-time degradation, rising variability, rework patterns, and coupling intensity between steps—interpreting these as indicators of fragility and regime weakening, analogous to capacity saturation and propagation probability in JUBAP.Net xSeil™ and liquidity stress in the fintech phase. The fragility function is recomputed from process telemetry: F = P_a × P_p The critical operational signal is the derivative dF/dt, interpreted as a regime-weakening indicator. When dF/dt crosses a defined threshold, the controller concludes that continued capacity reduction—such as retiring an application that appears redundant by static APM metrics—may risk driving the process network into a fragile regime. The engine can solve an internal D(x) = S(x) balance to estimate the protective buffer response required, or to identify which retirement candidates should be paused. Interventions may include pausing or slowing rationalization, rerouting execution load, activating additional capacity as digital buffers, or triggering reversal workflows through ITSM platforms such as ServiceNow. The result is a digital immune system for enterprise transformation.

Regime Awareness Capability: The Coherent Abstraction

Across all four phases, a consistent structural pattern emerges. Each mandate is narrower in business scope yet requires deeper modeling, stronger formalization, and more explicit treatment of nonlinear dynamics, propagation, and regime change. The resulting capability is not a forecasting engine in the classical sense: it does not attempt to predict exact future states in chaotic regimes—often impossible in principle. Instead, it focuses on detecting when the current operating regime is losing structural stability, so that capacity, buffers, or control posture can be adjusted before failure modes become visible at the surface. Four core properties define Regime Awareness Capability in its current form:

• Propagation control. Limiting cascade effects by detecting fragility increases early and allocating buffers dynamically before shocks reach critical thresholds.
• Structural explainability. Maintaining explicit compositions, influence graphs, and historical contributions at every level—enabling diagnosis, selective pruning, and regime-adaptive reconfiguration without full retraining.
• Efficient adaptation under regime change. Using dual-attractor logic to construct alternative stable configurations immediately upon detecting outlier behavior, without waiting for large datasets and full retraining cycles.
• Candidate cross-domain transfer. A partial structural correspondence is proposed across transport logistics, institutional fintech and enterprise IT; whether it generalises beyond these reconstructed cases remains to be tested.

Why This Belongs in the Tegrity.AI Circle

The current work is no longer the implementation of a domain-specific platform, but the articulation of a domain-agnostic capability for structural self-awareness in adaptive systems. What is required next is not incremental feature development, but rigorous validation, formalization, and generalization: identifying the minimal abstractions, boundary conditions, and failure modes that make Regime Awareness Capability transferable across sectors and architectures. The Tegrity.AI Circle provides the environment where this can be done credibly: a network of researchers, practitioners, architects, and domain specialists in complex systems, adaptive control, AI integrity, computational thermodynamics, and systemic risk, capable of challenging both the engineering assumptions and the mathematical formulations. Within this Circle, the framework is treated as a candidate reference architecture for regime-aware control in constrained systems—to be stress-tested, refined, and documented in a way that makes it usable for research, benchmarking, and operational adoption under diverse regulatory and governance regimes.

Current Status and Path Toward Broader Publication

The code, models, and architectural patterns described in this field case were contributed by JUBAP.Net, an Adaptive Systems Lab based in Mexico, also operating in San Francisco, USA, across four production mandates spanning 2006 to 2023: the JUBAP.Net GEPLAN™ lineage in enterprise portfolio control, JUBAP.Net xSeil™ in mission-critical transport logistics, the JUBAP.Net Phylon Neural Networks™ architecture in institutional fintech liquidity management, and JUBAP.Net GEPLAN™ integrated with enterprise-grade JUBAP.Net Process Mining™ and APM platforms at Richemont and Cartier. Within the Tegrity.AI Circle of The Integral Management Society (IMSV.org), this material is entering an independent evaluation phase focused on validating the core mechanisms, clarifying applicability conditions, and mapping the space of regimes where the framework is effective. The intent is to progress toward an open-reference framework—potentially open-source or otherwise openly specified—once the Circle concludes that the abstractions are sufficiently robust and clearly delimited. Until that point, JUBAP.Net xSeil™, JUBAP.Net Phylon Neural Networks™, JUBAP.Net GEPLAN™, and JUBAP.Net Process Mining™ remain proprietary implementations of this trajectory, while the underlying concepts are progressively distilled into a domain-agnostic regime-aware control framework suitable for broader publication.

Conceptual neighbours and references

• Nearby work. Scheffer and colleagues survey early-warning signals for critical transitions; Ashby’s cybernetics relates viable regulation to the variety a controller can absorb.
• Useful connection. These traditions motivate monitoring structural stability before surface failure, across domains with different physical meanings.
• Most distinctive contribution here. The field cases motivate a candidate correspondence across seats, liquidity, application capacity and routes: propagation-aware fragility, state-dependent objective prices, decision memory, dynamic buffers and protective switching are proposed as components of one transferable capability, not as a validated cross-domain equivalence or future-value forecast.