Beanome models your network in tables you already understand — sites, materials, demand, lanes, capacities, costs — solves it with mixed-integer optimization, and returns a run you can trace back to the exact data it came from. Then ask Isaac what changed and why.
Illustrative — a sample network, not customer data.
Not where a truck is right now. Where the trucks should be going at all — and what it costs to serve demand from there.
Which sites to open or close, which operations to run where, and which lanes carry what. Or, one question earlier: given where demand is, where should facilities be at all — the centre-of-gravity study.
Every cost in the model is named: resource, transport, site, operation, inventory, opening and closing. A run returns the objective it achieved and the decisions and flows that got it there.
A scenario is the same network with something changed. Solve it, compare it against the baseline, and read what moved. Nothing under either run can shift afterwards.
The model is tabular — sites, materials, customers, demand, lanes, capacities, costs and the rules connecting them. Author it in the grid or bring a workbook. Slicers narrow a table to the records you mean; mass edit changes them in one move.
A scenario is a pinned data version plus your changes to it. Ask “what if Porto closes in the winter peak” without touching the baseline. Scenarios have lineage — a child inherits its parent's changes unless it overrides them.
The platform validates the model, picks a solution strategy for its size and structure, and runs it. Large models are decomposed automatically. Objectives solve in priority order, not as a weighted blend.
A run is immutable and bound to the exact model version it was produced from. Six months later it still names the data it used, and that data still exists, unchanged. Compare runs, read the map, export the tables, ask Isaac.
| customer | material | period | quantity | price |
|---|---|---|---|---|
| Lisboa Retail | SKU-1180 | P11 | 1,344 | 42.00 |
| Lisboa Retail | SKU-1180 | P12 | 1,568 | 42.00 |
| Porto Norte | SKU-2210 | P11 | 820 | 37.50 |
| Porto Norte | SKU-2210 | P12 | 918 | 37.50 |
| Madrid Centro | SKU-1180 | P11 | 2,410 | 41.20 |
| Madrid Centro | SKU-3020 | P12 | 1,105 | 58.00 |
Baseline #12 | Close Porto, winter peak #14 | Δ | |
|---|---|---|---|
| Demand met | 100% | 100% | — |
| Total cost | €7.62M | €7.93M | +4.1% |
| Transport | €2.10M | €2.41M | +€312k |
| Site fixed | €1.48M | €1.30M | −€180k |
| Inventory | €0.61M | €0.60M | −€8k |
| Open sites | 5 | 4 | −1 |
| Resources ≥ 95% | 0 | 1 | Lisbon · line 2 |
Which resources are at capacity in this run?
One. Lisbon line 2 runs at 97% in periods 11 and 12 — it absorbed the Porto volume this scenario rerouted. Every other resource stays under 75%.
If you want headroom, branch a child scenario that adds a second line at Lisbon — I can prefill the resource row.
Illustrative — a sample network, not customer data.
Isaac is the assistant inside every scenario. It answers from the run's actual output — the flows, costs, activated sites and demand it produced — and says so. It does not answer from what a language model happens to remember about supply chains.
Total cost is +4.1%. Transport carries the whole difference: with Porto closed, Lisbon serves the Iberian customers at about 2.3× the distance, and the fixed cost Porto no longer incurs does not cover it.
One thing to check: Lisbon line 2 reaches 97% of capacity in periods 11–12. If demand there grows, this scenario stops being feasible before it stops being expensive.
Objectives are solved lexicographically: priority 1 alone, its result fixed as a constraint, then priority 2 within it. A lower priority can never cost you on a higher one. Scope any objective to a group — maximize demand met for the key accounts, then minimize inventory at the Iberian sites.
Full network design over all 21 tables — or a greenfield study over five: given where demand is, where should facilities be? Both are runs, with the same provenance.
Sites and lanes drawn on the map with their utilization: healthy, at capacity, bottleneck. The picture a run paints of itself, not a status board.
Halos on the map · list in the panelA slicer offers only the values actually present in your data. It defines the record set mass edit acts on. Import a workbook, export the tables a study reads — and only those.
Write down alternative demand futures and their likelihoods. Two or more, and the run is solved as a stochastic one across them rather than against a single forecast.
Submitting a solve materialises the scenario's data into a content-addressed version and records it on the run. The scenario stays editable; the run never changes. Compare any two runs side by side, restore a scenario from a run, and name scenarios so they still mean something in six months.
The guide lives inside the app, next to the grid. It says what each field means, what a blank means, and — where a field is stored but never reaches the model — says so plainly rather than inventing a purpose.
These are not slogans. Each one is a checked property of the product, or a decision recorded in its architecture.
Versions are immutable and hash-addressed. A result can always be traced back to the input that produced it — and that input still exists.
A centre-of-gravity study has no bill of materials. Not an empty one — none. The tables an analysis does not read are simply not offered, so the data pane and the export can never disagree about what your scenario is.
An infeasible model is told apart from a timeout, and both from a platform fault, by the tier that knows. A failure nobody can attribute is recorded as unattributed rather than as a plausible-looking one.
The in-app Network Modeling Guide documents every field and what it does to the answer. A build gate compares it against the model itself: a field you find there exists, and a field that exists is there.
A lane with no distance is measured great-circle; an inventory row with no period applies to all of them. Each field's entry says what a blank means, and it is rarely “nothing”.
Data does not cross between workspaces. Sign-in is OIDC through the identity provider; an unknown identity is never auto-provisioned into a tenant.
Beanome is in pilot. Here is what you can use now and what is being built — so the site does not promise what the product does not yet do.
We are taking on a small number of pilot networks. Bring your sites, demand and lanes in a workbook; we will load them, solve the baseline with you, and branch the first what-if together.
