Everything a review measures someone against comes from here. The framework is the organization's own matrix of what good looks like, and the product's bet is simple: if the expectations sit in front of you while you write an assessment, instead of a link you might click or something you're recalling from a meeting six months back, the review that comes out the other end is worth more.
The vocabulary
A few words the interface uses consistently:
- Track — a career path. Most workspaces have at least two, an individual-contributor track and a management one. A track is the thing that gets versioned and published; there's no separate "framework" object sitting above it. Its title is the one part none of this freezes — rename it and every version updates at once, published ones included.
- Level — seniority or scope within a track. IC3, M4, whatever your organization calls its rungs.
- Dimension — an area of expected contribution that gets assessed: delivery, craft, collaboration. The rows of the grid.
- Expectation — the text at one level-and-dimension intersection, read during an assessment. Along with the level and dimension names around it, this is what a published version freezes.
Building a track
New track offers four starting points:
- A starter framework — one of a handful of common shapes, fully written and ready to edit line by line rather than blank.
- A guided draft — a short triage about how the role actually works, then a few questions, then a preview to check before anything is saved. Your answers are sent to Anthropic to write the draft and are never used to train their models.
- A markdown document — paste in or upload the levels doc you already keep somewhere else, a Notion export or a Google Doc.
##headings become levels,###headings become dimensions, and the text under each becomes the expectation at that intersection. - An empty grid — you name every level and dimension yourself.
Whichever you pick, it lands as a draft. Nothing about a draft is visible to anyone but admins, let alone assessable, until you publish it. Click a cell to write or edit an expectation; click a heading to rename a level or dimension.
Publishing
Publishing does two things: it makes the track available to assign, and it freezes the wording. From that point, changing an expectation means starting a new version — the published one stays exactly as it was for as long as any review references it.
Name the version (anything: "v3," "2026 H1," whatever your team calls its own) and optionally note what changed. If this supersedes a version already in use, the old one is archived automatically, but the people already on it stay on it. Publishing never moves anyone onto a new version silently — a manager has to place them there.
Why frozen wording matters
This is what makes closed reviews trustworthy years later, and it works by locking rather than copying. A review records which version and level it was opened against; because publishing froze that version, the expectations it points at are still the ones that were on screen when the assessment was written. The locked version is the snapshot — there's no second copy to drift. Publishing a new version leaves it untouched, so nothing retroactively changes the ground someone was judged on.
It's also why a published version can't be edited in place. To fix wording, New version duplicates the current one into a fresh editable draft, which you publish when it's ready. The old version keeps existing underneath whatever review was written against it.
Archiving and deleting
Once a version has been assigned to anyone or used in a review, it can't be deleted, only archived — kept around, correctly, for the reviews that reference it, but out of the list of things newly assignable. A version, or a whole track across every version, can only be deleted if it was never used for anything.
Personal expectations
Not everyone fits the shared framework, and a manager can write personal expectations for one person instead: a short, freeform list rather than a full track with levels. It works the same way underneath — sent (frozen and emailed) rather than published, and a review against it is pinned the same way a track version is. Revising someone's personal expectations writes a new version rather than editing the one already sent, which is why a review against the old wording still reads correctly. Sending personal expectations for someone moves them off the shared framework, since a person is only ever assessed against one thing at a time.
Who can see what here
Anyone in the workspace can read the framework they're assessed against; it's read-only for everyone but admins. An employee's own slice of it, their track and level, always shows on their own record under What is expected. Only admins can write to it.