Daniel Lund

Independent software engineer / systems experimenter

I build systems that think under pressure.

Reinforcement learning, reverse engineering, and safety-first tools for places where the interesting problems live.

Hold to enter the work
FIELD ONLINE 00:00:00 PT X 000 / Y 000

The best software is not just functional. It has a point of view. It makes complexity legible, earns trust through proof, and feels inevitable once it exists.

Two current signals from the lab.
Move through them. They move back.

01 — SELECTED WORK

Built past the
comfortable answer.

Not mockups. Working systems with hard constraints and receipts.

Reinforcement learning / reverse engineering / CUDA

1942//PPO

A live neural policy that learned to finish the NES classic from power-on—without an action tape, hidden expert, or last-second rescue.

32/32stages cleared
64,178live decisions
0action overrides

Four frames of raw NES RAM go in. Controller actions come out. Stable-Retro, PufferLib, and PyTorch PPO run the experiment; strict evaluation proves the policy selected START and completed one uninterrupted game under its own control.

PyTorchPPOStable-Retro6502
Independent research build

Market systems / terminal UX / defensive engineering

OptionSentinel

A safety-focused terminal cockpit for understanding option positions, portfolio risk, working orders, and the decisions between them.

LIVEbroker truth
DRYby default
FAILclosed

It combines a responsive curses dashboard, Schwab integration, per-leg close and roll workflows, intraday charts, and explicit guardrails for uncertain outcomes. A deterministic fake broker keeps development honest without touching an account.

PythonSchwab APIcursesSQLite
View source on GitHub

02 — APPROACH

Proof over posture.

I like systems where correctness is not decorative. The work moves between low-level internals and human-facing interfaces, with one rule: make the real control path visible.

  1. 01

    Find the actual boundary.

    Broker versus ledger. Policy versus planner. Interface versus machine.

  2. 02

    Make uncertainty explicit.

    Unknown is a real state. Treating it like success is how systems become stories.

  3. 03

    Build the proof into the thing.

    Audits, hard gates, failure modes, and reproducible evidence belong in the product.

03 — OPEN CHANNEL

Bring me the weird one.

The stubborn bug. The system nobody quite trusts. The idea that needs a working proof.

github.com/TitanUranus67