Skip to content

Pion | Managed service providers

Coordinate operational work across client accounts.

Pion is being developed for teams that move between client environments, service records, remote management tools, and reporting obligations.

Pion · RMM OperationsSimulated estate · live tickets and requests
Screenshot of the running platform. Label: Simulated estate · live tickets and requests.

Start with a defined operational use case

A suitable evaluation scope

A defined incident workflow across a small set of client sites.

Measures to agree

Handling effort, escalation share, report preparation time, and accounts supported per operator.

Pion remains in development. These are intended applications, not customer deployments or claims of available production integrations.

Where it shows in the platform

The sections that carry this market's work.

Each label is the platform's own: green where every row is a record it wrote, amber where the estate is simulated.

RMM Operations

Simulated estate · live tickets and requests

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

Authorization Gate

Live — governed records

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

Reports

Live — governed records

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

SOC Operations

Platform records only · live governed requests

Governed security actions and the platform's own records — requests, refusals, and tamper-evident chains.

Reads · Security requests, recorded refusals, chain integrity

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

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.

Simulation

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.

Not yet implemented

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.

Planned

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.

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.