Researching intelligent systems for real-world problems.

Limitations

• Evaluation is simulation-only; no real donors, vehicles or consignments were involved.
• Cold-chain telemetry is synthetic, so sensor noise and failure modes are modelled rather than observed.
• The audit trail simulates blockchain immutability with hashing; it is not deployed on a distributed ledger with independent validators.
• The street network is a single-city model, so generalisation beyond Cambridge is untested.

What I learned

• A reward function is a product decision: what the policy optimises for is the specification, and small changes to it change behaviour more than model tuning does.
• Simulation is only useful when the baseline is honest — the static-routing comparison mattered more than the headline number.
• Trust mechanisms need a workflow before they need cryptography; the audit trail only helps if handovers are recorded at the right moments.

Future research directions

• Evaluate the policy against a real, instrumented pilot with a small number of donors.
• Compare PPO against simpler heuristics on cost, robustness and explainability, not just diversion rate.
• Study whether a verifiable audit trail measurably changes participation behaviour.
• Extend the digital twin to multi-city networks and to disruption scenarios.

Motivation

Signature-based defences are efficient and explainable, but their coverage is bounded by prior knowledge. The motivating question is not whether machine learning can classify traffic, but whether an adaptive system can be made trustworthy enough for security teams to act on.

Research question & objective

To what extent can machine-learning-based anomaly detection extend intrusion detection beyond signature coverage without an unacceptable operational cost in false positives? The objective is to define an evaluation frame that treats analyst workload as a first-class outcome alongside detection performance.

Literature review direction

• Signature-based versus anomaly-based intrusion detection.
• Supervised and unsupervised approaches to network anomaly detection.
• Concept drift and adversarial adaptation in security settings.
• Explainability and analyst trust in automated detection.

Proposed methodology

• Define the threat model and the detection scope before selecting techniques.
• Establish a signature-based baseline so any learned model has something honest to beat.
• Specify evaluation protocol, including how drift over time would be handled.
• Treat data provenance and labelling assumptions as explicit study limitations.

Model & data evaluation considerations

• Class imbalance makes accuracy a misleading headline measure.
• Precision, recall and alert volume matter more than a single aggregate score.
• Temporal splits are needed; random splits leak future information.
• Any dataset choice must be justified and its representativeness questioned.

Cybersecurity context

Detection sits inside an operational process. A model that raises defensible alerts a team can triage is more valuable than one that scores better offline and is ignored in practice.

Limitations

• This is proposed research: no implementation, dataset, experiment or result is claimed.
• Public intrusion datasets age quickly and may not represent current threats.
• Adversaries adapt to deployed detectors, so offline evaluation overstates durability.

Future research & potential PhD extension

• Build and evaluate a prototype detector against a justified, current dataset.
• Study drift-resilient detection and retraining strategies over time.
• Investigate explainability methods that measurably improve analyst decisions.
• Extend towards trustworthy, resilient intelligent systems as a doctoral programme.

Scope of the claim

Cambridge Field Tracker was a research-operations tool built for this evidenced fieldwork context. It was not a commercial product, an official university-wide system, deployed across ARU, or used outside that context.

What I learned

• Research operations fail on visibility long before they fail on analysis.
• Offline-first is a requirement, not an enhancement, when the work happens on foot.
• Status modelling is where the real requirements argument happens.