Understand
Correlate conditions and retain the selected client, site, system, and device context.
First version live: drafts beside the decision
Pion | Reasoning layer, first version live
Reasoning in context. Authority under control.
EALAI is the reasoning layer within Pion. Its first version drafts the likely cause and a proposed response for a request at the gate. Its intended role is wider: to help people understand conditions, prepare responses, and retain evidence while production authority remains governed.
First version only: EALAI drafts analyses in Pion; its wider reasoning is not built in this stage. The walkthrough shows drafts recorded from Pion.
Reasoning that supports an accountable workflow
EALAI is the reasoning layer within Pion. It is intended to connect relevant conditions, explain likely cause, prepare response options, and help assemble evidence and reporting.
Its first version is live in Pion: for an open request, EALAI drafts the likely cause and a proposed response from the platform's own records, which it must cite. It is text only and cannot act; a person decides at the gate, and the decision record names the draft that was on screen. Each citation opens onto the record as EALAI was given it, and Pion keeps a record of what followed each draft: the decision, the draft in view and the re-read afterwards. The walkthrough shows drafts recorded from Pion. The other functions described here are design intent.
Prepare
Explain the evidence, compare response options, and prepare the information an authorized person needs.
Support and record
Assist a governed workflow and carry the relevant context into verification and reporting.
A recommendation does not authorize a production change. Identity, role, policy, permitted capability, and the applicable approval conditions must govern any future connected action.
Evaluate the outcome the reasoning makes possible
A useful reasoning layer should improve the work around an operational problem. The planned measures include investigation effort, the quality of the decision package, reporting effort, and verified recovery within an authorized scope.
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.