Applying ANF to Clinical Exercise Data: HRV, Recovery, and Human Adaptation

In my recent posts, I explored how the Area of Normal Functioning — ANF — can be applied beyond computer systems.

I started with sport-performance data, including SoccerMon athlete-monitoring data and longitudinal runner training logs. Those examples showed that ANF can describe an athlete’s normal training-load range, detect unusual weeks, identify shifts in the normal regime, and even suggest possible training cycles.

This time I wanted to test ANF on a different kind of human-performance dataset: not competitive sport, but clinical exercise and recovery monitoring.

For this experiment, I used the ATOPE+Breast dataset, which contains daily monitoring records for breast-cancer patients during a therapeutic exercise intervention. The uploaded records.csv file includes daily fields for patient ID, study day, training-session information, HRV metrics, wellness self-reports, sleep, and activity/steps. The available fields include lnrmssd, recovery, fatigue, distress, sleep_satisfaction, sleep_time, Fitbit sleep fields, and step/activity metrics.

This makes the dataset especially interesting for ANF. The goal here is not athletic performance. The goal is safer human adaptation: how a patient responds to exercise, recovery, sleep, fatigue, and treatment context over time.

Why this dataset is different

In runner or soccer data, the main question is often about performance:

- Is the athlete training inside a normal load range?

In clinical exercise data, the question is different:

- Is the patient recovering and adapting within their own normal functional range?

That makes ANF potentially useful as a patient-specific monitoring layer. It does not diagnose medical problems, and it should not replace clinical judgment. But it can help highlight when a patient’s daily recovery or physiological state moves away from their recent normal pattern.

For a first proof of concept, I selected one patient with a relatively long daily history and built ANF charts using rolling percentile boundaries.

The model used:

• rolling baseline from recent observations,
• CL = P50,
• UCL = P95,
• LCL = P05,
• gray band = ANF,
• orange points = outside the ANF,
• vertical markers = training-session days.

Chart 1 — LnRMSSD / HRV ANF

Figure 1. Patient-specific ANF for LnRMSSD, an HRV-based physiological recovery metric. The gray band shows the recent normal range; points outside the band indicate days outside the patient’s recent physiological recovery pattern.

The first chart uses LnRMSSD.

LnRMSSD means the natural logarithm of RMSSD, a common heart-rate-variability metric. In practical terms, it is often used as an indicator of autonomic recovery or physiological readiness.

For ANF, this is important because it gives us a more objective physiological signal than self-reported wellness alone.

In this chart, the ANF band represents the patient’s recent normal range of HRV-based recovery. A day below the lower boundary may suggest that the patient’s physiological recovery is lower than usual. A sustained downward movement may indicate stress, fatigue, treatment burden, poor sleep, or another contextual factor.

Of course, one point should not be over-interpreted. Human physiology is noisy. The value of ANF is not in treating one daily value as a diagnosis, but in showing how the patient’s recovery pattern behaves relative to their own recent baseline.

Chart 2 — Recovery Risk Index ANF

Figure 2. Patient-specific ANF for a recovery-risk index based on subjective recovery and wellness variables. Higher values indicate worse recovery state relative to the combined subjective indicators.

he second chart uses a combined recovery-risk index.

This index summarizes the subjective side of recovery: perceived recovery, fatigue, distress, and sleep-related state. The dataset includes daily self-reported variables such as recovery, fatigue, distress, sleep_satisfaction, and sleep_time.

This chart is interesting because it represents the “human feeling” side of the same process. HRV may show physiological recovery, but subjective wellness may show how the patient actually feels.

In ANF terms, the recovery-risk chart asks:

Is the patient’s perceived recovery state still within their recent normal range?

Days above the upper boundary may suggest unusually elevated recovery risk — for example, higher fatigue, lower perceived recovery, poorer sleep, or higher distress. Again, ANF does not explain the cause by itself. It highlights the departure from the patient’s own recent normal state.

Why the combination matters

The most interesting part is not either chart alone, but the idea of comparing them.

A patient may have:

• normal HRV but poor subjective recovery,
• low HRV but normal self-reported recovery,
• both signals inside ANF,
• or both signals outside ANF.

That combination may be more useful than a single metric.

For example, if HRV drops below normal and the recovery-risk index rises above normal, that may be a stronger signal that the patient is under unusual strain. If only one signal changes, the interpretation may require more context.

This is very similar to the way I previously connected business-driver metrics with computer-system metrics. A single signal is useful, but two related ANFs can provide a better diagnostic picture.

From sport performance to human recovery

This example broadens the ANF idea.

In the runner dataset, ANF described normal weekly training load.
In SoccerMon, ANF described athlete load and wellness/readiness.
In ATOPE+Breast, ANF describes patient-specific recovery and adaptation during therapeutic exercise.

That is an important step.

It suggests that ANF may apply not only to computer systems and athletes, but also to broader human recovery and rehabilitation contexts.

The common question remains the same:

What is normal for this system, at this time, and when has that normal changed?

First conclusion

This is still an exploratory proof of concept, but it is a useful one.

The ATOPE+Breast dataset shows that ANF can be applied to daily human recovery data, combining physiological, subjective, sleep, activity, and training-session information.

For me, the main takeaway is:

ANF can help describe a patient-specific area of normal recovery and adaptation.

This should not be interpreted as medical diagnosis. Instead, it is a monitoring and interpretation framework that may help clinicians, coaches, researchers, or patients notice when daily recovery patterns move outside the recent normal range.

In the broader ANF research direction, this dataset provides an important bridge:

• from technical systems,
• to sport-performance systems,
• to clinical human adaptation and recovery.

That makes it a valuable addition to the future ANF paper.

Applying ANF to Runner Training Data: Load Boundaries, Change, and Training Cycles

In my previous posts, I discussed the idea of the Area of Normal Functioning — ANF — as a way to describe how dynamic systems normally behave, when they move outside their normal range, and when their “normal” itself changes.

Most of my earlier work came from computer-system performance analysis: capacity, workload, anomalies, change points, and trends. But I am now exploring whether the same logic can be applied to human performance systems, especially sport-science data.

After my first ANF experiment with the SoccerMon dataset, I tried another open dataset: Injury Prediction for Competitive Runners.

Dataset source:
https://github.com/sonicjoy/Injury-Prediction-for-Competitive-Runners

For this first analysis, I selected one runner with a long usable history and focused on a simple metric:

weekly total kilometers (total kms)

In sport terms, this is a basic measure of external training load.

Building the ANF

For each week, I calculated ANF boundaries using the previous 12 weeks of data:

• CL = rolling P50
• UCL = rolling P99
• LCL = rolling P01

The area between LCL and UCL represents the runner’s recent normal weekly load range.

This is important: the ANF is not fixed. It moves as the runner’s recent training pattern changes.

Figure 1 — Full-history ANF chart

The full chart shows that the runner’s normal weekly load was not constant. The ANF band moves up and down over time, reflecting changes in the runner’s typical training level.

This is already useful. Instead of looking only at isolated high or low weeks, ANF shows the evolving “normal” range of the athlete.

One especially interesting feature is the major downward shift late in the series. The actual weekly load drops, but more importantly, the ANF boundaries also move downward. In ANF terms, this means the runner’s normal load range changed.

This does not prove the cause. It could be related to injury, recovery, a change in training plan, seasonality, reduced availability, or another contextual factor. But the pattern is meaningful:

the runner was no longer operating within the same normal load range as before.

Figure 2 — Zoomed view of the late shift

The zoomed chart makes the late downward shift easier to see. Before the shift, the runner’s normal weekly distance was much higher. After the shift, both the center line and ANF boundaries moved to a lower level.

This is a good example of why ANF may be useful. It helps distinguish between:

• a one-week anomaly,
• a temporary fluctuation,
• and a real change in the underlying functional regime.

I also reduced the sensitivity of change-point detection so that the chart highlights only major regime changes. This produced a cleaner and more interpretable result.

Possible oscillation and training cycles

Another interesting observation is that the ANF band seems to move in repeated waves. It does not simply drift randomly.

A preliminary periodicity check suggested a broad recurring cycle around 46 weeks, with additional medium-scale patterns roughly in the 28–40 week range.

I would not over-interpret this yet, but it may reflect:

• seasonality,
• training macrocycles,
• buildup and recovery phases,
• or repeated changes in the runner’s training plan.

This is an interesting extension of the ANF idea. ANF may help detect not only anomalies and change points, but also repeated shifts in the normal operating range of a human performance system.

Why this matters

In computer performance engineering, we often ask:

• What is normal behavior?
• When is the system outside normal limits?
• Has the system changed?
• Is there a trend?
• Is there a recurring pattern?

The same questions can be meaningful for athlete data.

This runner example shows that ANF can describe:

• a typical weekly load range,
• unusually high or low load weeks,
• a major downward regime shift,
• and possible periodic training structure.

For me, the most important finding is not simply that the runner’s load dropped. The more interesting point is that the runner’s normal range moved downward.

That is exactly the type of behavior ANF is designed to capture.

First conclusion

This is still an exploratory analysis, but it provides another encouraging proof of concept for applying ANF beyond technical systems.

A runner, like a computer system, has a changing area of normal functioning. That area can expand, contract, shift, oscillate, or break.

Understanding those changes may be useful not only for performance engineering, but also for sport science, training analysis, and broader human-performance research.

Applying ANF to SoccerMon Data: A First Look at Load, Wellness, and Readiness

 As a first independent proof of concept, I applied the Area of Normal Functioning — ANF — idea to open SoccerMon athlete-monitoring data.

This work continues the broader ANF direction I described in my earlier post:
https://www.trub.in/2026/06/expanding-area-of-normal-functioning.html

The data source for this experiment is the open SoccerMon dataset:
https://zenodo.org/records/10033832

The goal was not yet to build a final predictive model. The goal was simpler: to see whether ANF can be defined from real sport-science data and whether it can help us interpret training load, wellness, readiness, and possible overload patterns.

For this first experiment, I selected one player with relatively complete longitudinal data. I built two weekly IT-control-style charts:

1.      Weekly training load

2.      Weekly wellness/readiness risk

Both charts use the same ANF logic. For each week, the athlete’s current value is compared with the previous 12 weeks of history.

The control limits are percentile-based:

·         CL = rolling median, or P50

·         UCL = rolling P95

·         LCL = rolling P05

The area between LCL and UCL represents the athlete’s recent Area of Normal Functioning.

Weekly load as external demand

The first chart looks at weekly training load. I calculated weekly load as the sum of daily load values within each week.

In ANF language, this chart shows the athlete’s normal range of external training demand. When weekly load stays inside the ANF band, it means the athlete is training within the range that has recently been normal for her.

When weekly load rises above the UCL, it means the athlete is experiencing a higher load than expected based on her recent history. This may indicate overload, an aggressive training ramp-up, or a temporary excursion beyond the normal functional range.

Several above-UCL weeks appeared in the data, especially during periods of rapid increase in training load. Some of these high-load excursions occurred near weeks with injury reports. This does not prove causality, but it suggests that the upper ANF boundary may be useful as an overload-warning signal.

The LCL is also shown for consistency. However, low-load excursions are harder to interpret. A week below the LCL may simply represent rest, tapering, recovery, disrupted training, or off-season behavior. In this first example, below-LCL weeks did not appear to align with injury reports.

So for training load, the upper boundary appears more informative than the lower boundary.

Wellness/readiness risk as internal response

The second chart looks at a composite wellness/readiness risk index.

This index combines normalized values of:

·         fatigue

·         soreness

·         stress

·         inverse readiness

·         inverse sleep quality

·         inverse mood

Higher values mean worse subjective condition or lower readiness.

This chart represents the athlete’s ANF for internal response rather than external demand. It asks a different question: not “how much work did the athlete do?” but “how did the athlete appear to be responding?”

Several weeks were above the wellness/readiness UCL. In ANF terms, these weeks suggest that the athlete’s subjective state moved outside her recent normal range. This may indicate reduced recovery, higher fatigue burden, elevated stress, or a temporary maladaptive state.

Interestingly, in this first sample, elevated wellness/readiness risk did not directly coincide with injury-report weeks. That is still useful. It suggests that wellness ANF may capture short-term internal state changes, while load ANF may better capture external stress. They are related, but not identical.

Why both charts matter

The most important lesson from this first experiment is that athlete ANF is probably multidimensional.

A player can have normal training load but poor wellness.
A player can have high training load but still report good readiness.
A player can show subjective stress without immediate injury.
A player can experience injury after load patterns that look unusual.

That means ANF should not be defined by one metric alone.

In sport, ANF may need at least two dimensions:

1.      External load — what the athlete is asked to do.

2.      Internal response — how the athlete appears to absorb and adapt to that load.

This is very close to the broader ANF idea: systems do not only have inputs; they also have internal state, adaptation capacity, boundaries, and delayed responses.

First conclusion

This SoccerMon experiment is still preliminary, but it supports the basic idea that ANF can be operationalized on real human-performance data.

The ANF framework allows us to ask:

When is training load normal for this athlete?

When is subjective wellness outside the usual range?

Is the athlete adapting, recovering, or moving toward overload?

Are we seeing noise, anomaly, change, trend, or possible breakdown?

This is exactly why sport science may be a promising first application area for ANF beyond technical systems. Athletes are living dynamic systems. They have individual boundaries, adaptation capacity, stress responses, recovery patterns, and changing normal ranges.

The next step should be to repeat this analysis across multiple players and test whether sustained or repeated departures from ANF boundaries are associated with injury, illness, poor recovery, or performance decline.

My new patent - "Systems and Methods for Proactive Workload Management" #Patent #Innovation #CapacityManagement #CloudComputing #FinOps #PerformanceEngineering

 I’m pleased to share that the USPTO has issued a Notice of Allowance for our patent application, “Systems and Methods for Proactive Workload Management” (US 2025/0383938 A1).

This means the application has been allowed and is now moving toward patent issuance.

The work focuses on proactive workload and capacity management using predictive analysis to anticipate resource needs and support better infrastructure decisions.

Many thanks to my co-inventor Jigneshkumar Shah and the Capital One patent team for their work and support.

#Patent #Innovation #CapacityManagement #CloudComputing #FinOps #PerformanceEngineering

Performance, Capacity, Cloud & FinOps Consulting — My Current Focus

IGOR A. TRUBIN

Performance, Capacity, Cloud & FinOps Consultant

TrubinIgor@gmail.com  |  240-486-6170

Available for short-term consulting, advisory, assessments, and specialized project engagements

CONSULTING VALUE

Senior specialist in computer systems/application performance, enterprise capacity management, AWS migration and cloud capacity, FinOps rightsizing, and statistical exception-based modeling. Creator of SETDS for anomaly/outlier/change/trend detection and business-driver forecasting, with an implementation available through the Perfomalist web app and API.

CORE CONSULTING EXPERTISE

• Systems & Application Performance — performance analysis, troubleshooting, workload characterization, SLA analysis, stress/load-test support, JVM memory analysis and rightsizing.

• Data Center Capacity Management — compute, storage, database and application capacity; business-demand forecasting; exception-based reporting; capacity-risk assessment.

• AWS Migration & Cloud Capacity — on-prem to AWS sizing, workload forecasting, post-migration optimization, capacity limits/utilization, and exception-based cloud capacity management.

• FinOps & Rightsizing — AWS EC2, RDS, EBS, ECS/Fargate, Lambda, ElastiCache, GPU workloads, plus JVM memory rightsizing and custom cost/utilization analytics.

• SETDS / Statistical Analytics — anomaly, outlier, change-point and trend detection; seasonality; statistical process control; forecasting; business-driver correlation; proactive risk detection.

• Model Factory — large-scale automated model generation, evaluation and selection for business-driven infrastructure/database forecasting.

MODERN TOOLS & METHODS

Cloud / FinOps	AWS: EC2, RDS, EBS, ECS/Fargate, Lambda, ElastiCache, Auto Scaling, GPU; CloudHealth; custom rightsizing analytics
Analytics / BI	Python, Pandas, R, Amazon QuickSight; time-series/statistical modeling; queuing theory
AI-assisted work	Claude Code, Gemini, ChatGPT/OpenAI — intensive use for Python development, data analysis, modeling, automation, research, documentation and rapid prototyping
Observability	Datadog, New Relic, Splunk; APIs; Docker; cloud microservices

SELECTED PROOF POINTS

• Supported Capital One sizing and migration to AWS; developed exception-based cloud capacity approaches using SETDS, business drivers, AWS capacity data, and cloud optimization tooling.

• Engineering lead for OptiCloud cloud cost optimization/rightsizing; CMG IMPACT Innovation Award, 2022.

• SETDS deployed across 20,000+ distributed servers plus mainframe, database, virtualization and cloud environments.

• Led Model Factory work modeling 10,000+ servers and 1,000+ databases; granted U.S. patent on modeling computer resource metrics; related proactive cloud workload management patent pending.

• Developed predictive capacity models delivering more than $1M/year savings in a major enterprise environment.

BACKGROUND

Capital One Bank — IT Manager / Lead Data Engineer / Product Owner (2013–Present). Earlier enterprise consulting and capacity/performance roles with IBM Global Services, SunTrust, A.P. Møller–Mærsk and major financial-services clients.

Ph.D. in Robotics — St. Petersburg State Technical University  |  AWS Certified Cloud Practitioner & Solutions Architect  |  Author of 50+ technical papers/whitepapers

From AIOps to Agentic Systems: Why Monitoring Is Not Enough (and Never Was) - CMG.org presentation

Most AIOps solutions today detect and explain anomalies, but they rarely act. In critical environments like IBM Z mainframes, this gap can prevent true operational resilience. This presentation argues that effective AIOps requires a shift from passive observation to autonomous control, built on a foundation of rigorous workload modeling. Drawing on a patent-backed framework, the session will explore the progression from simple metrics to autonomous infrastructure, including workload modeling that connects business activity to system resource consumption, context-aware analysis that segments diverse workloads for more precise service-level decisions, and automated execution that enables true agentic capabilities. Attendees will learn why reliable system models are a prerequisite for self-healing infrastructure and how organizations can evolve from reactive monitoring to proactive, autonomous control. 

The research is available on @ResearchGate:

Starting a Book Project: The Area of Normal Functioning

 I am starting to shape a new book project around the idea of the Area of Normal Functioning — ANF.

The goal is to develop ANF as a broader framework for understanding how systems, people, and organizations function, change, adapt, and grow.

This idea started for me in technical areas such as robotics, IT performance analysis, anomaly detection, change detection, and trend detection. But I now see its possible application much more broadly — including human behavior, organizations, comfort zones, and social change.

I shared some initial thoughts here:
“Starting a Book Project: The Area of Normal Functioning”

This is the beginning of a longer journey, and I plan to use my blog to document the progress.

Expanding the Area of Normal Functioning: From Technical Systems to Human Behavior

How a concept from engineering, anomaly detection, change detection, and trend detection may help us understand comfort zones, growth, organizations, and social change.

In my previous post (From Robot Grasping to Performance Anomaly Detection: Area of Normal Functioning and Exception Value), I introduced the idea of the Area of Normal Functioning, or ANF, as a way to describe the range within which a system operates normally.

My original interest in this idea came from technical domains. Earlier in my career, I applied similar thinking to robotics and assembly tasks. More recently, I have been using related concepts in IT Capacity Management, performance analysis, statistical pattern recognition, anomaly detection, change detection, and trend detection for dynamic systems. In these fields, we constantly ask questions such as:

When is a system behaving normally?

When is a deviation still acceptable?

When does a change become an anomaly?

When is a trend meaningful rather than just random variation?

When should we react?

These questions are familiar to engineers, performance analysts, and people working with complex systems. But I believe the same questions are not limited to technology. They also appear in human life, organizations, psychology, sociology, and even personal development.

That is why I now see ANF not only as a technical concept, but as a broader cross-disciplinary framework.

The Comfort Zone as a Human ANF

In psychology and sociology, we often hear the phrase comfort zone. Usually it describes the range of situations, behaviors, and environments where a person feels safe, competent, and in control.

This is very close to the idea of an Area of Normal Functioning.

A person has their own ANF. Inside it, they can operate effectively. They understand the rules. They know how to respond. They feel enough confidence and stability to function.

Outside this area, things become more difficult. A person may experience stress, uncertainty, fear, resistance, or even growth. Sometimes leaving the ANF is necessary. Sometimes it is dangerous. Sometimes it is exactly where learning begins.

This makes the concept more interesting. In technical systems, we often want to detect and avoid abnormal behavior. We also want to detect meaningful changes and emerging trends before they become serious problems. In human systems, however, moving outside the normal zone can be both a risk and an opportunity.

Normal Does Not Mean Ideal

One important point is that “normal” does not always mean “good.”

A machine can function normally but inefficiently. An organization can operate normally but still be outdated. A person can live inside a familiar behavioral pattern that is stable but limiting.

This is why I prefer the term Area of Normal Functioning rather than simply “normal state.” ANF is not a single point. It is a range. It has boundaries. It can expand, shrink, shift, or become distorted.

For example, an employee may function normally under a certain level of pressure. But if pressure increases beyond their ANF, performance may decline. Another person may need a higher level of challenge to stay engaged. The “normal area” is not the same for everyone.

The same is true for teams and organizations. A startup, a government agency, a hospital, and an IT operations team may all have very different ANFs. Their normal functioning depends on history, culture, expectations, constraints, and environment.

Anomaly, Change, and Trend Detection in Human and Social Systems

In IT performance analysis, anomaly detection is a practical necessity. We monitor metrics, define baselines, detect deviations, and decide whether the deviation requires action. But this is only part of the picture.

Sometimes the important signal is not a sudden anomaly, but a change point: a moment when the system begins to behave differently from before. In other cases, the important signal is a trend: a gradual movement in one direction that may not look dramatic today, but may become very important over time.

This distinction matters in human and social systems too.

A sudden change in behavior can be a warning sign. It can also be a breakthrough. A person who becomes quieter may be struggling, or simply reflecting. A team that starts challenging old assumptions may be in conflict, or may be moving toward innovation.

A gradual trend can be even harder to notice. A person may slowly lose motivation. A team may slowly become less open. An organization may slowly normalize inefficiency. Society may slowly redefine what is acceptable or unacceptable.

None of these patterns are always good or bad by themselves. Their meaning depends on context, direction, speed, and consequences.

This is where ANF could become useful as a thinking framework rather than only a mathematical tool.

Instead of asking only, “Is this normal or abnormal?” we can ask:

What is the current Area of Normal Functioning?

What are its boundaries?

Is the system experiencing a sudden anomaly, a structural change, or a gradual trend?

Who defines the normal boundaries?

Are these boundaries healthy or unhealthy?

Is the system being pushed outside its ANF?

Is the ANF expanding through adaptation, shifting because of change, or collapsing under stress?

These questions can apply to machines, people, organizations, and societies.

Growth as Expansion of ANF

In personal development, growth is often described as “getting out of your comfort zone.” I think this phrase is useful, but incomplete.

The goal is not simply to leave the comfort zone. The goal is to expand the Area of Normal Functioning.

When we learn a new skill, speak in public, move to a new country, change careers, or take on a new role, we are initially outside our established ANF. The situation feels uncomfortable because our normal patterns are no longer enough.

But with repetition, support, feedback, and adaptation, the new behavior can become part of our normal functioning. What was once difficult becomes manageable. What was once stressful becomes familiar. The ANF expands.

This also explains why growth must be managed carefully. If the challenge is too small, there is no expansion. If the challenge is too large, the system may break down. Effective growth happens near the boundary of the current ANF — not too far inside it, and not too far outside it.

From this perspective, personal growth can be viewed as a positive form of change detection: we notice when old patterns are no longer enough, and we intentionally develop new patterns until they become part of our expanded normal functioning.

Organizations Have ANF Too

Organizations also have Areas of Normal Functioning.

A company has normal ways of making decisions. A team has normal communication patterns. A culture has normal expectations. A profession has normal standards of behavior.

When external conditions change — new technology, market disruption, leadership change, economic pressure — the organization may be pushed outside its ANF. Some organizations adapt and expand. Others resist. Some become unstable. Some fail.

This is why change management is difficult. People often do not resist change simply because they are conservative or irrational. They resist because the proposed change may push them outside their established ANF without enough support, explanation, or time to adapt.

Trend detection is also important here. Organizations rarely become ineffective overnight. Often, performance, culture, or innovation capacity declines gradually. By the time the problem becomes obvious, the trend has already been active for a long time.

Understanding the ANF of an organization could help leaders design better transitions. Instead of forcing change mechanically, they could ask: what is the current normal functioning of this organization, how is it changing, and how can we expand it safely?

Why This Matters to Me Now

At this stage of my career, I am becoming increasingly interested in connecting my technical work with a broader human and organizational context.

My professional background is in IT Capacity Management, performance analysis, anomaly detection, change detection, trend detection, and statistical pattern recognition. I also developed Perfomalist.com as a practical tool for performance anomaly and change-point detection. But I now see this work as part of a bigger idea.

The same pattern appears again and again:

A system has a normal range.

The normal range has boundaries.

Change creates deviations.

Some deviations are noise.

Some deviations are warnings.

Some deviations indicate structural change.

Some trends reveal gradual movement toward a new normal.

Some deviations are opportunities for growth.

The challenge is to understand the difference.

This is the direction I would like to explore further — in writing, speaking, teaching, and possibly in a future book. My goal is to develop ANF as a universal framework that can connect technical systems, human behavior, organizations, and social change.

Toward a Universal Framework

The Area of Normal Functioning is still an evolving idea. I do not claim that it is a finished theory. But I believe it can become a useful bridge between disciplines.

Engineers, psychologists, sociologists, managers, educators, and leaders all deal with systems that function within boundaries. They all deal with change, adaptation, stress, stability, abnormal behavior, and emerging trends.

The language may be different, but the underlying questions are often the same:

What does normal functioning mean here?

How do we know when normal functioning has changed?

How do we distinguish noise, anomaly, trend, and meaningful transformation?

What happens when the system moves beyond its normal area?

Those questions may be technical. They may be personal. They may be organizational. They may even be philosophical.

For me, this is what makes ANF worth exploring further.

It started as a technical concept. But perhaps its larger value is helping us understand how systems — including human systems — survive, adapt, change, and grow.

ANF (ОНФ) example from Issledovanie_Processov_Zahvatyvania_Obektov_Manipulirovania_Promyslennym_Robotom

From Robot Grasping to Performance Anomaly Detection: Area of Normal Functioning and Exception Value

Many years ago, my PhD dissertation focused on industrial robot grasping processes and assembly accuracy using passive, sensorless adaptation. The practical problem was simple to describe but difficult to solve: how can a robot successfully grasp or assemble an object when there are inevitable errors in the object’s initial position, orientation, and geometry?

The main idea of that research was to calculate a set of initial conditions under which the grasping or assembly process would still succeed. I called this region the Area of Normal Functioning — ANF; in Russian, Область Нормального Функционирования — ОНФ.

In other words, ANF defined the “safe” or “normal” area of operation. If the initial coordinates of the object were inside this area, then passive mechanical adaptation could compensate for small errors and the operation would be successful. If the initial coordinates were outside this area, the process would likely fail.

Looking back, this idea has an interesting connection to my later work in IT performance anomaly detection. In my current research, I use the concept of Exception Value — EV — as the area between statistical limits and the actual observed values of system performance variables.

The domains are very different: one is industrial robotics, the other is IT system performance management. But the underlying idea is surprisingly similar.

In robotic grasping and assembly, the question was:

How far can the object’s actual position deviate from the ideal position while the robot operation still succeeds?

In performance anomaly detection, the question becomes:

How far can the actual value of a performance variable deviate from its statistically expected range before we should treat it as an exception?

In both cases, the main focus is not only the ideal or expected value. The more important question is the boundary between normal and abnormal functioning.

For industrial robots, ANF described the range of physical coordinates where passive adaptation was still able to correct errors. For performance data, EV describes the area where actual behavior moves beyond normal statistical expectations.

This connection is especially interesting because both ideas are based on “management by exception.” We do not need to react to every small deviation. We need to understand when a deviation becomes meaningful — when it leaves the normal functioning area.

Modern robotics research continues to explore related ideas under different terminology: passive compliance, compliant grasping, remote center compliance, sensorless robotic assembly, peg-in-hole insertion, and adaptive manipulation. Many recent methods also use sensors, machine learning, and vision systems. However, the older idea of defining a normal operating region remains relevant: successful automation depends not only on control algorithms, but also on understanding the tolerance zone where the process can still function correctly.

That is why I now see ANF as an early conceptual predecessor of my later EV work. ANF was about the boundary of successful physical operation. EV is about the boundary of normal statistical behavior.

Different fields. Different data. Same engineering mindset:

define the normal area, measure the deviation, and focus attention on meaningful exceptions.

 “conceptual comparison” table

From AIOps to Agentic Systems: Why Monitoring Is Not Enough (and Never Was)

For years, the industry has been obsessed with observability.

Dashboards. Alerts. Correlations.
Then came AIOps — promising intelligence on top.

But let’s be honest:

Most AIOps tools today are still just better dashboards.

They detect problems.
Sometimes they explain them.
But very rarely do they fix anything.

---

For mainframe environments, this gap is even more important. IBM Z systems still run many of the enterprise’s most critical transaction workloads, where CPU, memory, I/O, service classes, batch windows, and subsystem behavior interact in complex ways. AI on the mainframe is not only about adding assistants or anomaly detection. The real opportunity is to combine trusted workload models, mainframe operational context, and governed automation so the platform can recommend — and eventually execute — safe actions before service levels are at risk.

The Missing Step: Action

Across my (with Capital One and 2 other co-authors) patent family:

• US10437697 (2016)
• US11243863 (2019)
• US12007869 (2021)

there is a deliberate progression:

[Workload] → [Model] → [Insight] → [Action]

Most systems today stop here:

[Workload] → [Model] → [Insight]   ❌

The real value starts here:

[Workload] → [Model] → [Insight] → [Action]   ✅

---

Step 1 — Modeling the System (US10437697)

The first patent introduced a core idea:

Model how business activity (transactions) drives system resources (CPU, memory, I/O).

Not thresholds.
Not heuristics.
But statistical relationships.

Transactions ───► CPU / Memory / I/O
           (modeled mathematically)

This was already a shift from traditional monitoring.

---

Step 2 — Adding Context (US11243863)

The second patent introduced interaction types:

Different workloads behave differently — so model them separately.

Mobile ─┐
Web     ├──► Separate models ───► Better decisions
ATM     ┘

This aligns with what the industry now calls:

• service-level observability
• topology-aware analysis

---

Step 3 — Acting on the Model (US12007869)

This is the key leap.

The latest patent moves beyond analysis:

Use the models to automatically reconfigure the system.

Before:
Workload ───► Overloaded Node

After:
Workload ───► Optimal Node
          (automatically reassigned)

Or more formally:

[Model] → Decision → Remap workloads → Optimize system

This is no longer monitoring.

This is autonomous control.

---

Why This Matters Now (Agentic AI)

Everyone is talking about:

• AI agents
• autonomous systems
• self-healing infrastructure

But here’s the uncomfortable truth:

You can’t have agentic systems without reliable system models.

LLMs don’t understand system dynamics.
They generate text — not operational decisions.

What you need is:

Statistical Models (US10437697)
+ Context Segmentation (US11243863)
+ Autonomous Action (US12007869)

Which leads to:

→ Agentic AIOps

---

The Real Gap in AIOps Today

Platforms like:

• Datadog
• Dynatrace
• New Relic

are very good at:

✔ Detecting anomalies
✔ Explaining root causes

But still weak at:

❌ Acting autonomously
❌ Continuously optimizing systems

---

My Take (Provocative Version)

AIOps without action is just observability with better marketing.

The real transition is:

Monitoring → AIOps → Autonomous Systems → Agentic AI Ops

And the key step is exactly what US12007869 enables:

Systems that don’t just understand —
but act based on that understanding.

---

Final Thought

If your system still depends on humans to:

• interpret alerts
• decide what to do
• execute changes

Then it’s not AIOps.

It’s just monitoring — with extra steps.

______________

Reference:

My CMG presentation about the subject: https://cmg.org/wp-content/plugins/s2member-files/proceedings/2017/362_Trubin.pdf

___________________________________________

Disclaimer:  this post is written with ChartGPT's help. 

One of most recent parent with Capital One (2021 US12007869) is about Autonomous / AI ops (AIOps)

The following patent family:

Patent	Level	What it protects
2016 (10437697)	Foundation	`Build + validate statistical models
2019 (11243863)	Structured	Segment system into interaction types
2021 (12007869)	Adaptive	Dynamically reconfigure system using models

This progression covers:

✔ Observability / APM tools 

• Modeling + correlation (Patent 1)

✔ Capacity planning systems

• Segmented workload modeling (Patent 2)

✔ Autonomous / AI ops (AIOps)

• Self-optimizing infrastructure (Patent 3)

👉 You effectively moved toward:

self-driving infrastructure based on statistical modeling

Those patents map very directly to modern AIOps, especially the parts around business/workload demand → resource utilization → model scoring → automated load-balancing/remapping.

Core patent family vs AIOps platform features

Patent concept	Plain-English meaning	Modern AIOps equivalent
Interaction / transaction volume by type	Business workload demand, e.g. mobile banking, ATM, web traffic	Service traffic, request rate, user actions, business events
Device/resource utilization	CPU, memory, disk, network usage	Infrastructure + APM telemetry
Statistical / regression / multivariate models	Model relationship between workload and resource consumption	ML baselines, anomaly models, predictive analytics
Diagnostic scoring: R², RMSE, strength	Decide which models are reliable	Confidence/scoring of anomalies, correlations, RCA evidence
Filtering weak models	Keep only useful models	Noise reduction / alert suppression
Forecasts	Predict future demand/resource pressure	Bottleneck prediction, capacity forecasting
Remapping devices to interaction types	Use model output to change workload placement	Automated remediation, scaling, routing, load balancing

The  strongest overlap is not generic “anomaly detection.” It is business-demand-aware resource modeling that can drive infrastructure decisions.

"Automated Detection of Performance Regressions Using Statistical Process Control Techniques"

Exploring ICPE’12 — A Precedent I Didn’t Expect

I recently came across an interesting paper from ICPE 2012 where my earlier work was cited. It’s always a bit surreal to see your ideas show up in academic research years later—especially in a context that closely aligns with what you’ve been working on.

The Paper

Automated detection of performance regressions using statistical process control techniques

Thanh H.D. Nguyen, Bram Adams, Zhen Ming Jiang, Ahmed E. Hassan
Published by ACM, April 2012

What caught my attention was their discussion of using control charts to detect performance regressions—an approach very close to what I explored back in 2005.

The Connection

In the paper, the authors reference my work:

Trubin et al. [18] proposed the use of control charts for in-field monitoring of software systems where performance counters fluctuate according to input load. Control charts can automatically learn when deviations exceed control limits and alert operators.

They go on to build upon this idea, applying control charts not just to live systems, but to performance regression testing.

Key Idea: Control Charts for Regression Detection

The core concept is elegant:

• Use historical baseline runs (previous software versions) to establish control limits
• Compare new test runs against those limits
• Measure a violation ratio—how often metrics fall outside expected bounds
• A higher ratio indicates a higher probability of regression

This aligns closely with the fundamental principle I worked on: detecting anomalies not by fixed thresholds, but by statistically learned behavior.

The Real Challenge

The authors correctly highlight a critical difficulty:

We want to detect deviations in the system (the process), not deviations caused by input variability (the load).

This is the central problem in performance analysis—and one that still trips up many modern monitoring systems.

They also point out two assumptions required for traditional control charts:

1. Stable (non-varying) input
2. Normally distributed output

In real-world systems, both assumptions are often violated.

Their Solution: Preprocessing

To address this, they introduce preprocessing steps:

• Scaling – normalizing data to reduce input-driven variance
• Filtering – cleaning noise before applying control charts

This is a practical adaptation, though it also highlights the limitations of applying classical statistical techniques directly to complex software systems.

Looking Back

For reference, the cited work is:

[18] I. Trubin. Capturing workload pathology by statistical exception detection system.
Computer Measurement Group (CMG), 2005.

It’s interesting to see how the idea of statistical exception detection—especially under variable workloads—continues to evolve and reappear in different forms.

Final Thoughts

What I find most encouraging is that the core idea still holds:

Performance anomalies should be detected relative to expected behavior, not absolute thresholds.

Whether you call it control charts, anomaly detection, or change point analysis—the principle remains the same.

And it’s a good reminder: sometimes ideas don’t just age… they propagate.