Building Neuron Shift

Premise

The shift starts here. So what actually happens at that moment?

At 19:00 one operator goes home and another takes responsibility for the building. What changed? What was investigated and deliberately left open? What must the new operator not touch, because someone already decided otherwise?

Neuron already holds the telemetry, topology, incidents, and procedures. The gap is not data. Most systems keep what happened and lose why a person chose what they chose.

Do not only preserve knowledge for later search. Put the right knowledge into the exact moment responsibility changes hands.

The product thesis this prototype tests

The same applies to the model. Neuron proposes, the operator decides, and the decision and its reason become the record the next shift inherits.

Who it is for

The operator who takes control at 19:00

One person, arriving rather than leaving, with a building to answer for.

The role: Critical facilities technician or shift engineer. Often from a trade or a military route.
The rhythm: Twelve-hour shifts. Handover happens twice a day, every day. It is the most repeated moment in the operation.
Tools: A building management system, a power monitoring system, work orders, and a shift log that is often a notebook.
The pressure: The most experienced people are retiring, and what they know was never written down.

Why the handoff is hard

The window is short. Fifteen to thirty minutes. Nobody reads a twelve-hour history.
The valuable part is what was left alone. The outgoing operator knows what they looked at and chose not to touch. That never survives a verbal handover.
The costliest mistake is undoing a decision. Touching something a colleague left in place on purpose is how a stable situation becomes an incident.

What I do not know

This profile comes from public material and reasoning, not interviews. Whether six fields is the right shape, and whether "what you need to do" reads as help or as a peer giving orders, are questions for one conversation with one operator.

What is built

One workflow, end to end

A single path an operator would walk at the top of a shift.

Shift brief: Three inherited items, each with a six-field record: what changed, what we know, what was decided, why, who decided, and what you need to do.
Power path: A one-line diagram from the utility feed to the racks. Power visibly flows along it.
Ask: Questions Neuron already answered for the selected asset. No prompt to write.
Impact: What a failure would do right now, computed from the topology and drawn on the graph.
Decisions: Four ways to respond to a recommendation, with friction that scales with how hard the action is to undo.
Learning layer: Definitions and a self test in their own color, off by default.
Guided tour: Seven steps for a visitor exploring alone.

The shift brief. Item 01, UPS-A1 battery impedance, is open and shows six rows from what changed to what you need to do, with an Open on graph button. Below it, a list of what changed since 19:02. — The shift brief opens on load. Each item keeps the reasoning, not only the data.

Position

Chat is the right fallback and the wrong default

A chat box asks the operator for the question at the moment they have the least time and the least certainty about what to ask. Its answer does not attach to an asset, does not persist, and cannot be inherited. So every AI surface here follows three rules.

It attaches to objects. Selecting an asset is the query.
Its output is interface state. "What happens if this fails" is answered by drawing on the graph.
What you accept or override joins the record. That makes AI reasoning inheritable.

Chat is still good at the question nobody anticipated. A command bar that returns a reconfigured interface instead of a paragraph would keep that strength. I scoped it out.

Design decisions

The calls, and what each one argues against

The decision dialog for transferring critical load. It lists what Neuron does alone, what needs approval, and what it never does, with the last two struck through. Approve is selected, four pre-flight checks are ticked, and UPS-A1 is typed into the confirmation field. — A consequential approval: four checks and the asset name typed back.

Autonomy is shown, not implied

Every recommendation lists what Neuron does alone, what needs approval, and what it must never touch. WhyA promise about behavior builds more trust than a confidence score.

Friction scales with reversibility

Raising an alert threshold is one click. Transferring critical load takes four checks and the asset name. WhyA one-click approve on a consequential action invites rubber stamping.

Approve and Reject is the wrong pair

The choices are Approve, Defer with a trigger, Approve with changes, and Reject. Deferring names what brings it back. Overriding requires a reason. WhyIn operations the common right answer is "not yet". And an override is an expert disagreeing with the model, which is exactly the knowledge the industry is losing.

The learning layer is not the product

An earlier version taught the domain inside the operator tool. That was wrong. Real operators know what a PDU is. The teaching now lives in a separate violet layer, off by default. WhyI am not the user. My training wheels should switch off.

Pinned cards anchor to assets

A recorded decision pins itself beside its asset, moves with it, and stays readable at any zoom. NextThe pinned arrangement should travel in the handoff too.

The power path runs top to bottom

The first layout ran left to right in a tall canvas and rendered at about sixty percent zoom. One-line diagrams are usually drawn source at the top, load at the bottom. Following that convention made the graph readable on a laptop.

Motion carries state, never decoration

Power flows along live lines and stops where a failure would cut it. The graph powers up when you take the shift, marking the moment responsibility changes hands. Recording a decision settles one green ring on the asset.

The asset panel for Switchgear SWGR-A after approval, with the violet learning layer below it explaining what switchgear is. — The learning layer sits below the operator panel, in its own color.

The unguided visitor

Designing for someone nobody is walking through it

The first version assumed I would present it. In a portfolio, nobody does.

A visitor arrives from a link, has a couple of minutes, and does not know the domain. So the prototype makes its own argument. On a first visit, a guided tour opens beside the shift brief and covers the core ideas in seven steps.

The guided tour on step 5 of 7. A light card reads: now compare a single point of failure. PDU-05 is ringed on the graph, both racks below it are dark with struck-through readings, and the task Select PDU-05 on the graph is checked off. — Step 5 of 7. The card places itself where it hides the fewest assets, so both dark racks stay in view.

Every step asks for a real action. A ring points at the real control. A tour that describes buttons is a slideshow; one that asks you to press them lets the product demonstrate the claim.
Steps complete on state, not on clicks. The tour moves on when the app reaches the state a step asks for, however the visitor got there. Exploring ahead is never punished.
"Do it for me", with one exception. Every task can be performed for you, except the consequential approval. The tour opens that dialog but will not tick the checks, because that would contradict the point of the step.

Phones get their own page

The console needs a laptop-sized screen. Below 1000 pixels, a visitor sees the idea, what the colors mean, and a link here, instead of a squeezed layout.

The phone page: a small power path diagram, the headline what a night-shift operator inherits and what they still owe, and three lines explaining red, amber, and deciding.

Color semantics

One meaning per color

The chrome carries no hue at all. Color only ever means state.

Green: flowing, or decided

Healthy power, and decisions that were made.

Amber: a condition to watch

A state of the equipment.

Red: a person owes a decision

A state of the work, not the plant. Deciding clears it.

Gray dashes: power would be lost

Not a color, because loss of power is an absence.

The proof case is Rack R-42. It sits at 92 percent of its budget and stays amber, because nobody owes a decision on it. The canvas shows where judgment is outstanding, not just where the plant is unhappy.

The power path at rest. SWGR-A and UPS-A1 are outlined in red with Needs your decision. Rack R-42 reads 18.6 kW in amber.

The same power path after both recommendations were approved. No red remains. Each asset reads Decided by you, and a green Approved card is pinned beside each one.

Deciding both recommendations clears every red outline. Rack R-42 stays amber throughout.

Losing power is shown as absence, not as red

An earlier version drew the failure preview in dashed red. That gave red a second meaning right after the visitor learned it means "your call". Now the flow stops, the line turns to gray dashes, and the asset goes dark. A dark rack is what losing power looks like.

Failure preview for UPS-A1. Its lines are dashed, but PDU-05 and both racks are outlined in green and labeled Held by redundancy.

Failure preview for PDU-05. Both racks below it go dark with dashed outlines, struck-through readings, and the label Loses power.

Redundancy holds everything below UPS-A1. PDU-05 has no twin, so both racks go dark. Neither result is written by hand.

Technical decisions

Where the engineering went

React 19, TypeScript, Vite, and React Flow. The interesting parts are not the stack.

The nodes were lying about being draggable

React Flow in controlled mode hands position changes to a callback, and the app passed none, so every drag was discarded. I found it by reading the library's triggerNodeChanges source, then confirmed it by dragging a node 86 pixels and measuring that it had not moved. PrincipleNever ship an affordance you cannot honor.

Impact is computed, not written

The preview removes the selected asset and reruns reachability from the utility source. Unreachable means it loses power. Still reachable downstream means redundancy holds it. The numbers stay honest if the topology changes.

A deploy bug that would have blanked the demo

The host rewrote every unmatched path to the app shell, so a missing asset returned HTML with a 200. During a rollover the browser refused it and rendered nothing. Assets now return a real 404, hashed files are immutable, and the entry page revalidates. I caught it by loading the deployed site and reading the console, not by trusting a green build.

Accessibility as part of the work

Nodes are keyboard selectable. Tabs follow the standard arrow-key pattern. Dialogs trap focus, and the tour card joins that loop. All continuous motion stops under the reduced motion preference, and every colored state is also named in text.

What comes next

Where I would take this

In order. The first item is not a feature.

Put it in front of one real operator. Six fields felt right to me. Nobody who runs a facility has told me so.
An authoring flow for the outgoing operator. How do you get a tired operator at 18:55 to write one honest sentence about why? Everything depends on that.
A decision timeline. Scrub from the first anomaly to now and watch model confidence and human decisions move together.
Challenge this assessment. Show supporting, contradicting, and missing evidence. Trust needs a way to argue back.
Detail that resolves with zoom. Eight assets fit on a laptop. A real site has hundreds.

Deliberate limits

What this is not

Every value is simulated, and the interface says so.
No model is called. Reasoning and confidence figures are written and labeled illustrative.
Generators are not modeled, and the impact panel says so.
Domain assumptions are flagged on the assets where I was least sure, so an expert can correct them.
No server, no real telemetry, and no phone console. Persistence is local storage only.
I do not claim to know data center operations. I claim to have learned enough to build something an expert can correct.

Exploration

Can someone without expertise save the building?

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 were the newest on the team, could an intelligence layer carry them?

Tax preparation, investing, software, and medicine all moved capability toward people with less training. I think the question is badly posed, because any operational act is four capabilities, and software moves them unequally.

Detection: TransfersA newcomer with instruments notices more than an expert without them.
Diagnosis: TransfersFor failures the system has a model of. Not for the novel, compound ones that take buildings down.
Decision: PartlyThe deciding input is often invisible to the system: a technician already in the cabinet, a migration tonight.
Execution: Does notArc flash injures and kills. Qualified-person rules exist because people died establishing them.

Across fields, one pair of properties predicts whether the transfer works: how reversible the mistake is, and how fast the consequence arrives. Code assistants moved fastest because version control makes mistakes reversible. Driver assistance struggled at the handback, where the human is least practiced at the hardest moment. Neuron's approval gate is a handback too.

Hand capability downward in proportion to reversibility.

The counter-effect is Bainbridge's Ironies of Automation: the more a system absorbs the routine, the less practice people get for the exceptions. A tool aimed at the expertise shortage can deepen it.

So the realistic goal is not the novice as hero. It is the novice as competent first responder: do not make it worse, buy time, and get the right expert there faster with context. The decision record already does that pointed forward in time. Pointed sideways, it becomes an escalation packet.

Process

How it was built

I built it with an AI pair. I wrote the plans and acceptance criteria, gated each phase, checked every result in a real browser, and made every product and design call. The AI wrote most of the code. The interesting artifact is the sequence of decisions, including which of my own ideas to throw away.

A second pass redesigned it for my portfolio. The audience changed from an interviewer with me in the room to a visitor on their own. That one change drove the rest: an identity of my own, a graph that reads at a glance, motion that marks state, the guided tour, and a phone page. The principles and visual system are in the repository as PRODUCT.md and DESIGN.md.

React 19 TypeScript Vite React Flow Motion IBM Plex Sans and Mono Phosphor Icons OKLCH design tokens Vercel

Source is at github.com/trulou1028/neuron-shift.