How ATLAS is built in the open, and how to take part

We are working toward AI that verifies its own code. Work like that should be easy for other people to check, so ATLAS is open at every layer: the models it runs, its code, its plans and its faults. Anyone can send us code, so we also keep limits that do not depend on anyone's goodwill.

open at every layer

Many AI coding tools send your code to a model behind a hosted API, such as OpenAI's. The model's weights, and the system around the model, stay out of view. ATLAS takes the other route. It runs open-weight models on your own hardware, and it needs no hosted model and no model-provider API key.

The models come from Hugging Face. For the default model, and for the lens and steering files, our registry holds a SHA-256 hash, and the download is checked against it when it arrives. A file that does not match is deleted, and the install stops. Some other models in the registry have no hash yet, and the installer says so. The check proves a file is the one we registered. It does not prove who made it, and the code says so.

The code around the model is public under the AGPL-3.0 licence, and so are the decisions. Plans sit on a public board. A bigger proposal goes through a written request for comments that stays open for seven days, and whatever is accepted gets recorded in the repository as an architecture decision record. A declined proposal is closed with its reason attached, "so the next person with the same idea finds it." We like that line a lot.

Faults are public too. The page for the current release lists the known issues in the 3.1 line. When one of our own issues turned out to be wrong in October 2026, it was corrected in place, with a dated note saying what had changed (#281). The one exception is a security problem, which stays private until its fix ships. Our note on how we handle security reports explains why.

who has come in

Open means anyone can send us code, and that is the point. By 5 October 2026, eleven people outside the lab had work merged into ATLAS, and one more had found a security problem, reported it privately and written the fix. They are all on our contributors page.

Outside work needs answers, and we are a small lab. We aim to respond to every pull request within five business days. In the week from 28 September, the first response to an outside pull request came after about eight hours at the median, and about two days at the longest. That is one week of data, so read it as such. We have also been much slower. Two pull requests opened in August waited about eight weeks for a reply. The five-day target did not exist then. We set it so that no pull request waits that long again.

the limits we keep

ATLAS runs commands on your machine, so a bad change in a release would run there too. That is why the limits here are strict.

The governance document has to settle how a project like this hands out power as it grows, and its first principle is: "Access follows trust built over time, never a count of pull requests." We build a tool that writes code, so we know how cheap a pull request has become. A count of them says little about a person.

Each rung takes time and comes with a specific, limited power. Even a maintainer, who can merge and promote a release candidate, cannot publish a stable release alone.

Time is not enough by itself either, so the limits on each rung are technical and do not depend on goodwill. Every path needs review from its code owner. Only maintainers can create branches, so write access cannot be used to run a planted workflow. Nobody, administrators included, can force-push or delete the main branches or move a release tag. Access is reviewed every quarter, six months of inactivity drops a rung, and promotions are announced in public, so anyone can see who holds power.

Releases get the same treatment. Only listed signing keys can make a valid release tag, and release images are built only by our automation, from the tagged commit, with signatures that name the workflow and tag that produced them.

The licence is a safeguard too. If the project ever goes quiet for sixty days or more, the governance document says it should be treated as open to forking, and the AGPL licence and the public artifacts let anyone continue.

the path of a change

Outside urgent fixes, a contributor's change follows one path, and none of the steps is there for ceremony.

You work from a fork. Only maintainers can create branches in the repository itself, because anyone who can push a branch could add an automated workflow to it and run that workflow with the project's permissions.

For the same reason, the checks on a pull request from outside the organisation do not start until a maintainer approves the run. GitHub already gives forks a read-only token and none of the repository's secrets, and our own automation is written so that it never runs a contributor's code with privileges. One workflow even says so in a comment. The pull request's title is read "through an environment variable, never interpolated into the script, so a crafted title can't run as shell."

The rules require approval from the owner of the code a pull request touches, every conversation resolved, and twenty-four required checks green. Those checks are test suites in Go and Python, static analysis, install tests on four Linux distributions, an end-to-end acceptance test and a review of any new dependency. If you push again, earlier approvals are dismissed, so the version that gets reviewed is always the last one.

Merged changes are squashed or rebased onto dev, which keeps the history in one straight line. A promotion from dev to staging to main moves the branch forward without new merge commits, so the commits that were tested are the commits that ship.

On staging, a release candidate is tested for at least three days before it becomes a release. Semantic versioning describes a pre-release as one that "is unstable and might not satisfy the intended compatibility requirements", which is the whole reason to have one. We have not actually done this yet. The 3.2.0 candidate will be the first under this process.

Each release tag is signed, and an automated check rejects any tag that is unsigned or signed by an unlisted key. Container images go out in two phases: every commit gets an immutable image, and the public names only move to it after every service has built and the tests have passed on that same commit.

Releases 3.1.4 to 3.1.6 did not take this path. Each was a security fix, the development line was not ready to release, and so each shipped as a hotfix from main and was then merged back into dev, as the release process allows. Urgent fixes will keep using that route.

how to join

Start with the board. The Start Here view lists issues that are ready, sized for newcomers and unclaimed, and there are only ever a few. "Ready" means a maintainer wants the change and has written acceptance criteria. Meet them and pass the checks, and the change merges. To take one, comment /claim on its own line. The contributing guide covers the rest, and our community page links to it.

You do not have to write code to help. Triage, documentation and translations all count, and so do hardware reports: send the output of atlas doctor from your machine. Reports from AMD, Apple Silicon and Vulkan setups help most.

Contributors keep the copyright to their work and grant the project a licence to use it. The terms are in the contributing guide. Read them before your first pull request.

what is still unfinished

One key can sign releases today, and there should be a second (#198). Release tags are signed and checked. Individual commits are not signed yet (#197). Changes from inside the lab also get less human review than a contributor's. They can go to dev through a logged bypass, and until the reviewer role is filled, review of them leans heavily on the twenty-four automated checks.

The public OpenSSF Scorecard for the project reflects these gaps, and the issues that close them are on the board.

sources

• ATLAS 3.1.6: the README and the model registry.
• CONTRIBUTING, GOVERNANCE, MAINTAINERS and the release process.
• The ATLAS Roadmap board and the 3.2.0 milestone.
• The hotfix pull requests for 3.1.4, 3.1.5 and 3.1.6.
• GitHub Docs, Events that trigger workflows and About code owners.
• Semantic Versioning 2.0.0.