01
ReLab
Workflow Reliability Testing & Replay
Workflow engines get tested on the happy path, and the failure paths are the ones that cost money. ReLab runs workflows across real worker processes, breaks them on purpose, and then checks the recovery: the event history answers whether the run came back, and the attempt and side-effect records answer whether it came back twice.
- Written in Go over PostgreSQL with no message bus: the coordinator, the workers and the CLI coordinate only through the database, so a crashed process is indistinguishable from a slow one.
- Each state change and the event describing it are written in one transaction, so the journal records what happened rather than what someone remembered to log.
- Replay is a pure reducer with no I/O, no clock and no randomness. It refuses a journal it cannot verify instead of reconstructing a plausible wrong answer.
- Five fault types, none of them a flag the scheduler can consult and be written to survive. Worker crash and latency degrade the real system, a real SIGKILL and a real delay pushing a task towards its lease; duplicate delivery, HTTP errors and database disconnects produce the failure the dependency would have produced, at the point the task would have seen it.
- The guarantee matrix maps each proved claim to a named test, publishes the five it cannot prove yet rather than listing only its wins, and CI fails if it cites a test that no longer exists. A twelve-point benchmark at 1, 5, 10 and 25 workers against 0, 1 and 5 percent fault rates lost no tasks at any point, measured on 4 cores with the database alongside, which the project calls a laptop rather than a deployment.
Distributed systemsBackend & APIs
GoPostgreSQLDockerOpenTelemetryNext.jsReactTypeScriptGitHub Actions
02
DiaLog
Personal Glucose & Metabolic Health Record
A glucose and metabolic health record that logs readings, meals, activity, sleep and medication, imports the same records out of device and vendor exports, and grades every pattern it surfaces by how much of your own data supports it. It says "not enough data yet" when that is the honest answer, and it is not a medical device.
- Ten health event types behind server-side validated forms; storage is always mg/dL and the UI renders mg/dL or mmol/L per preference, with plausibility bounds enforced at entry.
- Imports CSV, XLSX, JSON and XML through nine connectors: six for vendor and device exports (Abbott LibreView, Abbott Optium Neo, Nightscout, Apple Health, Omron and DiaLog's own) plus three generic fallbacks. Parse and preview, then commit, with deduplication that makes re-importing the same file a no-op and per-row issues reported rather than dropped.
- The analytics engine covers summary statistics, meal, activity and sleep associations, anomaly and trend detection, day-pattern clustering and feature importance, and grades each finding by sample size before showing it, so nothing overclaims from thin data.
- The offline Python research pipeline trains on strict chronological splits and reports every model against majority-class and persistence baselines, because a random split on a time series lets a model train on its own future.
- The assistant explains the data without ever receiving it. The provider layer is handed a pre-aggregated, evidence-graded bundle of counts, averages, sample sizes and findings, never an individual reading, meal, medication or note, and runtime checks reject anything shaped like a raw record.
- Accessibility is a build gate rather than an audit: a WCAG 2.2 AA target, axe-core running over twelve public and signed-in routes on every CI run, no meaning carried by colour alone, and a real table alternative behind every hand-built chart.
Full-stackData pipelines
Next.jsReactTypeScriptPostgreSQLPrismaTailwind CSSZodPythonPlaywright