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
2Instrumented glove, Peripheral
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 discontinued controller, rebuilt end to end

    A 1989 Nintendo Power Glove stripped to its shell and rebuilt as a working Bluetooth input device, across mechanics, electronics, firmware and gesture classification.

    Why it earns its keepThat a piece of hardware with no usable documentation and no surviving vendor can be taken apart, understood, and rebuilt across every layer at once: mechanical, electrical, firmware and software. The estimator is the part that transfers: raw flex readings cross a threshold repeatedly on noise alone, so the gesture only becomes stable once the signal is filtered. Every instrumentation project meets that problem, and it is usually mistaken for a bad sensor.

    What it is notA university capstone sponsored by Lockheed Martin, delivered by a student team, and not a commercial engagement of this firm. One unit, built to prove the rebuild rather than to be produced: no design-for-manufacture pass, no environmental qualification, no fleet. The filter core is TinyEKF (Simon D. Levy, MIT), adapted here to two different state dimensions and made to run on the microcontroller; the estimator models, the gesture classification and the hardware are the team’s own.

    • nRF52840 (Feather Sense)
    • LSM6DSOX 6-DoF IMU
    • Flex sensors
    • Extended Kalman filter
    • Bluetooth LE HID
    • PlatformIO / C++
    • FDM 3D printing
    MCU
    nRF52840, Bluetooth LE
    Sensing
    6-DoF IMU + 5 flex
    Gestures
    31 finger combinations
    Output
    Bluetooth HID
    gesture(), over EKF-filtered flex valuesFirmware, C++
    // Per-finger thresholds: a pinky does not travel as far as a thumb.#define THUMB_THRES 60   // INDEX 40, MIDDLE 50, RING 35, PINKY 42 // Filtered values, not raw: an unfiltered flex reading crosses its// threshold repeatedly on noise alone.static inline Gestures gesture(float thumb, float index, float middle,                               float ring, float pinky){    int mask = (thumb > THUMB_THRES) << 4 | (index > INDEX_THRES) << 3 |               (middle > MIDDLE_THRES) << 2 | (ring > RING_THRES) << 1 | (pinky > PINKY_THRES);    switch (mask) { /* ... 31 named combinations: TIMRP, TI, T, I ... */ }}
    Five analog flex readings collapse to one integer and a jump table, which is what makes classification cheap enough to run every loop. The thresholds are per-finger because the fingers are not interchangeable. The filtering is the load-bearing part: classifying raw readings makes a gesture flicker on and off at the boundary, so the values reaching this function have already been through the state estimator.

  • Custom peripheral, RTL to user space

    A hardware peripheral described in Verilog, wired onto the bus fabric, built into an embedded Linux image, driven by a kernel character driver, and used from a six-line user-space program.

    Why it earns its keepThat the boundary between software and hardware is a place our engineers can work, which is where manufacturing and utility integrations tend to stall.

    What it is notA deliberately trivial function, chosen so no layer could hide behind a vendor block. The lesson is the bringup order, not the accelerator.

    • Verilog
    • AXI4-Lite
    • Vivado/Vitis
    • PetaLinux
    • Linux driver
    • C
    Read the write-up
    Layers
    5, brought up in order
    Bus
    AXI4-Lite
    OS
    PetaLinux on ARM
    Interface
    Character device
    userspace/main.cC
    /* Five layers sit under this file, each brought up and verified before the   next: Verilog RTL, AXI4-Lite bus attachment, device tree, kernel character   driver, and then this. */int fd = open("/dev/axi_acc0", O_RDWR);write(fd, &(uint32_t){ 42 }, sizeof(uint32_t)); uint32_t out;read(fd, &out, sizeof(uint32_t));printf("%u\n", out);            /* 84 */close(fd);
    The peripheral doubles a number, and the triviality is the point: a function this small leaves no layer anywhere to hide, so a failure is unambiguously attributable to the one you just brought up. Bringup order is the transferable skill; the accelerator is not.

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.