ClarusC64/clinical-quad-stress-buffer-lag-coupling-icu-collapse-v0.6

What this repo does

This repository contains a Clarus v0.6 intervention pathway dataset focused on ICU collapse dynamics.

The dataset evaluates whether a model can determine if a proposed intervention meaningfully stabilizes a deteriorating critical care system.

The task requires reasoning from:

• —system state
• —trajectory toward instability
• —boundary geometry
• —recovery geometry
• —intervention vector
• —projected trajectory consequence

The model cannot read the answer directly.

It must infer stabilization from the structure of the case.

This shifts the benchmark from simple ICU deterioration detection to intervention reasoning.

Core quad

The ICU collapse system is represented using four normalized variables.

• —critical_stress
• —physiological_buffer
• —intervention_lag
• —systemic_coupling

These variables capture the core structural drivers of critical care cascade progression.

Clinical variable mapping

The normalized quad variables correspond to measurable clinical signals.

These measurements illustrate how normalized values in the dataset map to real ICU physiology.

Prediction target

The target column is:

label_icu_stabilization

This label indicates whether the intervention pathway produces genuine stabilization.

Label logic

Default benchmark rule

A row is labeled positive only when both conditions hold:

stabilization_success = 1

and

trajectory_shift < -0.10

This rule filters out marginal corrections and ensures that positive examples represent meaningful stabilization.

Optional relaxed rule

Positive labels may trigger when:

stabilization_success = 1

This relaxed rule may be used for exploratory builds but is not the default benchmark configuration.

Row structure

Each row contains:

• —core ICU state
• —trajectory geometry
• —perturbation geometry
• —recovery geometry
• —intervention vector
• —projected trajectory consequence

Train rows include:

• —stabilization_success
• —label_icu_stabilization

Tester rows exclude these fields.

Why tester rows exclude stabilization_success

The tester file withholds:

• —stabilization_success
• —label_icu_stabilization

This prevents answer leakage.

The model must infer stabilization using:

• —the starting ICU state
• —drift toward the failure boundary
• —recovery basin geometry
• —the intervention vector
• —the predicted trajectory consequence

This structure forces real intervention reasoning.

Minimal intervention path

minimal_intervention_path encodes the shortest viable stabilization pathway.

Example interpretation:

• —0 = no viable rescue path
• —1 = direct stabilization pathway
• —2 = multi-step stabilization sequence
• —3 = complex high-risk rescue pathway

The field remains visible because the benchmark evaluates whether the model can combine intervention structure with trajectory consequence to determine stabilization.

Files

• —data/train.csv — labeled training dataset
• —data/tester.csv — unlabeled benchmark dataset with withheld stabilization signal
• —scorer.py — evaluation metrics and confusion matrix computation
• —cli.py — command-line evaluation wrapper used for benchmark scoring
• —README.md — dataset card and schema documentation

Evaluation

The scorer reports:

• —accuracy
• —precision
• —recall_successful_stabilization
• —failed_rescue_rate
• —f1
• —confusion_matrix

Primary metric:

recall_successful_stabilization

Secondary metric:

failed_rescue_rate

Interpretation:

recall_successful_stabilization measures how reliably the model detects interventions that genuinely stabilize the ICU system.

failed_rescue_rate measures how often the model fails to recognize a viable stabilization pathway.

These metrics prioritize intervention reasoning rather than generic classification accuracy.

Schema

train.csv columns

• —scenario_id
• —critical_stress
• —physiological_buffer
• —intervention_lag
• —systemic_coupling
• —drift_gradient
• —drift_velocity
• —drift_acceleration
• —boundary_distance
• —perturbation_radius
• —collapse_trigger
• —recovery_distance
• —recovery_gradient
• —return_feasibility
• —delta_critical_stress
• —delta_physiological_buffer
• —delta_intervention_lag
• —delta_systemic_coupling
• —trajectory_shift
• —minimal_intervention_path
• —stabilization_success
• —label_icu_stabilization

tester.csv columns

• —scenario_id
• —critical_stress
• —physiological_buffer
• —intervention_lag
• —systemic_coupling
• —drift_gradient
• —drift_velocity
• —drift_acceleration
• —boundary_distance
• —perturbation_radius
• —collapse_trigger
• —recovery_distance
• —recovery_gradient
• —return_feasibility
• —delta_critical_stress
• —delta_physiological_buffer
• —delta_intervention_lag
• —delta_systemic_coupling
• —trajectory_shift
• —minimal_intervention_path

Structural note

The Clarus dataset series evolves through progressively richer representations of cascade dynamics.

Version progression:

• —v0.1 — cascade state detection
• —v0.2 — trajectory-aware detection
• —v0.3 — dynamic cascade forecasting
• —v0.4 — boundary discovery
• —v0.5 — recovery geometry
• —v0.6 — intervention pathway reasoning

Earlier versions identify when instability is developing.

Version 0.6 evaluates whether a proposed intervention meaningfully alters the trajectory of a system approaching collapse.

This marks the transition from monitoring cascade dynamics to evaluating control pathways.

Production deployment

This dataset structure can support clinical decision environments where ICU collapse must be detected and corrected before irreversible transition occurs.

Example settings include:

• —ICU escalation surveillance
• —septic shock deterioration monitoring
• —organ-support step-up decision support
• —multi-organ collapse forecasting
• —high-acuity rescue pathway evaluation

Enterprise and research collaboration

This dataset class supports benchmarking for:

• —intervention-aware clinical AI
• —ICU cascade modeling
• —recovery feasibility prediction
• —false-stability detection
• —boundary-sensitive decision support systems

Contact

For dataset expansion, custom coherence scorers, or deployment architecture:

team@clarusinvariant.com

Instability is detectable. Governance determines whether it propagates.

License

MIT