Udgass / Enterprise decision intelligence · in development
From fragmented data to evidence-backed decisions.
Turn business data into decisions you can trust.
Udgass is an enterprise decision intelligence engine in development. It is being built to connect business data, evaluate possible outcomes and help organisations decide with evidence, with the assumptions, the uncertainty and a record of what happened next kept together. The first application is demand and inventory.
Understand what is happening. Explore what could happen next. Evaluate what to do. Learn from the outcome.
Evidence to outcome. Past events are linked. An estimate is made from them, a person decides, and what actually happens is recorded against the estimate.
The problem
Businesses record history. They don’t always learn from it.
What happened
Sales, orders, stock movements and supplier events sit in operational systems, each with its own timestamps and owners.
Held in: ERP, order and stock systems
What was decided
The reasoning behind a choice lives in meetings, messages and spreadsheets. Often only the result of the decision survives.
Held in: email, slides, personal files
What actually happened
Outcomes arrive later, in different reports, and are rarely tied back to the estimate and the decision that came before them.
Held in: periodic reports and reviews
Data is fragmented, forecasts are uncertain, analysis is separate from the decision, and outcomes are rarely traced back.
When events, decisions and outcomes stay in separate places, an organisation repeats its reasoning instead of building on it. Udgass is being designed to keep the three connected, so that each decision can be reviewed against what followed.
The Udgass approach
Understand, anticipate, evaluate, learn.
Five stages that feed one another. Select a stage to see what it takes in and what it produces.
-
- Takes in
- Exports of sales, orders, stock and supplier events that a team chooses to provide.
- Produces
- A time-ordered record in which each fact is tied to its source and date.
First stage · receives lessons from 05
-
- Takes in
- The structured history.
- Produces
- Flagged changes, shown with the evidence behind them and compared with normal variation. A flag is a prompt for review, not a conclusion.
After 01 · feeds 03
-
- Takes in
- History and detected changes.
- Produces
- A range of possible outcomes with the assumptions stated, rather than a single number.
After 02 · feeds 04
-
- Takes in
- Estimates, the options under consideration, and constraints such as supplier lead times.
- Produces
- A side-by-side comparison of options. People choose. Udgass does not act on your systems.
After 03 · feeds 05
-
- Takes in
- What was estimated, what was decided, and what happened.
- Produces
- A measured track record, including misses. Any change to the method is reviewed against that record rather than assumed to be an improvement.
After 04 · returns to 01
The record from stage 05 returns to stage 01, so each cycle starts with more evidence.
The intelligence architecture
Seven layers, built from the decision outwards.
Udgass is designed as layers with plain interfaces between them, so methods and models can be replaced without rebuilding the rest. The status column says what exists in the code today. Nothing here is a hosted service.
Data connectivity
Bring in data from authorised sources, read-only by default.
File imports (CSV) with preview before commit. No live connectors to ERP, databases or warehouses yet.
Data quality and lineage
Validate data, flag problems, keep source and history of every record.
Validation and data-quality reports, versioned corrections that never overwrite, and a fingerprint of the exact data each analysis saw.
Business context
Represent products, locations, suppliers, orders and how they relate.
A fixed model for inventory: products, locations, suppliers, stock, purchase orders and events. Not yet a general, configurable business model.
Analytical engine
Replaceable methods for forecasting, change detection and risk.
Simple forecasting methods chosen per product by backtest, change detection with evidence, and a gate that blocks a method change unless it wins on past data. Methods are deliberately basic.
Decision evaluation
Compare options against objectives, costs, constraints and uncertainty.
Inventory scenarios with costs and constraints, compared on the same simulated demand. Inventory decisions only.
Decision memory
Keep evidence, assumptions, approval and outcome of each decision.
Append-only decision records with a tamper-evident chain, and later comparison of forecasts with what actually happened.
Governance and deployment
Access control, audit, reproducibility and deployment choice.
Runs on a computer you control. Organisations, API keys with roles, an append-only audit log, export and purge. Not built: single sign-on, a hosted or private-cloud deployment, or a security certification.
Status reflects the Udgass engine source code as of October 2026. Built means implemented and covered by automated tests, not proven on customer data.
The decision record
Every important decision has a history.
An example of how one decision could be recorded and then reviewed. Move through the stages to see the record grow.
Set next quarter’s order quantity for Product group A
Available at decision time
- Sales history to 3 March
- Open orders and current stock
- Supplier quote: 21-day lead time
Not yet recorded
Evidence considered
- EV-0412 Same period, previous year
- EV-0415 Early rise in orders
- EV-0420 Supplier delivery record
Not yet recorded
Estimate and uncertainty
5,000 units
- Likely range 4,200 to 6,100
- Evidence quality: moderate
Not yet recorded
Assumptions and constraints
- Lead time stays near 21 days
- No change in pricing or promotion
- Storage limit: 6,500 units
Not yet recorded
Action taken
- Ordered 5,000 units on 5 March
- Recorded by the decision owner
Awaiting the decision
Realised outcome
5,450 units
- Actual demand over the quarter
Awaiting the quarter’s end
Variance against the estimate
- +450 units (+9%) above the estimate, inside the stated range
- Reviewer note: the lead-time assumption held. Evidence quality rating unchanged.
Calculated at review
Both outcomes inside and outside the stated range are recorded the same way. Nothing on this card is real data.
Record history
Evidence EV-0412, 0415 and 0420 attached
Estimate recorded: 4,200 to 6,100, central 5,000
Decision made and action recorded
Realised outcome recorded: 5,450 units
Variance calculated and reviewed
First application · Demand and inventory intelligence
Start where better decisions can be measured.
Which products are tying up cash, and which keep running out? Demand and stock are where estimates meet reality every week, so it is where Udgass starts. This is a hypothetical planning view built on synthetic data. Choose a scenario to see how the range and the inventory position change.
- Supplier lead time
- 4 weeks
- Replenishment order
- 1,200 units
- Opening stock
- 600 units
- Range at week 12
- ±0%
- Stockout exposure
- Low
- First week short
- None
Synthetic data. This view is not connected to any live system, and the exposure rating is a simple calculation on invented numbers to show how the idea works, not a measure of Udgass accuracy.
Working today
See where your stock is stuck and where it runs out.
This is the first working piece of Udgass. Choose a sales file and it replays your history, makes each estimate using only what was known at the time, and checks it against what happened. It runs in your browser and the file is not uploaded anywhere.
Your file
A sales export saved as CSV: one row per sale or per day, with a date, an item and a quantity. Tally, Busy, Zoho and Excel column names such as Voucher Date, Item Name and Qty are recognised. In Excel use File > Save As > CSV. It needs at least 56 weeks of history.
Prefer help? Book a 20-minute guided check: on a screen-share we do the export together and your file stays on your computer.
Please do not use files containing personal or sensitive data. The file is read in this page only and nothing is sent to a server.
What you will see
- Slowing products: recent sales well below earlier sales, where stock may be sitting
- Possible stock-outs: steady sellers with sudden weeks of no sales
- Error of the estimates compared with a simple flat baseline
- How often reality landed inside the stated range
- Results by product, and the largest misses
- The assumptions made about your data
The method is deliberately simple. On some data it will be no better than a flat average, and the result will say so.
Long-term direction
One architecture. More decisions over time.
The layers are not specific to inventory. If the first application earns its place, the same evidence, evaluation and memory could support other recurring decisions. These are possible directions, not commitments or current features.
Now: demand and inventory
What to reorder, how much stock to hold, and where stock is stuck or running out.
Supply and procurement
Supplier lead-time risk, delivery performance, and the cost of alternatives.
Working capital
Cash tied up in stock and orders, and the trade-off with service levels.
Operations and capacity
Matching production or fulfilment capacity to a range of possible demand.
Continuous monitoring
Flagging meaningful changes in authorised data to the right person, against thresholds a team sets.
Organisational learning
Reviewing which decisions held up, across teams, from the record rather than from memory.
Trust and governance
Reliance has to be earned.
Traceable evidence
Each estimate is meant to link back to the data and the date it was based on, so a reviewer can reconstruct how it was reached.
Explicit uncertainty
Outputs are ranges with their assumptions stated. Where the evidence is thin, the record is meant to say so.
Measured performance
Estimates are compared with what happened, and the results are reported, including where they were wrong.
Human accountability
Udgass advises and records. A named person makes and owns each decision. It is designed to read data, not to act on your systems.
Read-only, least privilege
Integrations are designed to read only what a team authorises. Any future ability to act would need explicit permission and human approval.
Model independence
No single model or language model is responsible for the whole system. Methods are replaceable and each change is tested against the record. No language model is used today.
Development status and data handling
What exists today, stated plainly. The principles above describe intent, not a deployed system.
- Stage
- Early development. A local engine (assessment report, backtests, change detection, scenarios, decision records) runs on a computer you control, and a backtest runs in your browser. Not built: live connectors or a hosted service. Not yet run on any company's real data. See Trust and evaluation.
- Production deployments
- None
- Customer results
- None. Examples on this page are illustrative. Measured results so far use invented data only.
- Security certifications
- None
- Independent security audit
- Not yet carried out
- Data handling
- The demand assessment runs on the company's own computer and makes no network connections. Udgass does not accept company data at present; if that is ever needed, signed written terms on storage, access and deletion come first.
- For now
- Please do not send sensitive or personal data. Early conversations can use sample or agreed export data.
Who is building this
The founder
In safety-critical software you never ship a number without knowing how wrong it could be.
I’m Kanthipriya Mahale, founder of KPAppWorx. I have spent more than nine years engineering safety-critical embedded software in aerospace and automotive, in work shaped by DO-178C and ISO 26262, where evidence, traceability and accountability are not optional.
Udgass applies the same habits to business decisions: keep the record, state the uncertainty, check the result, and keep a named person accountable. That is a discipline I bring to the work. It is not a claim that Udgass is certified to any standard.
- 9+ years
- Safety-critical embedded software engineering
- Aerospace and automotive
- Work shaped by DO-178C and ISO 26262
- 13 products shipped
- Through KPAppWorx: 10 iOS and macOS apps and 3 live AI software tools
Udgass itself is in early development and has no customers yet.
Early assessment and design partnership
See how your own history would have been forecast.
You run the assessment on your own computer with your sales export. It replays past periods using only what was known at the time, compares the estimates with what happened and with simple methods, and shows where they fail. You keep the report.
- 01Download the assessment kit below. It runs with Python 3.9 or newer on Windows, macOS or Linux and needs nothing else.
- 02Export your sales history and run one command. Preparing the export is usually the longest step.
- 03Read the report and decide whether a pilot is worth it. The decision is yours.
- What you need
- A sales export with date, product and quantity, daily or weekly: at least 56 weeks, ideally two years or more. Optional: stock-on-hand snapshots, purchase orders with receipt dates, and your own past forecasts for a head-to-head comparison.
- What you get
- A report covering data quality, which inventory questions your data can and cannot answer, accuracy against simple methods (and against your forecasts, if provided), the products where estimates fail, and an advisory view on whether a pilot is justified.
- Design partners
- We are looking for a small number of businesses to shape the first application with us: a short call each month and honest feedback on whether the results help real decisions. Larger organisations can start with one product group, site or region.
- Cost
- Free for the first three companies. In return, we learn how Udgass performs on real data from whatever you choose to share. Publishing any result or testimonial is a separate, optional permission you can decline; nothing is published without your written approval of the exact wording, and never your data. Later assessments and pilots are paid.
- Your data
- The assessment runs on your machine and makes no network connections; this was checked by tracing a full run. If you cannot run it yourself, tell us: written data terms come first, and no data is accepted before both sides have signed them.
See a sample report (illustrative, synthetic data) · Sample sales file (CSV) · Data requirements and how it runs
For IT teams: verify the file
SHA-256 of udgass-assessment-kit-0.4.1.zip:
8d21ea3d8f911dd3874e2d1672a189bbe3da153b7d5cdac4aecec0187355cf08
Mac: shasum -a 256 udgass-assessment-kit-0.4.1.zip · Windows: certutil -hashfile udgass-assessment-kit-0.4.1.zip SHA256