This is pre-normative material. Values and definitions here are working values, they are published so the reasoning is inspectable, not because they are settled.
This is synthetic data
Atlas Industrial Technologies does not exist. Every person, incident, supplier and measurement in the demonstration tenant was generated. Nothing in it derives from a customer, and no figure in it should be cited as a benchmark or an industry average.
Stating this plainly is not a disclaimer bolted on for legal comfort. A demo dataset presented as customer evidence is the first dishonest thing a security vendor can do, and a product whose entire argument is about honest measurement cannot afford it.
Dataset version 4, change note
| Property | Value |
|---|---|
| Dataset version | 4 |
| Document version | v3.4 |
| Registry/model version | v0.3 |
What changed in dataset version 4:
- Physical Security added as the eighth IO domain, with its canonical dimensions and verification measures.
- New physical signal source classes:
pacs,visitor_mgmt,physical_incidentandvms. - Terminology migration from capability areas to IO domains, including
the schema field rename from
area_idtodomain_id. Legacy fields remain readable for backward compatibility. This is a model change and not evidence of operational improvement. - Dataset totals below are pending recomputation. The signal, source-system, signal-type, intervention and verification aggregates carried forward from dataset version 3 have not been re-queried against the current canonical tenant since the Physical Security addition. They are marked pending recomputation rather than restated as current. Do not cite them as current totals, and treat unresolved aggregates as a release blocker for any figure published outside this manifest.
The organisation
| Property | Value |
|---|---|
| Sector | Industrial technology and manufacturing |
| Headcount | 1,000 |
| Regions | EMEA, AMER, APAC |
| Estate | Corporate IT plus operational technology at plant sites |
| Recorded history | 210 days, more than two complete quarters |
The evidence
| Property | Value | State |
|---|---|---|
| Signals ingested | 128,000+ (dataset v3 figure) | Pending recomputation |
| Source systems | 9 (dataset v3 figure) | Pending recomputation |
| Distinct signal types | 48 (dataset v3 figure) | Pending recomputation |
| Physical signal count | , | Pending recomputation |
| Physical source classes | pacs · visitor_mgmt · physical_incident · vms | Confirmed present |
| Registered connectors | 1 | Confirmed |
Every row marked pending recomputation predates the Physical Security addition and must be re-queried against the canonical tenant before it is used anywhere else. No figure has been invented to fill the gap.
The gap between nine source systems and one registered connector is real and worth understanding: the demonstration data was seeded through the ingestion schema directly rather than pulled through live connectors. The schema is the same one a live connector writes into, which is why a connector is a swap rather than a rebuild, but only one has been wired end to end.
The demo Connections screen may display a larger set of simulated active systems for visual walkthroughs. Those cards, health percentages and sync times are illustrative tenant state; they are not registered connectors and do not establish product availability. Product connector status is governed by the public connector catalogue and must be labelled separately.
The verification ledger
These are whole-tenant counts across the full 210-day seeded history from dataset version 3 and are pending recomputation for dataset version 4. The application's Physical Security view reports a 90-day window, which is a different window from the 210-day demonstration history; the two must never be combined or presented as one figure. A board update, screenshot or seat view may show a smaller reporting window and must label that window rather than appearing to contradict this manifest.
| Outcome | Count |
|---|---|
| Verified | 714 |
| Unverified | 261 |
| Regressed | 183 |
| Pending | 37 |
183 regressions are in the dataset deliberately. A demonstration tenant in which every intervention succeeded would be a worse demonstration, because the product's argument is that it reports failure. If you are walking the demo and want to see the thing that distinguishes it, look at a regressed verification before you look at anything else.
The seats
Sixteen role-based seats, operating across the eight IO domains. Eight practitioner, security operations; governance, risk and compliance; identity and access; security awareness; threat intelligence; data protection; OT security; and physical security. Eight executive, chief information security, information, executive, risk, operating, financial and people officers, plus general counsel.
Each practitioner seat lands on four ranked next actions. Each executive seat lands on decisions rather than tasks.
What is seeded rather than computed
Called out because the difference matters when reading the tenant.
The stated organisational maturity is seeded. It reads at a level because a seeder set it, not because the maturity instrument computed it from the execution history. The instrument exists; the tenant does not yet have enough elapsed programme history to drive it.
Capability scores are computed. These are real measurements taken from the seeded evidence. They moved substantially, in both directions, when a zero-denominator defect was corrected, because dimensions with no evidence had been scoring as though they had some.
Continuity has no history to read. Programme cadence became declarable recently and the tenant has not run long enough to evidence it.
Known gaps in the tenant
- One domain dimension in Third-Party Risk has a zero denominator and correctly carries no band.
- Most of the historical seed predates standing programmes and derives from correlations, so programme-driven work remains under-represented in the recorded window. IO Coach™ can now declare and schedule standing programmes, but it does not retroactively change the historical distribution.
- IO Chat™ is delivery-only. A reply typed in the chat surface is not received.
- Physical Security domain performance is measured where attributable evidence exists. It is not presented as a Physical Security maturity finding.
- Dataset aggregates for version 4 are pending recomputation, as above.
Stability
Record identifiers are hard-anchored. A demonstration that reshuffles its own identifiers between sessions cannot be walked twice the same way, and cannot be referenced in a follow-up conversation. The same risk, task and verification will be there tomorrow under the same identifier.
How the dataset may be used
Appropriate uses: product walkthroughs, deterministic screenshots, workflow testing, demonstration of result derivation and validation of empty or failed states.
Inappropriate uses: customer benchmarks, proof of product effectiveness, threshold calibration, cross-tenant comparisons, sales claims about connector availability, or evidence that a customer outcome occurred.
Every public figure from Atlas should carry synthetic demonstration data and the reporting window. Any derived value should also name the model version that computed it. Seeded fields must be visually distinguishable from computed fields wherever both appear on one screen.
Change control
A material change to the generator, population, signal distribution, domain set, schema terminology, connector representation or verification rules increments the dataset version and adds a short change note. Existing screenshots and narratives retain the version they were generated under. The dataset may evolve; its history must not.