Lower operating effort
Reduce repeated searches, handoffs, and manual reporting so technicians can spend more time resolving the condition.
Pion | First NGCC5 product
Resolve the issue. Keep the whole record.
Pion is being developed to help managed service providers and infrastructure teams investigate operational problems, authorize a response, verify recovery, and retain the evidence in one connected workflow.
The current demonstration uses a simulated estate. External connectors beyond a read-only one for Azure, and live device actions, are not built in this stage; EALAI drafts analyses, and a person decides.
- OverviewLive records · simulated estate
- Control CenterSimulated estate · live navigation
- SOC OperationsPlatform records only · live governed requests
- SCADA OperationsSimulated estate · live governed requests
- Digital TwinSimulated estate · readings against stated references
- RMM OperationsSimulated estate · live tickets and requests
- Identity / CloudSimulated directory · live governed requests
- ReportsLive — governed records
- Executive WorkspaceLive records · simulated estate
- Client OnboardingLive records · discovery sample or imported
- 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.
Value for Pion clients
Make the work easier. Make the result measurable.
Pion is being developed to connect investigation, authorization, action, and reporting in one operational workflow. Its intended value is measured in the work a client can complete and the disruption it can avoid.
Faster recovery
Carry the relevant client, site, system, and device context through investigation and a governed response.
Greater operating capacity
Support additional sites, assets, and accounts through repeatable workflows. Measure the capacity gained against the resources required.
These are intended outcomes. Client benefit must be established through a measured pilot and compared with the full cost of deployment.
The client problem
An incident crosses systems. The work should stay connected.
A support team can see the same incident in security alerts, endpoint tools, service records, cloud consoles, and operational systems. The operator still has to reconstruct the context, determine who may act, coordinate the response, and document the result.
Pion is designed to carry that context through one governed workflow. Existing monitoring and control tools remain important sources of information and execution capabilities.
Useful to the operator, accountable to the business
For the operator
Keep the affected client, site, asset, evidence, and next step in view. Reduce the need to reconstruct the same issue in separate tools.
For the operations leader
Understand incident progress, approval requirements, escalation needs, and the work required to restore service.
For the budget owner
Compare operational improvement with licensing, implementation, integration, training, and ongoing operating costs.
How Pion is intended to work
One incident, from investigation to closeout
Illustrative MSP scenario: a server condition affects a client service. The following sequence describes the intended connected workflow. The current demonstration uses simulated conditions and actions.
- 01
Locate the affected service
Move from a client or site condition to the relevant system and device. The operator keeps the operational scope in view.
- 02
Understand the evidence
Bring related conditions and dependencies into the investigation. EALAI drafts the likely cause and a proposed response for the person who decides.
- 03
Approve the response
An authorized person reviews the target, action, reason, evidence, and operating boundary. A requester cannot approve their own request.
- 04
Carry out the permitted action
A future connected deployment would recheck authorization and action conditions before using an approved connector. The present walkthrough simulates this step.
- 05
Verify and document
Check the affected condition and service outcome, then retain the decision and evidence. A recorded action alone does not establish recovery.
The client value to test is less investigation and coordination effort, a controlled response, and a clearer closeout record. A real deployment must demonstrate those benefits using connected systems.
Development status | October 18, 2026
What can be evaluated today
The current build demonstrates an authorization and evidence workflow using a simulated operational estate. The distinction between implemented controls, simulation, and future integration is part of the product explanation.
Implemented controls
The current demonstration includes requester and approver separation, allowed roles, a required decision reason, decision records, and closeout evidence packages. In Pion, which runs on Microsoft Azure, the evidence chain is also anchored outside its database, and a person can sign in with their own Microsoft account once an administrator has added them. A person at the gate can ask EALAI to draft the likely cause and a proposed response; every figure, date, device name and record key in the draft is looked up in the records EALAI was given, which shows where it came from, not whether it is right. The decision record names the draft that was on screen, each citation opens onto the record EALAI was given, and Pion keeps a record of what followed each draft. Pion's first connector reads a company's Azure resources, read-only.
Operational demonstration
Navigation, device conditions, recommended analysis, and recovery examples use sample data or simulation. They do not establish a connection to a live client estate.
Work still required
Connectors to tools other than Azure, reading a client's own Azure, live device actions, reading a client's directory beyond sign-in, and EALAI's reasoning beyond drafts are not built in this stage. Microsoft sign-in on the hosted platform uses a development registration until NGCC5's own exists, and the Azure connector is configured for no client yet.
Later capabilities
Predictive Digital Twin models remain future work. Their presence in the product design is not a claim of current availability.
What the evidence package proves
A closeout package records the demonstrated decision and evidence chain. It does not prove a live device change, production identity integration, or production readiness. 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. Nothing outside the database vouches for this chain here: no external anchor is written or readable.
Section by section
Eleven sections, one gate, and the record behind them.
Where NGCC5 has designed a section, the design is shown, labelled as a mockup, and a switch shows the same section as the platform runs it today. Every capture is taken as it is and carries the platform's own label — green where every row is a record it wrote, amber where the estate is simulated. Beside each: what the section reads now, and what it does not do yet. The captures come from a copy of the platform on an engineer's machine, so where they show the evidence anchors, those go to a directory on that machine; on the hosted platform they go to Microsoft Azure storage. The copy is seeded with the platform's sample, whose sites are registered with a plan, so its Digital Twin draws Sacramento Plant's; on the hosted record the same sample plan is registered, with seven devices placed.
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 · 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 — simulated, or reported read-only by the Azure connector — and the requests that name one
- Next
- A health score, a map of the sites and trends — today no scoring model, site location or history is kept
Design mockup · not a screenshot 02 · Overview
Overview
Where attention is needed, counted from the records, and what each section does today, in the sections' own words.
- Reads
- Every section below, plus the governed records behind them
- Next
- Trends across periods — today each figure is read from the record when the page is read, and no earlier value of it is kept to compare with
Screenshot of the running platform. Label: Live records · simulated estate. 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
- Next
- Telemetry from the client's SIEM and EDR — events, traffic, exposed ports, cloud findings — and a posture score; today this page reads the platform's own records
Design mockup · not a screenshot 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
- Next
- Availability, control-loop health, interlock state and process trends from an OT connector; today the equipment and its readings are simulated
Design mockup · not a screenshot 05 · Digital Twin
Digital Twin
The model-to-physical comparison — each reading against the reference its record states.
- Reads
- Readings against the references their records state
- Next
- The predictive half — confidence, horizon, wear, remaining useful life — and a layout drawn from a site's plan; today no predictive model runs, and devices are placed on the plan in Onboarding
Design mockup · not a screenshot Before and after
Sacramento Plant's plan, before the decision and after the re-read
The Digital Twin draws each device placed on a site's plan in the colour of what it reports now. Both pictures come from one run on the same copy of the platform: between them the pump's request was raised, approved by someone who did not raise it, and the re-read recorded.
Before the decision: Pump P-204 is red, and Control Valve V-17, Flow FT-502 and Pressure PT-501, which depend on it, are amber.Sample site plan · not to scaleCaptured on 18 October 2026 from a copy of the platform on an engineer's machine, seeded with the platform's sample, whose Sacramento Plant has a sample plan. The estate is simulated: no device was touched, and the re-read recorded what the simulated estate reported after the approval. On the hosted platform the same sample plan is registered, with seven devices placed.Open the untouched file 06 · RMM
RMM Operations
Every managed device, the tickets the platform opens for their conditions, the technicians working them, and the governed path to act on a device.
- Reads
- The managed fleet and its health, service tickets and their history, field visits, technicians' work
- Next
- Patch compliance, backup success, connectivity and OS inventory from a connected RMM tool, and alerts by email or text; today alerts are shown inside Pion
Design mockup · not a screenshot 07 · Identity / Cloud
Identity / Cloud
The identities on record, what a directory reports about each, who can reach which application, and the governed path to contain one.
- Reads
- Identities, their reported risk and its reason, privileged roles, MFA registration and application access
- Next
- Reading the client's own directory — sign-ins and risk signals — and containing an identity there; today the directory is simulated
Screenshot of the running platform. Label: Simulated directory · live governed requests. 08 · 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
- Next
- Scheduled and emailed reports, branded documents, period comparison and narrative summaries; today a report is a package another party can verify
Design mockup · not a screenshot 09 · Executive
Executive Workspace
Every client and site at a glance: their condition, who is working on what, reports, and questions answered from the records.
- Reads
- Every client's sites, tickets, field visits and governed requests
- Next
- Contract, financial and SLA figures, trends and scheduled or emailed reports; today every figure is read from the records as they are now
Screenshot of the running platform. Label: Live records · simulated estate. 10 · Onboarding
Client Onboarding
Register a client and its sites, then search each site — every other page reads what onboarding brings in.
- Reads
- Client profiles, sites and their codes, discovery runs, site plans and the devices placed on them
- Next
- Filling a site from the client's own tools — an RMM or monitoring tool, a SIEM, a SCADA historian — or a collector on its network; today a site is filled by the sample or an imported list
Screenshot of the running platform. Label: Live records · discovery sample or imported. 11 · Settings
Settings
How this platform is configured, read from the running system.
- Reads
- The session, the approval policy the server enforces, and the boundaries
- Next
- Changing a setting — who may approve what — as a governed request, decided by someone other than who raised it and recorded like any other; today this page reads what the server enforces
Design mockup · not a screenshot 12 · Authorization Gate
Authorization Gate
Governed decisions, the recorded re-read after them, evidence and closeout — steps 11, 13 and 14 of the resolution path.
- Reads
- The governed queue, decisions, transitions, evidence, and the re-reads recorded after an approved action
Screenshot of the running platform. Label: Live — governed records.
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 AnalysisEALAI draft · text only
- 10Choose Corrective ActionUser executesAuthorize EALAI recommendationInstruct EALAI
- 11Authorization GateAuthorized? — no: Return for reviewPerformed by Pion · on the record
- 12Execute Approved ActionTarget device controlSimulated in this stage
- 13Verify Device and Site HealthResolved? — no: Reanalyze or escalatePerformed by Pion · on the record
- 14Close Incident and Record Audit TrailPerformed by Pion · on the record
Marked by this site: Pion performs steps 11, 13 and 14 as records — the decision at the gate, the re-read of the device after an approved action, and the closeout with its audit trail. At step 9 EALAI writes a draft for the person who decides; it is text and cannot act. Step 12, carrying the action out, happens against the simulated estate in this stage, so Pion does not claim it.
EALAI retains company, site, system, device, evidence, permissions, and action context throughout the workflow.
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 with the EALAI drafts written for the request, the chain, the anchors written for it outside the database, 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. Nothing outside the database vouches for this chain here: no external anchor is written or readable. In production, Pion also writes each chain's latest hash outside its database, to Azure storage it can add to but not change, and every check compares the chain with those anchors. The walkthrough's sample chain is not anchored.
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 re-checkable on another machine without this platform: the five files below, and in a package from the platform a sixth, anchors.json, with the anchors written for its chain.
- 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, and no external anchor was written where this package was built.
- It does not prove an EALAI draft was right, or that the decider followed it: a draft is text a language model wrote from the records listed with it, and it decided nothing. What the record proves is which draft was in view when the decision was taken, by its hash in the decision snapshot.
- It does not prove who held an account beyond what its door checked. On this server people sign in through the demo door only: the platform's named demo accounts with the server's own password. Casey Whitfield decided through the demo door, as the named account casey.whitfield, whose password is the one every demo account shares: it shows which account decided, not which person held it.
- It does not prove anything about events that were never recorded: the package attests exactly the records as stored at export time, nothing more.
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
Next
Trends across periods — today each figure is read from the record when the page is read, and no earlier value of it is kept to compare with
Control Center
Simulated estate · live navigationReads today
The asset estate — company, site, system, device — simulated, or reported read-only by the Azure connector — and the requests that name one
Next
A health score, a map of the sites and trends — today no scoring model, site location or history is kept
SOC Operations
Platform records only · live governed requestsReads today
Security requests, recorded refusals, chain integrity
Next
Telemetry from the client's SIEM and EDR — events, traffic, exposed ports, cloud findings — and a posture score; today this page reads the platform's own records
SCADA Operations
Simulated estate · live governed requestsReads today
Systems, device readings, cascade dependencies
Next
Availability, control-loop health, interlock state and process trends from an OT connector; today the equipment and its readings are simulated
Digital Twin
Simulated estate · readings against stated referencesReads today
Readings against the references their records state
Next
The predictive half — confidence, horizon, wear, remaining useful life — and a layout drawn from a site's plan; today no predictive model runs, and devices are placed on the plan in Onboarding
RMM Operations
Simulated estate · live tickets and requestsReads today
The managed fleet and its health, service tickets and their history, field visits, technicians' work
Next
Patch compliance, backup success, connectivity and OS inventory from a connected RMM tool, and alerts by email or text; today alerts are shown inside Pion
Identity / Cloud
Simulated directory · live governed requestsReads today
Identities, their reported risk and its reason, privileged roles, MFA registration and application access
Next
Reading the client's own directory — sign-ins and risk signals — and containing an identity there; today the directory is simulated
Reports
Live — governed recordsReads today
Decided records, their packages, chain integrity, recorded activity
Next
Scheduled and emailed reports, branded documents, period comparison and narrative summaries; today a report is a package another party can verify
Executive Workspace
Live records · simulated estateReads today
Every client's sites, tickets, field visits and governed requests
Next
Contract, financial and SLA figures, trends and scheduled or emailed reports; today every figure is read from the records as they are now
Client Onboarding
Live records · discovery sample or importedReads today
Client profiles, sites and their codes, discovery runs, site plans and the devices placed on them
Next
Filling a site from the client's own tools — an RMM or monitoring tool, a SIEM, a SCADA historian — or a collector on its network; today a site is filled by the sample or an imported list
Settings
Live — read-only configurationReads today
The session, the approval policy the server enforces, and the boundaries
Next
Changing a setting — who may approve what — as a governed request, decided by someone other than who raised it and recorded like any other; today this page reads what the server enforces
Authorization Gate
Live — governed recordsReads today
The governed queue, decisions, transitions, evidence, and the re-reads recorded after an approved action
| Section | Reads today | Next |
|---|---|---|
| OverviewLive records · simulated estate | Every section below, plus the governed records behind them | Trends across periods — today each figure is read from the record when the page is read, and no earlier value of it is kept to compare with |
| Control CenterSimulated estate · live navigation | The asset estate — company, site, system, device — simulated, or reported read-only by the Azure connector — and the requests that name one | A health score, a map of the sites and trends — today no scoring model, site location or history is kept |
| SOC OperationsPlatform records only · live governed requests | Security requests, recorded refusals, chain integrity | Telemetry from the client's SIEM and EDR — events, traffic, exposed ports, cloud findings — and a posture score; today this page reads the platform's own records |
| SCADA OperationsSimulated estate · live governed requests | Systems, device readings, cascade dependencies | Availability, control-loop health, interlock state and process trends from an OT connector; today the equipment and its readings are simulated |
| Digital TwinSimulated estate · readings against stated references | Readings against the references their records state | The predictive half — confidence, horizon, wear, remaining useful life — and a layout drawn from a site's plan; today no predictive model runs, and devices are placed on the plan in Onboarding |
| RMM OperationsSimulated estate · live tickets and requests | The managed fleet and its health, service tickets and their history, field visits, technicians' work | Patch compliance, backup success, connectivity and OS inventory from a connected RMM tool, and alerts by email or text; today alerts are shown inside Pion |
| Identity / CloudSimulated directory · live governed requests | Identities, their reported risk and its reason, privileged roles, MFA registration and application access | Reading the client's own directory — sign-ins and risk signals — and containing an identity there; today the directory is simulated |
| ReportsLive — governed records | Decided records, their packages, chain integrity, recorded activity | Scheduled and emailed reports, branded documents, period comparison and narrative summaries; today a report is a package another party can verify |
| Executive WorkspaceLive records · simulated estate | Every client's sites, tickets, field visits and governed requests | Contract, financial and SLA figures, trends and scheduled or emailed reports; today every figure is read from the records as they are now |
| Client OnboardingLive records · discovery sample or imported | Client profiles, sites and their codes, discovery runs, site plans and the devices placed on them | Filling a site from the client's own tools — an RMM or monitoring tool, a SIEM, a SCADA historian — or a collector on its network; today a site is filled by the sample or an imported list |
| SettingsLive — read-only configuration | The session, the approval policy the server enforces, and the boundaries | Changing a setting — who may approve what — as a governed request, decided by someone other than who raised it and recorded like any other; today this page reads what the server enforces |
| Authorization GateLive — governed records | The governed queue, decisions, transitions, evidence, and the re-reads recorded after an approved action | — |
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. Beyond the closeout package, one report is built in this stage: the Executive Workspace's report, generated from the records. 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.
Next: Scheduled and emailed reports, branded documents, period comparison and narrative summaries; today a report is a package another party can verify.
- 6
- stages in the governed chain
- 14
- steps in the resolution path
- 5
- lifecycle transitions permitted
- 9
- parts in a closeout manifest
- 6
- approver roles
Build on the systems your team already uses
Pion is designed as a command layer above existing security, service, remote management, cloud, and operational systems. A deployment begins by identifying the information and actions needed for a specific use case.
The initial scope should state which systems remain authoritative, which connector capabilities are available, what can only be observed, and which actions require approval. External connectors beyond a read-only one for Azure are not built in the current stage.
Start with a defined scope
Choose the sites, systems, incident classes, and data sources that matter to the first operational problem.
Establish the operating boundary
Document identity, permissions, approved actions, rollback requirements, and evidence before enabling a connected workflow.
Expand after validation
Add scope only when the integration, operating controls, and client value have been demonstrated.
The difference to evaluate
This comparison describes a fragmented manual workflow and Pion's design intent. Existing products and implementations vary. The pilot should establish which differences matter in the client's environment.
Work to complete
Investigation
Fragmented manual workflow
Collect context separately from each tool.
Pion design intent
Retain client, site, system, and device context through the investigation.
Work to complete
Authorization
Fragmented manual workflow
Reconstruct approval scope from messages or separate records.
Pion design intent
Bind the requested action to a role, reason, target, and evidence.
Work to complete
Closeout
Fragmented manual workflow
Assemble the action history and report after the event.
Pion design intent
Carry the decision and evidence into a traceable closeout record.
Work to complete
Evaluation
Fragmented manual workflow
Measure activity in individual tools.
Pion design intent
Measure the complete workflow, its outcome, and its operating cost.
| Work to complete | Fragmented manual workflow | Pion design intent |
|---|---|---|
| Investigation | Collect context separately from each tool. | Retain client, site, system, and device context through the investigation. |
| Authorization | Reconstruct approval scope from messages or separate records. | Bind the requested action to a role, reason, target, and evidence. |
| Closeout | Assemble the action history and report after the event. | Carry the decision and evidence into a traceable closeout record. |
| Evaluation | Measure activity in individual tools. | Measure the complete workflow, its outcome, and its operating cost. |
Differentiation must be established against the client's actual alternatives. This is not a claim that competing products lack these capabilities.
Begin where coordination carries a measurable cost
The first commercial focus is managed service providers and infrastructure operations teams. Both coordinate multiple tools, assets, people, and approval requirements.
Managed service providers
A priority setting for testing a repeatable workflow across client accounts, sites, incidents, and service records.
Explore this use caseInfrastructure operations
A priority setting for evaluating service restoration, controlled changes, and evidence where disruption has operational consequences.
Explore this use caseAdditional operating environments
Manufacturing, energy, government, military, healthcare infrastructure, and enterprise use cases require domain-specific integration and validation.
Markets named here describe intended applications. They do not identify customer deployments, certifications, or completed integrations.
A useful pilot begins with an agreed business question
Select a bounded operating problem, establish its present cost and effort, and define what would justify continuing. Pion should be evaluated against those measures as connected capabilities become available.