Work
Six products (five you can click through, plus our own agent-driven sprint platform shown in screenshots), three projects from the Project Nexus Code lab, and prior engineering work across healthcare, aviation, and manufacturing. Each piece says what it does, what it is built on, and what is real versus demo.
Live demos
Complete products with real engineering underneath. Five are deployed and open to explore. Agile Cards, our own sprint platform, runs as a local operator tool and is shown here in screenshots instead. The four client-brand demos run on synthetic data; Provenance carries a real ledger from a scripted agent run.
-
Agile Cards
Agent orchestrationThe studio's own agent-driven sprint platform, built to run the way the studio already works as a loop. Work is filed as contract cards (a scope, the files a card expects to touch, its dependencies, and a machine-checked definition of done), and a re-entrant runner claims them, holds each to a per-card cost cap, verifies them at two levels, and merges them with a human on the button where the tier calls for one. The runner treats a card store as the source of truth, so a crash reclaims in-flight cards to the backlog instead of losing them. Built and tested (more than 700 tests, and a rehearsal that proved the gate refuses bad cards); it hasn't run a real backlog yet.
Local operator tool, shown in screenshots. No hosted instance; the source is public on GitHub.
-
(opens in a new tab) Provenance
Agent infrastructureA flight recorder for agent fleets, built for the studio's own agent work. Every decision an agent makes is logged with the options it actually weighed, the rationale, and the human verdict, on a tamper-evident hash chain you can verify offline. Kill the agent mid-decision and it resumes from the file alone; finished decisions and cached model calls are never re-run, so with a deterministic agent the resumed output is byte-identical. Verdicts export as SFT and DPO training data with per-row provenance, and the demo is a real hash-chained ledger from a scripted run, kill scar and all.
-
(opens in a new tab) AxlePoint Industrial
Industrial OperationsAsset health and maintenance operations for heavy industry. A 100-asset fleet of engines, generators, compressors, and pumps streams six months of synthetic sensor telemetry into a rolling anomaly detector; every asset carries an explainable 0-100 failure risk score that drafts preventive work orders on demand. Work orders, PM scheduling, parts inventory, and reporting round out the platform.
-
(opens in a new tab) Slatewell
Booking and SchedulingMulti-staff scheduling for service businesses. A five-step mobile-first booking wizard sits on top of a pure slot engine that knows about service durations, per-service buffers that occupy staff time, capability matching, and the lunch splits in a working calendar. Bookings re-validate the slot inside a SQLite transaction on insert, so a race to the same minute returns a 409 instead of a double-booking. Admin surfaces for services, staff, and the daily schedule work today; customers, communications, and reports are previews of planned sections.
-
(opens in a new tab) Lumen Analytics
B2B SaaS AnalyticsRevenue and behavior analytics for a B2B SaaS, with first-class anomaly detection at the center of the product. A rolling-median STL-style decomposition with MAD sigma scoring flags anomaly episodes across 32 metrics, every one with per-slice cause attribution (plan tier, geography, industry) and a triage workflow built on top. Metrics explorer, 500-customer list, d3-sankey acquisition funnel, signup-cohort heatmap, segments, demo auth, and a marketing landing round out the product. Sign in with one click on the landing.
-
(opens in a new tab) Harbor Bistro
Hospitality / RestaurantA coastal-American restaurant brand with a full mobile-first menu and ordering surface. Sixty menu items statically generated per slug with per-item customization (radios, checkboxes, upcharges priced live into the unit and total), a sticky filter chip rail tuned for dietary avoidance, and a session-persisted cart that merges identical configurations under a canonical line key. The database is baked into the image at build time behind a db:verify integrity gate that fails the build on bad seed data. Online orders check out through Stripe-hosted Checkout in test mode.
From the lab
One project runs live here: Draughts, learned from scratch, two small neural networks that taught themselves draughts by self-play, with their recorded training history and the networks running in your browser.
-
Project Nexus
A multi-node AI architecture across consumer hardware. Research stage.
- The problem
- Most agent systems are one model in one process that forgets everything between sessions. The research question is whether splitting the work the way a nervous system does (filter at the edge, remember in one place, reason in another) gets you agents that hold context over months, on hardware a small lab can own.
- What we built
- A containerized system designed to spread across Jetson edge devices, a 4070 node that filters signals and routes messages, a 4090 node that hosts the large models and swaps them in and out, and NAS-backed long-term memory with a vector store. Each part is tested in isolation (159 tests). The first live run of a full agent across the nodes is the next milestone, not something that has happened yet.
- Why it matters
- It's the lab's bet that you don't need a hyperscaler to do serious work on long-running agents. It's a bet, not a result: the repo is public, so you can judge where it stands.
-
Vector
Sensing for buildings. Patent stage.
- The problem
- Buildings already have sensors, but the data stays in the building management system, fixed to wherever the sensors were mounted, and nobody reads it until something breaks.
- What we built
- The design for a mobile perception platform that gathers sensor readings across a building and feeds them to the lab's other systems. It's the subject of the US provisional patent application filed in April 2026. Today it's specifications and the patent filing; the software is at the scaffolding stage.
- Why it matters
- It's where the lab's ML work meets the physical world. It's early, and we'd rather say so than dress it up.
-
Career Ops
A ToS-safe pipeline for ranking job postings.
- The problem
- Matching job postings to a profile is a data problem and a ranking problem first. The job boards have different APIs, different terms of service, and different definitions of what a "remote" job actually is.
- What we built
- A pipeline that ingests postings from sources that allow it (with required source attribution), fit-scores them against a profile, tracks applications through their lifecycle, and runs locally on the machine that owns the data. By default nothing leaves that machine; an opt-in scorer sends the profile to a hosted model, and the flag says so.
- Why it matters
- Ranking tooling that respects the boards it reads from and the person whose data it scores is rarer than it should be. It's a small, end-to-end ranking system: ingestion with attribution, scoring, and lifecycle tracking, all local by default.
Prior engineering work
Delivered during prior employment. Named engagements are kept anonymous here; the discipline and the outcomes are not.
-
Reporting for a healthcare claims clearinghouse
Claims and payment reporting on .NET, during prior employment.
- The problem
- An intermediary that sits between insurance carriers and dental plus vision provider networks lives or dies on the credibility of its claims and payment numbers. Adjudication status, EOB generation, statements, payment reconciliation: every one of those steps produces a number someone is going to read and act on, and a number that is slow or unclear is a number that does not get trusted.
- What we built
- Reporting surfaces over the claims and payment pipeline: claims status and adjudication outcomes, payment reconciliation against carrier remits, EOB and statement workflows. Medical coding and billing data, not clinical records. The whole stack inside a HIPAA posture, with the access controls and audit trails that go with it.
- Why it matters
- Claims and billing are where the money meets the spreadsheet. An EOB or a statement is a financial communication a system generates on a payer's behalf, and whoever reads it acts on the number in it, so provenance and freshness have to ride with the number instead of living in a footnote. That is the same burden an agent carries when it drafts or sends a financial message on someone's behalf: the figure it puts in front of a person has to trace back to its source and be known-current before it goes out.
-
Decision-support data systems for a manufacturing leader
Reporting UX on .NET, during prior employment.
- The problem
- Leadership at a Fortune-500 manufacturing company was being held up by reporting interfaces that hadn't been touched in a long time: slow, hard to read, hard to trust. The data was there. The path from data to decision was the slowdown.
- What we built
- Refreshed executive reporting interfaces on .NET. New layouts that matched the questions an executive actually asks. Charts that answered the headline question on first glance, with the supporting numbers one click away. Quiet performance work underneath so reports loaded in time to be useful.
- Why it matters
- The discipline -- get the right number on the screen first, know where it came from, know how stale it is -- carries directly into the AI/ML systems work we do now. Models that decide things deserve the same data hygiene as humans that decide things.
-
Applicant tracking system for an aviation operator
.NET ATS plus microservice integrations, during prior employment.
- The problem
- Hiring teams running real volume need an ATS that does not fight them. Requisitions in flight, candidates moving through pipeline stages, recruiters working three roles at once, interviews to coordinate, offers to track, compliance reporting that has to be defensible. Off-the-shelf options either fit one workflow well or fit no workflow at all.
- What we built
- A from-scratch ATS covering the whole pipeline: candidate sourcing, requisitions and role management, pipeline stages, recruiter workflows, interview scheduling, offer tracking, compliance reporting. On top of that, the integrations a modern ATS is expected to carry (email and SMS notifications, calendar, document and e-sign) wired through a microservices layer using accepted patterns: separation of concerns, idempotent message handling, retry plus dead-letter behavior, schema-versioned events, observability hooks the on-call can actually use.
- Why it matters
- Building ATS-grade integrations is agent-fleet reliability wearing a business-software costume. Idempotent handlers so a retry does not double-fire, dead-letter queues so one poisoned message does not stall the line, schema-versioned events so a producer can change without breaking its consumers: those are not ATS niceties, they are the properties any fleet of independent services needs to stay up in production. We built them there before the AI work made us need them here.
-
Aircraft maintenance management for an aviation operator
Maintenance, parts, and compliance tracking, during prior employment.
- The problem
- An aircraft is a moving compliance posture. Scheduled and unscheduled maintenance, flight hours, cycles, parts with lead times and airworthiness rules, work orders that have to land on the right technician with the right paperwork, and an audit trail an inspector can follow on a bad day. Keep one of those columns out of sync and the airplane does not fly.
- What we built
- A maintenance management system covering scheduled and unscheduled work, flight hour and cycle tracking, parts inventory with lead times and airworthiness compliance, technician work order workflow, and audit trails sized for regulatory inspection. Pre-AI engagement: rigorous data discipline first, then the workflow on top of it.
- Why it matters
- The engagement pre-dated practical AI deployment, but the opportunities were obvious from inside the domain: predictive failure modeling against hour-and-cycle data, parts demand forecasting against the lead-time graph, technician routing against the work-order queue. That domain knowledge is what the studio brings to AI and ML work now.
Want one of these tailored to your environment? The lab work and the client work share a method; what changes is the data and the constraints. Tell us what you're trying to do.