How Radar posts work (and how to use them)

This page is a pinned guide to the Radar format. It exists so Radar doesn't turn into an anxiety machine.

The internet is full of "updates" that don't tell you what to do. Radar is designed to do the opposite: fast context, clear action, and a route to the maintained evergreen page.

Use this guide in two ways:

• If you are reading Radar: use the structure to skim faster and decide whether the post is relevant to you.
• If you are writing Radar: treat this page as the checklist that keeps the format consistent and the feed useful.

The goal is simple: Radar should tell you what changed, who needs to care, and what to do this week, then route you to the maintained system so you are not stuck re-learning the same lesson from stale posts.

If you want the Radar feed itself:

• Radar

If you want the stable systems, skip Radar and go straight to:

• The Codex

Published and updated

• Published: Feb 06, 2026
• Updated: Feb 07, 2026

(When Radar is live with real posts, this page should remain pinned and updated as the format evolves.)

These dates are here on purpose. Radar is time-sensitive by design, so readers need a quick signal for whether the format guidance below is current. If the format evolves, this page should evolve with it, without changing the underlying intent: reduce noise, route to stable systems, and keep urgency proportional to reality.

The Radar promise

A Radar post should help you answer one question.

"What should I do this week, given what changed?"

That single question is the constraint. It prevents Radar from becoming vague commentary, and it prevents it from expanding into a long-term strategy essay that belongs in the Codex.

To keep that promise, a Radar post must be:

• short enough to skim,
• specific enough to act on,
• sourced enough to trust,
• and linked to the evergreen system so it doesn't rot.

If you are evaluating a post quickly, those four bullets are the scoring rubric. If any one is missing, the post may still be interesting, but it is not doing the Radar job.

• "Short enough to skim" means you can get the point without scroll-fatigue. You should not need to read five paragraphs before you know whether the change matters to you.
• "Specific enough to act on" means the post ends in steps you can actually do inside a realistic timebox. The format is built to translate information into action, not to create "advice vibes."
• "Sourced enough to trust" means the reader can see where the claim comes from and how confident we are. If there is uncertainty, it should be named plainly instead of hidden behind a confident tone.
• "Linked to the evergreen system" means the post routes to the Codex, where the maintained process lives. Radar captures the moment; the Codex holds the stable system.

Radar post structure (the four sections)

Every Radar post follows this structure:

1. What changed
2. Who it affects
3. What to do this week
4. Evergreen Codex links

You can think of these sections as a funnel. The top is context (what changed). Then relevance (who it affects). Then action (what to do this week). Then continuity (the evergreen page that stays true after the moment passes).

1) What changed

This is the event or shift.

It should be written so a busy reader can understand the change without having to guess what you mean. Keep it factual, keep it scoped, and link sources where possible.

Good "what changed" writing is:

• factual
• scoped
• source-linked where possible
• clear about uncertainty

Quick interpretation of those bullets (without adding new rules):

• Factual: describe what happened, not what you hope or fear it means.
• Scoped: keep the claim tight. "This changed" is more useful than "everything is changing."
• Source-linked where possible: show the reader the primary text or announcement when you can, and be transparent when you cannot.
• Clear about uncertainty: if details are still emerging, say so. If you are making an assumption, label it as an assumption.

Bad "what changed" writing is:

• vague
• speculative without labeling
• alarmist
• missing sources

A common failure mode is tone inflation: using certainty or urgency to make a post feel important. Radar should do the opposite. It should keep urgency proportional to the evidence, so readers can keep their week proportional to reality.

Examples of "what changed":

• a platform updated payout timing
• a marketplace changed its category rules
• a new common scam pattern appeared
• a law or policy was updated (high stakes; requires careful sourcing)
• demand signals shifted over multiple weeks (methodology matters)

Notice how each example is concrete and bounded. It points at something that changed in the world, not at a mood. That is the difference between a useful update and an anxiety machine.

2) Who it affects

This section prevents irrelevant panic.

Radar should not assume every reader is the target. The fastest way to make a post feel scary is to make it sound universal. The fastest way to make it calm is to state the boundary clearly.

It should specify:

• who needs to care (role, channel, industry, geography)
• who can ignore it
• what conditions make it relevant

This section can be short, but it should be precise. If a post is not relevant to you, you should be able to stop reading without feeling like you are missing something.

Example:

• "This affects freelancers who rely on platform payouts weekly."
• "This affects contractors working with clients requiring Net 60 terms."
• "This affects people raising rates in category X."

The format also invites a simple mirror question: "Does this apply to me?" If the answer is no, the post has done its job by saving your time.

3) What to do this week

This is the point.

If a post cannot name a next action, it is probably not a Radar post. It might belong as a Codex update, or it might belong nowhere until the facts are clearer.

The post should give:

• 1 to 3 concrete actions
• within a realistic timebox
• written as steps (not advice vibes)

Keep the actions tight. The point is not to create a new project; the point is to help you take the safest, most relevant step for the current week.

Examples:

• run a follow-up sequence on all overdue invoices
• update SOW payment terms for new clients (deposit/milestones)
• track close rate and lead flow weekly for 4 weeks before changing strategy
• pause work if invoices are overdue per policy
• switch from fixed pricing to a discovery sprint for uncertain scope

Radar is not for "long-term strategy essays." That's the Codex. Radar should get you through the moment and then hand you off to a maintained system.

A useful gut-check: if the "what to do this week" section turns into philosophy, it needs to be rewritten as steps. If the steps turn into a thesis, it belongs in the Codex.

4) Evergreen Codex links

Every Radar post should link to at least one maintained Codex page.

This is the routing layer. It's also the trust layer. Without it, Radar becomes a pile of momentary posts with no stable home.

• Radar captures the moment.
• Codex holds the stable system.

If a Radar post doesn't route to the Codex, it's incomplete. The link is how the site stays useful over time: the post can age, but the underlying process can stay maintained.

The Radar lifecycle (how posts "expire" responsibly)

Timely content decays. Radar manages this by design.

The lifecycle below is not a publishing schedule. It's an editorial safety rail: publish the moment, update while it's live, then route the durable parts into the maintained system so the feed does not become a graveyard of half-true advice.

1. Publish quickly, but not sloppily
2. Route to the maintained page
3. Update Radar while the moment is live
4. Archive or de-emphasize
5. Absorb durable insight into Codex

Step 1: Publish quickly, but not sloppily

Radar should be fast, but not careless.

Speed is only useful if it does not create confusion. A rushed post with missing sources or hidden assumptions is worse than no post, because it invites readers to act on a shaky foundation.

If something is unclear, the post should say:

• "Details are still emerging."
• "We are waiting on primary confirmation."
• "Here are the known facts vs assumptions."

Then update when facts settle.

That kind of language is not weakness. It's precision. It tells the reader what they can trust today, what they should treat as provisional, and what will change as more information becomes available.

Step 2: Route to the maintained page

The evergreen Codex page should contain:

• the stable process
• the reusable guidance
• the tools and templates

Think of this as the "what stays true" layer. Radar posts can change quickly. The Codex page should be where a reader can land and still get value even after the moment passes.

Example:

• Radar post: "Late payments are spiking"
• Codex page: Invoicing + getting paid on time
• Tool: Invoice Template + Late Payment Sequence

The Radar post handles the alert. The Codex page holds the system. The tool makes the system easier to execute. That chain is how Radar avoids rot.

Step 3: Update Radar while the moment is live

Some moments require multiple updates. Radar posts can be updated with:

• new confirmed details
• clarified "who it affects"
• refined action steps
• additional sources

Updates should make the post calmer and more actionable over time. "More words" is not the goal. Better clarity is the goal.

Step 4: Archive or de-emphasize

Once the moment passes:

• Radar post should remain accessible (for context and citation)
• but it should not be treated as "the evergreen truth"
• the Codex page should become the primary link target

This is the difference between history and guidance. The post is still useful for context, but the maintained page becomes the place you send someone who is trying to solve the problem now.

Step 5: Absorb durable insight into Codex

If the event reveals a recurring pattern, the Codex page should be improved:

• new examples
• updated checklists
• revised default advice
• new tool template if needed

This is how the site stays useful without accumulating rot. Radar is a signal layer. The Codex is the system layer. When the signal reveals a durable lesson, the system should get better.

Editorial approach:

• Editorial standards
• Review policy

How to read a Radar post in 30 seconds

If you're busy:

1. Read the title.
2. Read "Who it affects."
3. If it affects you, do the action steps.
4. Bookmark the related Codex page.
5. Stop reading.

That last step is part of the product. Radar is designed to prevent doomscrolling by being "action first."

Sourcing rules (how we prevent "confident nonsense")

Radar should prefer:

• primary sources (official policy docs, platform announcements)
• direct communications (public notices, changelogs)
• clearly stated methodology when citing data or trends

This is how we keep Radar from becoming a confidence performance. If the post is making a claim that can be checked, the reader should be able to check it.

When sources disagree:

• we should show the disagreement noted plainly
• we should avoid absolute claims
• we should provide the safest actionable step when stakes are high

The key idea is to separate "what we know" from "what we assume." That keeps the reader oriented, especially when the topic is high-stakes or fast-moving.

When a post is a template (like some early posts):

• it should say so
• it should include placeholders for sources
• it should be updated when converted into a real incident post

This aligns with: Editorial standards

What Radar does not do (boundaries)

Disclaimer: Radar is not legal advice, tax advice, or individualized compliance guidance.

Radar can point you to official guidance, summarize what changed, and offer conservative next steps. It cannot make a decision for your specific situation.

When a topic is high-stakes:

• we use conservative language
• we include disclaimers
• we point to official guidance and qualified professionals when needed

See: Terms

Radar is also not a place for "hot takes." If an update can't be explained clearly with a next action, it doesn't belong.

Examples: Radar post -> Codex page -> tool

These examples show the intended flow. The Radar moment names the change. The action list keeps you moving this week. The Codex page and tool are where the durable system lives.

Example 1: late payment drift

• Radar moment: "Late payments are spiking."
• Action: run follow-ups; update payment terms; enforce work pause.
• Codex: Getting paid on time
• Tool: Invoice Template + Late Payment Sequence

This is a classic Radar pattern: a time-sensitive cashflow issue that demands action now, but relies on a stable evergreen system (invoicing, follow-ups, and policies) to be executed correctly.

Example 2: rate pressure and demand uncertainty

• Radar moment: "Lead flow feels down."
• Action: track signal metrics weekly; improve distribution before cutting price.
• Codex: Set freelance rates
• Tool: Rate Calculator
• Plus pipeline: Find clients without a huge audience

The point here is to avoid reactive changes based on a single week of discomfort. Track the signal, take a small action, and route to the maintained rate and pipeline systems instead of making a high-stakes decision in a fog.

Example 3: admin overload and burnout risk

• Radar moment: "You're overbooked and reactive."
• Action: impose meeting windows; cap WIP; do weekly review.
• Codex: Solo operating system
• Codex: Boundaries and burnout

This example shows a different kind of "what changed": not a policy update, but a shift in your own operating condition. The post is still Radar when it translates that shift into immediate steps and routes to the maintained system for boundaries and operations.

FAQ

Is Radar the same as the Codex?

No. Radar captures the moment. The Codex holds the stable system. Radar posts should route to at least one maintained Codex page so the advice does not rot.

Why do Radar posts need action steps?

Because the core question is "What should I do this week, given what changed?" Radar exists to convert updates into decisions. If a post cannot name 1 to 3 steps inside a realistic timebox, it is probably not a Radar post.

What if the facts are unclear?

Then the post should say so, using language like "Details are still emerging" or "We are waiting on primary confirmation," and update when facts settle.

Does Radar give legal or tax advice?

Disclaimer: No. Radar is not legal advice, tax advice, or individualized compliance guidance. When a topic is high-stakes, we use conservative language, include disclaimers, and point to official guidance and qualified professionals when needed.

How to suggest a Radar post

If you notice a change that affects freelancers, submit:

• what changed (with a link if possible)
• who it affects
• what you think the next action should be
• and what you want the maintained evergreen page to be (if known)

Use:

• Ask the Codex

or:

• Contact