health.dare.co.uk — editorial-uplift dashboard (parked sketch)

DARE.CO.UK · PARKED SKETCH · 2026-05-18

Mirrored from ~/.claude/.../memory/project_health_dare_co_uk_editorial_uplift_parked.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

2026-05-18 sketch. health.dare.co.uk is the editorial-uplift-focused sibling to dashboard.dare.co.uk. Where dashboard. is the operational catch-all (edge health, traffic, country tables), health. is the “what should I write next + what’s worth upgrading + what’s working” surface. Built on the same toolkit substrate (Site Health card row, window toggle, click-through-to-latest-authoritative-report) but stripped down to ONLY editorial-uplift signals. Resume on Dan’s first content-quality investment push.

Dan, 2026-05-18 evening: “i suspect health.dare.co.uk might be a cleaner sub-set focused on editorial uplift to increase traffic. sketch it later.”

Surface delineation — three dare subdomains

The two health-style surfaces (dashboard + this) overlap in some signals (Site Health card row) but diverge in framing. dashboard = “everything’s OK”; health = “what to do next.”

What health.dare.co.uk should show — 5 cards / sections

1. Editorial backlog (priority queue) — the load-bearing surface

The page-priority queue. Each row = a page that’s a candidate for editorial uplift. Ordered by leverage (intersection of internal-signal + GSC-marker + traffic-potential).

Default sort: highest leverage at top. Pinable. Dismissable (per-page “not now” state, surfaces again in N days).

Cross-reference: the markers-from-google parked sketch (project_markers_from_google_parked.md) is the data spine for this card.

2. Recent edits × impact

When Dan rewrites a page or ships a new article, does its GSC indexing state change? Does it accrue impressions?

Time horizon: 30 days. Compounds as the corpus matures: the chart of “edits that moved the needle” becomes the training data for which interventions work.

3. Section coverage map

Where is the corpus light vs deep?

The gap column is editorial guidance: where would investment compound? Picks the section to focus on rather than scattering attention across 698 pages.

4. Voice / register check

Recent edits scanned for brand-voice consistency. Per feedback_dare_brand_voice_four_pillars.md, the four pillars (inspiration / conviction / optimism / innovation) define the register. Drift = silent quality regression.

Cards flagged DRIFT click through to a side-by-side compare with a known canonical example.

5. Forward content queue

What’s in flight + scheduled?

Manual-entry surface for things Dan’s actively thinking about but hasn’t started.

Surfaces that are NOT on health.dare.co.uk

To stay STRIPPED DOWN per Dan’s framing, deliberately exclude:

• Edge Health card row (operational, lives on dashboard.*)
• Country / Status code / Content type tables (operational)
• Traffic line charts (operational)
• 404 audit details (operational; though the page-priority queue may surface 404 candidates)
• Backlinks data, OPR score (different concern surface)

Pure editorial signals only. The user’s mental model when visiting: “I’m here to decide what to write today.”

Architecture — leans on existing toolkit substrate

existing toolkit                           health.dare.co.uk
─────────────────                          ─────────────────
dare_content_breadth_audit ────────────────► card 1 + 3
dare_body_image_coverage ──────────────────► card 1
dare_lost_image_audit ─────────────────────► card 1 (when audit cleans up)
dare_followup_audit ───────────────────────► card 5 (FOLLOW-UPS section)
dare_seo_title_audit ──────────────────────► card 4 indirectly
git log + file mtimes ─────────────────────► card 2 + 5
GSC API (when integrated) ─────────────────► card 1 + 2 + 3
Claude API for voice scoring ──────────────► card 4
sitemap.xml ───────────────────────────────► card 3
                                               │
                                               ▼
                                  dare_health_render.py
                                  (new — but small wrapper)
                                               │
                                               ▼
                                       CF Pages project
                                       (dare-health)
                                       custom domain
                                       (health.dare.co.uk)

The build is light: most data comes from existing audits + a few new aggregations. Maybe ~300 LOC for dare_health_render.py + corresponding HTML/CSS. Reuses card grid + window toggle + click-through patterns wholesale.

Implementation order (when unparking)

Phase 0 + Phase 1 = ~half-day. The rest stages over multiple sessions as data + conventions mature.

What’s intentionally tooling, in service of editorial

Per user_invest_in_content_quality_not_more_tooling.md: this build IS tooling, but its sole purpose is to shorten the loop between editorial decision and editorial output. Every card answers a question Dan would otherwise spend ~10-30 minutes hunting for. The investment is in service of editorial work, not displacing it.

The standing-instruction stance check applies: if a proposed addition doesn’t directly enable an editorial decision, it doesn’t belong on health.*.

Cross-portfolio extension

The same surface shape lifts to:

The pattern is brand-agnostic. The cards’ DATA SOURCES adapt per brand; the cards themselves stay constant.

Open design questions

1. How is the editorial-backlog priority computed? Currently sketched as “intersection of internal signal + GSC marker + traffic potential” — but the WEIGHT given to each signal needs calibration. v1 might just be (GSC = crawled-not-indexed) + (content = stub) → priority HIGH. Refine as patterns emerge.
2. Dismiss / pin / “not now” state. Where does that state live? Probably a small KV namespace per-brand: dare_health_state. Per-URL flags.
3. Voice-register scoring frequency. Card 4 hitting Claude API per edit might cost; perhaps just on flagged-uncertain pages, not every recent edit.
4. GSC API integration vs CSV import. CSV is faster to ship (manual export, drop in ~/Downloads); API is the long-term shape. Same trade-off as project_markers_from_google_parked.md — start CSV.
5. Time horizon for “recent edits.” 30 days seems right; calibrate after first month of use.

Sibling memories

• user_invest_in_content_quality_not_more_tooling.md — the stance that motivates this whole surface; this build qualifies per the “tooling in service of content” exception clause.
• project_markers_from_google_parked.md — the GSC-markers framework; load-bearing data spine for cards 1 + 2 + 3.
• feedback_window_toggles_are_high_value.md — the toggle pattern lifts onto health.* the same way.
• feedback_show_the_future_grey_it_out.md — pending-state cards for sections that haven’t accrued enough data.
• feedback_window_toggles_are_high_value.md + feedback_smoothed_area_chart_over_time.md — visual idioms for card 2’s recent-edits-impact chart.
• project_dare_content_strategy.md — forward content = business-design problem-solving + case studies. Card 5 is where this surfaces.
• user_dare_test_bed_to_commercial_leverage.md — the portability thesis. health.dare.co.uk is a portfolio pattern, not a dare-only surface.
• feedback_dare_brand_voice_four_pillars.md — the register canonical for card 4 scoring.

Resume conditions

• ✅ Dan begins a content-quality investment push (rewriting key pages, shipping case studies). The “what next” question becomes load-bearing → unpark.
• ✅ GSC API integration lands (per project_markers_from_google_parked.md) — gives card 1 its richest data source.
• ✅ Client engagement asks for an editorial-uplift dashboard (lifts the pattern as portfolio-portable, like Site Health did today).
• Earliest qualifying trigger → Phase 0 + Phase 1 build (the half-day vertical slice). Subsequent phases stage as data + conventions mature.