LEAF Labs: From emerging technology to working systems.
Labs is LEAF's engineering engine. We prototype, integrate and validate technology against the real constraints of the environment where it has to work: data, hardware, workflows, infrastructure and people.
Some projects remain purpose-built systems. When the same problem keeps appearing across organizations and the solution can become reusable, that work can evolve into a LEAF product.
- Prototypequickly
- Engineerfor reality
- Validatewith evidence
- Productizewhen it repeats
What Labs is
Engineering between research and production.
Research shows what may be possible. Production asks whether it works repeatedly, under constraints, with real data and real users. Labs operates in between.
We use prototypes to reduce uncertainty, then engineer the parts that matter: models, data pipelines, hardware, interfaces, integration, deployment and the surrounding software.
The output is not necessarily a product. It may be a validated prototype, a purpose-built system, a deployment architecture or a reusable product when the problem justifies one.
Why Labs
A promising technology is not yet a working system.
A model running in a notebook, a sensor producing data or an API returning the expected result once does not establish that the system is ready for real use.
Production exposes constraints that demonstrations hide. Labs exists to close that engineering gap.
What a demo shows
- A model runs in a notebook
- A sensor produces data
- An API answers once
What production asks
- Latency
- Data quality
- Integration
- Hardware limits
- Permissions
- Failure handling
- Deployment
- Maintenance
- How people actually use it
One engine, two outcomes
Build for the problem. Productize only when reuse is real.
Purpose-built systems
Not every problem should become a LEAF product. When requirements are specific to one environment, Labs can prototype, engineer and validate a system around those constraints without forcing it into a product model.
Examples of outputs
- Prototype
- Integration
- Technical demonstrator
- Deployment architecture
- Custom AI system
- Embedded system
- Data pipeline
Reusable products
When the same underlying problem appears repeatedly and a shared architecture solves it well across contexts, Labs can turn that validated work into a reusable LEAF product.
Current products
Productization is an outcome of evidence, not a requirement imposed at the start.
The engineering path
Prototype. Engineer. Validate. Deploy.
01/ Frame
Define what has to be proven
Translate the problem into technical requirements, operating constraints and measurable acceptance criteria.
02/ Prototype
Reduce the largest uncertainty first
Build only enough to test the assumptions that determine whether the idea deserves deeper engineering.
03/ Engineer
Build the surrounding system
Integrate models, data, hardware, interfaces, infrastructure and application logic according to the target environment.
04/ Validate
Measure what happens under realistic conditions
Test the technical and task-level behavior that matters for the system rather than treating a successful demonstration as proof.
05/ Deploy
Put the system into its operating context
Define integration, versions, monitoring, maintenance and ownership appropriate to the deployment.
Prototypes are questions
Build the smallest thing that can disprove the assumption.
A prototype should reduce uncertainty. It should answer a technical or operational question before the project accumulates unnecessary architecture around an untested assumption.
Once the uncertainty is reduced, engineering can become more deliberate.
Questions a prototype can answer
- Does the model hold up on representative data?
- Does inference fit the actual device?
- Does one enterprise source connect cleanly?
- Does the sensor topology cover the environment?
- Does the critical workflow run end to end?
Validate the system, not the demo
Evidence determines whether engineering continues.
Validation depends on the system. These are dimensions to select from, agreed per project: no engagement measures all of them by default.
Task quality
Does the system perform the intended task well enough on representative cases?
Performance
Are latency, throughput or resource requirements compatible with the operating environment?
Integration
Does the system behave correctly with the interfaces, data and infrastructure around it?
Failure behavior
What happens when data is missing, a dependency is unavailable or an unexpected case appears?
Operational fit
Can the system be deployed, monitored, updated and supported within the target environment?
Human fit
Where people interact with the system, does the workflow make sense in actual use?
Validation results apply to the configuration and conditions that were tested.
Engineering includes the failure path
A system is not defined only by what happens when everything works.
Labs designs around expected failures as well as successful execution.
The relevant failure modes depend on the system. They are identified and tested where their consequences justify it.
- Unavailable dependencies
- Invalid data
- Hardware limits
- Unsupported inputs
- Model errors
- Network interruptions
- Operator mistakes
What powers Labs
Engineering capabilities behind the systems we build.
These capabilities support both purpose-built systems and reusable Labs products. They describe what Labs knows how to engineer, not what it sells as a product.
Training Data Generation
Synthetic Data
Generate and validate fit-for-purpose synthetic datasets when representative real-world data is scarce, sensitive, imbalanced or expensive to obtain.
Explore Synthetic DataEdge AI Engineering
AI on the Edge
Design and optimize inference around the real constraints of embedded devices, gateways, accelerators and local edge infrastructure.
Explore AI on the EdgeConnected Sensing & IIoT
Industrial IoT
Engineer connected sensing, embedded acquisition and industrial data systems across devices, communication layers and downstream platforms.
Related product: ArgoWhen strategy and engineering meet
Some systems cannot be designed in separate phases.
Talk with Your Systems and AI Automation span Advisory and Labs because business rules, operating models, architecture and implementation affect one another directly. Each is one capability with one page, listed under both engines.
When a solution becomes a product
Repetition is a signal. Reuse has to be engineered.
Seeing the same problem more than once is not enough. A product needs a stable problem definition, a reusable architecture and enough common ground between deployments to justify maintaining a shared solution.
We consider productization when the same underlying problem has appeared repeatedly across independent contexts and the solution has meaningful potential for reuse. It then means deciding what stays configurable, what becomes common infrastructure and what must remain project-specific.
Labs products therefore come from validated engineering patterns rather than speculative feature lists.
Built from repeated problems
Products that emerged from Labs.
Each product has its own page describing its validated capabilities and deployment model.
Wireless Synchronized Sensing
Argo
Wireless sensor acquisition for synchronized sensing, IoT and edge AI.
Explore Argo
NFC Security & Traceability
Sigillum
Smart packaging security with batteryless NFC tags, cryptographic authentication and blockchain notarization.
Explore Sigillum
SEO & AI Search Auditing
Huntair SEO
Continuous website auditing across technical SEO, content, semantic structure and AI readiness.
Explore Huntair SEOHuntair SEO can be adopted directly on its own website; Argo and Sigillum are configured around the requirements of each deployment.
The LEAF flywheel
Research, problems and engineering feed each other.
Advisory exposes Labs to real strategic and operational problems. Labs turns selected questions into prototypes and systems, generating technical evidence that informs what LEAF recommends next.
Some solutions remain specific to one organization. Others reveal a repeatable pattern and evolve into products. Those products create further field evidence, new requirements and new questions.
The cycle is therefore driven by learning from real use, not by a fixed handoff from consulting to product development.
Research meets engineering
Close enough to research to test what is new. Close enough to production to know what breaks.
LEAF was founded by university lecturers and researchers who build products, and operates at the intersection of university research, engineering and business problems.
Labs is where that intersection becomes testable: new models, architectures, devices and techniques are useful only when they survive the constraints of a real system. Not every Labs project is a research project, and none implies a university endorsement.
No default stack
The architecture follows the problem.
Labs does not begin with a preferred model, cloud, framework or device and search for somewhere to use it. Technology is selected around the task, data, deployment environment, integration requirements and validation criteria. Concrete technologies are named on each capability and product page.
Models
Chosen for the task and its constraints
Data
Real, synthetic or both, fit for purpose
Hardware
Devices, sensors and accelerators in place
Runtime
Where and how the system executes
Integration
The systems it has to work with
Deployment
Cloud, private, on-premises or edge
From the field
Requirements become clearer when systems meet reality.
Real deployments expose constraints that architecture diagrams cannot fully predict. Data distributions change. Networks fail. Hardware overheats. Users take unexpected paths. APIs return edge cases. Workflows reveal exceptions.
Labs treats those observations as engineering evidence. They inform iterations, product boundaries and future technical decisions. It is why we build our products from the field up, not from assumptions.
Who Labs is for
For organizations that need to find out whether technology can actually work.
A technical hypothesis needs validation
Test the assumption on representative data, hardware or systems before committing to a full build.
A prototype needs production engineering
Turn something that worked once into a system that works under real constraints.
An emerging technology needs to meet existing systems
Integrate a new model, device or technique with the infrastructure already in place.
A recurring problem may deserve productization
Assess whether a shared architecture creates more value than rebuilding the solution each time.
A current product needs a deployment-specific integration
Configure and integrate an existing LEAF product around the requirements of one environment.
When to start elsewhere
Engineering is not always the first question.
The uncertainty is strategic
If the main question is which technology matters, which opportunity deserves investment or how the market is changing, start with Advisory.
Explore LEAF AdvisoryThe gap is capability
If the technology is understood but teams need the skills to adopt or operate it, Academy may be the more appropriate entry point.
Explore LEAF AcademyFrom system to capability
A working system still needs people who can use and operate it.
When Labs introduces a new technology or system, Academy can help the teams around it build the language, practices and skills required for adoption. It is an option, not a mandatory part of every Labs project.
What Labs does not promise
Prototyping reduces uncertainty. It does not remove it.
Labs exists to replace assumptions with engineering evidence, not to guarantee that every idea should move forward.
- A successful prototype does not automatically mean a system is production-ready.
- Newer technology is not automatically better technology.
- Not every technical problem requires AI.
- Not every AI workload requires a language model.
- Not every model belongs in the cloud.
- Not every workload belongs at the edge.
- Not every recurring problem should become a product.
- Productization does not eliminate deployment-specific requirements.
- Synthetic data does not automatically replace representative real data.
- Validation results apply to the tested configuration and conditions.
- Integration, security, performance and maintainability depend on the complete system.
- Technical feasibility does not by itself establish business value.
Start with what needs to be proven
Bring us the technical uncertainty.
Tell us what you are trying to build, what is still unknown and where the system would have to operate. We can assess whether the next step should be a focused prototype, deeper engineering, an existing Labs product or a different LEAF capability.
Not sure yet? Book a Scout Session