A working prototype that asks one question: if Neuron becomes the system of operational intelligence, how should that intelligence pass between people? Between shifts, and between the model and the operator who is accountable for what it recommends.
Teserac's Command Center says the shift starts here. Inside that sentence is a human problem that mission critical infrastructure cannot avoid: at 19:00 an operator goes home and another one takes responsibility for the building. What changed in the last twelve hours? What was investigated and deliberately left open? What must the incoming operator not touch, because someone already decided otherwise and had a reason?
Neuron already holds the raw ingredients. Telemetry, topology, incidents, procedures, history, and the decisions operators make. The gap is not data. It is that most systems preserve what happened and lose why a person chose what they chose. Teserac's own positioning names a shrinking skilled workforce as a core industry problem. Capturing resolved tickets for future search is one answer. This prototype proposes a stronger one.
Do not only preserve knowledge for later search. Put the right knowledge into the exact moment responsibility changes hands.
The same idea extends to the model. When Neuron recommends something consequential, the operator is the one accountable. So the recommendation, the decision, and the reasoning behind the decision all belong in the same record that the next shift inherits.
Not the facility. Not the fleet. One person, at one moment, with a building to answer for.
The organization buying this runs mission critical facilities around the clock. Colocation providers, hyperscale operators, and enterprises with their own data halls. What they sell is uptime, and uptime is defended by a small team that is physically present twenty four hours a day.
The user is one of those people, and specifically the one arriving rather than the one leaving. Every design decision in this prototype was made for them.
Three things, and only one of them is a data problem.
That third point is why the decision record has a why field and a who field, and why deferring a recommendation forces you to name the trigger that brings it back. The format is not a documentation exercise. It is the specific shape of the failure it prevents.
This profile is built from public material and reasoning. I have not interviewed a single operator, so it should be read as a stated hypothesis rather than a finding.
Each of those is answerable in one conversation with one operator, which is why that sits at the top of what comes next.
Not a suite of screens. A single path an operator would actually walk at the top of a shift.
The most directly relevant opinion I can offer, given where the product has already been.
Neuron started as a chat interface and moved away from it. I think the reason is specific and worth naming. A chat box asks the operator to supply the question at the exact moment they have the least time and the least certainty about what to ask. And a chat answer is a dead end. It does not attach to an asset, it does not persist, and the next shift cannot inherit it.
The replacement is not a different text box. It is three rules, and every AI surface in this prototype follows them.
What chat is genuinely good at is the open ended question nobody anticipated. That is a real strength, and it is why the position is "wrong default" rather than "wrong idea". A command bar that takes natural language and returns a reconfigured interface, rather than a paragraph, would keep that strength without the weaknesses. I scoped it out and did not build it.
Every recommendation displays three tiers: what Neuron does alone, what needs approval, and what it must never touch. On the load transfer, "initiate the transfer" and "place the unit in bypass" are both rendered struck through.
Raising an alert threshold is one click, and the dialog says so. Transferring critical load requires four pre flight steps acknowledged and the asset name typed back before the button unlocks.
The choices are Approve, Defer with a trigger, Approve with changes, and Reject. Deferring requires naming the condition that would bring it back. Rejecting or modifying requires a reason.
An earlier version of this prototype taught the domain inside the operator tool, with the same knowledge check attached to every asset. That was wrong. Real operators know what a power distribution unit is. The teaching material is now a separate overlay in its own color, off by default.
A pinned card attaches to the asset it concerns, travels with it when the node moves, counter scales so its text stays legible at any zoom, and collapses to a pill when zoomed out.
Amber was carrying two jobs badly. Splitting them was the highest value small change in the build.
Healthy equipment, and decisions that have been made and closed.
A state of the world. Something is drifting or loaded, and it is worth watching.
A state of the work, not the plant. The asset pulses and says "Needs your review" on the card. Deciding clears it.
The proof case is Rack R-42. It sits at 92 percent of its power budget, so it stays amber for the whole walkthrough. Nobody owes a decision on it. Meanwhile UPS-A1 and SWGR-A are red, because a recommendation is sitting there undecided.
The result is that the canvas shows where human judgment is outstanding, not just where the plant is unhappy. Both counts appear in the toolbar, and the red survives at fit to view zoom and in the minimap. Deciding both recommendations turns every red outline green by the end of the demo.
Stack is React 19, TypeScript, Vite, and React Flow. The interesting parts are not the stack.
The first version rendered nodes that looked draggable and were not. React Flow only writes a position change back to its own store when you use its uncontrolled mode. In controlled mode it hands the change to your callback, and this app passed nodes with no callback, so every drag was computed and discarded.
The failure preview removes the selected asset from the graph and re runs reachability from the utility source. Anything that becomes unreachable loses power. Anything downstream that is still reachable is held by a redundant path.
Pinned cards could have been added as React Flow nodes with a parent relationship. Instead they render through the viewport portal and position themselves from their anchor's coordinates.
The deployment config rewrote every unmatched path to the app shell. So a request for an asset that no longer existed returned 200 with an HTML body instead of a 404. During a deploy rollover a cached page asked for an asset hash that had already rolled, the browser refused the response on its content type, and the app rendered nothing.
Persisting pinned widgets required persisting decisions too. A restored decision card with no decision behind it would render empty. Orphans are dropped on load, and stored entries are validated against known asset ids before use.
Graph nodes are keyboard selectable with a visible focus ring, and Enter or Space updates the panel. The asset tabs follow the standard pattern, so only the active tab is in the tab order and arrow keys move between them. Dialogs trap focus and return it on close. Quiz feedback is announced through a live region. Motion respects the reduced motion preference.
In order. The first item is not a feature.
An open question, explored rather than answered. Nothing below is built.
If a facility were minutes from going down, and the only person on site was the newest member of the team, could an intelligence layer carry them? Or is software of this kind permanently reserved for people who already hold the expertise?
The question is not specific to data centers. The same shift is running through tax preparation, investing, software, and medicine: expertise is scarce, software is cheap, and capability keeps moving toward people with less training. Physical AI is doing the same thing to machines. It is worth asking directly whether critical facilities are part of that trend or an exception to it.
My reading is that the question is badly posed, and that fixing the framing produces a more useful answer than arguing about the original.
Any operational act contains four capabilities. Expertise is not spread evenly across them, and software does not move them equally. Treating them as one thing is what makes the debate circular.
So the honest answer is split. Detection and diagnosis transfer now. Decision transfers under conditions. Execution does not transfer at all, and should not. Any pitch that skips this distinction will not survive a conversation with someone who has stood in front of an energized switchboard.
Four software cases, ordered by how completely the transfer worked.
Physical AI has run the same experiment on machines, and the results are sharper.
The driver assistance case is the one that should worry anyone building this, because Neuron's approval gate is a handback. The system carries the situation, then stops and asks a human to take control at the least convenient moment. That is the exact shape that has proven hardest to make safe in vehicles.
Across every case above, one pair of properties predicts the outcome: how reversible the mistake is, and how quickly the consequence arrives. Tax errors are reversible and slow, so the transfer was total. Defibrillation is irreversible and immediate, so the scope was cut to almost nothing and the remaining act was made impossible to get wrong.
Hand capability downward in proportion to reversibility.
This prototype already applies that rule to actions: raising an alert threshold is one click, transferring critical load requires every pre-flight step acknowledged and the asset name typed back. Extending it to people is the same rule with a second input. The gate becomes a function of the action and of who is holding it.
Lisanne Bainbridge described this in 1983, in a paper called Ironies of Automation. The more a system automates, the more the remaining human role shrinks to exactly the situations the automation could not handle. Those are the hardest situations. And the human now has far less practice, because the routine work that built their intuition has been absorbed.
Air France 447 is the reference case. The autopilot disengaged after the airspeed sensors iced, and the crew's manual handling had degraded. Three Mile Island is the older one: the information was present and presented so poorly that trained operators reached the wrong conclusion.
Applied here, the risk is direct. If Neuron absorbs everything routine, it may produce operators who never build the pattern library that made the retiring generation valuable. A tool aimed at the expertise shortage can deepen it. That is a real tension in this product, not a rhetorical one.
In an actual emergency, the newest person's realistic contribution is almost never executing the fix. It is three things: do not make it worse, buy time, and get the right human there faster with better context.
The third one is where software changes the outcome, and this prototype already contains the artifact for it. The decision record is a handoff pointed forward in time. Pointed sideways it becomes an escalation packet: what changed, what I saw, what I already tried, what I did not touch and why. The expert arrives with seconds of ramp-up instead of twenty minutes.
That reframes the goal from novice as hero, which is not credible, to novice as competent first responder, which is. It is the defibrillator pattern. Narrow the scope until the remaining decision is one an untrained person can make correctly, make the harmful path unavailable rather than discouraged, and keep the human for the part the machine cannot do.
Each of these is falsifiable, which is the point of writing them down rather than asserting a conclusion.
The deeper question sits underneath all four. Does an intelligence layer raise the floor, or lower the ceiling? Raising the floor is the pitch. Lowering the ceiling is the risk: experts atrophy, and the system's model quietly becomes the limit of what anyone thinks to consider. Designing for the floor without capping the ceiling means the expert must always be able to see past the recommendation, into the raw signals, the rejected hypotheses, and the assumptions. Which turns the challenge surface from a refinement into a requirement.
I built this with an AI pair. I wrote the plans and the acceptance criteria, gated each phase before the next one started, inspected every result in a real browser, and made every product and design call. The AI wrote most of the code under those criteria.
I mention it because it is how the work actually happened, and because the interesting artifact is not the code. It is the sequence of decisions: what to build, in what order, what to refuse, and which of my own earlier choices to throw away. The quiz attached to every asset and the free floating learning panel were both mine, and both were wrong, and cutting them made the product better.
Verification was browser first throughout. A passing type check and a green build tell you the code compiles. They do not tell you a node can be dragged, that a gate actually blocks, or that the deployed site renders. Each of those was checked by driving the real interface and measuring the result.
The repository README carries a walkthrough written for a live demo, a code map, and the same positions stated for a reader rather than a viewer. Source is at github.com/trulou1028/neuron-shift.