How it's counted

A landed change is one unit of your own work that reached a project's default branch, found by walking the first-parent history. There are three kinds:

• A pull request merged into the default branch (merge commit, squash or rebase), credited to its author.
• A merge commit that is not a pull request, credited to the merge's author or committer. One merge counts once, however many commits it brings in.
• A direct first-parent commit, credited to its author.

Own work only. A change counts when its author is an identity you confirmed: your git names and emails, bots you marked as yours, or your GitHub login for pull requests. Teammates' changes in shared and company repos never count; they only decide whether the project is team work.

A project is one repository. A monorepo is one project. Contributions to someone else's public repo form a contributor project that holds only your merged pull requests.

• A direct commit within 30 minutes of the previous counted change in the same project folds into that change.
• Pull requests merged within 2 minutes of each other count once.

Folded changes stay visible in the change list, greyed out, with their reason.

A change is trivial when it changes 5 or fewer lines, or touches only docs, text, lockfiles or whitespace. A trivial change counts only when someone else reviewed or merged it. A direct push is a self-merge, so a trivial direct push counts 0.

Open source counts double. Team work counts a bit more. Everything you ship counts. Each project's landed changes are scaled by where the work landed, then rounded down, before h, i10 and the weighted score are worked out.

Every project shows its real name. Where you built it is yours to say: from your profile you can add a company or place name with a link to any project, or hide the project. That is separate from the weight: a team repo with no teammates in its history counts x1.

What counts as real open source

• It is a public repo you don't own.
• Someone else merged your pull request, not you.
• The project has outside users: 50 or more stars, or 5 or more contributors.

The server checks all three on GitHub, so a project counts x2 only once it has been checked. Until then, or if the project misses the gate, it counts x1 and the profile says why in a line under the row, for example "counts x1: no outside users yet". Pull requests your agent lists from repos you don't own are checked the same way and appear as one open-source project per repo. A repo is counted once: in a project your card already lists, only the pull requests someone else merged move into the open-source row at x2, while direct pushes and pull requests you merged yourself stay at x1.

landed(p) = your landed changes in project p, after folding and the trivial rule
w(p)      = 2 open source (verified) | 1.25 team (teammates in its history) | 1 everything else
eff(p)    = floor(w(p) × landed(p))
h         = the largest h such that h projects have eff(p) ≥ h
i10       = number of projects with eff(p) ≥ 10
landed    = sum of landed(p)        shipped = projects with landed(p) ≥ 1
live      = projects that are LIVE

h 6 means 6 projects, each counting 6 or more landed changes. This is the builder h-index, borrowed from the academic one. Hiding work can change the current h-index; your handle color keeps the highest h you have reached.

You edit how a profile reads: photo, name, bio and links. The numbers are read from your history and locked, and show a lock instead of a pencil: landed, difficulty, the live check, open source, points, h and niche rank.

• A disagreement about a number never changes it. Your agent asks what it missed and looks. If the helper skipped a folder or a repo, your agent runs the helper again on it, and the helper's own number moves: it is the same count on more evidence, with no limit on how many times.
• If the sessions show something the files don't (a plugin that runs inside another program, say), your agent may move difficulty by one step, once per axis, and the reason is printed on the project.
• Every project has a "How this was judged" panel with the lines behind its score.

Points come from evidence. On the Overall, Field and Area boards the weighted score only breaks ties between equal h, so nothing here can move anyone past a higher h. Niche boards are the exception: they rank by niche score, below.

status(p) = COMMITTED (1-2 landed) | LANDED (3+) | LIVE (a live check passed)
L         = COMMITTED 1 | LANDED 2 | LIVE 2.5 to 3.5, by who checked and how far
D(p)      = Scope + Ops + Longevity + Depth + Integration, 0-15
tier_mult = D 0-3 → 1 | 4-6 → 2 | 7-9 → 4 | 10-12 → 7 | 13-15 → 10
R         = last landed change within 6 months → 1.0 | within 12 → 0.75 | older → 0.5
points(p) = round(10 × L × tier_mult × R)

• Scope, from landed changes: 0-2 → 0, 3-9 → 1, 10-49 → 2, 50+ → 3.
• Ops, from the live evidence and a check now: 0 none, 1 deployed once, 2 live now and bound to the repo, 3 as 2 for 90 or more days. Contributor projects get 0.
• Longevity, from distinct months with landed changes: 1 → 0, 2 → 1, 3-5 → 2, 6+ → 3.
• Depth and Integration (0-3 each) are computed by the helper from what is in the repo: native code, a database, sign-in, payments, background workers, several services and the like (several deploy targets alone count 2; with a database, sign-in, payments or workers 3). Your agent may move one axis by one step for what only the sessions show, and says why.
• Clamps: Depth and Integration are at most Scope + 1. D 10-12 needs Scope 2+ and Longevity 2+. D 13-15 needs Scope 3 and Longevity 3. A project that misses a gate drops to the highest tier it meets.

No line counts go into the score.

Example: a project at D12, live and verified, with a recent change scores 10 × 3 × 7 × 1.0 = 210 points. Where the work landed changes the count that h uses; it does not change points.

One rubric for every project. Your own agent does the checking. The level can never be higher than the evidence the helper finds in the code: deploy files, recent deploys, monitoring, payments and on-call config.

• LIVE · VERIFIED (solid): our server fetched a URL and it answered, and the URL is tied to your public repo (the repo's homepage or its CNAME file names it) or the package is published and names your repo. LIVE · AGENT (dashed): your agent checked it, the URL stayed on your machine, or our server could not tie it to a public repo of yours.
• Whether users or payments exist is your agent's report, capped by what the helper found, for verified projects too. A public URL that fails our check holds a project at LANDED.
• "Not checked" is a label, not a score. When the files show a deploy but your agent made no live check in its run (a sandbox without network never ran curl), the project says "not checked" and lists what the helper found, such as a deploy config or a payments SDK, instead of "local only". It counts as level 0, so it is LANDED with the same points as local work, until a check is recorded. Your agent curls the production URL of every such project; if the network is blocked it asks you once to allow it, and a project it could not check stays "not checked". A project your agent did check and found nothing live still reads "local only".
• When the URL answered but your agent left a project below what the evidence allows, it says why from a short fixed list (an invite-only demo, staging only, the URL is not the product, not launched yet, an internal tool), and the project's "how this was judged" panel shows it.

Checked by your agent is always half a point under verified at the same level. Contributions to other people's projects keep one rule: a verified live URL or package is LIVE at 3.0, never higher.

• Overall, Field and Area boards rank by h-index within the node, then by weighted score. The node's numbers come from the builder's projects in that node.
• Niche boards (the smallest groups) rank by niche score, then niche h, then weighted score.
• Equal scores share a rank.
• A builder is on a board only when a project in it has at least one landed change.
• Each card leads with a best node: among the nodes with 3 or more builders, the one with the best rank. When two tie, the more specific node wins. If no node has 3 builders, it is the niche of the top project.

More shipped work should count for more, without letting raw volume swamp difficulty. Each project's points are scaled by how much landed (after the team and open-source weight), then your best five projects in the niche are added.

niche points(p) = points(p) × (1 + log2(1 + eff(p)) / 8)
niche score     = top + 0.8 × 2nd + 0.6 × 3rd + 0.5 × 4th + 0.4 × 5th   (of the niche points, best first)

Doubling the landed count adds about 0.12 to the factor, and it tops out near ×2.8. Difficulty and the live check still matter more.

Where a project is placed

Each project sits in one niche. If you think one is in the wrong place, you can ask to move it from your profile: your agent checks that the code fits the new niche first. A move changes which board the project counts on, never its points, and it shows in the project's "How this was judged" with the date.

Work from a second computer or a dev server can be added to a profile with a private, single-use link. A repo with the same history counts once, new projects and sessions add up, and the owner sees what changed, with an Undo.

A handle's color comes from the highest h it has reached. Colors have no names on the page; hover a handle to see its range.

• VERIFIED: a public repo, a GitHub profile that lists your X handle, and a server recount against GitHub. Changes GitHub does not confirm drop out of the count. The only thing a check can raise is the open-source weight.
• Everything else counts the same. A private repo, company work or a public repo whose GitHub login is not linked to your X handle has no VERIFIED label, and no discount.
• UNCHECKED: GitHub could not be reached for the project (an outage or a rate limit). It counts as sent, with no VERIFIED label. It never blocks a claim, and a later check can only settle it as VERIFIED.
• CHECKS PENDING: no check has run yet. The project counts as the card sent it until one does.
• GIT ONLY: found in git history with no agent session behind it.

Live sites are fetched by the server and need to answer 200. Every number on a profile links to the changes behind it.