On 2 August 2026 I opened a pull request to github/awesome-copilot and GitHub's Agent Governance Toolkit flagged my account HIGH risk. The signals were recent_repo_burst (29 repos in 90 days), awesome_fork_burst (15 awesome-list forks in 72 hours, labelled "credibility farming") and cross_repo_spread (issues across 9 repos). Every number was accurate. I did fork fifteen awesome-lists in three days. The flag was right about the pattern and wrong about the intent, and that gap is not a bug in one toolkit — it is the structural failure mode of every reputation system being built for the agentic era right now, because cadence is cheap to measure and content is expensive to evaluate.
What I actually did
I built a set of free calculators for AI cost, energy and agent-verification economics, published them at piszczek.pl/tools, wrapped them in an MCP server on npm, and then went looking for the places where people who care about that topic would find them. Awesome-lists are one of those places. So over a weekend I forked fifteen of them, read each list's contribution guidelines, and wrote one entry per list in that list's own format.
That is fifteen forks in seventy-two hours. On a time-series that is indistinguishable from someone farming stars. I want to be plain about this before I make any argument at all: I generated the pattern. Nobody misread my data. If I saw the same graph on someone else's account I would raise an eyebrow too, and a maintainer of a list with tens of thousands of stars, fielding a constant stream of low-effort self-promotion, has every reason to be suspicious of a stranger who shows up with a burst.
The submissions were genuine. One entry per list, no duplicate spray, all pointing at the same MIT-licensed project. But "the submissions were genuine" is a claim about my intent, and intent is precisely the thing a scoring system cannot see.
The mechanics of the flag
What makes this case worth writing about is that the toolkit told me exactly what it thought. The output was not a number. It was three named signals with values attached:
recent_repo_burst: HIGH — "29 repos created in last 90 days"awesome_fork_burst: HIGH — "15 awesome-list forks within 72 hours (credibility farming)"cross_repo_spread: MEDIUM — "Issues filed across 9 different repos"
Alongside that sat some context the scorer had but did not weight heavily: account age 5687 days, roughly fifteen years. 64 public repos. 11 followers.
The CI checks on the PR all passed. The flag is advisory — it surfaces to a human reviewer, it does not block a merge. That design choice matters and I will come back to it.
Look at what these three signals have in common. Every one of them is a derivative with respect to time. Repos per 90 days. Forks per 72 hours. Repos touched per unit of activity. Not one of them looks at what is inside a single one of those repos, forks or issues. The scorer measured how fast I moved and inferred why from the speed.
Why this is structural, not a bug
The obvious reaction is that the heuristic needs tuning. Raise the fork threshold, discount for account age, add an exception for accounts over ten years old. That fixes my case and misses the point.
Cadence signals dominate these systems for a good economic reason. Evaluating whether a submitted project is actually useful requires reading code, following links, forming a judgement about quality — expensive, slow, and hard to automate defensibly. Counting forks per hour is a database query. When you are building a governance layer that has to run on every PR to every repo in a large ecosystem, the cost differential between those two operations is not a detail, it is the whole design constraint. Cheap signals win. They should win, given the budget.
The predictable consequence is that these systems classify on a variable that carries almost no information about intent. An honest builder doing a concentrated push and a farmer gaming the commons produce the same time-series. That is not a statistical near-miss that better calibration will resolve; the two populations genuinely overlap on the measured axis, because the measured axis is speed and both populations are fast.
And the overlap is widening. Agents make bursts cheap for everyone. A person willing to spend a weekend on fifteen careful submissions used to be self-selecting — the effort was itself a weak signal of sincerity. That signal is now gone. An agent can produce fifteen individually-adapted, guideline-compliant PRs in an afternoon on behalf of someone who never read a single contribution guide, and it can produce them in whatever cadence pattern evades the current thresholds. Velocity heuristics are being adopted at exactly the moment velocity stops meaning anything.
The part where my own metric comes back at me
I have published a metric called Proof-Adjusted Autonomy:
PAA = P(A) × P(C|A) × P(R|A,C) × P(T|A,C,R)The argument behind it is that autonomy is not what an agent does, it is what an agent can prove it did — attempted, completed, verified as correct, and delivered in time, with each term conditional on the one before it. An agent that completes a task but cannot produce evidence of correctness has a low PAA no matter how much work it performed.
Sitting on the receiving end of that principle is instructive. My work was real. My evidence, from the scorer's position, was a cadence graph. The chain broke at the third term: attempted yes, completed yes, verifiable — not by anything the reviewer had in front of them.
What stings slightly is that cheaper proofs already existed and were not read. The project is in the official MCP Registry under pl.piszczek/ai-economics, a namespace that required DNS verification of a domain I have owned for years. It is archived on Zenodo with DOIs. It is in Software Heritage. There is an ORCID attached. The account is fifteen years old. None of these are expensive to check — most are a single API call each, all are machine-readable, and several are harder to fake than the cadence pattern that was actually used. A DNS-verified namespace costs a domain and a TXT record. Fifteen forks cost fifteen clicks.
My motto is nullius in verba — take nobody's word for it. I have written a fair amount about why claims should carry proofs. It is a strange thing to find that the proofs exist, are public, are standard, and that the verifier does not read them.
What I would change
Four things, in rough order of how cheap they are to implement.
Read the credentials that already exist before falling back on cadence. Domain-verified registry namespaces, DOIs, ORCID identifiers, signed commits, package provenance attestations — these are structured, resolvable, and already deployed. A reputation check that resolves two or three of them before computing a forks-per-hour derivative is not doing expensive content evaluation; it is doing cheap credential lookup, which is a different and much better-behaved category of work.
Weight cadence by whether the submissions are identical. Fifteen copies of the same paragraph pasted into fifteen lists is spam and looks like spam under any diff. Fifteen entries each written to a different list's stated format is a different behaviour that produces the same count. Similarity across a submitter's open PRs is trivially computable — normalized diff distance, a shingle hash, whatever you like — and it separates the two populations far better than the raw rate does. It is roughly as cheap as the count itself.
Keep publishing the signal names. This is a genuine compliment to the toolkit's design and I want it read as one. Because the signals were named, machine-readable and attached to their triggering values, I could see precisely what had fired and why. I understood the accusation. I could respond to it on its own terms, on the PR, in public, and tell the maintainer plainly that the burst was mine and that an easy "no" was available to them if they were not comfortable. A black-box risk score would have left me guessing at what I had done, and my only options would have been silence or a vague protest. Transparency in the signal made a fair-minded response possible.
Give the flagged party a way to attach evidence. Right now a flag is a one-way notice. There is no structured slot for "here is a DOI, here is a DNS-verified namespace, here is an ORCID, please re-score." Adding one costs a field and a re-check, and it converts a scarlet letter into an adjudication. Systems that accuse without an appeals path do not get more accurate over time, because they never find out when they were wrong.
Close
I stopped submitting to GitHub lists for about two weeks after this and moved effort to channels where the unit of credibility is not a fork: Zenodo, ORCID, Software Heritage, Wikidata. That is a reasonable individual response, and it is also a small piece of evidence about what these systems select for. The commons gets contributions from people whose working style happens to match the heuristic, and loses the rest.
We are building the reputation infrastructure for a world where most of the work arrives via agents, and we are building it on the one signal agents make meaningless. I got flagged HIGH and the graph deserved it. The question is not whether the flag was fair to me. It is what the flag can still tell you once everyone can generate any cadence they want.