OreFrame · resource estimation platform
Three modules, one platform. Data reads what you already have and puts the deposit on screen in minutes. VarioForge does the variography and the kriging, interactively. WorkflowCanvas turns the method into a routine anyone on the team can read, and orchestrates the packages you already pay for. One project, one truth, one link to share it.
Runs in Chrome, Edge, Firefox and Safari · nothing to install
The state of play
A resource estimate is assembled across a chain of software that was never designed to work together. Each package has its own file format, its own licence, its own interface from fifteen years ago, and its own idea of what a drillhole is. What crosses them is a method, and the method is not written down anywhere.
Modelling in one package, estimation in another, plots in a third, cleanup in Excel, and a Python script holding the joints together. Being good at the geology is no longer enough; you have to be good at five interfaces, and the person who is has a queue outside their door.
Separate contracts, separate renewal dates, separate seat counts, separate training budgets. The graduate who needs to look at one wireframe for ten minutes cannot, because the seat is checked out in another office.
Modal dialogs, parameter files, macro languages and a manual. New staff take months to be useful and the knowledge never leaves the few people who learned it the hard way. Meanwhile the deposit does not wait.
When the report has to be signed, someone spends a week rebuilding what was done: which file, which cut-off, which search, which version. The estimate is a legal document, and almost none of what produced it was ever recorded.
So we built the layer above.
Your packages keep doing the work. OreFrame is where the data, the method and the record live, in one interface, on one licence.
One platform, three modules
The modules are not three products bolted together. They share one project and one data model, so a domain built in the first is the domain the second krige and the third publishes. The canvas sits above all of it and orchestrates: it runs the steps in order, drives your existing packages, and keeps the record of what ran with which parameters.
Collar, survey, assay, CSV, Excel, DXF, STL, and Datamine studies read straight from disk. Desurvey, EPSG and column mapping handled on arrival. Then the deposit in 3D, the terrain and the satellite imagery under it, and an EDA that four variables at once does not slow down.
One variography engine, built as a calculation tree. Move the azimuth, the tolerance, the bandwidth, the lag, the grade or the domain and the answer is already drawn. It holds the same way on three hundred samples and on a full campaign, whatever the data came in as. Then krige on the block model.
The method as a graph: nodes, typed ports, parameters on the face of each step. Run it and it drives Datamine, Surpac, Isatis, QGIS and Python in their own syntax, node by node, with the run history kept. A graduate can follow it and an auditor can review it.
Module 01 · Data
Most of the delay in an estimation is not the geostatistics. It is getting the data in, in the right projection, with the right dip convention, and then finding somewhere to look at it. That part is the first module's whole job.
Drop three files and they sort themselves into collar, survey and assay by name. Type the source EPSG and the app tells you it is NAD27 Minnesota North in US survey feet, converts the coordinates to metres, and drops a satellite image of where your holes actually land. A projection mistake is caught in the first thirty seconds instead of in the block model.
On this trio it also reports: 100 % of 2,628 survey dips are positive → defaulted to "down = positive". It asks when it is unsure and states its assumption when it is not.
Point it at a Datamine study and it reads the
.dm
headers and tells you what each file is: drillholes, collar, survey, block
model, wireframe, variogram, variogram model, search and estimation parameters,
strings. Fields and record counts, before you import anything. You do not have to open
Datamine to know what is in the folder.
Holes as tubes coloured and sized by grade, wireframes and DXF surfaces in the same scene, clipping planes, a section flythrough, and the search cone drawn among the samples it actually selected. The parameters are in the ground, not in a legend.
Type the EPSG. The topography and the imagery for your licence area arrive on their own. No GIS request, no basemap licence, no waiting on another office, no cost.
Four variables at once: histograms, scatter, swath, all cross-filtered, with a mini-3D beside them so a selection in a histogram is a selection in the ground. The data table is virtualised, carries per-column statistics, and edits persist into the project. Looking at the data stops being a separate exercise from modelling it.
Module 02 · VarioForge
Underneath VarioForge is a calculation tree rather than a recompute. Move the azimuth, the tolerance, the bandwidth, the lag, the grade or the domain and the curve is already redrawn. It behaves the same way on three hundred samples and on a full campaign, and on any kind of data you feed it. That is the reason a study stops being a budget of minutes per test.
When a variogram costs nothing to ask for, the question changes. It stops being "which variogram do we have time to fit" and becomes "which of these hypotheses survives". Chain a domain against a variable, look, change the domain, look again. Four grades against three domains is an afternoon.
Geology, not charts
Most packages draw the result in 3D. Drawing the parameters in 3D, the cone that accepted the pairs, on the holes that produced them, is what turns a review meeting from an argument about numbers into a conversation about geology.
Build the grid, sub-block it, set the search neighbourhood, and run ordinary kriging on the model the variography just produced. The same fitted structures, not a set of numbers retyped into another package.
The experimental variogram, the four model types and the kriging system are asserted against independent reference implementations on every release, rotated anisotropy included. Ask for the test suite during a technical review and we hand it over.
The block model rendered inside the DXF volume it was constrained by, blocks sized and coloured by grade, turning in the same scene as the holes. Assembling the deliverable and reviewing it are the same act.
opening progressively
Module 03 · WorkflowCanvas
This is the part people do not expect. OreFrame does not only read your packages' files. It writes their work. Assemble the routine from templates on the canvas and it emits the macros and scripts those packages run, in their own syntax, then executes them in order and tells you where it is. The expertise moves out of one person's head and into a graph the whole team can see.
A routine can cross five packages in one run: database to QGIS to Python to Isatis to Leapfrog and back, with conditional branches driven by global variables, so the simulation runs only when the flag is set. Progress is tracked node by node and the run history is kept.
234 for Surpac, 100 for Datamine, 90 for RMSP, 69 for Isatis, plus Python and QGIS, across block modelling, estimation, variography, compositing, DTM, blasting and underground design.
libraries live · browser being finished
Ready-made routines for nickel laterite with weathering-profile domains, orogenic gold with indicator kriging and heavy top-cutting, porphyry copper with alteration zones and NSR, and BIF iron with product classification. Open one, change what your deposit does differently.
Every action in the study is recorded as a node: the import mapping, the composite length, the domain rule, the fitted structure, the search ellipsoid. Not a log file beside the model. The graph is the model's provenance, and it is the same object the canvas opens.
The licence you already pay for, driven by a routine your whole team can read.
Nobody has to learn the macro language to get the deliverable.
One source of truth
A model repository versions files. This versions the method. The samples, the composites, the domain rules, the fitted structures, the search ellipsoid and the routine that produced all of it sit in one project with one history. Nobody has to look in a folder, and nobody has to ask the person who ran it.
Python and language models
That is the honest starting point. Banning the tools has not worked anywhere, and the code those tools write is genuinely useful in a geostatistics workflow. So the Python module here is built on the assumption that the code in it came from a model, and the architecture is what keeps it safe rather than a policy nobody reads.
The machine that runs the code holds no credentials, sits on its own private network, and serves one tenant at a time. The worst case is code reaching data you uploaded yourself. That is not a promise about intentions, it is the size of the blast radius.
The run token is minted for that single machine at the moment it is created. Code can read the environment it runs in, so a token shared between machines would let one tenant post code to another's. There is no shared token here, which is the part most setups get wrong.
Provider keys live on the server and never reach the browser. Usage is limited per user rather than per address, so one enthusiastic script cannot spend the team's budget. And you can point the whole module at a local model when the data must not go near a cloud provider at all.
Every run also lands in the study's graph, with the code and the parameters it used. What the model did is reviewable afterwards by the person who has to sign the report, which is the difference between using these tools and hoping nobody used them.
What you actually get
Samples, composites, domain rules, fitted models, search ellipsoid, block model, and
the lineage that produced them, inside one project. Not a folder of
final_v3_REVISED
beside a spreadsheet of parameters beside a document explaining both. There is one
answer to "what is the current model", and it is the project.
Invite by email, or send a link that expires on a date you choose. The other person opens the project, so there is one model, and revoking access is one action rather than an audit of who has which zip. Every row and every stored file is scoped to its owner in the database, not by the app remembering to check.
Build the routine as nodes with their parameters visible on them. A graduate can follow it. An auditor can review it. The next geologist can change one parameter and see what depends on it. A macro is correct and unreadable; a graph is reviewable by the person who has to sign the report.
Model-written Python runs on a machine with no credentials, on its own private network, one tenant at a time, with a token minted for that machine alone. Provider keys never reach the browser and spend is capped per user. The worst case is code reaching data you uploaded yourself, and every run is recorded in the study's graph. How that works ↓
One project, end to end
Nine stages, one project, one data model. The dataset, the parameters and the lineage live inside the study, not in a folder someone can move.
We would rather show you the line than blur it. Stages 05 to 09 exist in the codebase and are covered by the same validation suite as the rest, compositing checked for mass balance and ordinary kriging against a reference implementation, but they are not yet open to every account. Stage 07 is being rebuilt around an editable ribbon interpretation, so it is marked in dev rather than promised.
Straight answers
The screenshots on this page are a 399-hole, 35,616-sample drillhole study, and the variography on it is immediate. The engine is built so that the size of the campaign changes what happens underneath rather than what you experience. Bring your worst dataset to the technical review; that is the honest way to answer this one.
Ask for the test suite during a technical review. The experimental variogram, the variogram models and ordinary kriging are asserted against independent reference implementations on every release, rotated anisotropy included. We would rather hand that over than argue about it.
Safer here than in the arrangement you have now, which is people pasting into a chat window. Model-written Python runs on a machine with no credentials, on its own private network, one tenant at a time. The worst case is code reaching data you uploaded yourself. And it lands in the study's graph, so you can read what it did.
Good, that is the point. OreFrame does not ask you to leave them; it drives them. The routine is assembled on the canvas and comes out as macros and scripts those packages run, so the licence you already pay for keeps doing the work while the method becomes something your whole team can read.
Be precise with us and we will be precise back. Part of the work runs on the engine, so the samples reach it; the interaction runs in your browser and reaches nobody. Where the engine lives is a deployment question, and on-premise is a normal conversation.
A small team that answers. Your variogram models leave in the formats your estimation package already reads, your geometry leaves as DXF, and your workflow leaves as a JSON graph. Nothing here is a hostage.
Where the line is
This audience checks. So here is the honest state of the product rather than a feature matrix with everything ticked.
Bring one dataset
No procurement cycle, no install, no two-day training course. Load a collar / survey / assay trio, take a direction off the variogram map, and see how long it takes you to test the hypothesis you have been putting off.
contact@oreframe.com
beta
