The Substrate Model

SPNT is built on one architectural idea: every security signal the platform processes — a vulnerability finding, a configuration drift event, an exploit verification result, a compliance obligation, an enrichment from an external feed — lives in the same shared data layer.

We call that data layer the substrate.

Everything else in this documentation flows from that one decision.

The problem with how security tools normally work

A typical enterprise security architecture has eight to fifteen separate tools. Each has its own database. Each speaks its own severity vocabulary. None of them are natively aware of each other.

When a new known-exploited vulnerability is published, somebody on the security team has to pull the CVE identifier, query the scanner output to find which assets are affected, check the log platform for exploitation attempts, and update the compliance tracker. In a large organisation this takes days. In a small one it may not happen systematically at all.

Vendors patch this with API integrations — connectors that move data between tools. Integrations reduce manual effort. They don't eliminate the problem: there are still multiple data stores, and synchronisation is always after the fact.

What changes when there's one substrate

Inside SPNT, the four modules don't integrate with each other. They share the same data.

When the detection module identifies a vulnerability, the record it produces is immediately available — with no synchronisation job — to:

• The prioritisation engine, which recalculates the finding's priority against current threat-intelligence enrichment.
• The governance module, which evaluates which compliance obligations are now affected.
• The autonomous research engine, which can investigate the finding alongside everything else it knows.
• The dashboard the CISO is reading.

When an OSINT signal arrives indicating a CVE on your environment has just been added to the Known Exploited Vulnerabilities list, the priority of the relevant finding updates within minutes. No analyst needs to be in the loop for the initial correlation.

What the substrate is not

The substrate is not a SIEM. It does not store raw logs at scale. If your organisation has regulatory obligations for petabyte-scale raw log retention, you will run a dedicated log platform alongside SPNT.

The substrate is not an EDR data layer. SPNT does not deploy endpoint agents or capture host-level process telemetry. For host-layer detection and post-compromise forensics, you will run a dedicated endpoint platform alongside SPNT.

These are deliberate architectural concessions. SPNT trades raw-data breadth for structured-substrate depth.

How to test the claim

In a pilot, connect a cloud account and an identity platform. Run detection for one week. Then watch whether a new threat-intelligence event — a KEV publication, a credential leak alert, a fresh CVE disclosure — automatically updates the priority of a relevant finding without manual input.

If it does, the substrate model is demonstrated. If it doesn't, the platform isn't doing what we claim it does. There is no in-between.