Build with a model. Take nothing on faith.
This is a workbench, not a trophy case.
I am Zain Dana Harper, a self-taught systems engineer in Seattle. I like taking systems apart, attacking concepts, and approaching problems abstractly before I narrow them into tools. I build like someone trying to make the private mess public enough to survive: scan the actual state, find the sharp edge, build the tool, dogfood it against real work, break it, document the break, merge what holds, and raise the bar again.
I like systems with teeth and taste: color science, old graphics pipelines, compilers, small local tools, messy source trails, agent ledgers, proofs that can fail, and interfaces that feel like a person built them. I do not want a demo that only works under flattering light. I want the thing in the hands of developers, in real repositories, under tests, under review, and still strange enough to be alive.
I do not move through this like someone who feels proficient. I move like abstract potential energy with an inextinguishable drive to learn. The tools are how I force that energy through a smaller aperture until it becomes useful: a compiler, a verifier, a map, a visual surface, a learning loop, a receipt.
I build accountability systems because I know what evasion, self-deception, shortcuts, blame, and wanting more than the work has earned can do to a person. I am artistic, restless, fallible, stubborn, and very capable of chasing a beautiful wrong idea farther than I should. My recent work keeps returning to the same loop: aim too high, pull the whole context into view, make the idea executable, and let the first embarrassing failure rewrite the plan.
Project Telos is the public form of that habit: a cross-domain research lab and product ecosystem for AI-era work across source intake, workspace maps, agent routing, claim checks, compiler experiments, graphics, color, simulation, learning workflows, and witnessed execution.
Site: harperz9.github.io
Work: resume | portfolio | CV | research | Studio
Flagships: telos | index | gather | forum | crucible | emet | buildlang | learn
| Pull | What it became |
|---|---|
| Taking systems apart | Maps, ledgers, verifier surfaces, compiler boundaries, and tools that expose where a concept stops holding together. |
| Attacking concepts abstractly | Wide ideas narrowed into focused artifacts: a CLI, a demo, a proof packet, a language feature, or a failing test. |
| Light, color, and rendering | Elder ENB, a public graphics project past 900,000 downloads; D3D11/HLSL engines; GPU trace tooling; Build Color, a Python color-science workbench. |
| Languages and boundaries | BuildLang, a Rust-built typed-effects compiler where functions declare what they may touch and the compiler checks the promise. |
| AI with memory and brakes | Project Telos, gather, index, forum, and crucible: sources, maps, routes, verdicts, and receipts. |
| Learning that does not bypass the learner | learn, Learning Forge, study loops, graded-step boundaries, and tools that help without taking the test for you. |
| Work that survives contact with people | Technical writing, compliance docs, Xbox networking support, field operations, arborist scheduling, customer calls, safety procedures, and the practical patience that comes from real jobs. |
| Beautiful things with accountable edges | The Studio, fractals, sound-reactive surfaces, renderer probes, visual studies, and the rule that a good artifact should leave a trail. |
The loop.
Scan the real project. Read the old sessions. Find the current state. Pull the docs, repos, tests, demos, and market evidence into the same room. Build the smallest tool that changes the situation. Use it immediately. Let it fail in public or near-public conditions. Fold the failure back into the product. Commit, push, verify, repeat.
That loop is the personality. I get impatient when work becomes posture, when tools are protected from real use, or when a claim cannot be made to stand next to its source. I am much more interested in the moment where the thing breaks and becomes better than the moment where it first sounds impressive.
The abstract engine.
My mind does not feel like a clean library of mastered facts. It feels more like stored charge: unstable, abstract, wide-ranging, and not automatically useful. The useful work starts when I build a constraint around it. A typed effect. A witness boundary. A source packet. A color model. A route ledger. A test that can embarrass me quickly.
That is why so many of my projects are instruments. They are not proof that I am refined. They are how I turn an aggressive idea into something with edges another person can inspect.
The accountability reason.
I do not write about accountability because I think I am naturally accountable. I write about it because I know how easy it is to dodge the mirror: blame the room, overclaim the work, take shortcuts, want credit before earning it, or confuse intensity with progress.
The tools are built against that. They make a claim stand beside its source.
They make a model answer say UNVERIFIABLE. They make an idea leave a receipt.
They give the next attempt somewhere firmer to launch from than mood, memory,
or self-protection.
The pressure I put on tools.
- Dogfood it: if the tool is for developers, run it on real repositories.
- Adversarially test it: make the smallest failure case and keep it.
- Make it public when it can be: ship the repo, demo, issue, receipt, or page instead of hiding the useful part in a chat.
- Keep the art alive: a rigorous system can still have color, rhythm, naming, motion, and a point of view.
- Do not sand off the ambition: narrow the next step without pretending the larger project stopped mattering.
The short version.
I started coding in middle school and came up without a CS degree or industry certification. The credential is the public trail: shipped crates, a VS Code Marketplace extension, open repositories, a real audience for graphics work, and tools that can be cloned, run, and argued with.
The throughline is not a job title. It is a pressure pattern: turn scattered state into an artifact, turn the artifact into a tool, turn the tool against real work, and keep whatever survives.
The work that shaped me.
- Technical Networking Support, Xbox Division: TCP/IP, DNS, NAT, router configuration, account-adjacent support, and the first hard lesson that a correct answer is not useful until another person can act on it.
- Operations Manager / Lead Arborist, family business: field work, client relations, scheduling, proposals, site assessments, safety procedures, vendor calls, budgets, and the kind of accountability that is not abstract.
- Freelance technical writing and consulting: API guides, security and compliance documentation, onboarding material, proposals, and the discipline of explaining systems without exposing client internals.
- Independent engineering since 2023: compilers, graphics, color science, multi-agent systems, research tooling, public demos, and a growing lab surface under Project Telos.
The projects that changed the shape of the work.
- Elder ENB: a Skyrim graphics and lighting project with roughly two years of public releases, feedback loops, named editions, and more than 900,000 downloads. It taught me taste, iteration, users, and the difference between a pretty frame and a maintained system.
- Native graphics lineage: D3D11/HLSL renderers, proxy-DLL interception, mid-frame compute dispatch, ACES/AgX tone mapping, TAA, SSR, SSGI, GTAO, volumetrics, ImGui tools, CMake/vcpkg, and shared-memory IPC.
- Build Color: a color-science workbench for color spaces, HDR tone mapping, perceptual difference metrics, chromatic adaptation, ICC profiles, gamut work, color-vision simulation, and 3D LUTs.
- BuildLang: a typed-effects language and compiler line: lexing, parsing, checking, effects, lifetimes, C FFI, C lowering, editor support, and explicit maturity labels for unfinished parts.
- Project Telos: the current flagship: give model-assisted work durable state, senses, action boundaries, receipts, and checks before anyone is asked to trust it.
I want the short version.
I build tools for messy, creative, model-assisted technical work. The tools usually do one of six things: capture sources, map workspaces, route agents, check claims, make visual systems, or turn an idea into a surface another person can inspect and break.
Start with Studio if you want the visual side, telos if you want the whole system, or the portfolio if you want the work history.
I want the visual and art side.
Open The Studio, then the graphics and color notes in the portfolio. This is where the old rendering instincts show up: light, color, tone mapping, volumetrics, game-engine edges, fractals, visual studies, and the refusal to let technical rigor make the work emotionally dead.
I want the AI systems side.
Start with telos, gather, index, forum, and crucible. The question underneath all of them is simple: what would an AI workflow look like if memory, source boundaries, routing decisions, action records, and failure states were first class instead of implied?
I want the compiler and systems side.
Open BuildLang and the public buildlang repo. The language asks a question I kept wanting tools to ask: what is this function actually allowed to do? That line connects back to the rest of the work: effects, receipts, permission boundaries, and explicit failure modes.
I want the messy human part.
I like clean instruments because I am not clean all the way down. I overreach, revise, get excited, get humbled by tests, and keep trying to build systems that judge the work instead of the worth of the person who made it.
The sharper version is this: these tools are what I build when I do not trust myself to stay honest by force of personality alone. They are surfaces for looking inward without turning the whole thing into theater.
The personal page is here: the person behind it.
I want to break it.
Pick the claim that sounds too confident. Stale a map. Tamper with a receipt.
Force a model answer past its source. Run the tool where it has no excuse. Make
a demo return UNVERIFIABLE for the right reason. The best feedback is the
smallest reproducible case where the proof surface fails.
Open something visual.
Start with The Studio. It is the live surface of Project Telos: a person and a model perceive the same thing, shape it, and check the result. The page includes the Atelier, 2D/3D fractals, dimension work, bring-your-own media, music, and physics routes.
Then open the catalog for the full front door and the flagship overview for the broader atlas.
Run a tiny demo from source.
These are not profile decorations; they are small runnable doors into the workbench.
git clone https://github.com/HarperZ9/telos
cd telos
node demo/run.mjsgit clone https://github.com/HarperZ9/gather
cd gather
python examples/demo.pygit clone https://github.com/HarperZ9/forum
cd forum
python examples/demo.pyInspect the demo surfaces.
| Demo | Link | What to look for |
|---|---|---|
| Studio | live surface | Visual creation, perception, and verification in one place. |
| Project catalog | live atlas | The public map of engines, demos, and research surfaces. |
| Flagships | overview | How the engines fit together as peers. |
| Research | current lanes | Domain packets, status notes, and explicit gaps. |
| BuildLang | landing page | Effects-language compiler positioning and public route. |
| index | atlas demo | A code/docs map as an inspectable artifact. |
| gather | proof surface | Source intake with provenance receipts. |
| forum | ledger replay | Agent routing with a replayable record. |
Pick a mood.
- I want craft: open Studio, then read the graphics/color lane.
- I want rigor: run
python scripts/check_profile_surface.py, then inspectcrucible,emet, orproof-surface. - I want systems depth: open BuildLang,
index, and the C++/graphics notes. - I want the person: read the messy-human door, then follow the portfolio, CV, and personal page.
Pick one path and press on it. Each quest is small enough to start in a few minutes and specific enough to become a real interview conversation.
| Mode | Start here | Artifact you should get |
|---|---|---|
| Make | Studio or telos |
A visual state tied back to a source route. |
| Map | index atlas |
A local HTML map of code and docs. |
| Capture | gather docs |
A source packet with a receipt boundary. |
| Route | forum route --json |
A routing decision you can replay. |
| Attack | crucible |
A MATCH, DRIFT, or UNVERIFIABLE verdict. |
| Dogfood | a real repo or workflow | A failure that teaches the tool what to become next. |
| Validate | proof-surface | A contract suite that either passes or names the break. |
Quest 1: make the machine draw.
Open The Studio, pick a route, and make something visual before you read another paragraph. Then pull the source surface:
git clone https://github.com/HarperZ9/telos
cd telos
node demo/run.mjsThis is the part of the work where my personality shows up fastest: image, motion, old rendering instincts, names, and the refusal to let a beautiful state float away without a record.
Quest 2: map a workspace.
Point index at a repo that has more knowledge than one person can keep in
their head:
python -m pip install index-graph
index atlas --root C:\path\to\workspace --format html --out atlas.htmlOpen the HTML file and ask two questions: which edge surprised you, and which doc no longer matches the code it claims to explain?
Quest 3: capture a source.
Give gather a small notes folder and make it preserve the method, scope, and
receipt instead of pretending the summary is the evidence:
python -m pip install gather-engine
gather docs ./research-notes --scope "claim,evidence"The interesting part is not whether it sounds polished. The interesting part is whether you can still find the boundary between source, digest, and claim.
Quest 4: replay an agent route.
Make forum choose a lane without hiding the choice behind personality or
vibes:
python -m pip install forum-engine
forum route --json "build the auth endpoint and the database schema"Then change the prompt until the route changes. That edge case is where the tool starts to become useful.
Quest 5: force a verdict.
Run crucible and look for the point where a confident sentence stops being
checkable:
git clone https://github.com/HarperZ9/crucible
cd crucible
python examples/demo.pyI like this kind of tool because it is rude in the correct direction. It does not care whether the claim is pretty. It asks whether the claim survived the measurement surface.
Quest 6: validate a contract.
Pull proof-surface and make the contract speak through tests:
git clone https://github.com/HarperZ9/proof-surface
cd proof-surface
python -m pip install -e .
python -m pytest -qThis is the boring-looking part that keeps the interesting parts honest.
- Ask me about a rendering mistake that turned into a tool.
- Ask me why I like taking systems apart before I claim to understand them.
- Ask me how an abstract idea becomes a focused tool.
- Ask why color, compilers, source receipts, and model boundaries keep showing up in the same room.
- Ask what I learned by making agents use the tools instead of merely describe them.
- Ask what field operations taught me about software.
- Ask what I overbuilt, what I misread, what I still do badly, and what I kept.
- Ask for the smallest demo that would make you trust one of these systems less.
| If you want to... | Open | What it proves first |
|---|---|---|
| Make AI work inspectable | telos | Shared human/model workspace, MCP tools, Studio surfaces, browser evidence, and replayable receipts. |
| See a codebase as a map | index | Workspace atlas, dependency evidence, freshness checks, and context envelopes. |
| Bring messy sources inside | gather | Method-labeled intake for web, docs, feeds, papers, PDFs, browser/OCR/audio paths, APIs, and derived notes. |
| Route agent work without losing the trail | forum | Ledgers, budgets, route records, resume state, intent checks, and verifier seams. |
| Attack a claim | crucible | MATCH, DRIFT, or UNVERIFIABLE, with the boundary visible. |
| Witness bytes from outside the claim | emet | Source/view consistency across independent conformance vectors. |
| Work below the app layer | buildlang | Rust compiler, typed effects, C as verified path, shader backends, and LSP surface. |
| Learn without bypassing the human | learn | Credential and coursework workflows that halt at graded steps and witness boundaries. |
GitHub renders this as a static diagram. The live surfaces are on the site: catalog, flagships, studio, and research.
flowchart LR
state["actual state / source / repo / visual idea"] --> gather["gather sources"]
gather --> index["index the workspace"]
index --> forum["route the work"]
forum --> telos["make / simulate / act"]
telos --> dogfood["dogfood on real work"]
dogfood --> crucible["attack the claim"]
crucible --> receipt["receipt, verdict, next question"]
receipt --> human["human judgment"]
human --> state
telos --> studio["Studio / visual surfaces"]
telos --> buildlang["BuildLang / effects"]
telos --> color["Build Color / perception"]
crucible --> emet["EMET witness"]
crucible --> proof["proof-surface contracts"]
pie title Profile routing mix, not traffic data
"Human and work history" : 20
"Visual craft" : 18
"Runnable instruments" : 25
"Research breadth" : 15
"Dogfood and break-it paths" : 22
- I notice when a system depends on hidden memory, private taste, or someone being in the room to explain it.
- I turn that hidden state into maps, CLIs, source packets, demos, receipts, tests, and failure names.
- I attack concepts before I trust them, then build tools that force the attack into something focused enough to help.
- I do not feel like a finished expert. I trust the drive to learn more than I trust any current inventory of knowledge.
- I push tools into real use early because the first failure is usually more honest than the first pitch.
- I do not trust my own first answer very much. That is why the tools keep
asking for evidence, replay, and a clean way to say
UNVERIFIABLE. - I care about beauty, but not as decoration. Light, color, rhythm, naming, and interaction are how a technical system becomes something people can keep using.
- I like broad research because fields cross-pollinate. A graphics habit can shape a verifier. A compiler boundary can shape an agent route. Field work can shape a product checklist.
Things I keep reaching for.
Color systems. Compiler boundaries. Old graphics pipelines. Small local tools. Taking things apart. Attacking concepts. Real repos. Dogfood loops. Diagrams that make a system less lonely. Receipts. Beautiful names. Harsh tests. Interfaces that feel quiet until they need to speak.
Things I am still learning in public.
How to make a very broad research lab legible without flattening it. How to keep ambition from becoming posture. How to let AI help without letting it launder uncertainty. How to make demos feel alive while still leaving a trail another person can check.
Things that usually mean I am doing the right work.
The first version is too strange. The second version is too clean. The third version has a test, a name, a diagram, a rough edge I still like, and a small door someone else can open.
- A broad research lab is not the same thing as finished expertise in every domain. Some lanes are mature tools; some are proof packets; some are experiments with explicit gaps.
- A receipt is not truth. It is a way to preserve enough state that another person can check what happened.
- A model is not a coworker, a judge, or a source of authority. It is a powerful instrument that needs memory, senses, brakes, and a record.
- I am not polished all the way down. I am a human trying to build clean instruments from a messy interior life.
The accountability line is the method, not the whole body of work.
- AI accountability: provenance receipts, claim checks, MCP surfaces, agent routing, model-boundary discipline, and public verification paths.
- Research operations: source capture, domain packets, adversarial testing, negative fixtures, and docs that mark what is verified, experimental, or unproven.
- Systems and compilers: Python tooling, Rust and C++ systems work, compiler/runtime experiments, typed effects, codegen, and release gates.
- Graphics and color: D3D11, HLSL, GPU traces, display calibration, ICC, 3D LUTs, perceptual color, Oklab, CAT16, and color-vision simulation.
- Formal and physical systems: theorem replay, physics/PDEs, thermodynamic computing, quantum workflows, numerical invariants, and AI4Science packets.
- Public product shipping: Project Telos on GitHub, Elder ENB on NexusMods, and a site where public pages link back to source.
Project Telos needs people willing to use the engines against real workflows, break the receipt discipline, and report where the proof surface fails.
This README is part of the workbench. It has a local verifier, CI, a template research receipt, an index-backed scope assessment, and a market/telemetry receipt. It stays deliberately static: no badge wall, no visitor counter, no typing SVG, and no dashboard that silently rots.
git status --short
python scripts/check_profile_surface.pyBuild it to be checked, or do not ship it.