Lower cost
Reduce avoidable labor, downtime, duplicated tools, and manual reporting.
Platform · Pion
Governed by intelligence. Experienced as operational clarity.
One operational view—from global condition to company, site, system, and root device.
- OverviewLive records · simulated estate
- Control CenterSimulated estate · live navigation
- SOC OperationsGoverned records · telemetry not instrumented
- SCADA OperationsSimulated estate · live governed requests
- Digital TwinSimulated estate · no predictive model
- RMM OperationsSimulated estate · live governed requests
- ReportsLive — governed records
- SettingsLive — read-only configuration
- Authorization GateLive — governed records
The platform's own labels: filled where every row is a record it wrote, hollow where the estate is simulated.
Faster action
Turn fragmented signals into governed, device-level resolution workflows.
Growth capacity
Add sites, assets, and clients without matching growth in coordination overhead.
01 / The difference
AI is not the product. The product is resolution.
Pion is designed around business outcomes: healthier systems, shorter incidents, fewer repeat failures, lower support burden, stronger evidence, and more capacity to serve customers and expand operations.
02 / One surface
Six consoles, or one governed one.
Instead of forcing technicians to jump between security tools, service desks, remote management systems, cloud portals, SCADA/OT consoles, and reporting documents, Pion is designed to bring those signals into a single command center.
Where the work is today
- Security tools
- Service desks
- Remote management
- Cloud portals
- SCADA/OT consoles
- Reporting documents
Each holds part of the answer. None holds the record. The operator carries the context between them by hand — the brief calls it swivel-chair work.
Where Pion puts it
Pion
One governed command layer
- Observe
- Connect
- Reason
- Govern
- Execute
- Verify
One surface, one context, one record. The operator sees which client, site or system needs attention, and is routed into the workspace that can act on it.
Design intent · not the current build
The single surface is built and captured on this page. The connectors that would feed it from those six systems are not built in this stage.
03 / Where Pion is going
The intended look of the operational pages.
These are NGCC5's design mockups of the operational pages — the control center, the four operational domains, executive reporting and settings — the destination, not a screenshot. Under each are the indicators the page is meant to monitor.
Design mockup · not a screenshot Control Center
Enterprise-wide operational visibility
- Companies and sites monitored
- Managed assets
- Critical issues
- Priority locations
- Global alert trend
Design mockup · not a screenshot SOC Operations
Real-time security monitoring, detection, and response
- Overall security posture
- Critical security alerts
- Active security incidents
- Threat-detection rate
- Mean time to respond
Design mockup · not a screenshot SCADA Operations
Process view and equipment status
- Process availability
- Control-loop health
- Active OT alarms
- Safety-interlock status
- Setpoints versus actual readings
Design mockup · not a screenshot Digital Twin
Model-to-physical synchronization
- Digital-twin synchronization
- Model confidence
- Prediction horizon
- Physical-versus-simulated readings
- Predicted asset-health deterioration
Design mockup · not a screenshot RMM Operations
Remote monitoring and management overview
- Total managed devices
- Devices online and offline
- Patch compliance
- Backup success rate
- Tickets requiring action
Design mockup · not a screenshot Executive Reports
Cross-domain reporting for governed operational decisions
- Reports ready
- Drafts in review
- Evidence complete
- Cross-domain health
- Report library
Design mockup · not a screenshot Governance & Settings
Identity, access, and policy boundaries for every tenant and site
- Authorized users
- Role templates
- Pending changes
- Policy boundaries
- Change history
The twin as a way in, not a page.
NGCC5's later mockup sheet makes the digital twin a route rather than a destination: six views of the same estate, each one a layer closer to the device that has the problem — the plant in three dimensions, the service topology, the site, the process loop, the incident replayed against its own timeline, and the portfolio a board would read. Every panel is a design mockup.
- 3D Asset Twin
- Topology Graph Twin
- Site Map Twin
- Process Schematic Twin
- Time-Travel Replay Twin
- Executive Portfolio Twin
The panels show an EALAI reading beside each view — signal meaning, recommended action, a confidence score, and the approval it would need. The approval half is what the walkthrough on this site already runs. The rest of it is the destination: no predictive model runs in this stage, and confidence, horizon, wear and remaining useful life are not computed anywhere in the delivered platform.
82 indicators · design intent
This is NGCC5's list, unshortened. Each line is something a page is meant to be able to monitor, not something it monitors today: the audit finds no connected data source behind any of them, and each domain below carries the platform's own sentence naming what it does not yet do.
SOC Operations18Governed records · telemetry not instrumented
Not built in this stage · SIEM ingestion, endpoint detections, network and cloud findings
- Overall security posture
- Critical security alerts
- Active security incidents
- Threat-detection rate
- Mean time to respond (MTTR)
- Security-event ingestion
- Incident severity
- Incident source
- Affected assets
- Incident status and ownership
- Identity and authentication anomalies
- Endpoint threats and malware detections
- Network and firewall threats
- Cloud-security misconfigurations
- SIEM-generated events
- Threat distribution by severity
- Security-event volume and trends
- Unresolved high-priority incidents
SCADA Operations20Simulated estate · live governed requests
Not built in this stage · Availability and loop-health maths, interlock state, process trends
- Process availability
- Control-loop health
- Active OT alarms
- Safety-interlock status
- Tank levels
- Pump operating condition
- Pump speed
- Valve position
- Valve operating mode
- Process pressure
- Process flow rate
- Process temperature
- Motor condition
- Heater condition
- Equipment setpoints versus actual readings
- Equipment operating state
- Alarm severity and acknowledgment
- Pressure and flow trends
- OT alarm distribution
- Overall industrial-process status
Digital Twin20Simulated estate · no predictive model
Not built in this stage · The predictive half: confidence, horizon, wear, remaining useful life
- Digital-twin synchronization
- Model confidence
- Prediction horizon
- Overall asset variance
- Physical-versus-simulated pressure
- Physical-versus-simulated flow rate
- Physical-versus-simulated temperature
- Physical-versus-simulated vibration
- Sensor-to-model consistency
- Equipment-state matching
- Model-to-physical deviations
- Pump and bearing condition
- Predicted asset-health deterioration
- Simulation-variance trends
- Projected bearing wear
- Predicted maintenance requirements
- Maintenance timelines
- Remaining useful life indicators
- Future failure risk
- Recommended inspection windows
RMM Operations24Simulated estate · live governed requests
Not built in this stage · Patch compliance, backup success, device connectivity, OS inventory
- Total managed devices
- Devices online
- Devices offline
- Overall device health
- Patch compliance
- Missing patches
- Missing critical security updates
- Backup success rate
- Failed backups
- Open support tickets
- Tickets requiring action
- Critical, high, and medium-priority tickets
- Workstation status
- Server status
- Network-device status
- Mobile-device status
- Operating-system versions
- Endpoint health status
- Device connectivity
- Last device check-in
- Client and site assignment
- Patch and remediation trends
- Device-health distribution
- Required remediation actions
04 / The platform today
Eight sections, one gate, and the record behind them.
Every screen below is the running platform, captured as it is. The label on each is the platform's own — green where every row is a record it wrote, amber where the estate is simulated. Nothing is asserted that the software does not compute.
One interface family, four operational domains
Each workspace presents the measurements, evidence, workflows, and controls appropriate to its operational role while preserving a common navigation model and a consistent EALAI interaction layer.
- SOC Operations
- SCADA Operations
- Digital Twin
- RMM Operations
01 · Overview
Overview
Where attention is needed, and what this platform can and cannot do in this stage — both computed, neither asserted.
- Reads
- Every section below, plus the governed records behind them
- Not built in this stage
- No cross-period trends — no history is collected in this stage
Screenshot of the running platform. Label: Live records · simulated estate. 02 · Control Center
Control Center
Every company in the simulated estate, down to the device — each level computed from the devices beneath it.
- Reads
- The asset estate: company, site, system, device
- Not built in this stage
- No connector feeds the estate; the geography map stays on the legacy shell
Screenshot of the running platform. Label: Simulated estate · live navigation. 03 · SOC
SOC Operations
Governed security actions and the platform's own records — requests, refusals, and tamper-evident chains.
- Reads
- Security requests, recorded refusals, chain integrity
- Not built in this stage
- SIEM ingestion, endpoint detections, network and cloud findings
Screenshot of the running platform. Label: Governed records · telemetry not instrumented. 04 · SCADA
SCADA Operations
The process view over the simulated estate — readings versus reference, cascades, and the governed path to act.
- Reads
- Systems, device readings, cascade dependencies
- Not built in this stage
- Availability and loop-health maths, interlock state, process trends
Screenshot of the running platform. Label: Simulated estate · live governed requests. 05 · Digital Twin
Digital Twin
The model-to-physical comparison — each reading against the reference its record states. No predictive model runs in this stage.
- Reads
- Readings against the references their records state
- Not built in this stage
- The predictive half: confidence, horizon, wear, remaining useful life
Screenshot of the running platform. Label: Simulated estate · no predictive model. 06 · RMM
RMM Operations
Every managed device in the simulated estate — health, last check-in, and the governed path to act on one.
- Reads
- The managed fleet, its health and last check-in
- Not built in this stage
- Patch compliance, backup success, device connectivity, OS inventory
Screenshot of the running platform. Label: Simulated estate · live governed requests. 07 · Reports
Reports
Decided records and the closeout packages they produce — each one verifiable by another party without trusting us.
- Reads
- Decided records, their packages, chain integrity, recorded activity
- Not built in this stage
- Scheduled delivery, branded documents, period comparison
Screenshot of the running platform. Label: Live — governed records. 08 · Settings
Settings
How this platform is configured, read from the running system — and why none of it can be changed from here yet.
- Reads
- The session, the approval policy the server enforces, and the boundaries
- Not built in this stage
- Every write: changing an authorization model is itself a governed action, and that path does not exist yet
Screenshot of the running platform. Label: Live — read-only configuration. 09 · Authorization Gate
Authorization Gate
Governed decisions, evidence and closeout — step 11 and step 14 of the resolution path.
- Reads
- The governed queue, decisions, transitions and evidence
Screenshot of the running platform. Label: Live — governed records.
05 / The resolution path
From global command to a closed incident, in fourteen steps.
NGCC5's own workflow: two ways in — from a functional page or from the map — and one governed way through.
- Company
- Site
- Domain
- System
- Device
- Analysis
- Approved action
- Verification
ExampleAcme ManufacturingSacramento PlantSCADAProduction Line 2Pump P-204
- 1Global Command UI
- 2Select Alert or Map Marker
- 3Select Company
- 4Select Site
- 5Select Operational DomainSOCSCADADigital TwinRMM
- 6Select System or Subsystem
- 7Identify Root Device
- 8Review Device Evidence
- 9EALAI Analysis
- 10Choose Corrective ActionUser executesAuthorize EALAI recommendationInstruct EALAI
- 11Authorization GateAuthorized? — no: Return for review
- 12Execute Approved ActionTarget device control
- 13Verify Device and Site HealthResolved? — no: Reanalyze or escalate
- 14Close Incident and Record Audit Trail
EALAI retains company, site, system, device, evidence, permissions, and action context throughout the workflow.
06 / Evidence
A closeout package a third party can verify without trusting us.
Every decision writes an evidence record in the same database transaction as the decision itself — who decided, what, from which state to which, with a canonical snapshot of the request and both timestamps — linked to the record before it by a SHA-256 chain. The closeout export is a ZIP with a nine-part manifest, the decision, the chain, and a standalone verifier that runs on another machine with nothing but Python.
The chain
recordHash = SHA-256( canonical JSON of the record ‖ previous hash )
genesis prevHash = 0000000000000000000000000000000000000000000000000000000000000000
Canonical JSON — any deviation breaks every stored hash:
- 01Property names camelCase, sorted by byte order.
- 02No whitespace — no indentation, no spaces after colons or commas.
- 03UTF-8 without BOM; non-ASCII written raw; only quotes, backslashes and control characters escaped.
- 04Dates in UTC, ISO-8601 round-trip form with seven fractional digits, always Z.
- 05Null values written explicitly, never omitted.
- 06List order preserved — order is data.
- 07Enums as their names: Pending, Approved, and so on.
- 08The request snapshot is itself canonical JSON, embedded as an escaped string.
Honest limit · A same-database hash chain detects accidental corruption and unsophisticated edits. It does not survive an adversary who can rewrite the whole table and rehash. Real tamper evidence needs an external anchor — next stage.
The lifecycle
Five transitions are permitted; every other pair is refused with the record unchanged.
- Requested— submit →Pending
- Pending— approve →Approved
- Pending— reject →Rejected
- Pending— request more info →MoreInfoRequested
- MoreInfoRequested— resubmit →Pending
The requester never decides their own request, and every decision needs a written reason.
The closeout package
A ZIP with five files — re-checkable on another machine without this platform:
- manifest.json
- decision.json
- evidence-chain.jsonl
- verify.md
- verify.py
Its manifest has nine parts, in this order:
- 1Package
- 2Files, with a SHA-256 for each
- 3Approval summary
- 4The decision, verbatim
- 5Transitions and estate effect
- 6Chain state at export
- 7Canonicalization specification
- 8How to verify
- 9What this does not prove
Part 9 — what this does not prove, as the package states it
- It does not prove any real device, endpoint, firewall, PSA, RMM or SCADA system was touched: every execution result in the platform carries SimulationMode=true, and connected-system execution is outside this stage by design.
- It does not prove the chain survived an adversary with database write access: a same-database hash chain detects accidental corruption and unsophisticated edits, not a full rewrite-and-rehash. An external anchor is the next stage.
- It does not prove production-grade identity: the accounts are the local demo identity provider's named accounts on the demo machine; production identity is the organization's platform.
- It does not prove anything about events that were never recorded: the package attests exactly the records as stored at export time, nothing more.
07 / Built and not built
What each section reads today, and what it deliberately does not do yet.
Both columns are the platform's own words — the same list its Overview page computes from.
Overview
Live records · simulated estateReads today
Every section below, plus the governed records behind them
Not built in this stage
No cross-period trends — no history is collected in this stage
Control Center
Simulated estate · live navigationReads today
The asset estate: company, site, system, device
Not built in this stage
No connector feeds the estate; the geography map stays on the legacy shell
SOC Operations
Governed records · telemetry not instrumentedReads today
Security requests, recorded refusals, chain integrity
Not built in this stage
SIEM ingestion, endpoint detections, network and cloud findings
SCADA Operations
Simulated estate · live governed requestsReads today
Systems, device readings, cascade dependencies
Not built in this stage
Availability and loop-health maths, interlock state, process trends
Digital Twin
Simulated estate · no predictive modelReads today
Readings against the references their records state
Not built in this stage
The predictive half: confidence, horizon, wear, remaining useful life
RMM Operations
Simulated estate · live governed requestsReads today
The managed fleet, its health and last check-in
Not built in this stage
Patch compliance, backup success, device connectivity, OS inventory
Reports
Live — governed recordsReads today
Decided records, their packages, chain integrity, recorded activity
Not built in this stage
Scheduled delivery, branded documents, period comparison
Settings
Live — read-only configurationReads today
The session, the approval policy the server enforces, and the boundaries
Not built in this stage
Every write: changing an authorization model is itself a governed action, and that path does not exist yet
Authorization Gate
Live — governed recordsReads today
The governed queue, decisions, transitions and evidence
| Section | Reads today | Not built in this stage |
|---|---|---|
| OverviewLive records · simulated estate | Every section below, plus the governed records behind them | No cross-period trends — no history is collected in this stage |
| Control CenterSimulated estate · live navigation | The asset estate: company, site, system, device | No connector feeds the estate; the geography map stays on the legacy shell |
| SOC OperationsGoverned records · telemetry not instrumented | Security requests, recorded refusals, chain integrity | SIEM ingestion, endpoint detections, network and cloud findings |
| SCADA OperationsSimulated estate · live governed requests | Systems, device readings, cascade dependencies | Availability and loop-health maths, interlock state, process trends |
| Digital TwinSimulated estate · no predictive model | Readings against the references their records state | The predictive half: confidence, horizon, wear, remaining useful life |
| RMM OperationsSimulated estate · live governed requests | The managed fleet, its health and last check-in | Patch compliance, backup success, device connectivity, OS inventory |
| ReportsLive — governed records | Decided records, their packages, chain integrity, recorded activity | Scheduled delivery, branded documents, period comparison |
| SettingsLive — read-only configuration | The session, the approval policy the server enforces, and the boundaries | Every write: changing an authorization model is itself a governed action, and that path does not exist yet |
| Authorization GateLive — governed records | The governed queue, decisions, transitions and evidence | — |
08 / Reporting
Reports as an output of the record, on the client's cadence.
The platform's own list of what reporting is meant to produce. None of it is built in this stage beyond the closeout package: the Reports section's own words are quoted beside it.
Design intent · not the current build
- Daily operations, incident, security, SCADA/OT, endpoint, patch, identity, cloud, SLA, approval, evidence, deployment and client reports
- Weekly, monthly and yearly summaries with comparison periods
- Executive reporting translating technical events into business impact
- AI-assisted report drafting with human review
- Evidence packages and exportable snapshots
The Reports section today
Reads: Decided records, their packages, chain integrity, recorded activity.
Not built in this stage: Scheduled delivery, branded documents, period comparison.
- 6
- stages in the governed chain
- 8
- EALAI functions NGCC5 defines
- 14
- steps in the resolution path
- 5
- lifecycle transitions permitted
- 9
- parts in a closeout manifest
- 6
- approver roles
See it work
Click through a governed action, end to end.
The interactive walkthrough runs the fourteen steps in your browser — with a real evidence chain you can verify and break — on sample data.