I built CutLine to measure a closure without pretending to predict traffic

Mascottz — Sun, 04 Oct 2026 13:22:52 +0000

I started CutLine with a narrow question: if i remove one street segment from a recorded graph, how much does the shortest route change, and which nodes remain reachable? i wanted a small, inspectable experiment rather than a traffic model dressed up as a map.

I keep the claim small

I use a frozen OpenStreetMap extract around Yaba, Lagos, collected on 2026-10-04 from a 0.01-degree bounding box. i preserve source way ids, node ids, direction tags, and local geometry; i record the query, counts, attribution, and ODbL-1.0 terms beside the bundled data.

I choose one street segment as a hypothetical closure. i do not claim a live road closure, current coverage, travel-time estimate, traffic-flow prediction, safety result, emergency-access result, or network-resilience measure. i calculate paths over the stored geometry, direction tags, projection, and closure set; that is the whole claim.

I get a baseline route of about 4.6 km and a route of about 4.9 km after the bundled closure; i calculate a 7.73 percent increase in graph distance and 1,162 reachable nodes for the selected origin. i display the same integer-backed measurements in the local atlas and keep the caveat beside the map.

I keep the graph authoritative

I normalize a bounded GeoJSON subset into a graph with stable ids and integer latitude and longitude in microdegrees. i calculate each segment weight once in integer millimeters, preserve supported one-way direction, and validate endpoints, ids, sizes, and local extent before routing.

I use deterministic Dijkstra searches for shortest paths and breadth-first reachability for the remaining graph. i apply closures as a read-only edge filter rather than editing the source graph; i keep the original route and changed route comparable under the same endpoints. i resolve equal-cost paths with a stable ordering and calculate route-change ratios in integer basis points.

I keep the browser out of the routing business. i send a versioned JSON bootstrap from the local OCaml service, let Elm hold the selection and pending state, and send relative same-origin requests for each graph analysis. i reject stale replies so an older response cannot replace a newer scenario.

I choose a small stack on purpose

I chose OCaml for import validation, graph invariants, integer routing, serialization, and the loopback service. i wanted a compiled core with explicit invalid and unavailable states, not a distributed system or a broad service framework.

I chose Elm for the atlas because the interaction is a bounded state machine with a small number of states and messages. i keep JavaScript to a short bootstrap that mounts the compiled Elm module; i use no frontend framework, external map tile, external font, or runtime account.

I pin OCaml 5.5.1, opam 2.6.0, Dune 3.24.2, Elm 0.19.2, Node 22.23.3, and their test packages. i keep the compilers and package caches outside the repository; i run the OCaml and Elm suites, compile the production UI, and smoke-test the local HTTP routes with make test.

I make the demo local

I bundle the Yaba extract and metadata, compile the checked-in Elm source, and start a local server command. i run make setup once to cache the pinned tools and packages; after setup, i run make demo without an account or outbound request. i bind the service to loopback and use an ephemeral port by default.

I keep the map quiet, mark baseline and changed paths differently, and cross the hypothetical closure with a rust-colored bar. i place the numbers in monospace and expose the same origin, destination, and segment choices through native controls. i omit a basemap, a scale bar, and any visual promise of real-world precision.

I leave the limits visible

I do not model turn restrictions, every access rule, live traffic, travel time, road condition, pedestrian access, or emergency response. i do not infer population impact or identify a real closure from the graph. i keep those omissions in the architecture notes and the screen copy instead of hiding them in a footnote.

I built CutLine as a portfolio project and a place to practice clear boundaries across a graph core, local data, a typed UI, and honest measurement language. i keep the source and the next small issues at https://github.com/Mascottz/CutLine; i welcome corrections to the implementation and to the limits i have drawn.

I built a circuit breaker for runaway cloud spend

Mascottz — Sun, 04 Oct 2026 10:16:32 +0000

A misconfigured loop once burned $34k in 8 days. not a typo, and not a big company; the invoice was the first anyone heard of it. i kept coming back to that story, because the uncomfortable part is not the loop. loops happen. the uncomfortable part is that every tool in the stack saw it coming, and every tool waited for the invoice to do something about it.

Budget alerts fire after the money is gone. dashboards show the fire while it is still burning. i wanted the part that actually stops it.

So i built killowatt. it is a circuit breaker for cloud spend; it watches usage in real time, checks it against spend policies, and trips before the bill gets away.

The shape of it

Usage events flow in, one shape for any provider; an account, a service, a cost in integer cents, a timestamp. the core keeps a rolling ledger per account and checks three windows, in order; a burst window of ten minutes, the hour, and the day. whichever breaks first is the one that gets reported, and the moment one does, the breaker trips.

Trip means enforcement. today that is two live adapters; one suspends the cloudflare worker behind the tripped service, one scales the aws auto scaling group behind it to zero. every order carries its own undo, and dry run is the default until switched. reversible first, lethal later.

Watch first, then arm

The posture i am proudest of is watch mode. armed, the breaker stops the loop the moment a window breaks. watching, it sees everything and touches nothing; the account keeps spending and the watcher just counts what it would have saved.

Run the same bill through both and the report writes itself;

armed   spent $40.20, then stopped it; prevented $209.38
watch   touched nothing, saw everything; would have saved $209.94

the right to arm the breaker starts in watch mode, and it is the report that earns the kill switch later.

Why the strange stack

The pieces are deliberately polyglot, each language sitting where it is best;

the breaker core is rust; no gc pauses at the moment a resource gets cut
the watchers are elixir; one tiny supervised process per account, and one account going sideways never touches the rest
the policies are cue; spend rules as data, validated before they get near production
the anomaly scorer is julia; median and mad against each service's own history, and it catches a runaway on the exact first bucket
the dashboard is zero-dependency node; because it should be

The polyglot part earns its keep for one reason; the core and the watcher share one policy registry, exported from cue, so the two sides cannot drift apart. one source of truth matters more than one language.

What actually works today

The offline story runs from a fresh clone with nothing installed but the bootstrap script; the incident replayed armed and watching, the beam demo, the dashboard with a trip worth watching.

The live path is real for cloudflare; the poller meters durable objects invocations straight from graphql, verified against a live account before i shipped it. the aws metering client is built and its signer is verified against aws's own test vectors; it wakes up the day a key shows up. the sample bill carries two planted incidents, a fast loop and a slow leak, and the scorer lights up both on their exact first bucket.

What i learned building this

money is integer cents everywhere; floats do not touch money
watch mode is not a demo feature, it is the trust ramp; nobody arms what they cannot first watch
dry run plus an audit log is the same ramp for enforcement; nobody enforces what they cannot first audit
the $34k class of incident is not caught by better alerts, it is caught by a part of the system that is allowed to say no

It is young, the issues labeled good first issue are genuinely small, and the readme starts offline on purpose. if a cloud bill has ever landed as a surprise, come break it.

https://github.com/Mascottz/Killowatt

DEV Community: Mascottz