Skip to content
Dylan Taylor

Dylan Taylor · Technical founder · San Francisco Bay Area

hey, i'm dylan.
I build systems that turn expert judgment into executable, auditable software.

I taught myself to build by reverse-engineering games. Now that instinct points at systems where being wrong is expensive — legal decisions at Littman, aviation risk at FlightReady. 17, in the Bay Area.

factruleevidencedecidedecisionaudit

expert judgment → auditable decision

§ 01Currently

What I'm building now

What I'm focused on this month

§ 02Selected systems

Three problems where the answer isn't the hard part

The hard part is showing the rule, the fact, and the evidence that produced the decision. Full case studies for each.

01ProductBuilding

Littman

Turns a firm's own legal standards into structured decisions, escalations, and audit traces — not another chat box.

Professional-class AI for legal work. Littman ingests a firm's documents, playbooks, and precedents and turns them into an assistant, a searchable knowledge layer, a document vault, and workflows. The output isn't just an answer — it's a decision (approve, flag, escalate) that carries the rule, the fact, and the citation that produced it. I work across the connective tissue: ingestion, hybrid retrieval, structured extraction, and the review and audit layers as one system.

rulesDocumentsmatters, PDFsIngestchunk · tagRetrievehybridExtractstructuredDecideapprove/flag/escPlaybookfirm standardsAudit tracerule · fact · cite
Littman · system sketch
02ResearchPrototype

FlightReady

A go/no-go risk model for general-aviation flights that shows its work — every score decomposes into factors, uncertainty, and tail risk.

A research prototype for standardized aviation go/no-go decisions. It takes the inputs a preflight risk assessment already uses — weather, pilot currency, route and terrain, aircraft, time of day — and turns them into a transparent risk score with per-factor contributions, an uncertainty band, and a tail-risk (CVaR) view of the worst outcomes, alongside a structured briefing. Designed around human-in-the-loop review, not automation of the decision.

WeatherPilot · routeAircraft · timeRisk modelweighted · MCScore0–100 + bandTail (CVaR)worst 10%Briefingexplained
FlightReady · system sketch
03ProductResearch

OENRA

Reads a wine's chemistry and a person's palate on the same eight sensory dimensions to predict who will actually enjoy the bottle — and explains the match instead of returning a score.

A chemistry-aware wine intelligence system. OENRA turns analytical chemistry — GC-MS, LC-MS, FT-IR, routine panels — into a structured sensory profile of a wine across eight dimensions, each carrying a confidence that widens when the data is thin. A person's palate is modeled on the same eight axes, so a prediction isn't a universal 92-point score; it's an explained, per-dimension match between one bottle and one drinker, with the reasons and the uncertainty shown. For the trade, the same representation feeds batch-quality insight and blend exploration. It's a research preview: capabilities are experimental, and I make no accuracy or adoption claims.

compareChemistryGC-MS · LC-MSWinestructuredSensory8 dimensionsMatchexplainedTaste DNAsame 8 axes
OENRA · system sketch
§ 03Interactive proof

Score the same flight four ways

A live piece of the aviation work: move the sliders and switch the risk philosophy to feel where an average hides the tail. Synthetic — not flight advice.

Synthetic

Synthetic simulation for illustrating risk models. Not flight advice, and not a flight-planning tool.

Loading interactive…
§ 04Build log

Recently

§ 05Writing

Things I've thought hard about

§ 06How I work

A few working principles

  1. 01Build the difficult path first.The easy version is a commodity. The hard version — decisions, provenance, review — is the whole value.
  2. 02Evidence should travel with the answer.A conclusion you can’t trace is a conclusion you can’t trust with anything expensive.
  3. 03A workflow beats another chat box.Professional work ends in a decision and a record, not a paragraph of advice.
  4. 04High-stakes AI should expose its uncertainty.Surfacing the tail and knowing when to abstain is a feature, not a weakness.
  5. 05The fastest way to understand a system is to build one.Most of what’s on this site started as “I wonder how that actually works.”
  6. 06Label the unfinished as unfinished.Shipped, prototype, and concept are different words for a reason. Using them honestly is the point.
§ 07Contact

Working on a hard problem involving decisions, documents, risk, or applied AI?

Send me a note. I'm always up for comparing notes with people building difficult systems — especially in high-stakes domains.