EHS Insight Hub

The situation

EHS work produces several kinds of record that belong together. An event happens at a site. A case is opened to manage it. Concerns are raised along the way, some of them before anything goes wrong. Over time, patterns across all of these become insights that leadership should act on. In most EHS systems these sit in separate modules and separate exports, so seeing one site's picture means joining them by hand.

That join is where numbers drift. When each report applies its own filter for what counts as open, overdue or closed, two dashboards can show two different figures for the same site in the same week. The Gensuite refresh attacked the same problem at the point of capture. Hexion's move to Palantir Foundry gave me the chance to fix it in the data model rather than in each report.

Constraints

• The people using it already work in Gensuite every day. A new tool that asked them to learn a new layout would compete with the system of record instead of supporting it.
• KPIs and status labels feed management reporting, so they had to be computed the same way everywhere, from rules that a reviewer can read.
• The ontology is shared with the wider Foundry migration, so changes go through a branch and a reviewed proposal before reaching main. Nothing ships by editing production directly.
• EHS records are sensitive. Nothing from the tenant appears on this page: the view below is a mock-up with invented values.

What I built

The work has three layers. The ontology gives every EHS record a typed object with links to the records it relates to, so a case knows its events and an insight knows the concerns behind it. A single logic module computes every KPI and decides every status label from those objects. The widget only displays what the logic returns, so no screen carries a rule of its own.

The core object types

Four of the twelve object types carry most of the story.

The view

The widget follows the Gensuite pattern of KPI tiles above a status-coloured list, so an EHS user can read it without training. The mock-up below shows that layout. Every value in it is invented.

Decisions I made and why

• I put every KPI and status rule in one logic module instead of inside each view. When the definition of overdue changes, it changes once, and every tile and list agrees.
• I modelled insights as objects in the ontology, not as text in a report. That way an insight keeps its links to the concerns and events behind it, and anyone can trace the claim back to the records.
• I copied the Gensuite layout on purpose. Familiarity was worth more than novelty for people who spend their day in the system of record.
• I built on a branch and sent it through a merge proposal, the same review path as the rest of the Foundry migration, rather than editing the shared ontology directly.

Where it stands

The ontology and widget are built and verified on a Foundry branch. On that branch, the 12 object types index 190 cases, 1,221 events, 11,546 concerns and 82 insights. The merge proposal that brings it to main is in review. I will update this page when it merges.

Cases

190

Events

1,221

Concerns

11,546

Insights

82

Related