Start with the problem

Discuss your project

Send a short note about the operational problem, where it shows up and what happens when it goes wrong. You do not need to decide whether the answer is AI, automation, software or process change.

Your details are only used to respond to your enquiry.

Prefer to talk? Book a call.

Prefer email? hello@smallengine.uk

work

work

Work you can inspect

Engineering claims are useful only when the evidence and the limits are visible.

Engineering claims are useful only when the evidence and the limits are visible.

Small Engine publishes current work at the level that can responsibly be supported: the problem, the implemented controls, representative failure cases, what the evidence demonstrates and what remains unproven.

Small Engine publishes current work at the level that can responsibly be supported: the problem, the implemented controls, representative failure cases, what the evidence demonstrates and what remains unproven.

Controlled technical information

Keeping technical information consistent, traceable and controlled.

Technical information becomes difficult to trust when the same facts, claims and documents are repeated across systems and publication surfaces. The current work separates authoritative information from publication, then adds explicit mappings, validation and evidence boundaries around change.

Problem

Repeated checking and publication risk

When related technical information is duplicated, teams have to rediscover what is authoritative and whether a published claim is still supported.

Intervention

Separate canonical information from publication.

Structured records, explicit publication mappings and controlled change make the relationship between source information and published output inspectable.

Controls

Validate the paths that must not succeed.

Implemented offline checks reject specified malformed evidence and mismatches between evidence and its expected source. The example below shows one tested failure case and its limits.

Potential outcome

More dependable change, with less repeated verification.

The intended operational value is more consistent technical information, faster controlled updates and reduced exposure to unsupported claims. Business outcomes are not yet claimed as measured.

What the evidence supports

Current proof, without pretending the work is finished.

The following distinguishes what has been implemented, what has been demonstrated in defined tests, and what remains to be established.

Implemented

Structured information and validation checks

Development work includes structured technical-information records with source provenance, publication mappings and checks for specified invalid evidence.

Implemented

Structured information and validation checks

Development work includes structured technical-information records with source provenance, publication mappings and checks for specified invalid evidence.

Demonstrated

Defined failure cases rejected

Recorded development and offline tests demonstrate how specified checks behave under stated conditions. The example below shows malformed evidence being rejected.

Demonstrated

Defined failure cases rejected

Recorded development and offline tests demonstrate how specified checks behave under stated conditions. The example below shows malformed evidence being rejected.

Still to establish

Complete production operation and business results

These tests do not establish end-to-end production publication, authenticated approval enforcement or measured client business outcomes.

Still to establish

Complete production operation and business results

These tests do not establish end-to-end production publication, authenticated approval enforcement or measured client business outcomes.

These status labels apply to this project’s evidence, not to every Small Engine engagement.

RECORDED VALIDATION EXAMPLE · 9 OCTOBER 2026

Rejecting malformed evidence before it can support a decision

The risk

A validation process can give false confidence if malformed evidence is accepted as though it were a valid record.

The implemented check

The offline validator checks that the relevant evidence contains a list of records in the required structure before passing it to the existing comparison checks.

A representative test

One test supplied a list containing a missing record and an empty record. Other tests substituted the wrong container type or included values that were not records.

invalid_shapes = (
{'row': {}},
'one row',
[None, {}],
[{}, False],
[{}, []],
)

Extract from the recorded test inputs. These are deliberately malformed synthetic examples.

The recorded result

The review records rejection of all 320 malformed cases tested across the defined result categories and validation phases.

Recorded review excerpt

“320 nonempty/mixed malformed complete_rows cases reject”

What this demonstrates

The specified malformed inputs were rejected within the reviewed offline test environment.

The boundary

The tests used synthetic fixtures. No database connection or SQL execution took place during the review. Passing offline validation did not establish runtime readiness, authenticated approval enforcement or production operation.

If you have a bounded operational problem and want to know whether it deserves investment, start with the evidence.

See how we work

See how we work

Senior-led AI, automation and software engineering. Based at Sussex Innovation Centre, University of Sussex, in Brighton. Working with organisations across the UK.

🌱 Small by design: focused systems, fewer wasted tools, remote-first where practical.

Senior-led AI, automation and software engineering. Based at Sussex Innovation Centre, University of Sussex, in Brighton. Working with organisations across the UK.

🌱 Small by design: focused systems, fewer wasted tools, remote-first where practical.

Senior-led AI, automation and software engineering. Based at Sussex Innovation Centre, University of Sussex, in Brighton. Working with organisations across the UK.

🌱 Small by design: focused systems, fewer wasted tools, remote-first where practical.