HUMAN PROFILE // PROFESSIONAL SUMMARY

THE BUILDER

I’m Daedalus. I’m a systems architect, developer, artist, musician, and builder of things that tend to begin with one inconvenient question: why does this have to work this way?

My work moves between operating systems, infrastructure, recovery engineering, AI, interfaces, embedded systems, audio technology, and creative tools. The subject changes. The underlying problem usually does not: understand what the human is actually trying to accomplish, find where the system gets in the way, and build something that preserves the intent.

COGNITIVE MODEL // INTENT BEFORE PROCEDURE

How I see systems

I’m autistic, and that meaningfully shapes the way I understand technology.

I do not always experience interfaces, communication, or implied conventions the way their designers expect. Things other people can absorb almost automatically may require me to stop, consult a reference, reconstruct the model, and understand why the system behaves as it does.

That experience made intent unusually important to me. I care about what someone is actually trying to do, what the system believes they are trying to do, and where those two ideas diverge.

Much of my work begins in that gap.

FIRST PRINCIPLES // EXPLICIT MODELS

The reference paradox

My relationship with systems is uneven.

When I am working inside someone else’s abstractions, I use documentation, references, diagrams, and known-good examples heavily. A workflow that another person can simply “feel their way through” may not become intuitive to me until I can build an explicit model of it.

The reverse happens too. I can sometimes spot a failure mode, contradiction, or missing assumption very quickly because I never followed the same mental path everyone else was following.

I tend to reduce problems aggressively. I look for the smallest fact that explains the largest amount of weirdness.

Sometimes the sophisticated diagnosis is a race condition, broken ownership boundary, or abstraction leak.

Sometimes the machine simply has no gas in it.

Both deserve the same attention. This is why I design systems to require less guessing than the systems I struggle with.

I design systems to require less guessing than the systems I struggle with.

FIRST PRINCIPLES, WITH BETTER TYPOGRAPHY.

PRODUCTION // LABORATORY // STAGE

I build across boundaries

I have spent years working with real infrastructure, endpoints, networks, servers, recovery jobs, documentation, technicians, customers, and the inconvenient behavior of production systems.

I also build operating-system architecture, local AI infrastructure, experimental interfaces, creative software, audio technology, embedded systems, games, and instruments.

Those are not separate personalities.

I am interested in the boundary where software meets hardware, where architecture meets interface, and where the technically correct answer meets the human being who actually has to use it.

My projects tend to begin where “that’s just how computers work” stops being a satisfactory answer.

PROFESSIONAL SIGNAL // WORKING DOMAINS

Capability matrix

Systems

Systems architecture
Windows & Linux infrastructure
Networking & virtualization
Storage, imaging & recovery
Workflow automation
Hardware-adjacent systems

Software

C++
Python
TypeScript / JavaScript
C# / .NET
Kotlin / Android
Web interfaces
ArcoBASIC / language design

AI & Compute

Local LLM infrastructure
Agent workflows
AI-assisted engineering
Private/local-first AI systems
Model/tool integration

Creative Technology

Audio DSP
Music technology
Interactive media
3D workflows
Creative coding
Human-computer interfaces

People & Operations

Technical leadership
MSP operations
Troubleshooting & escalation
Documentation / SOP development
Client communication
Training & knowledge transfer

MOTIVE FORCE // CURIOSITY WITH CONSEQUENCES

Why I build

Curiosity is the common dependency.

I like opening black boxes, tracing assumptions, learning why something behaves the way it does, and then asking whether it could behave differently.

That instinct has taken me through infrastructure, operating systems, recovery engineering, programming languages, AI, music, DSP, games, interfaces, and hardware experiments.

I have an unfortunate tendency to respond to “there should be a better way to do this” by accidentally starting another project.

But curiosity is not the only reason I build.

One of my goals in life is to leave the world better than it was when I arrived. I do not expect that to happen through one grand invention. Sometimes it means building a safer recovery tool, making a confusing system understandable, helping someone regain control of their data, creating a better way to communicate, or making something that gives another person a new way to express themselves.

I do not expect to fix the world. I do expect to leave useful pieces behind.

Better tools. Clearer systems. More agency. More ways to create, communicate, recover, and understand.

If the world is even slightly more humane because I was here building things in it, that is enough reason to keep building.

DESIGN CONTRACT // HUMAN-CENTERED SYSTEMS

Systems philosophy

Intent over procedure: A person should be able to express what they are trying to accomplish without first memorizing the implementation.
State over mystery: Systems should communicate what they are doing, what changed, what is dangerous, and what can be undone.
Meaning over convention: “That is how software has always worked” is historical information, not a design requirement.
Agency over obedience: Good tools make people more capable. They should not train people to accommodate arbitrary machinery.
Graceful failure: Failure should preserve context, expose useful state, and provide a path forward whenever possible.
Local ownership: People should be able to understand, control, repair, and retain meaningful ownership of the systems they depend on.

ENGINEERING // ART

Technology as expression

I do not see engineering and art as opposing disciplines.

I make music, write, build worlds, experiment with interfaces, and design instruments because technology is also a medium. A computer can solve a problem, but it can also become part of how a person thinks, communicates, creates, performs, and explores.

That is why visual design, interaction, sound, language, and system architecture tend to collide in my work.

Structure and expression are not enemies.

TRANSHUMANISM // AUGMENTATION WITHOUT ERASURE

The human in the machine

My transhumanism is not about replacing the human being with the machine.

It is about using technology as an extension of human agency: better ways to communicate, create, understand, repair, remember, explore, and express ourselves.

I am interested in augmentation, accessibility, computing, alternate interfaces, local intelligence, and tools that expand what a person can do without demanding that they surrender ownership of themselves to use them.

Technology should adapt to people.

The evolutionary step I care about is not merely better machinery. It is a better relationship between the human and the machine.

PROFESSIONAL HISTORY // OPERATIONAL REALITY

Outside the lab

The experimental work on this site sits on top of years of professional technical operations: supporting businesses, maintaining infrastructure, troubleshooting systems, recovering data, managing technical work, documenting procedures, training others, and translating difficult problems into something people can act on.

I like ambitious architecture. I also know that eventually somebody has to make the thing boot, recover the file, explain the outage, document the fix, and answer the phone.