I build a lot of different things because I am interested in a lot of different areas of technology. Software engineering, automation, AI, cybersecurity, infrastructure, game development, digital media, hardware, and other areas tend to overlap more than people give them credit for, so I stopped treating every project like it needed to exist by itself.

That eventually became Ghost Five.

Ghost Five is the structure I use to organize the different systems, projects, specialist teams, experiments, and infrastructure I build. Ghost Five Actual is me, the human operator behind it. The point is not to pretend there is some massive company sitting behind these repositories. A lot of this is still me sitting at a computer, finding something I want to understand or a problem I want to solve, and deciding to see how far I can take it.

Instead of trying to keep all of that in my head, I build systems around it.

Some projects become standalone applications. Some become developer tools. Some turn into autonomous or agent-assisted systems. Some fail completely. Some start as a small experiment and turn into something much larger than I expected.

That is part of the process.

A language for turning what you intend to happen into a system that can prove how it will happen.

VECTIS started from a problem I kept running into while building increasingly autonomous systems: it is easy to tell software what you want it to do, but it becomes much harder to prove exactly what it understood, what it planned to execute, what authority it had, what actually happened, and why the result should be trusted.

I did not want another automation framework where the interesting parts disappear into a black box.

So I started building a language.

VECTIS parses a mission, validates it, compiles it into an inspectable execution graph, and runs it through explicit runtime and capability boundaries. Values, dependencies, assertions, branches, capabilities, execution state, provenance, and published results remain visible instead of disappearing once execution begins.

The project now includes a custom language, parser and compiler pipeline, deterministic execution model, structured values, reusable functions, modules, assertions, capability-aware actions, execution receipts, provenance, CLI tooling, Mission Control, and Language Server Protocol support.

It is still growing because every time I use it to solve another problem, I find another part of automation that I think should be easier to inspect, explain, or verify.

View VECTIS →

Your money. Your computer. Your data.

OwnLedger is a free, open-source, offline-first personal finance and financial decision application.

It started as a budgeting application and kept expanding because personal finance does not stop at a monthly budget. It now covers income, bills, debt payoff, savings goals, investments, net worth, payroll and tax estimation, affordability decisions, reporting, backups, and other areas that affect how someone actually manages their money.

I specifically built it to work locally.

I do not think I need access to someone's bank account, income, debt, budget, or financial history just because they want to use software I wrote. OwnLedger does not require an account, bank connection, subscription, advertising system, analytics platform, or cloud financial database.

That privacy model is part of the architecture, not a marketing feature added afterward.

View OwnLedger →

GitLedger exists because GitHub accounts get messy.

Coursework, experiments, abandoned ideas, forks, old portfolio projects, prototypes, private applications, production projects, and repositories you forgot existed eventually pile up. I wanted something that could help me understand the state of an account before I started deleting or archiving things manually.

GitLedger provides repository auditing, portfolio intelligence, lifecycle management, archival workflows, exports, review tools, and safer repository cleanup.

It follows a fairly simple philosophy: understand what you have before you start destroying it.

That sounds obvious until you have enough repositories that it stops being obvious.

View GitLedger →

Not everything inside Ghost Five is public.

Some systems are operational infrastructure. Some are still experiments. Some contain integrations, internal data, autonomous workflows, or implementation details that I am not ready to release. Others may eventually become standalone open-source projects once I think they are useful enough outside of my own environment.

The system is organized around specialist teams instead of one giant agent or application trying to do everything.

Spectral Core handles software engineering and developer systems. Grave Shift focuses on cybersecurity and authorized security training. Shattered Veil handles OSINT and research. Death Echo focuses on gaming and strategy systems. Phantom Pulse works in entertainment and media. Other specialist teams cover areas such as game development, digital asset creation, hardware, e-commerce, opportunity discovery, and infrastructure.

They are different domains, but the idea behind them is the same: build focused systems that can become genuinely capable in their area while still being able to work as part of something larger.

Ghost Five Actual sits above that structure as the operator.

A lot of my projects start with something I do not know how to build.

That is intentional.

I would rather pick a problem that forces me to learn something than spend all of my time rebuilding things I already understand. That has meant learning language design because I wanted better automation, building local AI infrastructure because I wanted to understand where it was actually useful, working through security labs because reading about security is not the same thing as doing it, and building complete applications because a collection of isolated code examples does not teach the same lessons as maintaining a real product.

I tend to prefer systems with visible state, useful logs, explicit boundaries, repeatable execution, and enough documentation that I can come back months later and understand why I made a decision.

I also like local-first systems when local execution makes sense. Not everything needs an account. Not everything needs a cloud backend. Not everything needs telemetry. Not every problem needs another subscription.

Sometimes software can just do the job it was built to do.

Most of my current work revolves around Python, JavaScript, TypeScript, React, Electron, FastAPI, PostgreSQL, Redis, Docker, Linux, Git, GitHub, APIs, local AI models, automation systems, agent orchestration, and custom developer tooling.

The specific stack matters less to me than whether it makes sense for the problem.

I am interested in building complete systems, not collecting technologies for a badge wall.

If I build something that could genuinely be useful to somebody else, I would rather release it than leave it sitting on one of my computers doing nothing.

That does not mean every experiment needs to become a startup, subscription, course, or product. Sometimes the useful thing to do is release the source code and let somebody use it, fix it, improve it, fork it, learn from it, or take it somewhere I never would have.

I also do not think open source should mean uploading code and acting like nobody else gets a say afterward. If you find a bug, open an issue. If you know a better way to solve something, submit it. If the interface is bad, redesign it. If the documentation is confusing, improve it. If you can test something on hardware or an operating system I do not have, that is useful too.

You do not have to ask permission to make something better.

You do not need to sponsor me to use the projects I release.

I am not interested in deliberately making a worse version of something because somebody did not pay me, hiding the useful features behind sponsorship tiers, or turning every interaction into another opportunity to monetize somebody.

If you find the work useful and want to support more of it, GitHub Sponsors helps with development hardware, infrastructure, testing equipment, services, and the other costs that come with building this much stuff.

Sponsor GhostFiveActual →

Money is not the only useful contribution. Testing, bug reports, documentation, code, design work, ideas, and simply sharing something with someone who could use it all matter.