Case Studies

See how a difficult operating problem became a working system.

Explore the problem, constraints, engineered solution and result behind each implementation.

Explore case studies See solutions

Engineering case studies

Find the operating problem that feels familiar.

Find a project by industry, capability, technology or operating problem.

CapabilityIndustryTechnologyProblem type

Showing 12 of 12 case studies

Energy

Automated Data Extraction from Legacy SCADA Interfaces

Existing SCADA screens became a reliable data source without replacing the system or waiting for an API.

The problem: A renewable-energy operator used proprietary supervisory control and data acquisition (SCADA) software to monitor turbines and operating conditions across multiple wind farms. Staff could reach each system only through a restricted remote-desktop screen: there was no usable API or database connection. The screen itself was therefore the only available data source, but conventional optical character recognition was unreliable because the interface rendered heavily antialiased vector text with ambiguous character edges.
How it was engineered: Automation navigated each remote session and captured the relevant screens. Vision models first located tables, rows, columns, labels, status graphics and value regions; difficult text was then split into individual glyphs, classified and ordered back into words and numbers before the reconstructed record was structurally validated.

Computer Vision
Data Engineering
Integration

Explore the case study

Retail

Computer Vision for In-Store Attention Analytics

Anonymous camera observations were connected to spatial movement and shelf-attention signals.

The problem: A retailer wanted to understand how shoppers moved through a physical store and which shelf areas attracted attention before a purchase, without identifying individuals. Sales records showed only the final transaction, while people counting and person detection could not reveal what someone looked at. An ordinary store camera also provided no reliable training label for the shopper's true gaze direction.
How it was engineered: The store was mapped into a shared coordinate system and anonymous camera tracks were localized within it. During model development, eye-tracking glasses supplied the missing gaze ground truth, linking camera imagery, shopper position and the shelf actually viewed; deployment then required only the ordinary camera feed to estimate shelf-attention events.

Computer Vision
Spatial Analytics
Data Fusion

Explore the case study

Cities & public sector

Vision-Based Urban Vehicle Identification

Vehicle and plate regions became validated events despite difficult image conditions.

The problem: An urban camera project needed to convert passing vehicles into structured observations that included a validated plate candidate. A complete street image could contain several vehicles, signs, advertisements and road markings, so optical character recognition could not know which text belonged to a plate. The plate itself might also be small, angled, blurred, partly hidden or badly exposed.
How it was engineered: The pipeline first detected and tracked a vehicle across frames, then localized and normalized its plate region. Character recognition ran only on that focused evidence, allowing the system to prefer useful frames, validate the candidate and emit a structured event with its quality state and source context.

Computer Vision
OCR
Event Processing

Explore the case study

Enterprise operations

Natural-Language Interface for Complex Enterprise Software

Natural-language requests became validated, permission-aware actions inside enterprise workflows.

The problem: In this enterprise-software project, the existing platform already contained the required business functions, but non-specialist users needed substantial product knowledge to find them, supply the correct parameters, follow the required sequence and interpret failures. A chatbot alone could only produce text, while unrestricted system access could bypass business rules and permission boundaries.
How it was engineered: The orchestration layer translated intent into structured parameters and selected only predefined, authorized tools. It validated each enterprise response and, when an operation failed, could inspect approved dependencies and explain the recovery path rather than claiming success or exposing a raw error.

AI Agents
Software Engineering
Integration

Explore the case study

Laboratories & science

Unified R&D Laboratory Operations Platform

Projects, experiments, processes, samples, measurements, analyses and reports were connected into one evidence chain.

The problem: Within a broader research-and-development laboratory programme, scientists and operators needed to connect project planning, experiments, physical samples, equipment, process parameters, instrument files, analyses and reports. Those records naturally lived in documents, spreadsheets, calendars, machine computers and notebooks; no single conventional project-management or laboratory tool preserved the complete scientific history across them.
How it was engineered: The system was modelled around ownership of scientific truth: Project → Experiment → Process → Sample → Measurement → Analysis → Report. Equipment, materials, machine data, quality and audit records connected to that chain, preserving context as work moved from planning through execution and reporting.

LIMS
Scientific Data
Workflow

Explore the case study

Laboratories & science

End-to-End Sample Traceability and Genealogy

Physical identity and complete historical genealogy remained connected through transformations and measurements.

The problem: Within that laboratory programme, each research sample was a real physical object that could be labelled, moved, processed, measured, split into descendants, combined with other samples or assigned a specific position inside a batch. A mutable database row could show its latest state, but would erase many-to-many transformations and the evidence explaining how it reached that state.
How it was engineered: Each sample received a durable identity surrounded by append-only genealogy edges, state and location history, process participation and measurements. Batch executions recorded every physical position separately, preserving individual traceability without duplicating the shared process run.

LIMS
Traceability
Data Lineage

Explore the case study

Laboratories & science

Governed Scientific Instrument Data Integration

Raw artifacts moved through archive, fingerprinting, parsing, validation and correlation without losing provenance.

The problem: The laboratory used scientific instruments from different vendors, each exporting measurements through its own text, spreadsheet, XML, image or proprietary file format. A file extension did not establish scientific meaning, and parsing alone could not prove which instrument, sample and method produced a value. A silent import failure could also be mistaken for a genuine absence of observations.
How it was engineered: Each source was archived immutably and checksummed before format fingerprinting selected a versioned parser. Parsed records were normalized and validated, while sample and equipment correlation remained a separate controlled decision; ambiguous or failed inputs entered quarantine for review and replay against the preserved source.

Data Engineering
LIMS
Integration

Explore the case study

Laboratories & science

Experiment Planning and Adaptive Laboratory Workflow

Scientific intent became versioned, approved and executable work without confusing draft plans with operator tasks.

The problem: In the research laboratory, scientists needed to draft experiments with branches, dependencies, recipes, equipment and measurement decisions before operators received executable work. Treating every draft step as a task would expose unapproved plans. The system also had to distinguish rescheduling, retrying a failed attempt, adding scientifically necessary rework and correcting evidence instead of treating them as one generic edit.
How it was engineered: Scientific intention was versioned as activities and dependencies, then validated and explicitly released before executable work items existed. Execution attempts remained attached to the released intention; retries added attempts, rework added new intended work and evidence corrections preserved the original record with an amendment.

Workflow
LIMS
Resource Planning

Explore the case study

Laboratories & science

On-Premise AI and Scientific Computing Platform

Versioned local runs keep governed data, code, runtime, results and review state connected.

The problem: Researchers in the laboratory programme needed Python, notebooks, machine-learning models and graphics-processor workloads for confidential measurement data that had to remain on local infrastructure. A conventional shared server would create dependency conflicts, uncontrolled resource use and result files whose input dataset, code, runtime and model versions could not be reconstructed.
How it was engineered: A control plane recorded the user, project, governed measurement inputs, code version, runtime and resource limits for each request. Isolated workers executed the CPU or GPU job locally; immutable artifacts and results were then validated and published as separate Analysis records linked back to their exact inputs.

On-Prem AI
Scientific Computing
Data Lineage

Explore the case study

Laboratories & science

Laboratory Equipment and Resource Intelligence

Equipment readiness became an explainable decision across state, capability, people, time and materials.

The problem: Before releasing a laboratory operation, planners had to find equipment, a qualified operator, a valid time window and the required material lot. An empty calendar slot was insufficient: the machine also had to be operational, capable, calibrated and outside maintenance, while the operator's qualification and the material's quantity and expiry had to remain valid through execution.
How it was engineered: The planner evaluated the released operation against time-bounded equipment, operator, reservation and material evidence as one deterministic constraint set. It returned READY or NOT READY with specific reasons, searched for the earliest combination that satisfied every hard rule and reserved equipment, people and material together to avoid a partial plan.

LIMS
Industrial IoT
Scheduling

Explore the case study

Laboratories & science

Statistical Process Control for Research Laboratories

Governed observation populations, limits and rules turned charts into traceable quality decisions.

The problem: The laboratory wanted statistical process control to distinguish routine variation from isolated quality events and gradual drift. Drawing a chart was not the difficult part: measurements sharing a parameter name could come from different processes, materials, instruments or methods and therefore be scientifically incomparable. Using only today's control limits would also reinterpret historical alerts whenever those limits changed.
How it was engineered: The I-MR plan fixed the recipe, chamber, measurement method and approved baseline before evaluation. Every event retained its original limit set, rule set and engine version; reviewers could inspect the supporting observation and open an investigation without recalculating history.

Quality Analytics
LIMS
SPC

Explore the case study

Laboratories & science

Audit-Ready Scientific Reporting and Data Lineage

Report conclusions remained clickable back through analyses, measurements, raw files, samples, recipes and experiment versions.

The problem: Scientists needed to publish reports whose conclusions could survive technical review and later audit. Copying a result from a spreadsheet or analysis into a document preserved the visible number but severed its relationship to the measurement, raw file, sample and execution that produced it. If evidence or a template later changed, silently updating the report would also erase what reviewers originally approved.
How it was engineered: Every report value, image and chart was generated from an explicit source object and version. The system recorded the template, evidence set, generation job, artifact checksum and approval; later corrections created an amendment and, where needed, a new report version while retaining the original document and evidence state.

Reporting
Data Lineage
LIMS

Explore the case study

Start with the problem

Have a similar operating problem?

Share the environment, constraint and result you need. We can discuss the engineering path without exposing confidential details.

Discuss a similar challenge