Things I have built
Models, tools, and software with the gates that make their numbers trustworthy. The publishable parts, at least.
The bit-accurate models firmware is verified against
ModelingBit-accurate models of the downlink, uplink, and PRACH chains of multiband O-RAN radio units. Because the model runs the same fixed-point arithmetic as the hardware, firmware verification can compare RTL output against it stage by stage and treat any difference as a defect rather than a question of tolerance. The same models are the reference when a test team hits something unexpected on the bench: every intermediate stage is exported, so a problem can be narrowed to the stage that first disagrees. They also carry the architectural work, evaluating filter and gain structures and answering system-level questions about what a configuration will actually do before it is committed to hardware. Carriers from 3 to 100 MHz, FDD and TDD, packaged as versioned executables so running them needs no MATLAB license.
A PRACH receive chain covering every configuration
VerificationPRACH is the first thing a radio hears from a phone, and it is the most configuration-dependent chain in the receiver. The model covers LTE formats 0 to 3 and full NR FR1, long and short preambles, and all 256 configuration indices in both FDD and TDD. What makes it harder than the rest of the receive path is that very little is fixed. Preamble format, subcarrier spacing, and the occasion pattern together decide where in time and frequency a preamble is even allowed to appear, so the search window has to be derived per configuration rather than written down once. Timing has to be right to the sample, cyclic prefix and guard handling change with format, and the root sequence and cyclic shift have to be recovered without being told which ones were sent. Getting a single configuration right proves very little, which is why the model is exercised across the whole index space instead of a representative few.
Predicting where intermodulation will land
ToolingPassive intermodulation is far cheaper to design around than to find later. Once a radio is built, a product falling in its own uplink band presents as a sensitivity problem that looks like several other faults, and tracing it back to the mixing that caused it is slow work. This enumerates third, fifth, and seventh order products across a 46-band catalog and flags any that land in an uplink band, for the mixing topologies of single, dual, and tri-band radios. It uses corner-evaluation interval arithmetic, so the reported hit ranges are exact across the band edges rather than sampled at a few frequencies and assumed representative. The use is band-combination planning: combinations can be ruled in or out before anyone commits to a filter plan. Products are ranked in dBc, and the power figures are relative rather than calibrated, which the tool states plainly.
Uplink EVM without an instrument license
ToolingThe radio unit does not do channel estimation or equalization, so measuring uplink quality means demodulating the fronthaul capture somewhere else. That is normally a Keysight vector signal analyzer, and the licenses cost enough that there are only ever a few seats to share. Most of the people waiting for one do not need a vector signal analyzer. They need to open a PCAP, find the uplink fronthaul data going from the O-RU to the O-DU, demodulate it, and read an EVM. This does that and stops there, as a standalone executable with no license attached, for both uncompressed and block-floating-point compressed data. The instrument seats stay free for the work that genuinely needs them.
Fronthaul power, read straight off a capture
ToolingSeveral O-DU vendors, and they read the fronthaul standard differently. The power levels arriving on the wire differ with them, so getting the downlink right, and sometimes the uplink gain, depends on knowing what to expect rather than assuming. The system test team needs the expected level both per symbol and per tone, with the CCDF curve alongside it, and there was no quick way to load a capture and get either. This reports power from an O-RAN fronthaul PCAP per the working group measurement definitions, working out direction, numerology, MaxPRB, compression mode, and eAxC grouping from the capture itself. Written in pure Python for throughput, because the captures are large, and it will batch a folder into a spreadsheet. Command line and GUI, both packaged so nobody has to install Python to read a power number.
Forge: agents near instruments, with the limits kept outside the model
R&DAn agent that can drive test instruments and read specifications is genuinely useful in a lab, and is also one careless tool call away from mis-configuring hardware or asserting something a specification does not say. The usual answer is to write the guardrails into the prompt, which makes the thing being constrained also the thing enforcing the constraint. Forge keeps them outside it. Machine-checkable limits are compiled out of the 3GPP specification documents themselves, each carrying its clause, a source hash, and a review status, so a claim can be traced back to the sentence it came from. Instruments are reachable only through a typed control server, so an out-of-range setting cannot be expressed in the first place. The side that judges the work and the side that does it run under separate permission profiles, the settings carry a tamper alarm, and no completion claim is accepted until a person countersigns it. What that buys over a well-prompted agent is that the limits, the provenance, and the sign-off all survive the model being wrong.
TaxLens: rebuilding a year of books from the statements
SoftwareSmall businesses rarely have the capacity for meticulous bookkeeping, and personal and business money get mixed along the way: a business payment goes on a personal card, a personal one on the business account. By the end of the year it is a stack of statements, and putting it back in order means working through every transaction, which is hours of it whether the owner does the work or pays somebody else to. TaxLens does that reconstruction from the raw statements. It asks about the transactions it cannot place, learns how the particular business actually operates, and categorizes the way an experienced accountant would rather than by keyword: what is deductible, under which IRS category, against current guidance. Every deductible dollar carries a tax-code citation, an evidence tier, and a confidence score; classifications are append-only; and a citation it cannot verify is flagged rather than asserted. On one real client year it also found about ten thousand dollars of double-counted bounced payments that manual review had missed. It deliberately cannot file anything.
Salient: exam practice against a patient who cannot leak the answer
SoftwareClinical exam practice needs a patient who behaves like one: answers what is asked, withholds what a real patient would not volunteer, and never hints at the diagnosis. A general chat model manages the first and fails the other two, and it will invent a lab value if asked confidently enough. Salient is built so that it cannot. Every examination finding and lab result is pre-authored and schema-validated, so ordering an investigation is a deterministic lookup rather than something generated on the spot, and a leak guard redacts any reply that would give the diagnosis away. Six model roles are tiered by how hard each job really is, so the cheap work runs on cheap models. Cost governance sits in three layers over a per-call ledger denominated in micro-cents, because an AI product without a budget is a bill waiting to happen. Around 700 unit tests and 24 browser journeys run in CI.
RouteFlow: one system for a wholesale distribution business
SoftwareWholesale distribution needs inventory, costing, supply chain, orders, taxes, regulated-item sales, bookkeeping, and delivery route management, and there are very few systems that cover all of that rather than most of it. Running four tools instead means the numbers never quite agree. RouteFlow is the whole set in one place, and it works from both ends: the distributor runs catalog, orders, driver routes with proof of delivery, and compliance filings, while the retail shops order from all of their suppliers through the same platform instead of a separate portal for each. Inventory transfers straight through a sale, supplier invoices are scanned rather than typed, and one item can carry separate wholesale and retail SKUs. The problem underneath it is that a growing small business often cannot say what it is actually making, because the transactions and the expenses live in different places and never get added up in one view. AI does the parts that are judgment rather than arithmetic: reading a scanned invoice into line items, matching them to catalog products, and categorizing expenses so the profit figure is built from everything instead of from whatever got entered. Tenant isolation sits at the database layer, where an extension injects the tenant into every query and write rather than trusting each developer to remember.