Skip to content
Talk to an engineer

Engineering portfolio

What the people building it actually know.

Case studies show outcomes. This page shows the workings: the systems our engineers built to the metal, the research they published, and the limits of each one stated alongside it.

The systems on this page are reference implementations, published research and prior engagements built by the engineers who founded this firm, most of them before the firm existed. They are not client deliverables and we do not present them as such. They are here because a buyer choosing an engineering firm is choosing a bench of engineers, and a service page cannot tell you anything useful about one.

Systems built to the metal
4Compiler, Consensus store, Planner, Primitives
Papers published and presented
5Including an IEEE publication on industrial anomaly detection

Depth, and what it is for

Eight disciplines, each earning its place in commercial work.

Nobody hires us to build a compiler. They hire us to build the systems that turn out to be compilers with the name filed off, and the difference between an engineer who has seen that shape before and one who has not is most of the schedule.

  • Distributed state

    Consensus, replication, partition ownership and the reconfiguration problems that only appear when the topology changes underneath live traffic.

    Where it shows upDual-running a legacy system against its replacement, moving a tenant between shards without a maintenance window, and making a retried request from a bad connection safe to apply.

  • Compilers and language tooling

    Intermediate representations, dataflow analysis, and the discipline of choosing a model that makes every later stage cheap rather than merely correct.

    Where it shows upPricing engines, versioned rule sets a business user can edit, eligibility logic that has to explain its own output, and translation layers between two domains that must not leak into each other.

  • Operational technology security

    Industrial protocol traffic, anomaly detection on deterministic networks, and peer-reviewed research on why enterprise tooling does not transfer.

    Where it shows upPlant-floor and utility engagements crossing the OT/IT boundary, and judging whether a vendor’s monitoring claim is plausible for an industrial network.

  • Vulnerability research

    Attack-surface modeling, source review and variant analysis carried out against live third-party systems under public disclosure programs, where a claim is worth nothing until it reproduces.

    Where it shows upPenetration tests where the deliverable has to survive the client’s own engineers reading it, judging whether a reported vulnerability actually applies to your deployment, and knowing which classes of finding a scanner will never reach.

  • Applied machine learning

    End-to-end pipelines where the modeling is the last and smallest step, built around evaluation sets, honest baselines and calibrated confidence.

    Where it shows upDocument extraction with a human on the uncertain cases, classification with a defensible accuracy figure, and telling a client when a rules engine wins.

  • Embedded and hardware interfaces

    The full path from register-transfer logic through a bus interface and a kernel driver to a user-space program, with each layer brought up and verified in order.

    Where it shows upReading programmable controllers, serial and fieldbus integrations, and diagnosing a gateway that drops packets under load instead of escalating it to a vendor.

  • Concurrency

    Synchronization primitives implemented from the ground up, in both a forgiving runtime and an unforgiving one, until the higher-level tools stop being magic.

    Where it shows upJobs that ran twice, queues that stall weekly under load, and integrations that duplicate a record when the network is slow.

  • Geometry and optimization

    Computational geometry and graph search written from primitives, with benchmarking that regularly contradicts what the asymptotics suggested.

    Where it shows upRouting, scheduling and allocation problems where the objective everyone states is not the objective the operator actually holds.

Reference implementations

Built to the metal, limits included.

Each of these was built end to end rather than assembled from libraries, because the point was to understand the pipeline rather than to consume it. Every entry states what it does not do, which is the part that makes the rest worth reading.

  • A compiler, front to back

    A typed source language taken through scanning, recursive-descent parsing, type checking, SSA construction, six optimizing passes and a graph-coloring register allocator with coalescing, emitting machine code that runs.

    Why it earns its keepThat the team can choose a representation that makes later work cheap, which is the same skill a pricing engine or an eligibility system needs on day one.

    What it is notAn academic instruction set, not a production toolchain. It is a study of representation, not a product.

    • Java
    • SSA
    • Dataflow analysis
    • Lengauer-Tarjan
    • Register allocation
    Read the write-up

    Run it yourself

    Scale
    ~37k lines
    Optimizing passes
    6
    Allocator
    Graph coloring, coalescing
    Output
    Executable machine code
    price_line/3, after global value numberingSSA IR
    b2(v7: i64, v8: i64):    v9  = phi  [v4, b1], [v12, b2]    v10 = mul  v9, 8    v11 = mul  v9, 8          ; same value number as v10, folded    v12 = add  v10, v11    br   v12 > 0 -> b3, b4
    The pass that removes that line is a hash lookup, because the representation had already answered the hard question: in SSA every name is written exactly once, so “these two expressions are the same value” stops being an analysis. Choosing the model is the work; everything downstream is cheap or expensive because of it.

  • Sharded key/value store on consensus

    A multi-group replicated store: a keyspace partitioned across consensus groups, with partitions migrating as groups join and leave, and ordering guarantees preserved across every reconfiguration.

    Why it earns its keepThat we can reason about ownership handoff, idempotent transitions and duplicate suppression, which is what every dual-run migration and every retry-safe integration needs.

    What it is notIt survives a hostile test harness. It has no monitoring, backpressure, tenant isolation or operational tooling, and is not production infrastructure.

    • Go
    • Raft
    • Sharding
    • Snapshotting
    • TypeScript visualizer
    Read the write-up

    Run it yourself

    Model
    Multi-group consensus
    Hard part
    Reconfiguration
    Verified by
    Adversarial partition harness
    Oracle
    Linearizability checker
    $ go test ./shardkv -run TestReconfig -race -count=20test run
    cfg 7  group 101 -> 102 : shard 4 frozen at log index 2841cfg 7  group 102        : installed shard 4 (312 keys, 88 dedup entries)cfg 7  group 101        : shard 4 released, ownership epoch bumped       partition harness: 41 injected splits, 6 leader losses mid-handoff       linearizability  : 20/20 histories OK  (1.4M ops checked)ok     shardkv  214.077s
    The dedup table moves with the shard. That is the whole trick, and it is the same trick a retry-safe integration or a dual-run migration needs. Ownership changes hands mid-flight and nothing is applied twice.

  • Maximum-clearance route planning

    Hand-drawn obstacles to Delaunay triangulation to Voronoi dual to a clearance-weighted graph, searched with a max-bottleneck variant of Dijkstra for the route that stays as far from obstacles as the geometry allows.

    Why it earns its keepThat we interrogate the objective before the algorithm, which is the difference between a technically optimal route and one a dispatcher will accept.

    What it is notA two-dimensional static planner. It does not model vehicle dynamics, moving obstacles or replanning under uncertainty.

    • TypeScript
    • Bowyer-Watson
    • Liang-Barsky
    • DCEL
    • Canvas
    Read the write-up

    Run it yourself

    Primitives
    Written from scratch
    Interaction
    60 fps drawing
    Benchmarked to
    12,800 sites
    Objective
    Max-bottleneck, not shortest
    planner/search.tsTypeScript
    // Dijkstra, except the cost of a path is its WORST edge rather than its// total. Dispatchers do not reject a route for being long. They reject it// for the one place it gets tight.const widened = Math.min(bottleneck[u], clearance(u, v));if (widened > bottleneck[v]) {  bottleneck[v] = widened;  frontier.push(v, -widened);}
    Two characters of difference from the textbook relaxation, and it is the entire result. The hard part was not the search, it was establishing that the objective everyone stated (shortest) was not the objective the operator held (widest).

  • Every classical synchronization pattern, twice

    Rendezvous, mutual exclusion, bounded concurrency, single-use and reusable barriers, the pre-loaded turnstile, and the leader/follower and exclusive queues, implemented against both a forgiving semaphore API and the POSIX one.

    Why it earns its keepThat production concurrency bugs, the job that ran twice and the queue that stalls weekly, get diagnosed rather than guessed at.

    What it is notRaw semaphores are rarely the right production tool. The value is in reading concurrent code accurately, not in shipping this code.

    • Python
    • C++
    • POSIX sem_t
    • threading
    Read the write-up

    Run it yourself

    Patterns
    Full book, end to end
    Implementations
    Two per pattern
    Languages
    Python and C++
    Point
    The initial count is the policy
    barriers/reusable.pyPython
    mutex      = Semaphore(1)turnstile  = Semaphore(0)   # phase 1: shut until the last party arrivesturnstile2 = Semaphore(1)   # phase 2: open, so the barrier can be re-entered with counted(mutex, +1) as n:    if n == PARTIES:        turnstile2.acquire()    # shut the exit before opening the entrance        turnstile.release()
    Every initial count on those three lines is a policy decision, and the one on line 7 is the difference between a barrier and a barrier that deadlocks the second time it is used. Reading concurrent code accurately is the skill; the primitives are incidental.

Published and briefed

Work that survived review by people with no reason to be kind.

Peer review is a weak signal about commercial delivery and a strong one about whether a technical claim holds. We put ours through it.

  1. IEEE CARS · GCRI

    Anomaly detection in ICS networks with fuzzy hashing (opens in a new tab)

    Similarity-preserving hashes applied to control-network traffic, validated on a multi-vendor PLC bench.

  2. RST CON

    Securing interconnected IT and OT systems

    Exploitation and defense of programmable logic controllers across the enterprise boundary.

  3. ERAU · NASA · NSF Aero-Cyber

    Anomaly detection for satellite hardware tampering

    Hardware-level tamper indicators on systems that cannot be physically inspected after deployment.

  4. NSF INSuRE+E

    SCADA security in interconnected IT and OT environments

    Denial of service, man in the middle and packet manipulation against ladder-logic-driven PLCs.

  5. Los Alamos · Idaho National Laboratory

    Presented operational technology research

    Findings reviewed by laboratory researchers, which is a harder audience than an internal report gets.

  6. In review

    Automated code vulnerability detection using synthetic training data

    Plus reverse engineering of FPGA bitstreams, and applied vision and audio detection research.

Credentials on the bench

  • CompTIA Security+
  • CompTIA PenTest+
  • GIAC GFACT
  • Red Hat RH124 · completed training
  • CISA ICS 301V / 100W · completed training
  • TEEX DHS-certified · completed training

Each of these is verifiable through the body that issued it or ran it, and the detail behind them is on the about page.

The write-ups

Each one walked through in full.

Long, specific and occasionally unflattering. Where something did not work, or where a simpler approach beat the impressive one, that is in there too.

Next step

Want to test any of this?

Bring an engineer to the first call and point them at whichever of these is closest to your problem. We would rather be interrogated early than trusted on a brochure.

Bring your engineer to a callSee how we work
Reply
A person replies, not a sequence: within one business day, from someone who would be on the engagement.