- Entry date
- 1 September 2025
- Category
- Hardware
- Access
- 🔓 Public
Not everything in this portfolio is a web app — this is direct, low-level hardware control in C, deployed and still running.
- C
- language, plus shell scripts and a systemd unit
- SMBus
- hardware communication bus driving the LED indicator
- Deployed
- running on embedded railway-adjacent hardware
Honest evaluation
Deployed and still running as exactly the narrow monitoring service it set out to be, with no scope creep added after launch.
What would prove or disprove it further
What would prove or disprove it further: the test is really a non-event to watch for — if this service is later found to have grown new responsibilities (state-changing actions rather than reporting, or a network-facing control surface), that would be the point the "monitor, not controller" claim actually broke.
The evidence — full reasoning behind the verdict
Verdict: proven. The claim here was really about discipline: build a small, low-level monitoring service — not a controller, not a dashboard, not a safety-critical control function — and keep it exactly that narrow. A deployed, still-running C systemd service that watches network state and drives an LED over SMBus, and nothing more, is direct evidence the scope held.
The proof isn't a metric, it's an absence: no dashboard got bolted on, no remote telemetry got added "while we're in there," no feature creep happened after the service shipped and did its one job reliably. In a portfolio where the more common failure mode is scope growing until a project needs a cull, a small piece of embedded C that has simply kept running, unchanged, since deployment is itself the evidence for the claim.
Most of this archive is web applications and AI platforms. This entry is neither — it's a small piece of C running on embedded hardware, included precisely because the record should show the full range of what actually gets built here.
What it was
A systemd service for embedded, railway-adjacent hardware that monitors network-interface status and drives a physical LED indicator over SMBus — a low-level hardware communication bus — so that an operator can see network health at a glance without opening a laptop.
What we built
Shipped & measuredA small, working service written directly in C, packaged as a systemd unit alongside supporting shell scripts. It watches network-interface state and translates it into LED behaviour via SMBus calls to the indicator hardware — the kind of direct, close-to-the-metal control that most of this portfolio's web-and-AI work never touches.
What we learned — including the honest negative(s)
The value of this entry is contrast. Everywhere else in the archive, "production code" means a deployed web service or an API. Here, production code means C compiled for a specific embedded target, talking to a physical bus, controlling a physical light — arguably the lowest-level code anywhere in the portfolio that is genuinely in production, as distinct from the educational bootloader/kernel work done purely to learn.
The honest edge is scope, stated without inflation: this is a monitoring and indicator service, not a safety-critical control function. It doesn't make decisions or actuate anything with consequence beyond the LED itself — it reports state, reliably, and nothing more. That narrowness is a deliberate choice, not a limitation to apologise for.
Where it went / status
Deployed and still running. No further feature work is claimed for it — it does one small job, does it reliably, and has needed nothing else since.
That narrowness is worth dwelling on a moment longer, because it cuts against a habit that shows up elsewhere in this archive: the temptation to keep adding scope to a working thing. This service was left alone on purpose once it did its one job well — no dashboard was bolted on, no remote telemetry added "while we're in there," no feature creep. In a portfolio full of projects that grew until they needed a cull, a small, finished, unglamorous piece of embedded C that has simply kept running, unchanged, is its own quiet counter-example.
What is still open — kept visible
The honest edges, next to the wins. This is what turns 🔬 into 🟢 — honestly.
- Small in scope by design — a monitoring/indicator service, not a safety-critical control function.
- No web UI, no dashboard, no remote telemetry — deliberately minimal, matching the hardware it runs on.
Where this connects
Sources
- vocabotics project audit — Network LED Monitor (C systemd service, SMBus, deployed), Sep 2025vocabotics internal project history · as of September 2025