Business field 04
AI for development, evaluation and code generation
We apply AI where it measurably speeds up engineering work: evaluating measurement and test data, generating adapted code, and connecting models to the data and tools where the work actually happens. And we build the harnesses without which the benefit of such systems cannot be demonstrated.
Fine-tuning and adaptation of AI models
A general model does not know your components, your standards or your codebase. Adaptation brings that knowledge in.
The starting point is the task, not the model: what should measurably improve — evaluating a test report, classifying fault patterns, generating configuration or driver code? That determines whether good context design is enough, whether retrieval over your own documents is the right answer, or whether a fine-tuned model is genuinely needed. The three routes differ in effort by orders of magnitude, so the order in which they are tried is not a detail.
Where fine-tuning is the right choice, most of the effort is data work: preparing training examples from your existing material, deliberately including edge cases, and holding a separate evaluation set back. Only then comes training — followed by testing against exactly the same evaluation set as the base model, so the difference is documented rather than asserted.
Your data stays where you want it. Adaptation and operation are also possible entirely within your own infrastructure, with no training or operational data leaving the building.
Framework conditions
| Parameter | Value |
|---|---|
| Approach | context design, retrieval over your own documents, fine-tuning |
| Base models | open models for operation in your own infrastructure, or hosted models |
| Data residency | on-premise or exclusively within your own infrastructure |
| Evidence of improvement | comparison against the base model on a held-back evaluation set |
| Operation | in your environment or as a service operated by us |
Customisable to your requirements
- Task and acceptance criterion agreed jointly
- Choice of approach: context design, retrieval or fine-tuning
- Base model chosen for your privacy, cost and quality requirements
- Preparation of training and evaluation data from your own material
- Data sovereignty: processing exclusively in your infrastructure is possible
- Integration into your existing tools and workflows
- Retrainability: tooling and process for later model versions
Typical tasks
- Evaluation of measurement and test reports
- Classification of fault patterns and deviations
- Generation of adapted configuration, driver and test code
- Search across your own standards, datasheets and legacy projects
- Preparation of documentation from existing material
MCP servers and tool integration
A model only becomes useful once it can reach the real data and tools. That is exactly what an MCP server provides.
The Model Context Protocol (MCP) is an open interface through which an AI model can reach external tools and data sources, instead of having them pasted into the prompt. We write the servers that expose your systems on that interface: measurement databases, test benches, file stores, version and issue tracking, in-house calculation tools.
That turns a chat window into a workplace: the model reads the current measured value instead of asking for it, opens the correct datasheet instead of inventing its contents, and files the result where it belongs. What it may and may not do is your decision — every tool is enabled individually, with read and write access granted separately.
We pay attention to what actually causes trouble in practice: clear permission boundaries, traceable logging of every tool call, and tools that behave in a defined way on unexpected input rather than doing something arbitrary.
Scope
| Parameter | Value |
|---|---|
| Interface | Model Context Protocol (MCP), an open standard |
| Connectable sources | databases, file stores, test benches and instruments, version and issue tracking, in-house tools |
| Permissions | per tool, with read and write access granted separately |
| Logging | every tool call traceable with a timestamp |
| Operation | inside your network; no external access is required |
Customisable to your requirements
- Selection and scoping of the tools exposed
- Permission concept, read or write per tool
- Connection to your data sources, equipment and test benches
- Logging and review of accesses
- Operation inside your own network with no external access
- Extension with your own calculation and test tools
Typical applications
- Access to measurement data and test reports without copying
- Search across datasheets, standards and legacy projects
- Automatic filing of evaluations and reports
- Connection of test benches for query and control
- Working directly in version and issue tracking
AI harnesses
Harnesses that turn “the model seems better” into a defensible, repeatable number.
A harness is the infrastructure around an AI system: datasets with established ground truth, automatically computed metrics, versioned and reproducible runs, and a report that makes two model versions directly comparable.
Without that infrastructure a model change cannot be justified: you cannot tell whether an average improvement was bought with a degradation in exactly the cases that matter. That is why edge and special cases belong in their own test set, not as a sample folded into the average.
The harness runs automatically in your CI: every model or data version produces the same report, and regressions show up before they ship.
Scope
| Parameter | Value |
|---|---|
| Systems assessed | In-house models, third-party models and LLM-based workflows |
| Reproducibility | Datasets, models and configuration versioned per run |
| CI integration | GitHub Actions, GitLab CI or your existing pipeline |
| Operation | On-premise or in your own cloud environment |
Customisable to your requirements
- Metrics and acceptance thresholds for your use case
- Construction and maintenance of the reference datasets
- Target systems: in-house models, third-party models, LLM-backed workflows
- Integration with your CI system
- Report format and level of detail
- Robustness and edge-case tests as a separate test set
- Operation exclusively within your infrastructure
Typical applications
- Regression testing when changing model or vendor
- Acceptance testing of bought-in AI components
- Ongoing quality monitoring in production
- Comparing several model candidates under identical conditions
- Evidence and documentation for audits
Related fields
From requirement to series
-
Specification
We clarify the application, constraints and acceptance criteria: temperature range, power, measuring range, installation, quantities, service life.
-
Design and samples
Design, engineering and sampled prototypes — each with a measurement report, so deviation from spec is documented rather than asserted.
-
Verification
Functional and endurance testing, thermal characterisation, EMC preparation and support through testing up to release.
-
Series
Manufacture of the components we developed, electrical end-of-line test, documentation, batch traceability and long-term availability.
Enquire about this field
Temperature range, power, measuring range, installation, quantity — with those we can answer concretely rather than generically.
Send an enquiry