A strong engineering promotion packet needs evidence of judgment, contribution, scope, and results. In 2026, when work may span AI sessions, documents, and repositories, the final code change often tells only part of that story. These nine evidence types help you reconstruct the contribution without turning every artifact into a promotion claim.
You do not need all nine for every project. Choose the ones that support the actual claim and your company’s expectations. A small set of relevant sources is easier to assess than an archive of everything you touched.
This is an editorial checklist, not a universal company policy or a scoring system. The examples are hypothetical. Use approved sources and keep confidential material within the locations your employer permits.
1. The problem or requirement
Keep the document, ticket, or decision note that explains the problem. A reviewer needs to know what constraint mattered before they can evaluate your response. “Improved caching” is hard to assess without knowing whether the problem was cost, latency, freshness, or operational complexity.
What it supports: the context and success condition. What it does not prove: that your work solved the problem. Add the result separately.
2. The decision and alternatives
Preserve the point where you selected or changed an approach. Include the alternatives and the reason for the choice. A short decision note can show judgment more clearly than a long implementation summary.
If you rejected an assistant’s suggestion, record the missing constraint and the reasoning behind your correction. The useful fact is not that you disagreed with AI; it is that you identified something consequential and changed the work appropriately.
3. A clear record of your role
Use a responsibility note, design authorship, review history, or agreed account of the collaboration. Explain what you owned, what you contributed, and what others did. Do not infer sole ownership from being the person who wrote the final summary.
A project can produce several legitimate career stories. Your packet should tell yours accurately while preserving the shared result. The attribution guide includes concrete examples.
4. The delivered artifact
A pull request, document, runbook, migration tool, or prototype can establish that a piece of work exists. Name its state. A draft design and an adopted design are different; a local prototype and a production feature are different.
For work that does not produce code, identify the artifact others used to make or execute a decision. Avoid privileging a repository link simply because it is easier to count.
5. Verification of the relevant behavior
Keep the test, experiment, review, or operational check that supports your conclusion. Include enough context to understand what was tested and what was excluded. A passing test suite is evidence about the behaviors it covers, not proof that the system has no defects.
For AI-assisted implementation, this is especially useful for explaining your responsibility. Record the checks you selected and the result you inspected, rather than relying on an assistant’s statement that the work is complete.
6. Release or adoption evidence
A merge is not a rollout. A published library is not an adoption. Keep the release record or evidence that another team actually used the result. If adoption is pending, say so and schedule a follow-up.
For an investigation, the equivalent may be a documented decision that used the findings. You can show that the work changed a plan without claiming a production release.
7. A bounded outcome measurement
Include the baseline, result, population, and observation period. Preserve the query or dashboard reference when possible. Explain other changes that may have contributed to the result.
If you estimate a consequence, label the assumptions. Build-hours saved are not automatically engineer-hours saved, and available capacity is not automatically cash savings. The platform-impact guide walks through that distinction.
8. Specific feedback from affected people
Feedback can establish how a contribution helped someone else. “Your migration checklist caught the unsupported client path before our rollout” is more informative than “great work.” Keep the context and avoid expanding the statement beyond what the person observed.
Feedback complements artifacts; it does not replace them when the claim is independently measurable. Respect the original audience and any restrictions on sharing.
9. The exact career expectation
Attach or reference the criterion you believe the evidence supports. Explain the connection in a sentence. If the mapping is uncertain, use it as a question for your manager.
A record mentioning several teams does not automatically prove cross-team influence. The evidence should show the decision or behavior the criterion describes. Keep current-level strengths and next-level gaps visible at the same time.
Assemble a case a reviewer can follow
Scroll sideways to see all columns.
| Claim | Useful evidence | Common overreach |
|---|---|---|
| I changed the design | Constraint, alternatives, and decision record | Claiming the downstream result before delivery |
| I delivered the change | Role and completed artifact | Calling a merge a successful rollout |
| The change improved an outcome | Release, measurement, and attribution | Treating correlation or an estimate as proven causality |
| This demonstrates the target level | Relevant criteria and a pattern of scoped contributions | Using one keyword match as a readiness verdict |
Start the packet with a few clear claims, then connect each to its sources. Keep uncertain results in a separate follow-up list. A reviewer should be able to understand the story without opening every link, and verify the important parts when they do open them.
- Choose evidence for a specific claim.
- Label the work’s actual state.
- Preserve your role and collaborators’ roles.
- Separate observation from estimate.
- Use the company’s real expectations.
- Remove material that is irrelevant or not approved for sharing.
Use The Promotion Packet, by Hand to start a record, or inspect Worktold’s sample journal. For turning the evidence into prose, continue with the self-review examples.
Written for Worktold using public sources and original illustrative examples. Product research checked November 10, 2026. Read our editorial approach and comparison limits.
