Methodology

How AI-Atlas turns public work into an evidence map.

AI-Atlas reads the technical shape of public projects — architecture, implementation, training logic, evaluation, data work, infrastructure and documentation — then maps the strongest evidence across six AI domains.

Public repositories onlyCode never executedEvery score traceable

six-domain mapanimated preview

READ

public evidence

MAP

six domains

TRACE

back to files

The rules behind the map.

The interface is visual, but the underlying rules stay simple: prove capability with work that can be inspected.

Evidence over keywords

A repository matters because of what its implementation demonstrates, not because its README happens to contain popular AI terms.

Depth over repository count

A few substantial systems should carry more signal than dozens of thin wrappers, tutorials or near-duplicates.

Results stay inspectable

Every conclusion remains connected to the projects and files that produced it, so the Atlas can be checked instead of simply accepted.

Public work only

The map describes evidence visible in public GitHub repositories. It is not a judgement of everything a person knows or can do.

From repository to Atlas.

Select any stage to inspect what happens there.

from GitHub account

Inventory

1,000repositories per scan, at most

Builds the list every later step works from, as one fixed snapshot.

Public only
Owned by the account
Pinned commit

Output

Repository manifest

One entry per repository

One portfolio, six independent signals.

The result is a shape rather than a single label. Select a node to see what each domain represents.

Six-domain map

Select a node to inspect the domain

1 / 6

Atlas

Active domain

Machine Learning

Model architectures, training loops, optimisation, classical and deep learning method work — the mathematics and mechanics of learning systems.

Evidence to explore

Model and training implementation
Baselines and measured results
Reproducible experiments

What changes a score

The score rises when several strong projects independently demonstrate this capability, with deeper implementations carrying more weight than repeated surface-level examples.

Compare domain evidence

What makes project evidence strong?

A repository is useful evidence when its implementation shows technical ownership and depth. Mapping is free; optional planning credits pay for new AI roadmaps and merit scenarios.

Signal A

Technical depth

Implementation detail, architecture and engineering ownership matter more than surface area alone.

Signal B

Difficulty & originality

Projects gain weight when they solve meaningful problems, modify ideas or go beyond a thin integration layer.

Signal C

Completeness & usefulness

A coherent project with a working path from idea to result is stronger evidence than a disconnected experiment.

Signal D

Documentation & reproducibility

Structure and explanation help the evaluator understand what was built, how it works and which files support the claim.

From strong projects to a skills profile.

Aggregation is designed to preserve depth without letting repository volume dominate the result.

Strong work matters most

The projects with the clearest evidence have the largest effect on a domain.

Repeated evidence helps

Several substantial projects in the same area strengthen that part of the profile.

Quantity has diminishing value

A pile of shallow or near-duplicate repositories cannot overwhelm a few deeper systems.

Security guardrails for every scan.

AI-Atlas can inspect hostile or broken repository content without giving that content an execution path. The model reads project evidence; it does not run the project.

Scan security

Read the repository. Never execute it.

No repository execution

S01

Code stays inert

Repository files are read as text. AI-Atlas does not run scripts, install packages, build projects, launch binaries or invoke commands from a repository.

S02

Repository instructions are not commands

README text, code comments and prompt-injection-style instructions are treated as project content. They cannot redefine what the evaluator is supposed to do.

S03

Even malicious code is only inspected

If a repository contains code that would attempt remote code execution or another exploit when run, AI-Atlas still only reads that code as evidence. The payload is never executed.

RCE-like payload present ≠ payload executed

Included

What AI-Atlas is allowed to inspect for the map.

Public repositories owned by the account
Source code, notebooks, configuration and documentation
Repository metadata such as language, topics and description

Outside the map

Useful context that AI-Atlas intentionally does not claim to measure.

Private repositories
Work inside repositories owned by other people or organisations
Production systems, papers, mentoring or work that is not visible on GitHub

The methodology should make the Atlas easier to trust, not harder to read.

Map a public profile to see these rules expressed as an actual six-domain evidence shape.

Map a profile View the leaderboard