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.
Deploy and improve: make model value sustainable
AI model deployment turns an evaluated model into a supported business capability. It includes integration, operating responsibility, monitoring and a safe response when performance changes. We agree these requirements before rollout. The same business objective guides improvements to source data, model architecture and the workflow in which predictions or generated outputs are used.
Experience: connecting model output to the next team
The NetPincér project in our portfolio describes automated data processing, model scoring and a defined output format for campaign handover. The historical implementation used Azure ML, Azure Data Factory and Power BI. The important delivery principle is the connection between a model result and a system that can use it; a contemporary project needs its own architecture and support decision.
Our Cofidis work similarly connected product-affinity scoring to eligibility and outbound allocation. In manufacturing test-code work, the receiving team is engineering, so identifiers, configuration integrity and validation become part of acceptance. These examples show why deployment starts during scoping: the eventual user, interface and review process shape what the model must produce.
Choose a release boundary your team can operate
A scheduled file, an interactive API and an action-enabled agent carry different support obligations. Compare freshness, response time, availability, access and recovery requirements. The first release can be a bounded advisory workflow if that is enough to test the business decision. Expand only when the team can operate the additional scope and the evidence supports it.
Version the data transformation, model and decision policy together. A changed threshold or product-eligibility rule can alter outcomes even when model weights stay fixed. Monitoring should therefore help the owner distinguish a data problem, a model change and a business-policy change.
Choose the approach that fits the decision
| Option | Useful when | Trade-off to test |
|---|---|---|
| Batch decision support | Decisions follow a regular planning cycle | Data freshness and delayed feedback |
| Interactive application | Users need an answer while working | Latency, availability and uncertain outputs |
| Action-integrated workflow | A system can execute permitted steps | Approval, reversibility and audit requirements |
Identify the receiving system and accountable operator
For a campaign handover, agree the output schema and when it must arrive. For an engineering assistant, agree validation and approval. For an agent, agree permitted actions and escalation. Identify who responds to failure, which dependencies they control and how the business continues during recovery.
Release a version your team can support
- Record the accepted model, transformations, decision rules and receiving interface.
- Replay valid, incomplete and failed-dependency scenarios before release.
- Start with a bounded workflow and a documented, tested fallback.
- Approve changes using comparable evidence; diagnose data, model and policy changes separately.
Measure the service after the handover
Measure accepted output arriving on time, correction workload, incidents and recovery time alongside the original business objective. For a queued workflow, alert volume and user action matter; for an API, response time and failure handling matter. A dashboard is useful when an owner can act on its signals.
Sample: an illustrative evaluation plan
Sample — illustrative scenario, not a client result. For illustration, start a supplier-delay workflow with one buying team and a daily queue capped at 20 alerts. Replay 50 representative requests before release, including missing inputs and a changed timestamp format. Record action taken, exception resolution and accepted outcomes. These Sample volumes make ownership and fallback testable; the actual release limits follow the client's workload.
What you receive
A release checklist, versioned evaluation evidence, interface contract, operational runbook and monitoring definitions. Specify alert owners, escalation, fallback, rollback and change approval. The agreement also identifies model and data rights, recurring dependencies and support boundaries so the system remains operable after handover.
Questions buyers ask
- How does this relate to CRISP-DM and PMI CPMAI?
- These frameworks support an iterative business-to-operation lifecycle. Our delivery approach makes coordinated data and model improvement, accountable handovers and acceptance decisions explicit for the assignment.
- Should every drift alert trigger retraining?
- No. First diagnose whether data quality, business conditions, a model limitation or measurement delay explains the change. The appropriate response may be a data repair or workflow change.
- Which versions need to be recorded?
- A Sample release record can identify data mapping v3, model v2, eligibility policy v5, the evaluation report and the approving owner. Changing any one component triggers its relevant checks; model weights alone do not define the deployed decision.
Explore our project references for examples of modelling connected to business workflows. The appropriate handover depends on the project’s role and operating context. Explore relevant industry applications.
Discuss your AI deployment. Bring a short, non-confidential description of the decision, current process and available data.
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.