Project summary

I would say this whole thing started with a usage limit that I just couldn't get past.

I've always been somebody who, when something doesn't seem right, just can't leave it alone.

When the little guy at school was getting picked on, I was the one who would step in. When the quiet girl in the back of the classroom was too shy to raise her hand and ask to go to the restroom, I'd raise mine for her.

I wouldn't always stand up for myself, but I would absolutely stand up for somebody else.

And I guess that same part of me is what got me into this.

I would have been perfectly happy living my life in seclusion, playing with AI, experimenting with my computers, and seeing what I could make them do.

But then I started looking at who controls the computing power behind this whole AI revolution.

And I got concerned.

We're moving toward a world where access to compute determines who gets to experiment, who gets to build, and who gets to participate.

And the software underneath so much of that computing is controlled by a relatively small number of companies.

NVIDIA has built some incredible hardware. I own a DGX Spark myself.

But I started wondering whether we could develop another way to use that hardware.

So I started digging.

And I couldn't stop haha.

That eventually turned into Aien, an open-source research project I've been developing with the help of AI coding agents.

I've now demonstrated native GPU execution on my Spark without NVIDIA's proprietary CUDA user-space runtime.

That was exciting enough. I was over the moon!

But then something else happened....

While trying to make my swarm better at generating programs (it was really going some weird things with 50-100 of these going at once), I started questioning why we're making them communicate with computers through programming languages that were originally designed for humans.

As someone with AuDHD, I struggle with communication and human speak drives me up a wall. I am so bad with making my words sound like my brain intended it to sound. I just knew that somehow I was saying something wrong to claude to make the swarm act weird. So then I asked the question...

What if AI had its own language? Well, that's actually how this whole thing happened. And the funny part is, I wasn't trying to invent a programming language in the first place haha.

I was getting frustrated. The AI just kept LYING to me. All the time. So I decided I was going to do somethign about it and die every single token of that agent will be equal to a byte of data and that LLM was now GUILTY until it proves itself innocent by giving me a RECIEPT from a physical process or a calculation with a hash. To boot, I had AI built the semantic ID into the langauage so that it could be check from beginning to end and yeah, that's why I ended up wanted to go all the way to the root btyes so that an AI built on Omega can be verifed with a single hash function similar to how MathLib handles checking math proofs!

ANother thing!

I've been running a swarm, which is basically a bunch of AI agents working together on different parts of my projects. And they kept making these stupid little mistakes. JSON brackets, commas, backslashes, syntax errors, all this ridiculous stuff that would throw everything off.

I'm sitting here thinking, why the hell are we making these incredibly intelligent machines communicate with computers using all this human programming nonsense?

I mean, seriously. We're building AI that can reason through some incredibly complicated problems, but then we're making it count brackets and remember where to put a semicolon?

That just seemed ridiculous to me.

So I told my AI to come up with something better.

And here's the important part. I didn't tell it to invent another programming language for humans. I told it to figure out what language IT would prefer to use.

Forget what I want. Forget what programmers are comfortable reading. You're the one writing the code, so what would make YOUR job easier?

That's where Omegese came from.

It started as a shorthand to help my agents communicate computation without constantly tripping over all that syntax. Something simple, structured, and predictable that the AI could generate without having to keep track of a million little formatting rules.

And Opus 5.5 being… well, Opus 5.5, it started building haha.

But then I had another thought.

Why stop at a shorthand?

If we're already giving the AI its own way to describe what it wants the computer to do, why are we translating everything back into C or another human programming language just to execute it?

Why couldn't we take that representation and compile it directly into something the machine understands?

And that's when I started digging underneath C.

Now, I'm not a traditional programmer. I don't have decades of computer science experience. So when somebody tells me C is fast because it's close to the hardware, my first question is, okay, but HOW close?

What's underneath it?

And what's underneath THAT?

I couldn't leave it alone.

So I pointed my swarm at the problem and told it to dig.

That eventually led us toward a seed approach. Start with something incredibly small, build the compiler from that foundation, and work toward a system where Omega could compile Omega.

And here's where I really started getting excited.

What if Omega could become a common language between all our existing programming languages?

Not replace Python. Not replace Rust. Not replace C, Zig, or whatever language somebody loves using.

Let them keep their languages!

I want the AI to have its own.

Then we build bridges between them so the AI can communicate its computation through Omega and connect that work to the software people already have.

That's what Omega Bridge is intended to accomplish.

We've already built a restricted converter that takes checked Omega programs and generates C and Python. Going the other direction, taking existing C and converting it safely into Omega, is one of the big research problems I want to tackle next.

And I know what some of you are probably thinking.

Didn't we just reinvent another compiler?

Maybe! Haha. That's why I'm asking people who actually study this stuff to look at it.

But then something else occurred to me, and this is where the project started turning into an AI safety problem.

If the AI is going to have its own language, why should we allow it to make the same dangerous memory mistakes we've spent decades trying to eliminate?

Why not make the compiler responsible for catching those mistakes before the program ever runs?

And if we can prove that certain mistakes are impossible within a defined part of the language, then we don't have to rely on the AI remembering how to avoid them.

We can actually check.

That's the part I want to investigate properly.

Because I didn't start this journey trying to build another Rust.

I started because my AI couldn't stop screwing up its brackets, and I wanted to know what would happen if I let it design a language around the way it actually works.

And somehow that little experiment has turned into a much bigger question.

What if we could make AI-generated computation safer by changing the language underneath it, instead of just trying to train the AI to make fewer mistakes?

That's what I want to find out.

What if that language could connect to C, Python, Rust, Zig, and other existing languages without everybody having to abandon what they're already using?

And what if we could make certain kinds of dangerous programming mistakes impossible within a formally verified part of that language?

That's how Omega and Omega Bridge became central to the project.

And that's where I think this research becomes particularly important to AI safety.

We are building increasingly autonomous AI systems that write code, execute programs, call tools, and interact with computers.

What happens when one of those agents makes a mistake with memory?

What happens when it accesses something it shouldn't, frees memory that another process is still using, or accidentally corrupts the environment that's supposed to keep it contained?

My research goal is to investigate whether we can make the language, compiler, and execution system prevent those failures rather than relying on the AI to always make the correct decision.

I want to build a serious, independent research program around that question.

I'm seeking up to $10 million over 24 months, beginning with a $250,000 minimum funding milestone.

The money would fund compiler researchers, formal verification specialists, GPU engineers, independent security reviews, and a physical hardware laboratory with NVIDIA, AMD, and Intel systems.

I want to find out what we can actually prove.

And if my ideas are wrong, I want the evidence to show it for the advancement of Humanity.

One personal thing I should mention: I'm autistic, and AI has been an incredible way for me to communicate and explore ideas that I sometimes struggle to put into words.

I'm dictating much of this because I want you to read my voice the way that I speak.

I also use AI extensively to help develop and research this project. I'm being transparent about that because independently checking AI-generated engineering is one of the reasons I need this funding.

I love this stuff. I'm obsessed with seeing what we can do with it.

But I need people who know this field better than I do to help determine what actually works.

What are this project's goals? How will you achieve them?

The primary goal is to develop and independently verify a computing environment that prevents specific classes of memory-safety vulnerabilities in AI-generated and AI-executed programs.

I want to investigate five things.

1. Can we build a language specifically for AI to communicate computation?

This is the heart of Omega.

I don't want to replace the programming languages humans already use.

I want to give AI a language of its own.

One that is small, regular, mechanically checked, and designed to make generating valid programs as straightforward as possible.

Instead of an AI having to remember all the conventions of C, Python, Rust, or whatever else, I want it to describe a computation in Omega.

Then the compiler can determine whether that computation is valid and whether its requested operations are permitted.

There is already a seeded Omega compiler and experimental AI-oriented language work in the omega-mv repository.

The next step is evaluating that language scientifically.

Does it actually reduce AI generation errors?

How does it compare with existing languages?

Can we measure whether models produce valid programs more reliably?

And can we establish mathematical guarantees for a useful subset?

I don't want to assume Omega is better.

I want to test it.

2. Can Omega Bridge make existing code safer?

This is where things get really interesting.

The long-term goal for Omega Bridge is to connect existing programming languages through a common checked representation.

The bridge currently generates C and Python from a supported subset of Omega.

I'm interested in going the other direction.

What if we could take existing C code, analyze its memory ownership, pointer lifetimes, allocation behavior, and bounds, and translate the portions we can verify into safe Omega?

And what if the translator refused to proceed when it couldn't establish the necessary guarantees?

I'd like to research methods for preventing:

• Out-of-bounds memory access

• Use-after-free

• Double-free

• Unsafe pointer lifetime transitions

• Certain categories of memory leaks

• Invalid access to GPU memory

• Unsafe memory sharing between asynchronous tasks

This has to be done carefully.

Memory corruption and memory leaks are different problems. Preventing one doesn't automatically prevent the other.

And there are always assumptions at boundaries where programs interact with operating systems, drivers, hardware, and foreign libraries.

So the research needs to define exactly what can be guaranteed, under which assumptions, and how we test those guarantees.

My intention is to build something researchers can challenge mathematically, not just another compiler that claims to be safe because its own tests passed.

3. Can we make the execution layer safer even when AI-generated code is wrong?

This is where CUDApp comes in.

I already have an experimental GPU execution runtime running native Blackwell instructions on my NVIDIA DGX Spark.

But GPU programming introduces its own memory-safety problems.

You have buffers being passed around, memory being shared between the CPU and GPU, asynchronous execution, and situations where one part of the computer may still be using memory another part thinks is finished.

I want to research how to make those boundaries safer.

The compiler should understand what memory an operation is allowed to access.

The runtime should validate its commands.

The system should have ways to detect invalid memory use and reject dangerous operations before they execute wherever that is technically possible.

For autonomous AI agents, I also want permissions and execution evidence to remain under the control of an independent monitor.

An AI agent shouldn't get to grade its own homework.

And if something goes wrong, the system needs a way to stop the execution and revoke access.

That's an important connection between memory safety, cybersecurity, and AI safety.

4. Can we test all of this on different hardware?

Right now, my primary GPU research machine is an NVIDIA DGX Spark.

That's a start, but it's not enough.

I want more Sparks.

I want AMD processors and GPUs.

I want Intel GPUs.

I want discrete NVIDIA GPUs.

And I want dedicated machines that can be used for testing without interrupting everything else.

Different hardware means different memory architectures, drivers, synchronization rules, and opportunities for things to go wrong.

I want to investigate all of them.

The goal is a cross-vendor hardware research lab that can reproduce memory-safety experiments, compare execution results, test driver changes, and deliberately inject failures.

I also want to test whether the same Omega computation can be executed correctly through different backends.

Some architectures will require entirely new backend development. Buying hardware alone doesn't establish software support.

But without the hardware, we're going to be guessing.

And I've done enough guessing.

5. Can we develop a repeatable safety evaluation for AI-generated systems code?

This may be one of the most valuable parts of the whole project.

I want to assemble a collection of real and deliberately defective programs.

Memory leaks, corrupted pointers, missing cleanup paths, stale GPU buffers, unsafe concurrency, invalid array access, and everything else we can reasonably test.

Then I want AI models to generate solutions to the same problems in different languages.

We measure the mistakes.

We measure which errors each compiler catches.

We measure which unsafe programs are rejected.

We measure the runtime overhead.

And we try to establish formal proofs for the properties that can actually be proven.

We'll also deliberately damage the compiler and test system to make sure our tests can detect a wrong result.

Everything gets published.

I want independent reviewers to be able to reproduce the experiments and challenge the conclusions.

And I want this evaluation to be useful to researchers outside AIEN.

How will you know it worked?

This is probably the most important question.

Because I've learned something about working with AI.

It can be incredibly convincing when it's wrong.

And when you're working at the level of compilers and GPU instructions, you cannot just take its word for anything.

So my approach is simple.

Show me the evidence.

For the first stage, success means we can publish a reproducible safety evaluation using the existing Omega compiler and Bridge.

We need an explicit list of which operations the compiler supports, which memory-safety properties it checks, and which cases it refuses.

Then we need tests designed specifically to break those claims.

Within six months, I want a documented C-to-Omega translation prototype for a restricted language subset, with differential tests comparing the original programs against the translated versions.

Within twelve months, I want independent researchers evaluating the compiler, its safety rules, and the generated code.

I also want automated GPU memory-safety testing running on more than one hardware architecture.

At twenty-four months, the goal is a publicly available research platform that includes:

• A machine-readable specification of a verified Omega subset

• A translator with clearly documented input-language coverage

• Formal proofs or independently checkable proof artifacts for selected memory-safety properties

• A reproducible adversarial test corpus

• A cross-vendor hardware testing environment

• Public reports of vulnerabilities discovered and corrected

• Reproducible comparisons against existing tools and languages

• Integration with existing open-source AI software

A successful proof must state its assumptions. A compiler's guarantee is only as strong as the parts of the system that guarantee depends upon.

For the supported verified subset, I want every deliberately injected violation of the defined safety rules either rejected or caught by the qualified checker.

For unsupported cases, I want explicit refusal rather than an invented safety guarantee.

I also want independent researchers to attempt to falsify our claims.

If they find a memory-safety violation in something we claimed was safe, that is a serious result. We investigate it, correct the specification or implementation, and publish what happened.

Memory safety will not guarantee that an AI is aligned, truthful, or harmless.

But it can remove important classes of vulnerabilities from the systems those AIs operate inside.

That's a meaningful research objective on its own.

And if we can demonstrate it, other projects should be able to use the results.

How will this funding be used?

Okay, this is where I want to go bigger.

I initially thought about asking for enough money to buy some more hardware and keep working on the project myself.

But the more I've researched this, the more I realize that doing it properly means involving people who have spent their careers studying compilers, formal verification, computer security, and hardware.

I don't just need more GPUs.

I need a research team.

So I'm proposing a four-stage, 24-month program.

These are planning budgets, not vendor quotations or commitments from researchers. Every phase would have its own spending report and technical acceptance criteria.

Minimum funding: $250,000 — First 90 days

The first stage establishes the core research team and safety evaluation infrastructure.

UseBudgetCompiler, systems, and formal-methods research contracts$150,000Initial hardware laboratory$35,000Independent security and architecture reviews$35,000Test infrastructure, storage, and research compute$15,000Contingency$15,000Total$250,000

The hardware budget would support approximately three additional DGX Sparks, an AMD CPU/GPU testing system, an Intel GPU test system, and basic measurement equipment.

I want one Spark for development, one for reproducibility testing, and another available for destructive experiments and regression testing.

We need to be able to break things without bringing the rest of the project down.

The main deliverables are a published memory-safety threat model, compiler capability inventory, initial adversarial test corpus, independent architecture review, and reproducible safety test results.

$1 million cumulative — Six-month research milestone

Additional funding required: $750,000.

At this level, I want a dedicated team developing the restricted C-to-Omega converter and formal memory-safety specification.

We would expand the GPU laboratory, begin testing additional NVIDIA architectures, and establish AMD and Intel development targets.

The focus becomes verifying ownership, lifetimes, bounds, and failure behavior across language and runtime boundaries.

We would publish our first comparative evaluation of AI-generated programs in Omega and conventional languages.

The goal is to establish whether this language design actually provides measurable safety benefits.

Not because we think it should.

Because the evidence says it does.

$4 million cumulative — Twelve-month research milestone

Additional funding required: $3 million.

This is where I want the project to become a proper independent research laboratory.

The team would expand to cover compiler verification, language translation, GPU execution, security testing, and release engineering.

We would build a larger automated hardware test environment using NVIDIA, AMD, and Intel systems.

I want formal verification specialists investigating the compiler's guarantees and independent security engineers deliberately attempting to break them.

We would also begin working more closely with existing open-source frameworks.

The point is not to make everybody switch to Omega.

It's to make the safety research usable by people who already work in C, C++, Rust, Python, and existing AI software.

$10 million cumulative — Full 24-month program

Additional funding required: $6 million.

At this level, I want to establish a sustained open-source computing safety research effort that can continue beyond my personal involvement.

That includes long-term researchers and maintainers, an expanded hardware laboratory, independent audits, public benchmarking infrastructure, and support for external contributors.

I want formal verification work to proceed alongside implementation, not months afterward when somebody discovers that the assumptions were wrong.

I also want to investigate more complex cases involving concurrency, GPU memory, foreign-language interfaces, and autonomous agent execution environments.

The ultimate deliverable is an independently reviewed, openly maintained research platform for safer AI-generated systems computation.

And if it works, I want the results contributed to the broader open-source ecosystem.

Who is on your team? What's your track record on similar projects?

My name is Drake Stapleton.

I'm an independent engineer based in Springfield, Missouri. My background is in aerospace engineering, chemistry, and biology.

I'm also autistic, and I came into computer science through my interest in artificial intelligence rather than through a traditional software engineering career.

I don't claim to be a formally trained compiler researcher.

I know that's going to make some people question whether I should be leading something like this.

That's fair.

But I've spent a tremendous amount of time developing and coordinating AIEN, and I have working software and public repositories that other people can inspect.

I'm building the project using AI-assisted engineering.

That means AI systems help generate source code, investigate technical problems, develop tests, and explore possible implementations.

My role is to define the research direction, challenge the assumptions, coordinate the work, and determine what evidence is needed.

The existing work includes:

CUDApp: An experimental GPU runtime that executes native Blackwell GPU instructions on the NVIDIA DGX Spark without the proprietary CUDA user-space runtime.

Omega: A programming language and seeded compiler with bounded operations, experimental AI-oriented representations, and a developing verification framework.

Omega Bridge: An interoperability project that currently generates C and Python from a supported subset of Omega, with a broader language-conversion roadmap.

AIENOS: An experimental operating-system and execution environment for locally owned AI systems.

The main code repositories are public under the GitHub organization aien-dev.

Relevant projects:

• https://github.com/aien-dev/CUDApp

• https://github.com/aien-dev/omega-mv

• https://github.com/aien-dev/omega-bridge

• https://github.com/aien-dev/ggml-omega

These are research-stage projects. A successful experimental result is not the same as an independently audited production system.

And that distinction is important to me.

The formal research team has not yet been assembled.

The first funding milestone would allow me to recruit people with expertise in programming-language theory, formal verification, GPU architecture, memory safety, and adversarial security testing.

I want people who will disagree with me when the evidence demands it.

Especially then.

Because I don't want to build an echo chamber full of AI agents telling me I solved every problem in computer science.

I want to find out what I've actually built.

What are the most likely causes and outcomes if this project fails?

I think there are several ways this project could fail.

The first is that Omega may not provide a meaningful advantage over existing languages and tools.

Rust already has a sophisticated ownership model. Existing compiler research has spent decades investigating memory safety.

We may discover that important parts of what I'm trying to accomplish are already better addressed elsewhere.

If so, we should publish that result and contribute whatever useful work we've developed to those projects.

Another possibility is that translating existing C code safely is much harder than anticipated.

Some programs depend on behaviors that are difficult to preserve or verify.

The converter may need to reject a substantial amount of real-world code.

If that's what the research demonstrates, we narrow the supported subset and publish the limits.

Hardware is another major uncertainty.

My current native GPU work is concentrated on the DGX Spark.

Other NVIDIA architectures, AMD GPUs, and Intel GPUs have different interfaces, drivers, and memory behavior.

Getting the same guarantees across all of them may require significantly more work than expected.

There's also a serious concern about using AI-generated code to develop a safety-critical system.

If the compiler itself has bugs, it could accept programs that violate the guarantees we're trying to establish.

That's why I want independent implementations, negative controls, formal verification, and external reviewers.

Finally, the project could fail because we can't assemble the right team or maintain the work over time.

Right now, too much of the project depends on one person.

The funding is partly intended to change that.

If the full research program fails, I still want it to produce something useful:

A documented experimental language, a corpus of memory-safety tests, independent evaluations, hardware research, and open-source components that other people can continue working on.

I want the knowledge to survive even if a particular implementation doesn't.

And I'm willing to publish results that contradict my original ideas.

That's science.

How much money have you raised in the last 12 months, and from where?

My earlier AIEN proposal on Manifund currently shows $0 raised.

I've been developing this project using my own time and existing equipment, including my NVIDIA DGX Spark.

Other grants, donations, sponsorships, or outside funding received in the last 12 months: [Enter any additional funding received, with amounts and sources, before submission.]

I'm now seeking institutional and community funding so the research can be independently examined and expanded beyond what one person can accomplish.

I want the funding process to be transparent, just like the technical work.

Final thoughts

I know $10 million sounds like a lot of money. There will be a full budgeted breakdown that has a complete and transparent audit trail. I may use AI for engineering but I can assure you, I am the one in control of this ship. We are going virticle and over the last 4 weeks, I have accomplished the equivelant of the entire human programming history. That is not meant to make humans feel small. That is make to wake people up to realize the dangers this can pose if we continue to let it go unrestricted in a programming language (C) for any longer.

And yes, there is RUST. That is the point. Rust is meant for the humans and Omega is the AI language. I have built a universal converter that will translate C programming language to Rust, Python, Zig, Go, and more. Since Omega is a SEMANTIC programming language, the programs' meaning can be translated rather easily into other langauges.

Believe me, I know.

I started this because I was annoyed by a usage limit, and now I'm sitting here talking about programming languages, memory safety, GPU architecture, and building an entire research laboratory.

That's a pretty ridiculous journey when I say it out loud haha.

But the more I work on this, the more convinced I become that these are questions worth investigating properly.

We're giving AI systems more and more authority over our computers.

We're allowing them to generate code, execute tools, manage information, and make decisions.

And I think we should be investing just as seriously in the foundations that make those systems safe to operate.

I don't believe the answer is to trust the AI more.

I believe the answer is to build systems that can check what the AI is doing.

Systems where we know exactly which rules are enforced, where the boundaries are, and what happens when something goes wrong.

If the AI generates a program that violates those rules, the compiler should catch it.

If it tries to access memory outside its authority, the execution environment should prevent it wherever the verified protections apply.

And if the system claims something is safe, there should be evidence that somebody else can check.

That's what I want to build.

I'm not asking anybody to believe I've already solved memory safety or replaced CUDA.

I'm asking for the resources to find out how much of this we can actually accomplish.

With real researchers.

Real hardware.

Real experiments.

And results that anybody can inspect.

I love artificial intelligence, and I genuinely believe it can help humanity accomplish extraordinary things.

But if we're going to keep building more capable AI, I want the computing systems underneath it to become safer at the same time.

And I want that research to stay open.

For Humanity.

Thank you for taking the time to hear me out.

Best,

Drake Stapleton