The work that proves you're senior leaves no trace.

That worked because writing the code and demonstrating you could write the code were the same motion. The artifact and the evidence were one object. Now the artifact is largely produced by something else, and what you contributed sits in the difference between what was produced and what shipped. Differences are not stored anywhere.

WHAT THE SYSTEM RECORDS
  the commit that shipped  ·  the ticket that closed  ·  the review you approved

WHAT IT DOESN'T
  the version you rejected, and why
  the six weeks of work you argued down to two days
  the thing you asked about that nobody had considered
  the outage that therefore did not occur

The bottom line has no artifact at all. It is a counterfactual,
and counterfactuals need an argument rather than a link.

There is a second-order effect worth naming, because it decides how urgent this is. Reviewers are already noticing that shipped volume has stopped correlating with quality, and the institutional response is to reach for something else to count. If nobody supplies a better measure, they will settle on whatever is easiest to extract from the tooling, which will be worse than what it replaced. Supplying the better measure is partly your job now.

Notice what is not on the list: features delivered, tickets closed, lines written, systems launched. Those are not worthless, but they no longer distinguish anybody, and a packet built on them reads as a report on how much the agent produced while you were nearby.

2026-03-04  #412  agent used a float for the refund amount; switched to
                  integer cents. wrong → silent rounding loss on every refund

2026-03-11  #418  agent retried the payment call on timeout; we fail fast
                  here by policy. wrong → duplicate charges

2026-03-12  —     talked the export feature down from a scheduled pipeline
                  to a signed URL. 6 weeks → 2 days, no new infra

2026-03-19  #431  approved the cache change; it broke stale reads in prod.
                  now: any cache PR gets an explicit invalidation claim

The one field that matters

Cost if wrong. Without it a rejection log is a list of preferences and reads like fussiness. With it, each line becomes an argument. Turning down a suggestion that would have cost nothing is housekeeping and does not belong in the file. Turning down one that would have double-charged customers is the entire job, and the difference between those two is exactly what a reviewer is trying to establish.

Two practical rules

• Keep it somewhere you own. A plain file in your own notes or a personal repo, not a company wiki you lose access to on your last day. The evidence should outlive the job, because the next conversation about your seniority may not be at this company.
• One to three lines a week is the honest rate. If you are writing twenty, you are logging keystrokes rather than judgment, and the file will be useless because nobody including you will read it. If you are writing zero for a month, that is a genuine finding about the month and worth sitting with.

A private log kept diligently all year and a private log written the week before review look identical on the page. That is a real problem and it is worth solving structurally rather than by asking people to trust you. A sentence in a pull request body from March is timestamped, public, and was written when you had nothing to gain from it.

## What the agent proposed, and what I did instead

- Proposed a retry with backoff on the charge call. Replaced with
  fail-fast: this path is not idempotent, so a retry risks a double
  charge. See CHARTER.md §payments.
- Proposed caching the tax lookup for 24h. Left uncached; rates
  change intraday during the state transition window in April.

This costs nothing extra, because you already made both decisions. It also does a second job immediately: it is the most useful thing a reviewer can read, since it tells them where you deviated from the obvious path and why. Teams that adopt this as a norm find review gets faster, which is a better argument for adopting it than the promotion one.

# your merged PRs with bodies, to find the ones where you explained a choice
gh pr list --author "@me" --state merged --limit 200 \
  --json number,title,body,mergedAt

# PRs you reviewed: where your catches live
gh search prs --reviewed-by "@me" --merged --merged-at ">2026-01-01"

# discussions you weighed into that were not yours
gh search prs --commenter "@me" --merged-at ">2026-01-01"

Then, in descending order of yield

1. Best Review comments that were followed by a change. A comment plus the commit that answered it is a documented catch, and the timestamps prove it happened before merge.
2. Good Design documents where the final scope differs from the first draft. The diff between versions is a reduction you can point at, and version history usually survives.
3. Good Incidents you were on. Look for what you changed afterwards, not for how fast it was resolved.
4. Underrated Ask two colleagues: "what is something I stopped from happening?" People remember your refusals far better than you do, because they experienced them and you have moved on.
5. Lost Nearly every rejection that never reached a pull request. This is the bulk of it, and it is gone.

One pattern, repeated six times: a claim in the vocabulary of the ladder, the evidence, and the consequence. Nothing else.

CLAIM        I am the last check on payment-path changes.
EVIDENCE     PR #418, #431, #447 — three agent-proposed retries
             rejected on the non-idempotent path, each with the
             policy cited in the PR body.
CONSEQUENCE  A retry on that path double-charges. We have shipped
             none since March.

CLAIM        I approved something that broke, and changed how I review.
EVIDENCE     PR #431, incident 2026-03-19.
CONSEQUENCE  Every cache change now needs an explicit invalidation
             claim. Two caught since, #455 and #470.

Four rules for the page

• Lead with the escape. It buys the credibility that carries the other five.
• No feature lists. If a line could have been written by anyone who was staffed on the same project, cut it.
• Consequence in the domain, not the codebase. "Prevents duplicate charges" beats "improves correctness". The reader is deciding what to trust you with, not admiring the fix.
• Link, do not paste. Six links they can check beats six paragraphs they have to believe.

Ask for different things

• What did you turn down, and what would it have cost if you had been wrong?
• What got smaller because you were in the room?
• What did you approve that broke, and what do you check now that you did not check before?
• Which rule in our harness exists because of you? Which one did you remove?

And stop asking for impact denominated in shipped work. Volume now measures how fast somebody can drive a model, which is a real skill, an easily acquired one, and not the thing a promotion is supposed to be recognising.

The structural fix is worth more than the request. When "what the agent proposed and what I did instead" is a standing section in the pull request template, every engineer produces this evidence as a byproduct of working, which is exactly the property the old commit history had and the thing we are trying to get back.

1. Inflation Logging every rejected autocomplete. Fifty entries of no consequence dilute four that mattered to zero, because the reader stops reading at entry six.
2. Borrowed credit "I shipped forty pull requests" where the agent wrote them. Reviewers can tell, and the claim contaminates the true ones sitting next to it.
3. The wall of links Thirty URLs and no claims. It asks the reader to do your synthesis, which they will not, so they will fall back on their prior impression of you.
4. Dressed-up archaeology Reconstruction presented as a contemporaneous log. See §4: label it and it is fine, hide it and you have misrepresented the exact trait under discussion.
5. Rejections as a metric The moment rejection rate is counted, rejections get manufactured, and the manufactured ones are indistinguishable from the real ones on any dashboard. Goodhart arrives here faster than almost anywhere else, because the supply is unlimited and free.

1. Habit one On the next pull request you open, add one sentence: the agent proposed X, I did Y, because Z. Repeat on every pull request where that sentence is not trivial.
2. Habit two Keep one plain file. Add a line whenever you turn something down or talk something smaller, with the cost had you been wrong. One to three lines a week.

In a year that is roughly a hundred and twenty lines, most of them timestamped by a system you do not control, describing precisely the work that used to be invisible. It is also, separately from any promotion, the most useful document you will own: it is the only honest record of what you were actually deciding while the code was being written by something else.