About
Review policy
“Last reviewed” should mean something. This policy defines what our labels mean, how review cadence works, and how we update evergreen pages, tools, and timely posts.
If a page claims to be maintained, the maintenance needs a clear definition and a visible process.
This page explains:
- what “published,” “last reviewed,” and “change log” mean on Freelance Codex,
- how often we review different kinds of pages,
- what triggers out-of-cycle updates,
- and how corrections are handled.
If you want to understand how we decide what qualifies as reliable information, read: Editorial standards. If you want transparency about affiliate links and recommendations, see: Disclosure policy.
Definitions (what the labels mean)
Published
The first date a page goes live.
“Published” means the page exists publicly. It does not necessarily mean “complete forever.” Most pages evolve.
Last reviewed
The date the page was checked for continued correctness and relevance.
A “review” is not a cosmetic edit. A real review means we did at least some of the following:
- checked whether key claims are still correct,
- verified whether time-sensitive details changed,
- improved clarity where readers commonly misinterpret,
- added or updated links to tools/templates,
- and updated the change log when the page meaningfully changed.
In practice, the checklist depends on the page type. For example:
- on a Codex page, we focus on assumptions, process steps, and the internal “go next” links;
- on a tools/templates page, we focus on whether the tool is still operational and whether the wording is still usable under real-world pressure;
- on a time-sensitive Radar post, we focus on whether the moment is still active and whether readers are being routed to the maintained evergreen page.
What we do not count as a review: fixing a typo, changing formatting, or rewriting for style without actually checking the guidance.
If a page is reviewed and nothing needed changing, the “last reviewed” date can still update, but we aim to make that honest by adding a brief note like “reviewed, no changes.”
Change log
A short record of meaningful changes.
A change log is not a full git diff. It's the human-readable summary:
- what changed,
- why it changed,
- and (when relevant) what a reader should do differently now.
When a page has both “last reviewed” and a change log, the intent is simple: “last reviewed” answers is this checked?; the change log answers what changed that affects action?
Why review policy exists
Freelancers are making real decisions based on what they read:
- how to price,
- what to put in a contract,
- when to pause work for non-payment,
- what to track for taxes,
- how to respond to a platform change.
Those decisions can cost time, money, or legal risk.
A review policy is how we avoid two failure modes:
- “Evergreen” pages that quietly rot, and
- Constant posting that never gets maintained.
Freelance Codex is trying to do the opposite:
- fewer canonical pages,
- reviewed deliberately,
- and updated transparently.
You can browse the canonical evergreen layer here: The Codex.
Cadence (v0): how often pages are reviewed
Not all pages need the same review frequency. We group pages by risk and volatility.
1) Pillar Codex pages (high importance, medium volatility)
These are the “spine” topics: getting started, clients, pricing, contracts, getting paid, taxes workflow, delivery/retention, systems, and burnout.
Default cadence: quarterly review, or immediately when a related “Radar moment” hits.
Examples:
2) Tax/legal/compliance pages (high stakes, higher volatility by jurisdiction)
These pages can become wrong faster, and the cost of being wrong is higher.
Default cadence: more frequent reviews, plus conservative wording and primary source links.
Also: we keep jurisdiction notes explicit rather than blending rules. See: Editorial standards.
3) Tools/templates/calculators (high use, volatility depends on reports)
Tools break in practice. The failure modes show up when people reuse templates under stress.
Default cadence:
- review when a template is commonly reused,
- review when readers report a failure,
- review when a related Codex page changes in a way that impacts template language.
Examples:
4) Radar posts (time-sensitive by design)
Radar posts capture a moment. They should be useful quickly, and then route readers to the maintained evergreen page.
Default cadence:
- update while the moment is live,
- archive/age out gracefully,
- ensure the linked Codex page absorbs the evergreen lesson.
Browse: Radar.
5) Index/Research pages (high trust requirement)
If we publish research summaries or indexes, the bar for transparency is high.
Default cadence depends on the report (monthly/quarterly), but the methodology should be stable and visible:
What a scheduled review looks like (a practical checklist)
A scheduled review is meant to be boring in the best way: re-check, tighten, and make the page safer to use. Depending on the page, a review may include:
- reading the page end-to-end to confirm the process still works as written,
- checking that internal links still route to the right “next step” pages,
- verifying time-sensitive statements and removing or reframing anything that is no longer reliably true,
- updating examples so they match the current guidance (without changing the underlying guidance),
- and writing a change log entry only when a reader's action should change.
What triggers an out-of-cycle update?
Some changes should not wait for the next scheduled review.
Out-of-cycle triggers include:
- Policy changes that impact freelancers materially
Example: platform payout changes, contractor compliance updates, major regulatory shifts.
- Repeated reader confusion
If many people misinterpret a section the same way, the page needs clarity.
- Template failure modes
If a tool/template produces predictable problems (for example, invoice follow-ups that are too vague to be effective), the language should be updated.
- A new, better canonical structure
Sometimes a topic needs splitting into a clearer page + subpages to reduce confusion.
Out-of-cycle updates are also appropriate when something is technically “small” but operationally risky, like a broken link that prevents a reader from finding the correct next step, or a tool instruction that no longer matches how the tool actually behaves.
Radar often serves as the “early warning” system, because it is designed to capture timely changes and route to the evergreen version:
What counts as a “meaningful change”?
We update a change log entry when we change meaning, not just phrasing.
Meaningful changes include:
- updated process steps,
- new template language that affects how you operate,
- clarified assumptions or constraints,
- corrected factual statements,
- added/remade internal link structure (when it changes how the site is used),
- jurisdiction note changes that affect action.
Non-meaningful changes (usually no change log entry):
- typo fixes,
- minor formatting,
- small phrasing improvements that don't alter guidance.
We still care about small fixes; we just don't pretend they're major updates.
How we handle uncertainty during reviews
Some topics don't have clean answers. That's normal.
During review, we aim to:
- label uncertainty explicitly,
- separate facts from recommendations,
- prefer conservative guidance when stakes are high,
- and encourage qualified professional advice when appropriate.
This isn't “being vague.” It's refusing to lie with confidence.
The detailed framework is here: Editorial standards.
Corrections: how to report an error
If you spot an error, please send:
- the URL
- what is wrong
- a source that supports the correction (when applicable)
- why it matters (what a reader might do incorrectly)
If you can, quote the exact sentence/step that is wrong and suggest replacement wording. That makes it easier to verify the issue and update related pages consistently.
For tools/templates, “what is wrong” can mean: a broken download, a formula that produces an incorrect result, or wording that is too ambiguous to execute. Include reproduction steps and what you expected to happen versus what happened.
Please do not include sensitive personal or client information in a correction request. If a real-world dispute is the context, anonymize it and focus on the generalizable issue. (See: Privacy policy.)
Use: Contact.
What happens after you report an error?
We aim to:
- verify the issue (including checking primary sources when relevant),
- update the page,
- add a change log entry if the change is meaningful,
- and check whether related pages need updates too.
If the issue is time-sensitive or high-stakes, we may prioritize a fast clarification (for example, adding a note that a section is being re-checked) before making a larger rewrite. The goal is to reduce the chance of a reader taking the wrong action while the full review happens.
If a correction affects a template, we update the tool page and link back to the relevant Codex explanation, so the “why” and the “how” stay aligned.
Sunsetting and archiving (what we do with time-sensitive content)
Not everything should live forever.
Radar posts
Radar posts are allowed to age out. Their main job is to route readers to the maintained page while the change is live.
When a Radar topic becomes evergreen, the correct home is a Codex page, not an ever-growing archive of stale posts.
Templates
Templates should evolve. A template that stays static while the real world changes becomes a trap.
That's why tool pages include:
- “when to use this,”
- “how to customize,”
- and “common pitfalls.”
Browse: Tools & templates.
Review transparency: what readers should be able to see
A maintained page should make it easy for a reader to answer:
- Is this current?
- What changed recently?
- Where do I go next?
- What assumptions are being made?
That's why we keep:
- “Last reviewed” visible,
- a change log visible,
- and internal links to relevant tools and sibling pages.
If you're new to the site structure, start at Start here or The Codex.
FAQ
Does “last reviewed” mean the page changed?
Not necessarily. It means the page was checked. If the review caused meaningful changes, the change log should say what changed and why.
Why not show a full detailed revision history?
We want review notes to be useful, not noisy. The change log is meant to tell a human what changed in a way that affects action.
How often are templates updated?
When templates are reused, failures show up quickly. We update tools when:
- the linked Codex guidance changes,
- readers report failure modes,
- or the template language is too weak to be operational.
Start with: Invoice template + late payment sequence and its explanation: Getting paid on time.
What if you're wrong about something important?
Then we want to know quickly. Please send the URL + the correction + a source. Use: Contact.
Can I request a review or update of a specific page?
Yes. Send the URL and explain what changed in the real world (or what's confusing). If you have a primary source that supports the update, include it. Use: Contact.
Do you log every tiny fix?
No. Typos and minor clarity edits are important, but they are usually not “meaningful changes.” The change log is reserved for updates that would change what a reader does.
Is this legal, tax, or accounting advice?
No. Freelance Codex is educational material and a process reference. When topics are high-stakes, we aim to be explicit about assumptions and uncertainty and encourage qualified professional advice when appropriate. See: Editorial standards.
How do affiliate links affect reviews?
They don't change the review standard. The disclosure and recommendation rules are defined separately here: Disclosure policy.
Status and change notes
This policy is a living document. If we change how “last reviewed” or change logs work, we will update this page to match.
- Last reviewed: February 7, 2026
- Change notes: expanded examples, added a mini table of contents, and clarified the correction workflow (policy meaning unchanged).
Related links
- How we define reliability and uncertainty: Editorial standards
- Transparency on recommendations: Disclosure policy
- Browse maintained evergreen answers: The Codex
- Report an issue: Contact