Blueprint ofAshley Sum

Roadside equipment was distributed across multiple platforms that identified, monitored and operated the same physical devices differently — an enterprise maintenance register, a traffic control system, an IoT telemetry platform and a network monitor. Equipment records, network alarms, traffic events and maintenance activity could not be correlated reliably, producing duplicate identities, unactionable alarm volumes and fragmented operational workflows.

Analyzed live systems, source code, APIs, operational records and existing architecture documents to distinguish implemented capabilities from proposed designs. Identified gaps in equipment identity, network topology, maintenance data, credential management and system ownership.

Developed end-to-end process flows covering device registration, commissioning, monitoring, fault detection, human verification, work-order creation, repair and closure. Defined system responsibilities and designed the maintenance workflow to require human approval before dispatch.

Designed a layered architecture connecting roadside telemetry, network monitoring, traffic operations and enterprise maintenance. Developed an Asset Hub that correlates system-specific identifiers and synchronizes equipment records into one operational view of each physical device. Implemented field-ownership and device-lifecycle rules, idempotent synchronization, dry-run defaults and validation that rejects an incomplete read rather than treating it as complete.

Diagnosed identity and data-quality defects across live systems, including duplicate identifiers, incomplete API responses and conflicting device states. Identified that reconciliation never read activation status, so devices switched off in the control system still counted as live in the register. Added the missing comparison and implemented explicit failure states for partial or conflicting data.

Deployed identity and fault correlation to production. 386 of 391 roadside devices carry one identity across the register, the control system and the network monitor, with no conflicts, gaps or duplicate codes, and 248 monitoring outages reduce to 24 actionable findings. The report-to-repair workflow is validated in staging and the Asset Console reads live systems; neither is deployed. Counts verified August 2026.

Established explicit ownership across operational, monitoring and enterprise systems. Integration alone could not resolve conflicting identities, incomplete records or authority boundaries.

A cloud point-of-sale system could talk to exactly one printer protocol, a single manufacturer’s dialect, and a printer that didn’t speak it failed badly rather than cleanly: it printed raw markup as receipt text instead of an actual receipt. The printers already mounted on site were not going to be replaced to fix that.

The manufacturer’s own compatible printer box wasn’t available to this deployment, and upgrading wasn’t on the table. A custom server-side module was ruled out because the hosting platform’s own installer refuses that kind of code with no file access to the server, and a VPN tunnel was rejected too, since it meant managing encryption keys and an always-on connection for something this narrow.

The point-of-sale software already renders every receipt to a bitmap in the browser and posts it, unauthenticated, to whatever address is configured for its one supported printer. The service impersonates that printer: it takes the address, decodes the bitmap it receives, and forwards it to whichever real thermal printers the site actually has, routed by a path in the destination URL since the platform hardcodes one printer identity for every destination.

Because the point-of-sale never re-draws the receipt for this path, whatever comes out of a printer is the same bitmap the screen showed, so drift between what a cashier sees and what prints is designed out of the path rather than merely tested against. Each destination printer gets its own delivery queue, so one stuck printer can never block deliveries to a healthy one.

It ran production print traffic on the store’s own machine, confirmed on paper by a manager who added a printer and watched a job route live. One issue remains open rather than fixed: a connection-handling edge case that is mitigated for now rather than properly resolved.

Comparing printer models directly got me nowhere. Once I stopped treating the hardware as the problem and targeted the shared protocol instead, picking a printer became a purchasing decision, not an engineering one.

Getting into a sport means asking questions with obvious answers to everyone but you: who drives for which team, who is number 11, why that lap mattered. Ask a chatbot and you get a fluent answer that may be entirely invented, which is worse than no answer when you have no way to check it. The idea was an assistant a newcomer could actually check.

Fetch the numbers first, then let the model write only from what a tool returned. An agent mode lets it choose which data tools to call across several steps. It is built against Formula 1 timing data, and the shape is deliberately sport-agnostic: the model never touches the data source directly, so another sport is another set of tools rather than a rewrite.

73 tests, all offline, with every external call fixtured, so the suite runs anywhere without a network or an API key.

Prompting the model to be careful did not hold. Only the structure did — it cannot cite a number it was never handed.

Python · OpenAI function calling · Typer · Jolpica-F1 · FastF1 · pytest

A company running recurring team meetings has its preparation scattered before and its notes scattered after. Each team keeps its own notes somewhere, the minutes are written from memory by whoever remembers to, and a month later nobody can find what was agreed.

One flow across three cooperating pieces: a web app where teams submit ahead and an admin reviews, records and presents; a local engine that turns the recording and the submitted notes into minutes against a chosen template; and an optional desktop recorder. Meeting status is derived from what has actually happened, never set by hand: collecting, recorded, draft, published.

The AI generation is opt-in and runs locally. The web app health-checks a bridge on the local machine; if it is not running, generation is disabled with a message that says so, and the entire structured flow still works. The model is an enhancement to the product, not a dependency of it.

Two row-level security failures, both fixed with definer-rights functions. The admin check queries the profiles table, and the policy guarding profiles calls the admin check, so without definer rights it recursed forever. Separately the signup trigger needed its search path pinned, or creating an account failed outright with a database error that said nothing useful about why.

Eight pages and no framework, with the pure helpers split out and unit tested.

Getting row-level security right was harder than building the features it protects. A policy that queried the same table it guarded recursed forever, and the fix was to move the lookup into a definer-rights function.

JavaScript · Supabase · PostgreSQL · row-level security · Python

Swim analysis tools want a subscription and a level of detail most swimmers cannot easily produce: sensors, stroke telemetry, somebody entering all of it. I swim, so I knew which numbers actually matter and which ones anyone can get with a stopwatch and a lane. The question was how much useful insight you can reach from only the easily measurable ones.

The only numbers it needs are the times at 15m, 25m, 35m and 50m. Every 50m pool already marks those — the 15m line at each end and the midpoint — so anyone on the side can capture them with a stopwatch. No sensors, no telemetry, nobody entering data a swimmer cannot produce. From those four times it derives each split and the velocity between marks, and compares a swim against a target pace and against previous swims. Stroke rate needs a stroke count entered alongside them.

Deployed and running, with a recorded demo. I use it on my own swims.

I swim the sport, so I already knew which numbers mattered, and that turned out to be most of the design work. Deciding what a race is actually made of took far longer than building the charts.

Flask · SQLite · Bootstrap · Chart.js · Python