Case Studies

See how a difficult operating problem became a working system.

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

Engineering case studies

Find the operating problem that feels familiar. Find a project by industry, capability, technology or operating problem.

Capability

Industry

Technology

Problem type

Showing 13 of 13 case studies

Manufacturing

High-Precision RTLS and MES Workforce Integration

Worker presence, machine activity and project budgets became one governed, automated record.

The problem: A global medical-device and eye-care manufacturer needed to replace manual work-time logs with objective evidence of where floor workers were working and which active production job their time should support. Separate location, machine and payroll systems could not reliably connect physical presence to the correct project budget.
How it was engineered: GAIAA connected an Omlox-compatible UWB real-time location system to the MES through an on-premise integration layer. The software validates an operator's position against active machine and work-order state, then sends the resulting, audit-ready allocation to payroll and reporting tools.

Industrial IoT
System Integration
Operational Intelligence

Explore the case study

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 SAP Interface for Complex Enterprise Software

An LLM layer turned natural-language requests into validated, permission-aware SAP actions.

The problem: The existing SAP platform already contained the required business functions, but non-specialist users needed substantial SAP knowledge to find them, supply the correct parameters, follow the required sequence and interpret failures. An LLM layer could make SAP easier to use through natural-language requests, but unrestricted SAP access could bypass business rules and permission boundaries.
How it was engineered: GAIAA built an LLM layer over SAP that translated intent into structured SAP parameters and selected only predefined, authorized SAP tools. It validated each SAP response and, when an operation failed, could inspect approved SAP dependencies and explain the recovery path rather than claiming success or exposing a raw error.

AI Agents
SAP
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