The UpSynQ platform

One decision foundation. Configured for how each business operates.

UpSynQ connects messy enterprise data, forecasting, operational constraints, optimisation and scenario evaluation into recommendations teams can inspect and act on. The underlying software is reused; the rules, objectives and decisions reflect the business.

See the platform in action Discuss your operation
From data to a reviewed decision Scattered source data is prepared into a single series; a forecast with an uncertainty band follows; constraints such as capacity, corridors and policy enter from above and bound a region of feasible choices; the recommended choice sits at a corner of that region; a person reviews it, and what happens next feeds back into the data. capacitycorridorpolicy Approve or send back actuals and overrides feed the next cycle DATA PREDICTION CONSTRAINTS CHOICES REVIEW
  1. Data sources, masters and history, prepared and checked
  2. Prediction a forecast with its uncertainty
  3. Constraints capacity, corridors, policy — what is actually possible
  4. Choices feasible alternatives; the recommended one at the best corner
  5. Review a person approves, adjusts or sends back — and the outcome feeds the next cycle

Switch the business, keep the foundation

Five stages that never change. Everything inside them does.

The same five stages run a pharmaceutical planning cycle and a utility's operating day. Switch between them: the foundation stays put; the data, rules and decision are the business's own.

Illustrative example · synthetic data

A month's plan for Product A, after commercial adds 20% to demand. Tomorrow's power position, after a 14% evening demand surge.

  1. 01

    Connect & prepare

    Source systems, mappings and data-quality checks.

    ERP sales, stock by batch and expiry, open orders and bills of materials, mapped to product × depot × month.

    Load history, contracts, unit availability, fuel cost and weather, aligned to 96 fifteen-minute blocks a day.

  2. 02

    Forecast & evaluate

    Explicit grain and horizon; models chosen by backtest.

    Monthly demand per product and depot; consensus adds +20% for a new contract — 50.0k to 60.0k units a month.

    Day-ahead load for every block; the evening runs +14% from 17:00, peaking near 2,230 MW.

  3. 03

    Model constraints

    What is physically and commercially possible.

    Only 57.0k of 70.0k units are usable (QA hold and short expiry); 25.0k batches; one granulation line; ≥ 100 days of cover.

    Unit minimums and maximums at their own costs; a 550 MW import corridor; block bids 5–100 MW, ≤ 50 bids.

  4. 04

    Optimise & simulate

    Feasible alternatives, an objective, the trade-offs.

    Net requirement 123.0k → options priced: as proposed, defer a batch, or move one to Plant South. Cheapest plan within cover wins.

    Three dispatch policies priced block by block: merit order, units flat out, units at minimum. Least uncovered energy, then lowest illustrative cost.

  5. 05

    Review, decide, learn

    An owner approves; actuals and overrides improve the next run.

    The planner approves or sends back; plan versus actual feeds the next cycle's netting.

    The desk reviews the bid pack maker-checker; error by block feeds the next model evaluation.

Recommended decision

Make
5 batches · 125.0k units at Plant North
Allocate
The 60.0k monthly demand plan across three depots — North 27.0k · East 21.0k · West 12.0k
Confirm material
RM-1 supply from an existing open order: 2 lots available from day 16

Trade-off: 106 days of cover at no added cost; moving a batch to Plant South costs $3.0k for 104 days.

Explore the IBP decision

Recommended decision

Generate
1,150 MW from 18:15 to 21:45 — own units at 1,000 MW plus 150 MW of peaking supply
Buy
2,636 MWh market requirement — peak 430 MW of a 550 MW corridor
Bid
17 block bids + a single-bid profile; 4 MWh unbid residual

Trade-off: ₹856.8 lakh illustrative expected cost against ₹863.3 lakh running units flat out all day; 120 MW of corridor headroom at the tightest block.

Explore the power decision

Shared foundationThis business's rules and chosen action

Data Foundry

Enterprise data rarely arrives ready for a decision.

Most of the work before a good decision is making the data honest. The Data Foundry turns messy source data into reusable, decision-ready mappings and checks — and reruns those checks as the data changes.

  1. ConnectMasters, transactions, history and external signals — from ERP extracts, planning files and feeds.
  2. MapMessy columns, date layouts and hierarchies matched to a common model; ambiguous fields surfaced for a person to confirm.
  3. AuditCompleteness, inconsistent masters, sparse demand, stockout censoring and structural breaks — found and reported.
  4. BuildA versioned, solver-ready decision model, with notes on what was inferred, kept with the run.

As it arrives Illustrative

  • Mat_No
  • Loc
  • Jan Total 2024 sales … Dec Total 2025 sales
  • Matrch Total 2024 sales
  • Retail sales Jan 2024 · Online sales Jan 2024
  • Pack

Ready for a decision

  • product_id, location_id — matched to the product and depot masters.
  • period, quantity — 24 months read from the column names and reshaped into rows.
  • “Matrch” read as March — a spelling slip, not a new period.
  • Retail and online columns left out — already inside Total; keeping them would count the same sale three times.
  • Needs a person: is Pack a pack size or a pack-change code? Not guessed.

Different algorithms, one disciplined flow

Language models help with the mess. Numbers make the call.

Language models assist

Where context is messy

  • Proposing field mappings for unfamiliar files — alongside deterministic matching where that is enough, with a person confirming the result.
  • Interpreting what a file or field most likely means.
  • Answering questions about your data through a fixed set of read-only tools inside the product.

Numerical methods decide

The operational answer

  • Statistical and machine-learning forecasts, chosen per series by evaluation — not by a prompt.
  • Explicit constraints: capacities, batches, corridors, policies.
  • Mathematical optimisation and simulation that produce feasible alternatives and their trade-offs.

How a forecast model earns its place

  1. ProfileEach series: seasonal, intermittent, trending or short.
  2. ShortlistCandidate families that suit the profile — e.g. Croston-type methods for intermittent demand, ETS, ARIMA and Theta for seasonal.
  3. BacktestRolling-origin tests on history the model did not see.
  4. Beat the baselineNo model ships if seasonal-naive does better on the same holdout.

Series with little history get a deliberately simple candidate pool rather than a complex model they cannot support.

What is reused, what is configured, what is specialised

Common substrate. Explicit business configuration. Specialised optimisation.

This is how a new deployment avoids becoming a fresh consulting project — without pretending a production plan and a power bid are the same maths.

Shared foundation same software everywhere

  • Ingestion and schema mapping
  • Data quality and feature representation
  • Forecast evaluation and execution
  • Scenario orchestration
  • Optimisation interfaces
  • Decision explanations and review

Configured business layer set up per enterprise

  • Hierarchies and masters
  • Sources and lead times
  • Objectives and costs
  • Approval tiers
  • Coverage and stock policies
  • Grid and market rules

Domain-specific models specialised, not interchangeable

PlanningNetting, batch and BOM feasibility, inventory and sourcing algorithms.
PowerUnit dispatch, fuel cost, corridor-bounded bidding and market algorithms.

What every deployment leaves behind

  • Connector patterns and mapping templatesThe next file with similar columns maps faster.
  • Constraint and review patternsBatch, cover, corridor and bid rules — and their approval steps — start from a tested shape.
  • Evaluated model configurationsWhich methods hold up on which kinds of series.
  • Software abstractionsReusable building blocks for runs, scenarios and decision views.

Every deployment refines the reusable platform — connectors, mappings, model selection, constraint patterns and workflows — while each customer's data and operational rules remain specific to that engagement.

Decisions have owners

Trust isn't a confidence badge.

It's a feasible proposal a planner or desk operator can challenge — with the inputs it used, the constraints it respected and the alternatives it beat, in plain view.

When people override a recommendation, that is information too. Comparing actuals and overrides with what was proposed is how the configuration and the model evaluation improve, cycle after cycle.

Decision recordIllustrative

Make 5 batches of Product A at Plant North

Inputs
Approved consensus (frozen), stock snapshot by batch and expiry, open supply orders
Constraints checked
25.0k batches · line G1 calendar · RM-1 release dates · ≥ 100 days cover
Alternatives
Defer one batch — 94 days, below policy · Move one to Plant South — $3.0k, 104 days
Owner
Central planner → planning approver
Status
Ready for review
After the cycle
Plan versus actual and any override reason feed the next run
  • Commercial

    Signed

    Enterprise integrated business-planning engagement with a fast-growing Indian pharmaceutical manufacturer.

    Integrated business planning
  • Live

    96 blocks a day

    Day-ahead load forecasts for an Indian power utility, at 96.8% average block-level accuracy across counted live days.

    Power & energy
  • Technical evaluation

    8.3% WAPE

    Forecast error on a sealed three-month national × SKU pharmaceutical holdout.

    Planning proof

The hard part isn't producing a prediction. It's producing a decision that respects reality.

Discuss a decision your business makes repeatedly

Integrated business planning Power & energy