Fleet Intelligence

Fleet Intelligence asks whether knowledge survives beyond the machine on which it was learned. The hierarchy expands carefully from a component through its machine, system, plant, fleet, and enterprise context:

Fleet intelligence asset hierarchy

  1. Component Twin
  2. Machine Twin
  3. System Twin
  4. Plant Twin
  5. Fleet Twin
  6. Enterprise Intelligence
Evidence may be organized across these nested scopes, but every move outward requires a new generalization claim and every move inward requires local validation.

Cross-asset validation, transfer learning, fleet benchmarking, model and feature portability, failure-signature reuse, operating-regime clustering, leave-one-asset-out validation, federated learning, and organizational learning are candidate methods—not assumptions of equivalence.

Conceptual leave-one-asset-out protocol

Train
Pump P01–P49
Test
Pump P50

Conceptual and synthetic research protocol — not a field result

The target asset stays outside training so portability is tested against a named local machine rather than inferred from a mixed population.
Did the AI learn pump degradation, or did it memorize individual machines?

Population evidence is not local evidence

Population evidence can show that a relationship recurs across a declared group. Local evidence asks whether that relationship survives the target asset’s data semantics, duty, instrumentation, operating regime, maintenance history, and acceptance criteria. Evidence from one asset does not automatically generalize to another.

Answering requires comparable asset metadata, sensor semantics, units, maintenance labels, operating envelopes, twin fidelity, and provenance. P-101 evidence can form a hypothesis for another centrifugal pump, but it cannot be copied as validation. Regime and configuration differences in driver, hydraulic design, instrumentation, environment, and maintenance practice may dominate the learned signature.

Leave-one-asset-out validation tests portability more honestly than randomly mixing samples from every machine. A held-out asset can reveal negative transfer risk: a population model may perform worse than an asset-local baseline when mechanisms or data contracts differ. A portable feature is often more valuable than a portable model when its physical meaning can be reviewed locally.

Federated learning may reduce raw-data centralization, but it does not remove semantic mismatch, label quality, security, privacy, or governance concerns. Every target asset still requires local evidence, its own validation gate, and named human decision authority.

Knowledge Flywheel

Knowledge Flywheel

  1. Machine Data
  2. Twin
  3. Experiment
  4. Evidence
  5. Knowledge
  6. Fleet Learning
  7. Better Experiments
  8. Better Machine Knowledge

The ordered cycle continues from the final step to the first.

The ordered cycle preserves successful and failed replication evidence. Human owners decide whether the next asset-local experiment is warranted.

The flywheel advances through traceable evidence, including failed replications. Organizational memory records where a hypothesis worked, where it failed, and what changed. Human owners decide whether fleet findings warrant a local experiment, and each asset retains its own validation gate and operational authority. Fleet learning creates a testable next hypothesis; it never creates automatic deployment or control authority.

Conceptual demonstration — synthetic fixture results.

P-101 and the P01–P50 fleet notation are conceptual fixtures, not an actual fleet dataset or field result.

Local authority retained

Fleet evidence proposes; each asset validates

Population findings can prioritize a local experiment. They cannot silently replace target-machine evidence, engineering review, or the asset owner’s operational authority.