Your business case deserves its own model set
Holistic Relationship Matters. HolisticRM is a Hungary-based AI development agency. We connect the business decision, the people using the system, the available data and the models that can help.
136+ AI models deployed
Trusted by 5 banks
Selected by ESA for 8 AI projects
21+ years of expert AI-development experience. Banking experience includes company, partner and earlier expert roles. The model portfolio includes varied AI and machine-learning models. Explore the relevant experience → ESA project roles and stages →
A business process may need several different predictions or decisions: forecast demand, identify an exception, interpret a document and recommend the next action. We design a bespoke set of models around those tasks. Depending on the evidence, that can mean a compact predictive model, a language model adapted to technical documents, computer vision, an agent workflow or a carefully tested combination.
Our work spans energy, manufacturing, space, banking, insurance, retail, ecommerce and healthcare. Domain experts help define what the data means, which mistakes matter and what a usable output looks like. In high-trust settings, the review, access and validation requirements are part of the design.
Better data and better models, developed together
Improve the data. Refine the model. Evaluate the business result.
Our Holistic Agile ML approach builds on CRISP-DM and draws on the business-led, iterative principles of PMI’s CPMAI methodology. We turn that lifecycle into two connected improvement tracks, judged against the same objective.
Develop the right data
With your domain specialists, we examine relevance, quality, coverage and availability at the point of decision. We improve labels and features, connect useful sources and test additional context where it is appropriate. A supplier’s historical deliveries, current order state and external conditions can contribute different information.
Working outputs: a data inventory, agreed definitions, quality checks, feature versions and documented gaps.
Refine how the models learn
We compare suitable model families, representations, architectures and training settings. An LLM may use retrieval, fine-tuning or task-specific tooling; a forecasting task may need a different approach entirely. We test combinations when they solve a defined problem.
Working outputs: a candidate shortlist, a reproducible experiment record and a reasoned selection for each task.
Connect the tracks through controlled experiments
We test whether a useful change comes from better inputs, a different model, improved training or a combination. Comparable experiments help separate those effects. More data and greater model complexity must justify their contribution to the intended use.
Domain knowledge runs through both tracks. It helps spot unavailable future information in a feature, a misleading target, an impractical prediction window or an output that a team cannot act on.
Framework foundations: IBM CRISP-DM guide ↗ · PMI’s six-phase AI lifecycle ↗.
A clear lifecycle, with room to learn
Business understanding leads the work. Each phase can return to an earlier question when the evidence changes. The activities and handover materials are agreed for the project.
Scroll the table sideways to compare columns. Keyboard: focus the table and use the arrow keys.
| Phase | What we resolve together | Example handover and decision |
|---|---|---|
| 1. Business understanding | Which decision should improve? Who acts on the output? What is the current process, and is AI appropriate? | Problem statement, baseline, accountable business owner and measurable acceptance criteria. Confirm a useful, feasible next step. |
| 2. Data understanding | Which relevant data exists, what does it mean, and can it be used for this task? What does it fail to cover? | Data inventory, quality and access assessment, domain definitions and critical gaps. Confirm that a credible evaluation is possible. |
| 3. Data preparation | How should records, labels, documents and features be prepared without introducing future information or other leakage? | Versioned preparation pipeline and a split strategy appropriate to time, entities and the intended use. Approve the experimental dataset. |
| 4. Model development | Which candidates suit the task? How should they be trained, adapted or combined within the agreed constraints? | Baseline and candidate experiments, recorded configurations and validation results. Shortlist approaches for fuller evaluation. |
| 5. Model evaluation | Does the candidate meet technical and business criteria, including important failure cases and practical limitations? | Evaluation report, error analysis and documented trade-offs. Accept, refine or stop; a promising experiment is not automatic production approval. |
| 6. Operationalisation | How will the model enter the workflow, be reviewed, monitored, maintained and, when necessary, rolled back? | Agreed integration, deployment and monitoring plan; ownership, release checks and feedback into later iterations. |
CRISP-DM names the final phase “Deployment”; PMI CPMAI uses “Model operationalization”. Both provide an iterative lifecycle. Our contribution is the project-specific engineering and coordination of data, models and business use. IBM lifecycle overview ↗ · PMI phase definitions ↗.
Current research, tested against your actual task
“State of the art” is a starting point for investigation. The decision comes from relevant evidence.
We review current research, suitable model families and available implementations before proposing a shortlist. A published benchmark can inform that choice, but your data, workflow and constraints determine whether an approach is useful here.
- Establish a credible baseline. Record the existing rule, simple statistical model or current process. This provides a practical reference for added complexity.
- Build a relevant candidate set. Consider model capability, data requirements, licensing, deployment options and task suitability. Document why a candidate is included or excluded.
- Compare fairly. Use comparable data, preprocessing rules, validation windows and an agreed search budget. Record model, data and configuration versions so that the result can be inspected.
- Evaluate the whole decision. Examine prediction or generation quality, important error types, robustness, latency, inference requirements and how a person will use the output.
- Confirm on a protected final test. Keep final-test data separate from training and iterative tuning. For time-dependent or grouped data, use a separation strategy that reflects the real deployment.
- Release with an operating plan. Agree ownership, human review, monitoring and a change process. A new model or data source is evaluated before replacing the accepted version.
The selected approach is the strongest fit among the candidates evaluated under the agreed protocol. New research, new data or different requirements can change that decision.
Validation reference: scikit-learn on cross-validation, test leakage and time-dependent data ↗.
Illustrative planning example · not a client result
One manufacturing decision. Several testable approaches.
A procurement team wants to identify purchase orders likely to arrive late, early enough for a vendor manager to intervene. The candidate design below illustrates the method; it reports no measured performance.
Define the prediction before choosing the model
Agree what “late” means, when the prediction is made, which orders are eligible and what action follows an alert. Only information available at that moment can be used. Evaluate on later orders, with entity separation where it is needed to avoid leakage.
Scroll the table sideways to compare columns. Keyboard: focus the table and use the arrow keys.
| Candidate | Relevant inputs | What the experiment should resolve |
|---|---|---|
| Existing rule and simple baseline | Promised delivery date, order state and historical supplier delay rates. | What can a transparent, inexpensive approach achieve before extra data and model complexity? |
| Tabular predictive model | Order and supplier history, lead times, seasonality and approved contextual features. | Do richer features and a suitable tree-based or other tabular model improve the agreed decision measures? |
| Sequence-based candidate | Time-ordered supply and order events, where there is enough reliable history. | Does modelling the event sequence add useful information beyond the tabular baseline? |
| Document-assisted candidate | Approved supplier updates or logistics documents, with traceable extraction. | Do validated document-derived features help? An LLM is considered only if interpretation of the text is useful. |
| Combined candidate | Selected model outputs and relevant inputs from the preceding experiments. | Does a tested combination improve the decision enough to justify its added operating requirements? |
The final dataset, metrics, thresholds and candidate set depend on the actual project. No synthetic score, uplift or client outcome is presented here.
Engineering experience from industry to space
Different domains call for different inputs, models and acceptance decisions. These examples show the scope and role of our work.
From technical specifications to test code
Our manufacturing work includes multiple language models, task-specific fine-tuning, document processing and dedicated tooling for an engineering workflow. Identifier and configuration consistency are important evaluation concerns. The client’s identity remains confidential.
This is a specific application of model adaptation and integration, rather than a claim that one general-purpose LLM can reliably complete every engineering task.
Progressive comparison, with domain features
The ESA NAVISP account of the EGNOS project describes an agile CRISP-DM process, progressively expanded features and comparison of several tree-based and deep-learning approaches. LightGBM was selected for the reported tasks after evaluating performance and training time.
HolisticRM’s contribution to AI model development is described in our own project portfolio, within the Integricom-coordinated project. The ESA article documents the consortium project and its method.
Read ESA NAVISP’s project account ↗
Our space project roles →
OPT4SOL.AI: decision support for solar-site selection
The ongoing ESA demonstration project combines Earth observation, infrastructure and land-use information with machine learning to assess candidate solar sites. ESA lists GeoX as prime contractor and HolisticRM as subcontractor.
The official page describes the project in its Baseline Design Review phase, with further design and pilot work in progress. This is active development, rather than a completed outcome claim.
Marketing Agent Set: specialist work, connected
Apply the same business-led discipline to coordinated marketing workflows.
Our existing Marketing Agent Set brings together configurable specialist roles for research, planning, content, customer decisions and review. We configure the relevant capabilities around the task, available tools and agreed responsibilities.
Understand and plan
Market and competitor research, audience understanding, brand context and SEO/AEO/GEO analysis support a documented plan. Behavioural-science and conversion reviews examine comprehension, friction and how a customer can take the next useful step.
A workflow with accountable outputs
For example, a product launch can move from an evidence-backed audience brief to a content plan, draft assets and an evaluation plan. Each handover records what was used, what remains uncertain and who owns the next decision. Access, integrations and execution rights are agreed for the engagement.
Our own AEO/GEO agent core has already been developed through our GINOP work. For an assignment, we tune and configure it to the required prompts, sources, reporting and monitoring workflow, including relevant existing tools.
Explore AEO/GEO audit and monitoring → · Read the MarTech publisher profile ↗
Research that strengthens applied AI
Our R&D connects model development, domain applications and the infrastructure needed to put AI to work.
Space and geospatial AI. Experience across eight ESA-selected AI projects informs our work with navigation, Earth observation and location-based decisions. Explore the projects and roles →
European AI infrastructure. Through IPCEI–AI / ShAIr.ly, we contribute to secure European AI infrastructure and distributed model development, collaborating through a network spanning 12 countries and 33 partners. Our own platform work also includes a DIMOP Plusz programme. Company and programme background →
GlobAI.ly. We collect international AI practices, examine their relevance and use that knowledge to improve the solutions and service we deliver. A new method still needs to be evaluated for the actual business case.
INNOspace Masters · 2026
Top 3 Winner · Mercedes-Benz car2space Challenge
SpaceFlow Swarm Mobility Intelligence was named a Top 3 Winner in a competition receiving 313 submissions from 38 countries. The final ranking and Overall Winner are expected on 12 November 2026.
According to our company records, HolisticRM is the only Hungarian company to receive an INNOspace Masters award in the past ten years.
Questions before an AI project
How does your method build on CRISP-DM and PMI CPMAI?
We use their business-led, iterative lifecycle as a foundation and translate it into project-specific data development, model experiments and delivery decisions. Our emphasis is coordinated improvement of inputs and models, with domain experts and agreed acceptance criteria throughout.
Do we need one model or several?
That depends on the decisions and tasks. Several specialised models may serve a wider workflow, while a single compact model may be sufficient for a narrow prediction. We define the tasks first and test whether combining models adds value.
Will you always choose a new or more complex model?
We examine relevant current approaches alongside a practical baseline. Selection depends on the evaluation protocol, useful performance, deployment constraints and maintainability. A more complex candidate needs evidence that it is worth operating.
Can we begin with incomplete data?
Yes. Data understanding is an early part of the work. We assess critical gaps, clarify a feasible pilot and agree what can be evaluated before committing to a model-delivery scope.
What do we receive beyond a model?
The agreed scope can include the problem and data definitions, experimental comparison, evaluation report, integration design, versioned deployment and monitoring plan. Responsibilities, acceptance criteria and maintenance arrangements are made explicit for the engagement.