You may have seen recently that the platform that was formerly known as GraphXR, the modelling, analytical and data visualisation platform from Kineviz is now simply renamed as Kineviz. The recent triggering of this event has given me an opportunity to reflect on my journey so far and to look at the exciting future direction.

To do this reflection I went back to a model that I created early on in my Kineviz relationship and had a number of people around me at the time wondering if I had lost the plot. Why would you ever want to create a model that contained over 30,000 nodes and what could I possibly get from doing this? The first question was an easy one to answer and that was to explore if I could create a “usable model” that large (not simply some wild hair ball), and the second was I really had no idea but it seemed like a great idea at the time. Also, for those that had been experimenting with Bloom from Neo4j around the same time period you would know how limiting this was.

Was it straight forward, err no... The data part was the easy bit. The West Australian government through their mining oversight operations is currently known as DMIRS (Department of Mines, Industry Regulation and Safety) and they update this data daily.

So not having a mining background I had some very simple questions to ask like what does the ownership of a tenement look like? Was it one to one, or one to many? This simple question was answered by downloading a csv file and loading this into GraphXR and the journey began. Yes, I could this through Excel or Power Query but do they look this good?

The model below shows what was later affectionately referred to upon public sharing as the "Death Star". It helped visually answer the question on the structure. If the structure was to reflect a one to one relationship we would see model that only had a central holder and all of the tenements they license sitting around this node. You can see in the view that there are indeed many one-to-one relationships but there are also some complex one-to-many relationships in place ( have a look at that great one just just left of centre).

Who’s playing with who? This is that central cluster filtered down to the connected entities.

*It’s a complex interplay of 650 tenements over 9 holders*

From this foundational model we leap forward to today to show some of things that we can do in the current release that would have required a trained and skilled analyst at the beginning of the 2026, but now even I can do some of this stuff which means you can to. This quantum leap is delivered through the introduction of two core additional pieces, an internal graph database (KoreDB)and an interactive agent to assist in the coding and analytics.

I was super sceptical when this new offering was first discussed with me and didn’t exactly embrace it with any great enthusiasm, but we agreed to trial bits of it to develop and interactive Master Class that we ran in conjunction with the ACS (Australian Computer Society) in March this year. This came together and we had lots of positive feedback so the seed was sown. Now I use it daily and its become part of my go to toolkit.

Sticking with the original tenement model we now have a better understanding of the scale and ownership structure, we can now start to explore other data within the dataset. So what about looking at this data set from a date perspective?

*A busy last decade and a very busy renewal period looming…*

Both of the above charts were generated through the use of the agent by simply prompting it to analyse the tenement data over time. You can see the rapid increase in tenement licensing over the last decade, but more importantly on the second chart see how many tenements are due to expire in the next few years! I hope DMIRS have this in their demand forward resource planning or a lot of mine project plans may be impacted.

We are starting to get a picture and some context on the scale of the tenement management problem but tenements are physical pieces of land so how can we provide some insights on this aspect. Where are they on the continent?

The original dataset that we imported from DMIRS had lots of tenement information but did not contain any geo-spatial data so for that we need another file, and fortunately there was several available for us to explore further.

So before we just plough on, we need to sit back and ask a few questions about where is the best place to store this data? We could load it into the internal KoreDB but its a lot of data and what other analytics are we likely to run against this? For me, it made more sense to extract the data that I needed into a separate external look-up file and query this when geo-spatial information was required. This was both quick and efficient.

Whilst I could have displayed this spatial data within Kineviz, I made the decision to again use the agent to generate this spatial information into a KML file which is a native Google Earth file and then use it to display the tenement data. This also allows me to display other Google Earth datasets in conjunction with the tenement data that was very beneficial.

*Overlay of Google Earth view on top of the logical Kineviz model*

So what's still missing?

The fundamental reason why all of the above is in place is to maximise the extraction of minerals from these tenements as this is where the State Government generates funds from the subsequent sale of these mineral assets. This data is stored in a third dataset that was also available from DMIRS and we used the agent to analyse this data and populate our tenement structures with the mineral records. This was information that was likely to be actively queried so this went into KoreDB.

So what we can do now?

We can structure our questions around ownerships, relationships, tenement status, geolocation or mineral deposits against all tenements across the state and an example is shown below.

*Tenement, Type, Location, Site Type and Commodities*

If you have any questions on any of the above then please feel free to reach out to me. I will be sharing some additional projects in the coming weeks but some really outstanding one’s are rightly covered under strict NDA’s.

If you have a project that that you think could benefit from this approach then feel to bounce questions off me.

Thanks to all of the team at Kineviz who have been incredibly supportive (and patient) over the years and are a fantastic group to partner with.

From GraphXR to Kineviz (2021-2026)

Visualising The Social Life of Organisational Data.