Training and Retraining XNNs

Structure first, parameters second

Induction decides the XNN structure: selected modules, feature interactions, partitions and rule forms. Weight training then optimises the coefficients within that structure.

This makes later adaptation more targeted. When the input schema and underlying relationships remain compatible, the trainable XNN can be updated without discovering a completely new architecture.

The trainable and serving forms

The trainable XNN is retained independently so that it can be updated in a later training cycle. For deployment, a serving XNN is prepared for inference and embedded within or linked to an ESM.

After retraining:

1. the updated trainable XNN is evaluated;
2. a new serving XNN is produced;
3. the serving model is incorporated into a refreshed Explanation Structure Model (ESM) where required; and
4. identifiers, metadata and integrity references are updated.

Separating the forms reduces the risk of treating the production package as an undocumented training artefact.

Evaluation objectives

The evaluation metric should match the prediction task and business consequence. The source material highlights Receiver Operating Characteristic Area Under the Curve (ROC-AUC) for ranking quality and Precision-Recall Area Under the Curve (PR-AUC) for imbalanced classification problems, while noting that metrics can be selected according to the data and objective.

No single metric is sufficient for high-impact use. Teams may also need calibration, threshold analysis, subgroup performance, explanation stability and operational cost measures.

When targeted retraining may be appropriate

Retraining can address compatible changes such as:

• additional observations drawn from the same schema;
• gradual shifts in customer or operational behaviour;
• recalibration of existing categories;
• updated objective weights; or
• changed coefficients within established relationships.

New data categories require care. If they fit the existing encoded structure, retraining may be possible. If they introduce new semantic behaviour or change the model inputs, reinduction may be more appropriate.

Human knowledge across retraining

Human-injected rules and constraints should have explicit lifecycle policies. A rule may be locked, weighted, reviewed or permitted to evolve. The retraining process should record how learnt parameters interacted with those rules and whether conflicts arose.

Preserving a symbolic scaffold does not mean freezing all behaviour. It means changes can be compared at a meaningful level: module, partition, rule, expression and coefficient.

Targeted goals

The source framework describes retraining objectives such as fairness optimisation, bias reduction and alignment with business key performance indicators. These objectives must be precisely defined and evaluated.

For example, "reduce bias" needs a named population, outcome, metric, baseline and acceptable trade-off. A goal label alone is not a governance control.

Versioning and traceability

Each training run should produce a new version with links to:

• the parent model;
• training data or governed references;
• configuration and objective;
• evaluation results;
• structural and parameter changes;
• the resulting ESM; and
• the Model Unique Verification Code (UVC) where used.

Stable identifiers allow the team to compare corresponding modules and rules across versions. Additions, deletions and changed coefficients can be reviewed without relying only on a global performance number.

Runtime adjustment is separate

The Identify-Assess-Resolve framework can apply rule-based handling, alerts or other resolution outside the core model. This can address an edge case without immediately retraining the XNN.

The operational record should distinguish a model update from a runtime policy action. Otherwise, a downstream override can be mistaken for learnt behaviour.

Why it matters

Separating training, serving and runtime control creates a lifecycle that can be reviewed. It makes clear what changed, why it changed, how the new version was evaluated and which explanation structure is active in production.

This separation also makes rollback and comparison more precise: the organisation can identify the trainable parent, the approved serving artefact and the ESM that exposed it to users.