HIVE OS — Industrial Operations Intelligence

The problem

HAEEV needed a trustworthy operational picture across 15 machines and seven production areas without replacing existing equipment or giving experimental software control of machine motion. The core problem was turning uneven factory evidence—machine logs, telemetry, cut lists, scans and operator input—into decisions that people could understand, verify and safely act on.

My contribution

1. 01

   Architected and built the Python, FastAPI, SQLite and React system, including the live dashboard, REST/SSE interfaces and the factory data model.

2. 02

   Created an observation-first integration layer for Cabinet Vision exports, Maestro machine logs and commissioned MQTT, Modbus TCP and OPC-UA telemetry.

3. 03

   Implemented evidence-gated OEE, production-loss accounting, WIP and flow intelligence, predictive control, maintenance, warehouse and production-planning workflows.

4. 04

   Designed a governed autonomy layer that can shadow, recommend or approve reversible order-release decisions while remaining technically separated from PLCs, CNC controls and machine safety functions.

5. 05

   Built an offline Windows deployment and recovery path for the factory central PC and machine agents, including mutual-TLS device identities, diagnostics, backups and rollback.

Technical challenges

1. 01

   Normalising incomplete, duplicated and differently timestamped evidence without presenting uncertain data as production truth.

2. 02

   Connecting legacy factory software and machines through read-only, site-commissioned interfaces that fail safely when mappings or signals are unverified.

3. 03

   Making advanced scheduling and autonomy useful while preserving human approval, traceability and a hard boundary around machine control.

4. 04

   Packaging the complete platform for a Windows factory environment that may need to install, operate and recover without internet access.

What I learned

1. 01

   Industrial intelligence depends on evidence quality and operational definitions before it depends on sophisticated models.

2. 02

   A useful factory system must explain why a metric or recommendation is ready—and why it is still pending when evidence is weak.

3. 03

   Safety boundaries, conservative defaults and operator authority are architectural requirements, not final-stage compliance work.

4. 04

   Deployment, recovery and commissioning are part of the product when software has to survive on a real factory floor.

Potential next steps

1. 01

   Commission each machine passport, route, cycle model and telemetry contract against physical factory evidence.

2. 02

   Run the release controller in shadow mode and compare its decisions with named supervisors before enabling supervised authority.

3. 03

   Calibrate production forecasts and improvement experiments with completed-shift data from the live factory.