Corrections log: public record of BroadbandSwitch.uk content corrections

Public correction documentation supports reader trust. Where significant corrections happen, readers benefit from being able to see what was corrected, when, and why - rather than the correction happening silently with content updated in place.

Builds on the corrections process. The corrections process at https://broadbandswitch.uk/corrections/ is the engagement path for submitting corrections. The corrections log is the public record of what's been done as a result. Together they form the accountability cycle.

Foundational to the editorial mission. BroadbandSwitch.uk's mission to help UK households and small businesses requires reader trust. Reader trust requires visible accountability. Visible accountability requires public correction documentation. The corrections log is the documentation layer.

Aligned with comparable editorial standards. Quality news organisations and editorial sites typically maintain public corrections records as part of standard editorial practice. BroadbandSwitch.uk's corrections log aligns with this standard.

Verifying that submitted corrections have been actioned. Where readers have submitted corrections through the corrections process, the log provides verification that the correction has been processed (where the correction was substantive enough to log).

Tracking patterns in editorial corrections over time. Aggregate patterns - what kinds of corrections happen, where corrections cluster, what topics need most updating - provide insight into editorial quality and content evolution.

Verifying date-relevant claims on specific pages. Where the corrections log shows a recent correction on a page covering a topic readers care about, readers can be confident the page reflects current information.

Researching specific topics. Researchers, journalists, regulators, or readers interested in how UK 2026 broadband content evolves can use the log as primary source for that evolution.

Building confidence in the editorial process. Where readers see that corrections happen, get logged, and result in substantive content improvements, that builds confidence that the editorial process is responsive to feedback.

Routine maintenance. Typo corrections, minor formatting adjustments, internal cross-link updates, regular lastModified date refreshes - these typically aren't logged because they don't change the substantive content readers rely on.

Editorial style changes. Where the editorial team updates style conventions across the cluster (for example, updating phrasing standards), individual page changes from the style update aren't logged separately - the underlying convention update is documented in the editorial policy or methodology hub instead.

Internal workflow updates. Internal editorial workflow changes (review processes, source verification approaches, AI tool usage updates) aren't logged here. These are documented in the editorial policy and AI disclosure.

Personal information about reader submitters. Where readers submit corrections, log entries don't identify the reader by name unless they're a public figure speaking in their public capacity. Reader privacy is respected.

Confidential commercial information. Where corrections relate to commercial relationships, log entries describe the correction without disclosing confidential commercial terms.

Factual corrections affecting reader-relevant claims. Pricing corrections, regulatory framework corrections, provider data corrections, customer service ranking corrections, and similar factual corrections that affect what readers understand from the content.

Methodology updates. Changes to the documented 12-factor scoring model, the four core ranking principles, or contextual ranking adaptation logic. These affect how rankings work and warrant transparency.

Source attribution corrections. Where source attribution was incorrect (wrong publication date, wrong author, wrong URL) and corrections are made.

Significant accessibility fixes. Where accessibility issues that affected reader access are resolved. Standard accessibility maintenance isn't logged but substantive accessibility fixes are.

Provider response-driven corrections. Where providers submit corrections through the corrections process that result in substantive content updates. Same evidence standards apply to provider responses as reader corrections; logged entries don't distinguish source beyond the documentation.

Typo corrections. Spelling fixes, punctuation corrections, minor wording adjustments that don't change meaning.

Minor formatting adjustments. Spacing fixes, list reformatting that doesn't change content, callout block adjustments.

Internal cross-link updates. Where related guides cluster or internal references need updating because of broader cluster reorganisation.

Regular lastModified date refreshes. Where pages get updated as part of regular review cadence without substantive content changes.

Reference list maintenance. Where APA references get format corrections without underlying source changes.

Some corrections fall on the boundary. A correction that's small in scope but addresses a meaningful factual issue might warrant logging; a correction that's larger in scope but only affects formatting might not. Editorial judgment applies.

When in doubt, log. The default approach is to log if there's any meaningful question about whether a correction is substantive. Logging is cheap; missing significant corrections is expensive in terms of reader trust.

Reader feedback can drive logging decisions. Where readers tell us a correction we considered minor was actually significant to them, we adjust our logging approach.

Date of change. The date the correction was applied to the affected page. Format: DD Month YYYY (for example, 28 April 2026). This lets readers see currency and track timing.

Page affected. Full URL of the page where the correction was made. Letting readers click through to verify the corrected content.

Nature of the correction. Plain-language description of what was corrected. Specific enough to be useful (mentioning the specific claim or section affected) without revealing private reader information.

Source supporting the corrected information. The authoritative source the correction is based on (Ofcom publication, provider Key Facts document, Citizens Advice research, customer review platform aggregate, etc.). Helps readers verify the correction independently.

Editorial team member who actioned the correction. Adrian James (broadband editor) for most corrections; Dr Alex J. Martin-Smith (head of editorial) for methodology-related entries. Reflects accountability through named editorial team.

Category. Which of the five logged categories this correction falls into (reader-driven factual, methodology update, regulatory framework change, provider data refresh, accessibility fix).

Reader feedback context. Where the correction came from reader feedback through the corrections process, this is noted (without identifying the specific reader unless they're a public figure speaking in their public capacity).

Provider response context. Where the correction came from a provider response through the corrections process, this is noted.

Pattern recognition note. Where a correction is part of a pattern of similar corrections across multiple pages, the pattern is noted.

Cross-page impact. Where the correction was applied to a single page but informed similar updates across the cluster, the broader impact is noted.

External regulatory trigger. Where the correction was triggered by external regulatory developments (Ofcom rule changes, Telecoms Consumer Charter updates, etc.), this is noted.

Each log entry appears in the recent-entries section as a structured callout block. The standard fields appear in consistent order so readers can scan multiple entries quickly. Plain language is used throughout - no jargon or insider terminology that would obscure what was corrected. Length varies based on the complexity of the correction; most entries fit in 3-5 sentences while substantial methodology updates may need longer explanations.

Corrections triggered by reader feedback through the corrections process where readers identify factual errors in published content. Examples of what falls within this category: pricing corrections where a reader notices a provider package price doesn't match current Key Facts documents; regulatory information corrections where a reader notes an Ofcom rule has been mischaracterised; provider information corrections where a reader notices a provider has changed their service and our content hasn't caught up; customer service ranking corrections where a reader provides evidence that customer service patterns have shifted; missing alternatives corrections where a reader points out we haven't included a relevant altnet covering their address. How these get processed: Adrian reviews the submitted correction; verifies against authoritative sources; updates the affected page; logs the correction with reader-feedback context noted.

Changes to the documented 12-factor scoring model, the four core ranking principles, or contextual ranking adaptation logic. Examples of what falls within this category: scoring weight adjustments where review identifies that one of the 12 factors should weigh more or less in specific contexts; new factor additions where market evolution makes a previously unconsidered dimension important; factor refinements where the description of a factor needs improvement; ranking principle clarifications where the four core principles need clearer articulation. How these get processed: methodology updates typically involve both Adrian and Alex throughout because the underlying methodology framework is Alex's responsibility; methodology changes are logged with detailed explanation of what changed and why because methodology is foundational to ranking outputs.

Updates triggered by external regulatory developments that affect content across the cluster. Examples of what falls within this category: Ofcom rule changes (mid-contract price rise rules, Automatic Compensation rate updates, social tariff guidance updates, Voluntary Code of Practice on Broadband Speeds revisions); Telecoms Consumer Charter updates (the February 2026 Charter and any subsequent amendments); Ofcom Connected Nations report releases (the November 2025 release and future annual releases); Citizens Advice research releases that update loyalty penalty figures; provider regulatory complaints that result in market changes. How these get processed: regulatory framework changes typically affect multiple pages across the cluster; Adrian implements updates with Alex review; logged with external regulatory trigger note and cross-page impact note.

Updates to provider package data, pricing, service availability, and similar provider-specific factual content. Examples of what falls within this category: package pricing changes that fall outside the standard 90-day refresh cadence (significant promotional changes, package launches or withdrawals); provider corporate changes (mergers, rebrands, ownership changes); altnet rollout milestones (new geographic coverage, technology upgrades); customer service satisfaction data updates from new Ofcom Telecoms Customer Experience reports; provider response-driven corrections where providers submit corrections through the corrections process. How these get processed: Adrian implements updates with verification against provider Key Facts documents and authoritative sources; logged with provider response context where applicable.

Updates triggered by accessibility issues identified through reader feedback or editorial review. Examples of what falls within this category: alt text additions where informational images were missing alternative text; contrast adjustments where text colour against background didn't meet WCAG 2.2 AA requirements; heading hierarchy fixes where heading levels were skipped or misused; link text improvements where generic anchors needed replacement with descriptive text; navigation pattern adjustments where breadcrumb or table of contents needed accessibility improvements; screen reader compatibility fixes where reader feedback identified issues with specific assistive technology. How these get processed: Adrian implements accessibility fixes with priority routing through the corrections process; structural accessibility issues route to Alex for review; logged with reader feedback context where applicable noting that priority routing was applied.

Date of change: 28 April 2026.

Page affected: https://broadbandswitch.uk/corrections-log.html (this page).

Nature of the correction: Initial publication of the corrections log as a dedicated public transparency page. This formalises the corrections logging approach that has informed editorial workflow throughout the v3 programme. Going forward, substantive corrections that meet the documented logging criteria will appear in the recent-entries section of this page.

Source supporting the corrected information: Editorial policy at https://broadbandswitch.uk/editorial-policy.html which documents the corrections process and accountability standards.

Editorial team member who actioned the correction: Adrian James (broadband editor) wrote the corrections log content; Dr Alex J. Martin-Smith (head of editorial) reviewed before publication.

Category: Methodology update (formalising the corrections logging approach as part of the documented trust framework).

Cross-page impact: The corrections log is now linked from the trust block on every page where the affiliate disclosure and editorial policy are linked, completing the multi-tier trust framework.

Prior to the formal launch of this corrections log page, substantive corrections were tracked through the editorial workflow but not published in a dedicated public log. Where readers want to verify whether a specific page received corrections during the v3 programme rollout, the dateModified attribute in each page's JSON-LD reflects the most recent substantive update. Going forward, the corrections log provides additional public transparency beyond just dateModified attributes.

The v3 programme rollout itself involved comprehensive content updates across the cluster including: refreshed UK 2026 regulatory framework references (Telecoms Consumer Charter introduced February 2026, Ofcom January 2025 fixed pounds-and-pence rule, Ofcom Connected Nations 2025 published November 2025); updated April 2026 mid-contract rise documentation across all major UK providers; refreshed customer service satisfaction data from current Ofcom Telecoms Customer Experience reports; comprehensive UK altnet inclusion expanded to cover Hyperoptic, Community Fibre, CityFibre-based retail, Netomnia-based retail (including YouFibre with multi-gigabit symmetric up to 7 Gbps), toob, Brsk, Trooli, BeFibre, Lit Fibre, Zen Internet, Gigaclear, B4RN; updated trust framework documentation across about page, methodology and trust hub, how-we-rank, why-trust, editorial policy, affiliate disclosure, AI disclosure, contact page, media centre, two editorial team profile pages, accessibility statement, and corrections log. These updates aren't logged as individual corrections because they were comprehensive content production rather than corrections to existing v3 content; the v3 programme is documented in the methodology and trust hub.

Newest entries first. Recent entries appear in reverse chronological order so readers see the most current corrections first.

Approximately 12 months of entries visible. Recent entries section shows approximately 12 months of corrections; older entries are archived to maintain log readability while preserving the public record.

Archive available on request. Where readers want access to corrections older than the visible 12-month window, archived entries are available through the corrections process noting "log archive" in the subject.

Consistent format across all entries. Each entry follows the documented log entry format so readers can scan multiple entries efficiently.

Pattern recognition through aggregate review. Where corrections cluster around specific topics, providers, or page types, that pattern visibility supports both reader trust and editorial quality improvement.

Adrian handles the corrections process and maintains the log. When Adrian processes a correction submitted through the corrections process at https://broadbandswitch.uk/corrections/, the workflow includes determining whether the correction warrants logging and adding the log entry if so.

Methodology-related entries route to Alex for review. Where corrections affect methodology, ranking framework, or trust principles, Alex reviews both the correction itself and the proposed log entry before publication. This ensures methodology log entries reflect the editorial team's collective view.

Logging happens at correction completion. Once a correction is implemented on the affected page, the log entry is added. This means the log accurately reflects what's been done rather than what's planned.

Logging is not a separate workflow. Adding log entries doesn't require separate review or approval beyond the editorial review of the underlying correction. Treating logging as part of correction handling rather than a separate task makes consistent logging practical.

Alex reviews the corrections log periodically. As part of regular trust framework maintenance, Alex reviews the corrections log to ensure entries are accurate, appropriately detailed, and consistent with the documented log entry format.

Reader feedback on log entries. Where readers identify errors or missing context in log entries, the corrections process accepts that feedback noting "corrections log" in the subject. Log entries can be corrected like any other content.

Pattern review. Periodic review of the corrections log across categories helps identify whether logging conventions are working well or whether adjustments are needed.

Reader privacy respected. Where corrections come from reader feedback, log entries don't identify the reader by name unless they're a public figure speaking in their public capacity. Reader-feedback context is noted without compromising privacy.

UK GDPR compliance. We respond to UK GDPR data subject access requests within statutory timeframes (typically 30 days where applicable, or extended where the request is complex). Privacy enquiries route through the corrections process noting "privacy" in the subject.

Confidential commercial information protected. Where corrections relate to commercial relationships, log entries describe the correction without disclosing confidential commercial terms.

Provider response privacy. Where corrections come from provider responses, log entries note provider response context without disclosing confidential commercial communications beyond what's necessary for transparency.

Approximately 12 months of recent entries visible. The recent-entries section shows approximately 12 months of substantive corrections so readers can see current correction patterns and verify recent submissions.

Visible retention may extend longer for high-impact entries. Particularly significant methodology updates or regulatory framework changes may remain visible beyond 12 months because their context remains relevant.

Page readability balanced with comprehensive coverage. Visible retention balances the need for readers to see current correction patterns with the need for the page to remain readable. As corrections accumulate, older entries are archived to maintain readability.

Archived entries available on request. Where readers want access to corrections older than the visible 12-month window, archived entries are available through the corrections process noting "log archive" in the subject.

Minimum 12 months archived retention. Substantive correction log entries are retained for at least 12 months even after they leave the visible recent-entries section.

Longer retention for methodology and regulatory entries. Methodology updates and regulatory framework change entries are retained longer because they affect ongoing content interpretation.

Provider response and reader feedback context preserved. Where archived entries note provider response or reader feedback context, that context is preserved in archived form.

Pattern reference. Where understanding a current pattern requires older entries as reference, those older entries may remain visible or be re-surfaced.

Regulatory or legal relevance. Where archived entries become relevant to current regulatory or legal context, entries may be re-surfaced for visibility.

Reader research access. Where researchers, journalists, or regulators have legitimate research interest in older corrections, archive access is available with reasonable response timeline.

Reader submits correction via the corrections process. Available at https://broadbandswitch.uk/corrections/ from every page on the site. Reader provides specific page URL, description of the issue, and any supporting evidence.

Adrian reviews the submitted correction. Verifies against authoritative sources; assesses whether the correction is supported by evidence; determines next steps.

Methodology challenges escalate to Alex. Where corrections affect methodology, ranking framework, or trust principles, the issue routes to Alex for review.

Affected page updated. Where the correction is supported by evidence, the affected page is updated with the corrected information.

Correction logged where substantive. Where the correction meets the documented logging criteria, a log entry is added to the corrections log on this page.

Reader can verify through the log. Where the reader wants to verify their correction has been actioned, the log entry provides verification.

Pattern recognition over time. Where multiple readers identify similar issues, pattern recognition through log review prioritises the editorial update queue.

Corrections process is the engagement path. The corrections process page documents how readers can submit corrections, what evidence helps, what to expect, and the routing logic. This is the prospective page for readers thinking about submitting a correction.

Corrections log is the public record. The corrections log page documents what corrections have been actioned and provides public transparency on editorial accountability. This is the retrospective page for readers wanting to see what's happened.

Together they form the complete accountability framework. Engagement path plus public record creates a complete accountability framework. Either alone would be incomplete - just an engagement path without a public record means corrections happen silently; just a public record without an engagement path means readers can see corrections but can't easily contribute new ones.

Corrections process page links to the corrections log. So readers thinking about submitting can see the public record of how corrections are handled.

Corrections log page links to the corrections process. So readers viewing the log can submit new corrections through the appropriate path.

Trust block on every page links to both. The trust block at the end of every substantive page references the corrections process for engagement; the broader trust framework documentation references the corrections log for public record.

Browse the recent-entries section. Recent corrections appear in reverse chronological order so readers can see what's happened recently.

Verify specific submitted corrections. Where readers have submitted corrections through the corrections process, the log provides verification that the correction has been actioned (where the correction was substantive enough to log).

Track patterns. Aggregate review across multiple entries reveals patterns in the kinds of corrections happening, which topics are most frequently corrected, and which providers receive most update activity.

Verify currency on specific pages. Where the corrections log shows recent corrections on a page covering a topic of interest, that's evidence the page reflects current information.

The corrections process is the engagement path. Available at https://broadbandswitch.uk/corrections/ from every page on the site.

What helps with corrections submissions. Specific page URL where the issue occurs; description of the issue including what specific claim is incorrect or what's missing; supporting evidence including authoritative sources where the corrected information can be verified; any context that helps Adrian assess the correction efficiently.

What to expect. Acknowledgement within 1-2 working days for typical corrections (faster for accessibility); resolution within 2-5 working days for substantive corrections; substantive response engaging with the specifics; log entry where the correction meets logging criteria.

Where readers see issues with log entries. Errors in log entries, missing context, unclear descriptions - these can be raised through the corrections process noting "corrections log" in the subject. Log entries can be corrected like any other content.

Where readers want format suggestions. Suggestions about the log entry format, what fields would be more useful, how categories are defined - these are welcomed through the corrections process. Periodic review of the corrections log format incorporates substantive reader feedback.

Where readers want longer or shorter retention. Suggestions about retention approach (visible retention duration, archive access ease, retention triggers) are welcomed through the corrections process.

Submit archive requests via the corrections process noting "log archive" in the subject. Adrian handles archive access requests with reasonable response timeline.

What helps archive requests. Date range of interest; specific topic, page, or category if applicable; research context if relevant. Specificity helps efficient retrieval.

What to expect. Archive access typically within 5-10 working days for standard requests; faster for time-sensitive requests where reasonable.