In development · the deterministic core is built and running
The AI manufacturing planner for Odoo.
Planning that looks ahead: what runs short, when, why, and what changed since yesterday.
Odoo holds every fact a plant needs. Nanti Manufacturing Planner connects them into one living plan: day-level coverage across warehouses, a cause chain on every exception, and replanning minutes after reality changes. Every number is computed from your own records, never by a language model. AI assist and manager-bounded automation are being built on top.
An installed Odoo 19 module, Community and Enterprise, Odoo.sh or self-hosted. In development. An independent nanti.ai project.
The morning problem
Your plan was right. Yesterday.
The scheduler ran at night. Then a truck slipped, a rush order landed, a work order ran long. By 9 a.m. the plan is history, and the real one lives in a spreadsheet and one planner’s head. Every morning starts with the same three questions:
- 01
What breaks first?
Which product drops below its floor, at which warehouse, on which day. Not a report to interpret: a date.
- 02
What does it cost?
Every exception priced by the value at stake and the day it bites, so the queue is ranked by consequence, not by noise.
- 03
What changed since yesterday?
New, resolved, moved. The diff between plans, not two hundred rows to re-read every morning.
Odoo already holds the answers: the orders, the stock, the BoMs, the calendars, the lead times. What’s missing is the system that connects them into decisions, and keeps them connected as reality moves. That is the whole product.
Not a mockup
The real product, running on Odoo 19.
In development does not mean imaginary. The deterministic planning core is built, tested on Odoo 19 Community and Enterprise, and running. Every screen below is a real capture of the current build on a sample plant.
- Daylevel coverage, per product, per warehouse
- 14exception types, each with its cause chain
- ~2 minfrom a change in Odoo to a replanned row
- C + EOdoo 19 Community and Enterprise
Real screens of the current build, captured from our live Odoo 19 bench on “Orbit Cycles”, a small fictional sample plant: invented products, partners, and documents. Nothing was retouched. The bench runs Enterprise; the module installs on Community too.
The engine
Deterministic first. On purpose.
A plan you cannot trace is a plan you cannot trust. So the Planner’s engine is deterministic: same records in, same plan out, every time, and every figure carries its provenance back to the Odoo documents behind it.
- provenance
Every number has a paper trail
The break date on a product traces to the sale lines demanding it, the purchase lines supplying it, and the reorder rule flooring it. Click the cause, land on the document. No black box between your data and your decision.
- reproducible
Same inputs, same plan
The plan is an immutable snapshot, hashed on its inputs. Run it twice on the same records and you get the same answer, which is what makes “what changed since yesterday” a real diff instead of a guess.
- no model in the math
No language model in any figure
Today the module makes no outbound calls at all: nothing leaves your server. And when the AI layer ships, that stays the rule by design: the model explains and chooses among computed options. It never produces a quantity, a date, or a price.
- complete without ai
Degrade, never break
The planner is a complete product with AI off. That is a design rule, not an accident: if a subscription ever lapses or a model is unreachable, the plan, the exceptions, and the schedule keep working in full.
Built today
What the Planner already sees.
Phase one is the seeing: the complete, honest picture of your plant’s next 90 days, kept current. Everything below is built, tested on both editions, and shown running above.
-
Coverage, day by day, per warehouse
On hand plus scheduled supply minus scheduled demand, projected for every product at every warehouse, with the break date and the documents behind each step of the line. Not a monthly aggregate: a date you can act on.
-
Exceptions that explain themselves
Fourteen exception types, from shortages and late supply to a missing BoM or a stale reorder rule. Each carries a one-sentence cause with the documents linked: “Short 375 units from Wed 2 Sep: S00001 needs 120 on Wed 2 Sep. P00001 from Treadly is late.”
-
Learned lead times
Your vendors’ real receipt delays, computed from your own history and shown next to the configured number. Open purchases likely to slip get flagged before they do, and a manager adopts the observed value in one click, logged.
-
Replanning in minutes, not tomorrow
Confirm a sale, move a purchase date, validate a receipt, finish an MO, adjust stock, edit a BoM: the affected products are recomputed inside the current plan after a short debounce, two minutes by default. The nightly full plan still runs.
-
Capacity you can see and move
Planned work-order hours against each work center’s real calendar, capacity, and efficiency, with overloaded weeks flagged. Drag an order on the schedule and get the exact ripple as a sentence before anything is written. Confirm, or undo.
-
Forecasting you can read
Named rule-based methods per product or category: moving average, same period last year, weekly profile, growth factor. Forecast rows are labelled in the ledgers, editable per week in the Grid, and scored against what actually happened.
-
A data-health scanner
Missing lead times, missing vendors, missing BoMs, zero-quantity BoM lines, stale reorder rules, work centers without calendars: found for you, each with a plain explanation of what it silently breaks.
-
Every decision logged
Snooze, assign, dismiss with a reason, adopt a lead time, confirm a reschedule: each lands in an action log with before and after values, the user, and an idempotency key. The plan itself is an immutable snapshot with provenance.
A day on the plan
Reality moves. Watch the plan answer.
Five things that happen in every plant, and exactly what the Planner does about each of them, today, with no AI involved.
The vendor slipped. The plan already knows.
A purchase line’s planned date passes with the receipt still open. The engine flags the supply late, prices what it would have covered, and turns the affected product’s coverage short, with the break date and a cause that names both the sale demanding it and the late purchase order. If that vendor’s own history says deliveries run late, open purchases get flagged “at risk” before the date even passes.
You open the purchase order straight from the cause, chase it, or adopt the learned lead time so future dating is right.
Sales confirms. Minutes later, the plan has moved.
Confirming the sale order queues a replan for every storable product on its lines. After the debounce, two minutes by default, their coverage, ledgers, and exceptions are recomputed inside the current plan. New exceptions arrive marked new; the Grid’s week shows the new demand; the projected-end cell changes colour.
Today opens with the new reality already ranked. No one re-runs anything.
More hours planned than the calendar holds.
Load is measured against each work center’s real calendar, capacity, and efficiency, per day. An overloaded week raises an exception naming the work orders driving it, and the schedule shows the red capacity cells under the lane.
You drag the order to a later day. The preview names the exact ripple: “Move this operation to Thu 28 Aug; finish moves to Fri 29 Aug.” Confirm writes the dates through standard Odoo fields, logged, with undo. Moves inside the frozen horizon need a manager.
Due to start in days, components not reserved.
The MO is flagged blocked, with each missing component’s gap and its own coverage break behind it. The order view shows the operation path with what it is waiting for, and the floor queue lets an operator report a blocker, which lands on the MO’s chatter and surfaces on Today.
The planner sees the block before the morning it happens, not during it.
The quiet numbers that poison every plan.
A vendor line with zero lead time, a buy product with no vendor, a manufacture product with no BoM, a reorder rule whose minimum no longer matches real demand. Health lists them grouped by type, each with a plain sentence on what it breaks: “Supply dates cannot be offset reliably without a vendor lead time.”
Open the record, fix it, or adopt the learned value where history already knows better.
Designed · in development
Then AI. On your terms, inside your bands.
The AI layer is being built on top of the finished engine, and its contract is set before its first line ships: the engine computes every quantity and date; the model only explains, answers, and chooses among computed options. Here is the designed shape, labelled as exactly that.
-
Off
The full planner, exactly as it runs today. Deterministic, complete, nothing leaves your server. AI is never required.
-
Assist
The AI explains every exception and proposal in your language, answers questions grounded in the plan’s real numbers, drafts the vendor message. It never invents a figure: the engine computed them all.
-
Bounded automation
Managers set bands per action type: count, value, horizon. Inside a band, the agent executes routine decisions after each plan and writes a digest. Everything outside escalates to a person.
An automation band · designed shape
reschedule unreserved MOs allowed when: ≤ 5 orders · ≤ $2,000 at stake · beyond the frozen horizon
Inside the band: the agent acts, logs, and reports in a digest. Outside it, or for anything that confirms a purchase, changes a BoM, adjusts inventory, or crosses a company boundary: a person decides. Drafts by default; confirmation is a human act unless a manager put it in a band. Everything logged, undoable where Odoo allows.
The switch is designed to be yours: off, our hosted models, your own API key, or local models. With AI off, nothing leaves your server; with it on, only compact plan excerpts travel, and your data never trains anyone’s models. The designed trust stack runs through its siblings: the Context Layer for Odoo for verified meaning, the Execution Layer for Odoo for receipts on every write. None of this section is shipped, and we will not pretend otherwise.
The honest comparison
Odoo plans. This makes the plan decidable.
Odoo 19 already ships reordering rules, forecast-based replenishment, and, on Enterprise, MPS and a Gantt. The Planner is not a replacement for any of it. It is the decision layer those tools never had.
The left column is Odoo doing its job, and we build on it, not against it. The right column is the seeing layer we have built so far, told straight, including the row that is not there yet.
Straight about status
Where this stands.
In development, with the deterministic core built and running. Here is the line between what is real today and what is designed, exactly where it actually sits.
- Day-level coverage per product per warehouse, with ledgers naming every document, on Odoo 19 Community and Enterprise
- Fourteen exception types with cause chains, the ranked Today cockpit, and the since-yesterday diff
- Learned vendor lead times with one-click adopt, and event-driven replanning within minutes of a change
- Work-center workload, the draggable schedule with ripple preview, confirm, and undo, rule-based forecasting, the Grid, and the Health scanner
- No outbound calls: today, nothing leaves your server at all
- Buy and make proposals with draft RFQs, MOs, and transfers: today the Planner creates no documents
- The AI layer: explanations, Ask, drafts, and automation inside manager-set bands, with the off, hosted, own-key, or local switch
- Automatic capacity levelling, scenarios, and capable-to-promise
- The bridge to the Execution Layer for Odoo, so every planner write comes back with a receipt
- Pricing: announced at early access, and the deterministic planner is designed to keep working in full if a subscription ever lapses
Nanti Manufacturing Planner is an independent nanti.ai project. Odoo is a trademark of Odoo S.A.; this project is not affiliated with or endorsed by Odoo S.A.
Plain answers
Asked, answered.
What is Nanti Manufacturing Planner?
A planning cockpit that installs inside Odoo 19 and reads your own records, BoMs, stock per warehouse, open sales, purchase and manufacturing orders, and work-center calendars, to show what runs short and when, why, and what changed since yesterday. It computes deterministically; AI assist and bounded automation are in development. It is built by nanti.ai, an independent company not affiliated with Odoo S.A.
Does it need AI to work?
No. Everything built today is a deterministic engine with no language model involved. The design keeps it that way: when the AI layer ships, the model explains and chooses among computed options; it never produces a quantity, a date, or a price. The numbers come from your data, never from the model.
Which Odoo versions and editions does it support?
Odoo 19, Community and Enterprise, on Odoo.sh or self-hosted. It depends only on Community apps: Manufacturing, Inventory, Purchase, and Sales. Odoo Online cannot install third-party modules.
How is this different from Odoo reordering rules and MPS?
Odoo tells you a quantity to replenish. The Planner shows the day-by-day projected balance per product per warehouse with the documents behind each step, the break date, and a one-sentence cause on every exception, and it replans within minutes of a change rather than on the nightly scheduler. Its planning grid works in Community. It does not create replenishment orders yet; proposals are in development.
Does it plan against real capacity?
It measures planned work-order hours against each work center’s calendar, capacity, and efficiency, flags overloaded weeks, and shows a schedule you can drag with a preview of the ripple, a one-sentence confirmation, and undo. It does not move work on its own yet; automatic levelling is in development.
What does it write into Odoo?
Today only three things, each logged with before and after values: a vendor lead time when a manager adopts the learned value, manufacturing and work-order dates when a reschedule is confirmed, and chatter notes or activities. It creates no purchase, manufacturing, or transfer documents yet; proposals and drafts are in development.
How fast does it react to a change?
Confirming an order, changing a purchase date, validating a receipt, finishing a manufacturing order, adjusting stock, or editing a BoM, reorder rule, or vendor lead time queues a replan of the affected products. After a configurable delay, two minutes by default, those rows are recomputed inside the current plan. A full plan runs nightly and on demand.
What are learned lead times?
From your received purchase lines the Planner computes each vendor’s typical and conservative receipt delay and on-time rate, shows them next to the configured lead time, flags open purchases likely to slip, and lets a manager adopt the observed value in one click.
Does it forecast demand?
Yes, with named, rule-based methods you set per product or category and per warehouse: moving average, same period last year, weekly profile, growth factor. Forecast rows are labelled, consumed by confirmed demand, editable per week, and their accuracy against actual consumption is tracked. Confirmed demand always wins.
Will AI run my plant on its own?
Not without your rules. The automation being designed is bounded: managers set bands per action type, the agent acts only inside them, and everything else is escalated to a person. Confirming purchase orders, changing BoMs, inventory adjustments, and anything above a band are approval-gated by design. Every action is logged and undoable where Odoo allows. None of this is shipped yet, and we say so.
Does my data leave my server?
Today, no: the module makes no outbound calls at all. When the AI layer ships, the design is outbound-only compact plan excerpts, only while AI is on, with an own-key and a local-model option. We do not train models on your business data, ever.
Can I use it from Claude or ChatGPT?
Not yet. A bridge to the Execution Layer for Odoo is designed to publish the Planner’s functions as MCP tools with receipts and approvals. It is not built, and we will not ship it half-done.
What does it cost?
Pricing is announced at early access. The deterministic planner is designed to keep working in full if a subscription ever lapses.
Be first
Watch it get built.
If you run manufacturing on Odoo 19, the fastest way to get this is to help shape it: design partners get the first deployments and a real say in what the planner learns to do next. Or just follow the build, and we write when something real opens.
One list, real milestones only. No newsletters, no spam.