Configuration

Instantiating AEGIS for a specific domain requires populating a set of configuration parameters that define the deployment context, dataset structure, performance metrics, thresholds, and decision categories. This page walks through each parameter group with worked examples.

Download the S2 Configuration Template

Instantiation parameters overview

Table V in the manuscript defines the complete set of parameters required to instantiate AEGIS. They are grouped into seven sections:

S2.1 -- Deployment context

The deployment context section captures the fundamental characteristics of your AI/ML system.

Data modality

Select the primary data type your model processes:

**Sepsis example:** The sepsis prediction system uses **Tabular EHR** data modality. The model is a Random Forest with 300 trees, processing 202 clinical features (vital signs and laboratory values) collected hourly from ICU patients. Primary metrics are sensitivity, specificity, ROC-AUC, and balanced accuracy. The clinical use case is early prediction of sepsis onset in adult ICU patients, where the model produces hourly risk scores and clinicians receive alerts when the score exceeds a threshold.

Model architecture

Document the model type with sufficient detail for reproducibility. Include:

• Algorithm family (e.g., Random Forest, neural network, gradient boosting)
• Key hyperparameters (e.g., number of trees, depth, learning rate)
• Pre-processing pipeline details relevant to performance

Primary metrics

List all metrics that will be tracked by MMM. These should include:

• At least one safety-critical metric (e.g., sensitivity for a screening tool)
• Metrics that map to the clinical requirements of your intended use
• The metric(s) used for the critical safety floor P_fail

S2.2 -- Dataset configuration

Golden dataset

The golden dataset D_G is the cornerstone of AEGIS evaluation. It must be:

1. Representative of the target population
2. Locked before the first deployment (immutable)
3. Hashed for integrity verification (SHA-256 recommended)
4. Documented with inclusion/exclusion criteria, source, and time period

import hashlib
import pandas as pd

def hash_golden_dataset(df: pd.DataFrame) -> str:
    """Generate SHA-256 hash of golden dataset for integrity verification."""
    content = df.to_csv(index=False).encode('utf-8')
    return hashlib.sha256(content).hexdigest()

# Lock and record
golden_hash = hash_golden_dataset(D_G)
print(f"Golden dataset hash: sha256:{golden_hash[:12]}...golden_v1.0")

Split strategy

AEGIS supports several split strategies. The choice depends on the clinical context:

**Sepsis example:** A random 80/20 hold-out split was used with patient-safe splitting (all samples from a unique patient ID in the same split). D_T,0 = 8,134 samples and D_G = 4,067 patients (20% of 20,336) from PhysioNet Hospital A. Iterations 1--5 used ~1,626 real samples each from Hospital A as drifting batches. Iterations 6--10 used mixed/synthetic batches with controlled corruption. Patient ID deduplication was performed via SHA-256 hashing across all splits to ensure no patient appeared in more than one partition.

Deduplication

Patient-level deduplication across all dataset splits is mandatory. A single patient appearing in both D_G and D_T,k will invalidate the governance loop by introducing data leakage.

S2.6 -- Active decision categories

APPROVE and REJECT are always active. The two intermediate categories (CONDITIONAL APPROVAL and CLINICAL REVIEW) can be disabled with documented clinical justification.

Four-category configuration (default)

REJECT ← P1
CLINICAL REVIEW ← P2 (performance buffer / regression from fixed performance reference)
CONDITIONAL APPROVAL ← P3 (minor drift or TAI concern)
APPROVE ← P4

Two-category configuration

Some domains may not support meaningful intermediate states. For example, in binary segmentation quality assessment, the output mask is either clinically acceptable or not.

REJECT ← P1, P2, P3
(CONDITIONAL APPROVAL — disabled)
(CLINICAL REVIEW — disabled)
APPROVE ← P4

When disabling categories, document the clinical justification in the S2 configuration form. Regulatory reviewers will need to understand why intermediate governance states were not implemented.

**Sepsis example:** The sepsis case study used all four active categories plus ALARM, exercising all five decision outputs across 11 iterations. CONDITIONAL APPROVAL was triggered at iteration 6 when cross-site drift was detected (minor drift from Hospital B data). CLINICAL REVIEW was triggered at iteration 7 when sensitivity regressed from the fixed performance reference (P^ref 0.723 minus observed 0.702 = 0.021 > tau 0.015). In contrast, the BraTS brain tumour segmentation study used only REJECT, APPROVE, and ALARM, disabling both CONDITIONAL APPROVAL and CLINICAL REVIEW with the justification that the binary DSC metric does not support a meaningful buffer zone.

S2.7 -- Fixed performance reference baseline

The fixed performance reference (P^ref) is established at the first iteration that receives APPROVE. Record:

Once the fixed performance reference is set, it must not be modified without a formal change control process. Any change to the fixed performance reference effectively resets the governance baseline and should be treated as a significant modification.

Configuration checklist

Before proceeding to threshold configuration, verify:

• Data modality and model architecture documented
• Primary metrics selected and clinically justified
• Golden dataset locked, hashed, and described
• Split strategy documented with rationale
• Patient-level deduplication confirmed
• Active decision categories selected with justification
• Fixed performance reference baseline recorded (or planned for iteration 0)

Source

Manuscript Section II-D, Table V. Instantiation parameters are formally defined in Table V, with the sepsis column providing worked example values. BraTS configuration appears in Section IV-D. Dataset management follows the Dataset Assimilation and Retraining Module (DARM) specification in Section II-B-1. Active category configuration is described in Supplementary S2.6.