Entries

How much of a physical process can be replaced by a learned surrogate before the error compounds?

Surrogate modelling is attractive wherever a reference simulation is too slow to sit inside a design loop, an optimiser or a control system. Fitting a surrogate is rarely the difficult part. The difficult part is characterising the regime in which the surrogate's error remains irrelevant to the decision it supports, and detecting when a query has left that regime.

Mean error is a poor proxy for this. A surrogate can be accurate on average and still flip the sign of a design comparison near a boundary, which is precisely where engineering decisions are made. Our working position is that a surrogate should be assessed on decision agreement with the reference model over the region of interest, and should refuse to answer outside it.

The current harness sweeps model coarseness and training-set coverage against a reference solver, and records the coarsening level at which decision agreement — not mean error — begins to degrade. It also records the cost of each level, because the whole point is the trade.

Method

Reduced-order modelling; error-bound sweeps against a reference solver; decision-agreement scoring; out-of-distribution refusal criteria.

State

In progress — internal, no publication yet.

Data

Synthetic and public reference problems only; no client data.

Outputs

Internal harness, parameter sweep records, working note.

Can filtering at the sensor make cheap hardware behave like expensive hardware?

A large share of instrument cost buys noise performance rather than new capability. Where the dominant noise is structured — thermal drift, mains pickup, quantisation, mechanical resonance, sampling jitter — a meaningful part of the gap is recoverable in software, on the device, inside a small compute and power budget.

The limit is hard and worth stating plainly: filtering cannot recover information the sensor never captured. Once the signal of interest is below the noise floor at the point of capture, no downstream processing restores it. The useful work is therefore establishing, for a given class of measurement, where that boundary sits — so that a hardware selection can rest on measurement rather than on a datasheet claim.

Bench work is currently on a constrained microcontroller target with fixed-point arithmetic, comparing filtered cheap-sensor output against a reference instrument under matched environmental conditions.

Method

Noise structure characterisation; fixed-point filter design; matched-condition benchmarking against a reference instrument.

State

Open — bench work under way.

Data

Laboratory captures made by us; no third-party data.

Outputs

Filter implementations, bench protocol, comparison record.

Where does a problem stop being hard and start being intractable?

Commercial software regularly commits to requirements that are quietly impossible at the scale they are written for: exact scheduling under a full constraint set, exhaustive matching across a growing catalogue, a combinatorial search that behaves in a demonstration and explodes in production. The failure appears late, expensively, and usually as a performance defect rather than as the specification error it actually is.

This entry is about producing a short, readable feasibility argument early enough to change the plan. Three things go into it: how the cost of the exact problem grows with the parameters the business cares about; which relaxations — approximation, bounded optimality, restricted inputs, tolerated staleness — recover tractability; and what the organisation would be giving up in each case, expressed in its own terms rather than in complexity notation.

An internal write-up exists. Work now is on turning it into a repeatable assessment that can be run in days rather than weeks.

Method

Complexity framing; empirical scaling curves on representative instances; documented relaxations with their cost in accuracy or coverage.

State

Written up internally — being turned into a repeatable assessment format.

Data

Generated instances and public benchmark sets.

Outputs

Assessment template, scaling-curve notebook, worked example.

What shape should engineering data take before anyone knows what will be asked of it?

Test rigs, production lines and fielded equipment generate data long before there is a question to ask of it. Decisions taken at capture time — what constitutes one observation, which units are recorded, whether uncertainty travels with the value, whether the instrument and its calibration state are identified — determine whether the archive can answer anything useful years later.

The failure mode is not missing data. It is data that exists in volume and cannot be trusted: readings whose units are ambiguous, samples that cannot be tied to the specimen or batch they came from, and time bases that drifted without record. Retrofitting provenance is usually impossible.

We are looking for the minimum discipline that keeps an engineering dataset answerable without imposing a schema that nobody will maintain once the project that mandated it has ended.

Method

Provenance modelling; units and uncertainty carried with values; retrospective answerability tests against archived public datasets.

State

Open — internal, using public engineering datasets only.

Data

Published open engineering datasets; no client material.

Outputs

Minimum-provenance checklist, answerability test set.

How much inference can move to the device before latency stops being the binding constraint?

Edge deployment is usually justified on latency and privacy. In practice, once a workload is actually on the device, the binding constraint frequently turns out to be something that was never in the architecture argument: sustained thermal budget, memory bandwidth, the logistics of updating a model on equipment in the field, or the difficulty of getting diagnostic evidence back when behaviour changes.

This entry is a measurement exercise. For a representative workload we profile latency, sustained thermal behaviour, and quantisation effects on target silicon, and we cost the update and observability overheads that rarely appear in a benchmark. The intent is that the edge-versus-server argument can be settled with numbers specific to the deployment rather than with general claims.

Method

Latency and thermal profiling on target silicon; quantisation sweeps; measured update and observability overheads.

State

Open — early instrumentation stage.

Data

Synthetic workloads on hardware held by the lab.

Outputs

Profiling harness, deployment cost model.

What does an experiment record have to contain to survive scrutiny two years later?

Research and development tax relief in the United Kingdom is claimed against work that sought an advance in science or technology and faced technological uncertainty. The claim is made long after the work, often by people who did not do it, from whatever record survives. Where that record is a set of commit messages and a memory, the claim rests on reconstruction.

We are interested in the smallest record that is both honest and durable: what the uncertainty was before the work began, what was tried, what the result was, when it happened, and who did it — captured at the moment rather than assembled at year end. This is a discipline question as much as a tooling one, since any system heavy enough to be ignored produces no record at all.

This is not tax advice and we do not give it. Our concern is the technical evidence: making sure the engineering story is written down accurately and contemporaneously, so that whoever prepares a claim has something real to work from and an adviser can do their job properly.

Method

Contemporaneous capture of hypothesis, method, parameters and result; minimal-friction tooling; review of what a technical narrative must evidence.

State

In progress — internal tooling being built and used on entries 01–05.

Data

Our own experiment records only.

Outputs

Internal record-keeping tool; template technical narrative.