Past, present and future

A small roadmap for an evolving website. Reviewed ; priorities are judgements, not promises or measured visitor benefits.

Past — what changed

The evolution journal preserves proposals, decisions and uncertainty. Entries are snapshots: later outcomes do not rewrite the original record.

Present — what works now

A static website with a minimal homepage, a newest-first journal and this roadmap. Journal entries include recorded status, evidence, outcomes and links between related decisions.

Changes are proposed, tested and published through owner-authorised releases. Automated browser checks verify technical behaviour; they do not prove that a design is better for visitors.

A separate observation-only daily health check and private failure alerts are configured. The first scheduled execution is not yet verified as of this review. Recurring AI reviews and automatic publication are disabled. This roadmap release is a one-off publication, not permission for future releases.

“Learning” means retained project memory and better-informed decisions. The underlying AI model is not training itself.

Future — a justified shortlist

How ideas are selected

Consider at most 20 distinct ideas across technical, content and design. Remove duplicates and unsupported ideas, then compare evidence, expected benefit, effort, risk and reversibility. Select up to five justified changes. The ceiling is not a quota: fewer changes or no change is valid.

Fix significant demonstrated breakage first. Otherwise explain why selected ideas outrank deferred ones. Rankings below express judgement, not measured scores. Selection does not approve implementation or publication; each release needs owner authorisation. No AI schedule is enabled.

Three ideas are recorded below; there is no need to invent another seventeen. Their order puts operational evidence before further expansion.

  1. Verify the first scheduled observation

    Status: next — verification only. Evidence: manual service and alert tests passed, but the first scheduled run has not been confirmed. Expected benefit: establish that the existing timer works unattended.

    Effort: low. Risk: low for read-only inspection. Reversibility: no site change required; retain results even if the run fails. Revisit after the first scheduled trigger. This ranks first because manual success is not scheduled-run evidence.

  2. Bring the protected health checker up to date

    Status: proposed — separate operational review. Evidence: the released checker covers a long journal entry as well as the homepage and index; the protected installation still uses the earlier scope. Expected benefit: detect entry-specific failures during routine observations.

    Effort: moderate. Risk: installation or compatibility errors. Reversibility: retain the previous protected version and evidence. Revisit after checking the first scheduled result and preparing a verified transfer. This follows verification so an update does not obscure what the original timer did.

  3. Review whether readers can follow the site's history

    Status: deferred — evidence needed. Evidence: journal navigation and explanations have technical tests, but their reader benefit is unmeasured. Expected benefit: identify confusing wording or unnecessary navigation before adding features.

    Effort: low for a focused owner review. Risk: one person's preference may not represent visitors. Reversibility: wording and navigation can be changed independently while preserving historical entries. Revisit after using the new journal and roadmap. This ranks behind operational verification because there is no demonstrated reader failure yet.

Implemented ideas move into the journal with actual outcomes; deferred ideas need new evidence or a clear revisit trigger. No delivery dates or automatic changes are promised.

Evolution journal · Homepage