The layer above your mining software
You paid for your modelling software. Keep it as the engine, and run it faster and for less. Oreframe does not replace your modelling software, it drives it. Your routine runs the package you already paid for, or ours, or both in the same pass, and the geologist running it never learns a new one.
Writing that routine is where the AI goes. It will not hand you a better orebody. What it takes off you is the hand on the mouse: agents that drive your packages step by step, the way you would have driven them yourself, and stop for you before anything runs.
Open accounts since September 2026 · runs in a browser, with free use to start
Written for four people
who inherits a model somebody else built and has to put a signature under it.
with six clients, and a licence budget for none of them.
whose data is not allowed to leave the site, and who have been told to use AI anyway.
who wants AI in everybody's hands, and who will be the one asked where the data went.
What is actually missing
Your package models the orebody and does it well. What it was never built for is the rest: a script somebody else can run, AI that can touch sensitive data without it leaving, and a model a client can open on a Tuesday afternoon.
The package your estimates are signed off through stays where it is.
The orchestration drives it, so the modelling is still done there. Or use ours, and have the deposit modelled in a day instead of a fortnight.
Four ways in
Nobody adopts a platform. People solve one problem and keep what solved it.
Share a study and the person on the other end opens the same orebody in a browser tab, from a link that expires when you say so. About two minutes, including the invitation.
Your licence count may not fall. Your licence bill does: an Oreframe seat costs a fraction of the one it stops you renewing.
Load the model somebody else built, cut a section wherever you drag it, click a hole to read its log, and send the reviewer the same scene instead of forty screenshots.
Bring in the Datamine macro or the Python script and publish it with a form in front of it. The geologist who does not code runs the method. The author stops being a bottleneck.
Each user's work runs on their own machine, one tenant, no credentials on it. Every run is journalled as it happens, with the parameters it ran with, so a result can be defended a year later.
What it will not do
A model can be wrong and still be defensible, as long as a person who can argue for it put their name under it. That line is not one we go near, and the rest follows from it. The answer to "can we use AI on this?" has to be architectural too. Everybody in the room knows a policy telling people to stop pasting grades into a chat window will not hold.
Built with you
Last quarter's holes arrive, the profile is re-logged, the domains are rebuilt, the model is re-estimated. It is the work that most deserves to be a routine and it is almost never written down as one.
Writing it down used to be a consulting project. Now the agent does the writing. It proposes each step, you approve it, and the routine ends up in your library instead of on somebody's invoice.
Custom apps and orchestration
A macro or a Python script comes into Oreframe and arrives as a graph with its parameters on the face of each step. And the person who runs it next quarter never has to read the macro.
Annotate the parameters and the panel appears: dropdowns, sliders, dates, and the columns the app expects. Apps live in a library and travel to another user with a code.
Nothing gets built. The work is annotating a script you already have, which is minutes, not a sprint.
653 ready-made steps across Surpac, Datamine, Isatis, RMSP, Python and QGIS. The run history is kept, which is what makes a routine safe to re-run next quarter.
The agent
Ask in plain language. It reads the columns, the domains and the units your project actually holds, asks for what is missing instead of guessing, and then works the packages for you: the parameter screens, the file shuffling and the clicking you would otherwise have done yourself, one step at a time.
A chat window has never seen your collars, your domain codes or the units your assays are in, and it cannot run anything. This one is standing inside the project with its hands on the tools, so what it proposes compiles against your data and then actually executes.
What comes back is a step in your routine, calling the packages you already run. You edit it, you re-run it next quarter, and it belongs to you rather than to a conversation.
Nothing acts on the orebody until a person says so, and the journal records what ran, with which parameters, at what time. The agent proposes all day. It never signs.
Integrations
Datamine · Surpac · Vulcan · Isatis · Leapfrog · Micromine · QGIS · Microsoft 365 · SharePoint · OneDrive · Teams · Slack · Google Chat · Python
Through an app registration in your own Azure tenant. You enter a directory id and an application id, never a client secret, and the permissions stay with your administrator. Import from SharePoint, and send a finished table back.
Point Oreframe at an incoming webhook and a finished run announces itself in the channel, with what it ran and how long it took. No bot to install.
A bench of the block model, a domain or a table goes out as GeoPackage, and GeoJSON comes back in. Terrain and satellite imagery load on their own.
Studies read before import, macros in and out, variogram models in their own formats, geometry as DXF. Native readers for Surpac, Vulcan, Leapfrog and Micromine are next, and the connectors keep coming.
Straight answers
Not instead of yours. Those packages have twenty years of modelling behind them and your estimates are validated through them, so the sane thing is to keep them as the engine and let the orchestration drive. We do have our own implicit modelling, and you are welcome to run both in the same pass and compare them. What we will not do is ask you to migrate.
You almost certainly do have everything. The question is not whether you need another package, it is whether anybody can run the ones you have without the person who wrote the macro. So do not roll anything out. Share one study by link and watch what the person on the other end does with it. If that is the only thing you ever use, it will have paid for itself, and the rest of this page can stay unopened.
Then ignore the geostatistics, which is the part everybody assumes this is about. Looking at a deposit in three dimensions and sending it to somebody who has no licence is not an advanced requirement. It is something every operation needs and almost none can do without exporting a folder of screenshots. The complicated half is there the day you want it and costs you nothing until then.
Most serious teams do. The question is whether you want a geologist spending a year on a web application and its security model instead of on orebodies. Bring us the script they would have started from and we will run it in front of you.
Then tell us precisely what "outside" means in your policy, because the answer changes with it. The interaction runs in your browser and reaches nobody. The compute runs on a machine dedicated to your account, single tenant, holding no credentials. If the rule is that nothing leaves the site at all, that is a deployment question rather than a refusal, and a dedicated instance is a normal conversation to have.
As it is usually practised, that is correct. What most teams actually have is a tool nobody approved and a rule that pretends otherwise, which is not a control. Here the model writes into a cell you read before anything runs, on a machine that belongs to your account, and every run is recorded with the parameters it ran with. You are not being asked to trust it. You are being asked to read it.
Twenty minutes, on something of yours
We open an Oreframe account during the call, and you leave with it working, or with a straight answer about what is missing. Some of those accounts are design partner places: one real piece of work, the founder on the other end of the line, and you decide what gets built next.
contact@oreframe.com