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 something else writes most of the artifact, and what you contributed sits in the difference between what it proposed and what shipped. Nothing stores that difference.

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. So 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 reads a log that long. 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 public, its date is not yours to set, and you wrote it when you had nothing to gain.

## 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, because it is the most useful thing a reviewer can read. That paragraph 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 the author acted on. 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 the team resolved it.
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 anyone staffed on the same project could have written that line, 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. That is a real skill, and an easily acquired one, but it is not what a promotion should be recognising.

The structural fix is worth more than the request. Once "what the agent proposed and what I did instead" is a standing section in the template, every engineer produces this evidence as a byproduct of working. The old commit history had exactly that property, and it is the one worth getting 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. They will not, so they 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 the packet misrepresents the exact trait under discussion.
5. Rejections as a metric The moment somebody counts rejection rate, engineers manufacture rejections, and no dashboard can tell the manufactured ones from the real ones. Goodhart arrives here faster than almost anywhere else, because the supply costs nothing and never runs out.

1. Habit one On the next pull request, 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. They describe precisely the work that used to be invisible. Promotion aside, that file is also the most useful document you will own: the only honest record of what you were deciding while something else wrote the code.