Skip to content
EN

Capabilities

Machine learning, optimisation and decision models

Turning data into predictions, signals and decisions that can be measured and improved.

On one page

We design models for classification, ranking, forecasting, anomaly detection, vision, time series, optimisation and decision-making over structured and unstructured data. We select models and methods according to the real problem, the cost of error, uncertainty, latency and the ability to measure the result afterwards.

  1. 01Starting from the decision. Before selecting a method, we represent the situation the organisation wants to improve.
  2. 02Rules, calculations and models under a single criterion. A stable condition can be expressed as a rule.
  3. 04Data available at the right moment. Training with information that only appears after the decision produces a model that cannot be used.

An organisation needs to understand which decision it can improve, what information will be available when it has to be taken and what consequences follow from using the signal in one way or another.

A model can estimate a probability, anticipate a demand, order cases, detect an anomaly or recognise a pattern. The decision appears when that output is combined with objectives, alternatives, constraints, available capacity, costs of error, uncertainty, rules, authority, a policy for acting and a later signal of the result.

We build models and decision systems around that relationship.

We work with tabular data, text, images, audio, signals and time series. We combine machine learning, statistics, operational research, simulation and rules to produce a signal that can enter the work usefully.

Starting from the decision

Before selecting a method, we represent the situation the organisation wants to improve.

This representation prevents the project from optimising a technical metric disconnected from the use.

A more precise prediction can turn out to be less useful if it arrives late, if it demands data that does not yet exist, if it produces too many cases to review or if it concentrates errors in high-impact situations.

The complete decision is the object of design and evaluation.

Rules, calculations and models under a single criterion

A stable condition can be expressed as a rule. A calculation can resolve an exact relationship. A model learns patterns that would be difficult to program explicitly. An optimiser chooses between alternatives under constraints.

We use each mechanism where it contributes a clear function. This makes it possible to build hybrid systems:

  • a rule protects a constraint;
  • a model estimates risk or priority;
  • an optimiser allocates capacity;
  • a person decides the high-impact cases;
  • a workflow preserves the state;
  • observability records the result.

Technical complexity is justified by a demonstrable improvement in the decision, or by a capability that a simpler alternative cannot offer.

What we build

Classification

Assigning a case to a category, state or treatment: document classification, incident typing, intent identification, content categorisation, route assignment, condition detection and quality-control support.

Evaluation considers the unequal cost of errors and the ability to refer uncertain cases.

Ranking and prioritisation

Ordering items by relevance, urgency, opportunity, risk or expected value: prioritisation of case files, review order, source selection, ranking of alternatives, incident handling, resource allocation, knowledge retrieval and content selection.

A ranking is evaluated by the quality of the first positions and by the work it makes it possible to organise, as well as by aggregate metrics.

Forecasting and time series

Anticipating demand, load, risk, evolution, capacity or behaviour.

We design forecasting with temporal discipline:

  • every variable must exist at the moment of the prediction;
  • training respects the order of time;
  • the evaluation periods represent different regimes;
  • the horizons correspond to real decisions;
  • uncertainty is expressed in a form that can be used;
  • updating is adapted to the speed of the phenomenon.

We can combine statistical models, gradient boosting and specialised time-series architectures.

Anomaly and change detection

Identifying observations, patterns or regimes that deserve attention.

An anomaly is defined with respect to a context. A value can be normal for one entity and strange for another; a sequence can be plausible in isolation and problematic within a process.

The system can detect deviations, pattern breaks, distribution shifts, infrequent behaviours, inconsistencies between sources, unexpected transitions and physical signals outside tolerance. The result is integrated with investigation, explanation and operational response.

Scoring and probability estimation

Producing a calibrated signal about risk, propensity, quality, relevance or the probability of an event.

A score needs a clear definition of the event, a horizon, calibration, evaluation segments, thresholds, a policy and subsequent monitoring.

The figure helps to compare or to decide. The interface explains what it means, what uncertainty it contains and what action it allows.

Scenario analysis

Comparing alternatives under different assumptions: demand, capacity, prices, times, resources, constraints, policy changes, external events, failures and possible responses.

Scenarios help to understand sensitivity and trade-offs. They also reveal which assumptions really control the result.

Optimisation

Choosing an allocation, a sequence, a schedule, a route, a policy or a set of decisions within constraints: time, cost, quality, risk, capacity, energy, priorities, dependencies, permissions, safety, human load, fairness and reversibility.

The objective is formulated together with the people in charge. A mathematical function always represents a choice about what is valued and what is protected. Optimisation makes objectives and constraints explicit and makes it possible to compare the consequences of different priorities.

Multimodal models

Relating text, images, audio, video and signals when the problem needs to combine several forms of observation: document analysis, vision with textual context, correspondence between narration and video, inspection, physical perception, multimodal search and information extraction in complex formats.

Evaluation separates the quality of each modality from the coherence between them.

Data available at the right moment

Training with information that only appears after the decision produces a model that cannot be used. That is why we build an explicit timeline:

Each variable is assigned to a moment. Later data is reserved for building the label, evaluating or learning.

This discipline is especially important in forecasting, risk, prioritisation, operations and processes with several updates.

Baselines that represent the current work

The main comparison is the way the organisation decides today: a rule, a threshold, a heuristic, a historical average, a model already deployed, the judgement of a team, a combination of filters and review, or an allocation policy.

The new system is compared under the same conditions of information, time and capacity.

A technical improvement acquires value when it translates into a decision that is better prepared, more consistent, faster, cheaper or safer.

Uncertainty and calibration

Uncertainty is part of the output.

We work so that a probability of seventy per cent has a consistent empirical meaning within the scope evaluated. We observe calibration by segments, horizons and periods.

Uncertainty can be used to adjust thresholds, refer cases, request information, choose another model, show an interval, reduce the scope, abstain or ask for human judgement.

The interface presents the meaning the decision needs, alongside the confidence interval the figure admits.

From the model to the policy

A score or forecast becomes a decision through a policy.

The policy defines what action corresponds to each range, which constraints prevail, which cases need review, what capacity exists, what happens when data is missing, how ties are resolved, when it is updated, what is recorded, how it is reverted and what result will be observed.

We can optimise thresholds and policies according to costs, capacity and multiple objectives.

The policy remains examinable and versioned. A change in the model keeps its effect on authority and journey visible.

Optimising the complete system

A local metric can improve while the system gets worse:

  • prioritising more high-risk cases can saturate the review;
  • reducing the time per task can increase the next queue;
  • maximising utilisation can lengthen the cycle;
  • raising automation can concentrate complex exceptions in a few people;
  • optimising cost can reduce stability or the ability to explain.

That is why we evaluate the effect on the complete journey.

The objective function can combine quality, cost, time, risk, load, capacity, satisfaction, stability, recovery and the distribution of the result. We also declare constraints the optimisation must respect; some are technical and others represent organisational decisions.

Human participation

People take part in the formulation and in the use.

During design they define the objective, explain the current process, identify costs of error, establish constraints, review data and labels, point out regime changes, discuss trade-offs and decide which cases deserve human authority.

During operation they receive recommendations, contribute information, review uncertain cases, correct, authorise, change the policy and explain unexpected results.

The interaction is designed so that human judgement concentrates where it makes a difference, with sufficient context and a sustainable load.

Integration within the work

The model is connected with APIs, ERP, applications, workflows, agents, reporting systems, analysis tools, review interfaces, physical systems and observability.

The integration determines latency, availability, permissions, update frequency and responsiveness. It also makes it possible to record whether the recommendation was used, what action was taken and what result appeared.

Monitoring and learning

After deployment we observe predictive quality, calibration, drift, distribution shifts, latency, cost, availability, human decisions, corrections, rate of use, operational effect, segments with different performance and policy changes.

Retraining is triggered by evidence and by the needs of the process.

Each version preserves data, variables, code, parameters, metrics, period, associated policy, conditions of use and deployment decisions.

Possible applications

Operational prioritisation

Ordering requests, incidents, documents or cases by urgency, impact and capacity.

Demand and load forecasting

Anticipating volumes, needs and resources in order to plan.

Risk and anomalies

Detecting conditions that deserve investigation or a different route.

Recommendation and next action

Proposing alternatives within policies and context.

Allocation and planning

Distributing tasks, resources, shifts, models or agents under constraints.

Editorial optimisation

Selecting sources, formats, times and models to balance quality, cost and latency.

Financial intelligence

Combining signals, scenarios, forecasting and risk within information and decision systems.

Physical Intelligence

State estimation, planning, predictive control, routes and sequences under physical constraints.

How we evaluate

Predictive metrics
Precision, recall, F1, AUC, absolute error, squared error, ranking or forecasting metrics depending on the problem.
Calibration
Correspondence between estimated probability and observed frequency.
Cost of decision
Different valuation of errors, delays, abstentions and referrals.
Temporal validation
Evaluation over later periods and different regimes.
Baseline
Comparison with rules, heuristics and current practice.
Robustness
Sensitivity to noise, missing data, distribution shifts and segments.
Policy
Impact of thresholds, capacity, constraints and human review.
Operation
Latency, cost, availability, integration and ability to recover.
Result
Effect on time, quality, risk, load, resources and other business metrics.

Conditions and limits

Historical data contains the decisions, biases and omissions of the process that produced it. Modelling must make those conditions visible and evaluate how they affect different cases.

A predictive relationship makes it possible to anticipate; a causal explanation needs a different design and different evidence.

Regime changes can degrade usefulness before an aggregate metric makes it evident. Monitoring combines data, domain knowledge and operational signals.

The decision about the objective, the trade-offs and the authority belongs to the organisation. The system helps to represent it, apply it and learn from its results.

  • Finaz: forecasting, classification, ranking, risk and financial reporting.
  • ERP-Bots: prioritisation, anomalies and policies within operations over ERPs and business applications.
  • SuperSocrates: detection of gaps and discrepancies between sources, decisions and assumptions, and the choice of the next useful question.
  • SuperQuestions: representation and management of questions, evidence, decisions, dependencies and project work, including the optimisation of that work.
  • Visort, MagdalenOS and MontojOS: perception, estimation, planning and control.
  • Decision intelligence: application of these capabilities to specific decisions.

Closing

Machine learning provides signals. Optimisation turns objectives and constraints into choices. The decision system integrates both functions with policies, people and observable results.

What we represent before choosing a method

  1. 01what decision is taken today?
  2. 02who takes it?
  3. 03what alternatives exist?
  4. 04what information is known at that moment?
  5. 05what information arrives later?
  6. 06what objective is to be improved?
  7. 07what constraints must be respected?
  8. 08what cost does each type of error carry?
  9. 09what capacity does the process have to act on the recommendation?
  10. 10what result will make learning possible?
  11. 11which cases need human judgement?
  12. 12when is it better to abstain?

Let's think about which decision you want to improve.

We can represent together the moment of decision, the costs of error, the constraints and the signal that will show whether the system brings a real improvement.

Search · Type to search. Esc to close.

Search results →

Ask the bot

This is Ask 3.14, an automatic assistant. It answers only with the public content of this website — solutions, capabilities, systems, questions, readings and laboratory work —, shows the content it has used and distinguishes what the website does not yet allow it to establish. It is not a person from the team and it does not know your case; to speak with someone, write to the team.

Automatic assistant limited to the public content of 3.14; it may abstain. To speak with a person, write to the team.

Write to the team →