The question

Which external event will hit the BRT, and what do I do before it arrives?

What it does

Reads news, social media, weather and history continuously, classifies each event into 5 stages and recommends preventive action before the impact.

The problem

Mobi Rio operates Rio de Janeiro's BRT: four corridors (TransOeste, TransCarioca, TransOlímpica and TransBrasil), with operating history since 2012. External events that hit the BRT (police operations, shootings, heavy rain, protests, large events) are detected when they are already under way. The information exists: it is in the news, social media, weather alerts and the incident history itself. But it lives in separate databases, nobody cross-references it in real time and the warning arrives by phone. The bottleneck is not coverage, it is speed: without minutes of notice, every decision is reactive.

How we built it

We started from the real cases that cost the most and separated four layers: internal history for calibration, 24-hour reading of open sources, the probability × impact calculation, and outputs to the map, the phone and the management dashboard. The 5-stage scale is the same one COR-Rio uses.

Features

The question

In preparation.

What it does

Coming soon.

The problem

Coming soon.

The question

Which truck takes which order, and when is it really free?

What it does

Recommends which truck takes which order, forecasts when it is really free and learns from every supervisor decision.

The problem

Rota B runs dedicated transport for a supply operation: its own fleet going back and forth between a base and several destinations. Almost half of each order's time is lost before the truck starts loading. The supervisor assigns by gut feeling, with a dashboard that shows only the last leg and hides re-entries, and a fixed 3-hour traffic light that turns on for 4 out of 10 orders: the alert stopped telling anything apart.

How we built it

In the meeting, the manager summed it up in one word: times. Reading each order's history stage by stage showed why: the dashboard reset the counter at every re-entry. We separated two clocks, the client's and the fleet's, and on top of them built an assignment queue that recommends, explains its reasoning and learns from each different decision by the supervisor.

Features

The question

What do I do now with this incident?

What it does

Answers "what do I do now?" for each incident using the company's own judgment, and turns what happens in the operation into queryable data.

The problem

Nortran carries people: the most critical cargo there is. A passenger transport operation with more than 130 vehicles and about 280 drivers across 3 bases. Telemetry lives on third-party platforms, incidents circulate in WhatsApp groups and 25 indicators are filled in by hand on a wall board. For every incident there was one answer: call the manager.

How we built it

We listened to how the manager decides in real cases and read the disciplinary code and the operations manual. We designed a system that sorts each incident, applies the escalation rules with their deadlines and proposes what to do citing the manager's judgment, which is captured as a company asset and not a person's.

Features

The question

What has to be ready, where and when, so the line does not stop?

What it does

Synchronizes preparation, assembly and suppliers: flags each order's critical point and builds the schedule from the order book.

The problem

Magnus Modular builds residential and industrial modules with automotive logic: a preparation area assembles the packages (doors, windows, floors, bathrooms) and the assembly line only assembles. The line produces 26 modules a day and wants to cut from about 30 to 19 minutes per module. Scheduling was done by hand in Excel, a week ahead at best and one or two days when the customer is in a hurry. With no digital record on the floor, nobody knew which component was holding up each order and logistics shipped incomplete orders.

How we built it

We started from the meeting with the manufacturing manager and his scheduling spreadsheet. The diagnosis was clear: it did not need more production, it needed synchronization. We designed a tower that crosses the order book with times per module type, flags each order's critical component, builds the preparation schedule and adds a simple digital record on the floor so logistics sees what is truly finished.

Features

The question

How much do I buy of each item this week, and can I trust that number?

What it does

Calculates how much to buy or produce of each item every week, states its confidence and learns from the planner's judgment.

The problem

Topaz Tech sells electrical, hydraulic and HVAC components for construction, with 1,792 SKUs and part of them made by third parties. The spreadsheet that decided how much to buy used a demand equal to 52.5% of the real one: every month above the average was turned into zero. The result: 48 items with more orders than stock plus purchases in progress, while 277,282 idle units filled the warehouse. And when something ran short, nobody could prove whether it was the forecast, the supplier or purchasing.

How we built it

We reverse-engineered the spreadsheet with code and found the rule that broke it: peaks were not excluded, they were set to zero. We rebuilt demand item by item, crossed stock, orders and purchases in progress and built a weekly decision queue: how much to buy, with what confidence and why. Each analyst adjustment stays as a precedent that the next recommendation cites.

Features

The question

How much of each product should we make, and which customer should we stop pushing?

What it does

Cleans the history, forecasts demand by product and channel and turns it into an integrated production and purchasing plan.

The problem

Voltra makes and imports batteries for cars and motorcycles: about 300 products reaching around a thousand distributors through four channels, with the traditional one moving most of the volume. The whole operation hung on an Excel forecast with 27% accuracy per product. The production plan, import purchases and arrivals all came from that number. The error was found late, when it was already batteries built and sitting in the warehouse, and the history was contaminated by campaigns, bonuses and early purchases to hit volume tiers.

How we built it

We analyzed how the forecast was built and what its history contained. The series mixed real demand with past shortages, campaigns and early purchases. We separated those layers, measured each customer's saturation and built a forecast by product and channel that warns before the error reaches the plant.

Features

The question

How much does each executed m³ really cost me?

What it does

Allocates machine and staff hours to each service, calculates the real cost per m³ and warns when a work front drifts.

The problem

Forja Construcciones has 10 active job sites, with up to 50 heavy machines per site across yellow-line and white-line equipment. The company did not know the real cost of each executed m³. Machine and staff hours were written on paper and the manager typed them into Excel at the end of the day. A previous job was considered profitable until the cost survey revealed R$ 8.8 million in losses already consolidated.

How we built it

We followed the data's path: from the clerk's paper to the manager's spreadsheet. We designed a mobile record that works offline, automatic allocation of machine-hours and man-hours to each service, and a real cost per m³ compared against the budget, with alerts and a re-planning recommendation when a front drifts.

Features

The question

If a key person leaves tomorrow, who steps in and when?

What it does

Calculates the real coverage of each critical position, warns where a vacancy will open and shows the talent nobody is looking at.

The problem

Grupo Andino tracks 11 critical and leadership positions, with a group of 27 employees between incumbents and successors. Succession for critical positions was handled in spreadsheets and meetings. Each position had nominated names, but nobody knew whether those successors were ready in time or whether the same person covered several vacancies at once. Coverage on paper looked high; the real figure, if several departures coincided, was half.

How we built it

We organized the plan into three pieces (position, person and nomination) and built a calculation engine that always gives the same result for the same data: availability, time gap, real coverage and collisions. On top, an AI layer that prioritizes, detects hidden talent, estimates flight risk and drafts the readings for the committee without inventing numbers.

Features

The question

Can I approve this order without breaking the month's ceiling?

What it does

Shows the real balance any day, stops an order before it breaks the ceiling and explains each difference between sources.

The problem

Pretenza makes precast concrete products and its maintenance team looks after more than 150 assets: overhead cranes, extruders, plants. Maintenance managed an annual budget with two spreadsheets that never matched: the department's records when the purchase is committed and finance's when the invoice arrives. Spending was known the following month, most months closed above the ceiling and nobody saw what was already committed before approving another order.

How we built it

We started with the meeting with the manager and the two spreadsheets. Crossing them month by month revealed the cause: it was not an error, it was the moment at which each one records. With that we designed a layer that tracks the commitment, what is ordered but not yet invoiced, and deducts it from the ceiling before approving. On top, a model that explains each difference, groups asset names and learns from the manager's judgment.

Features