Page maintenance
Spelling, formatting, accessibility repair, metadata or layout changes that do not change the method or substantive claim.
Trust and governance · Corrections
Not every edit is a method change—and not every method change is a minor edit.
The correction system separates presentation maintenance from changes that alter facts, decision logic or safe use. The goal is a visible record without creating meaningless version churn.
4 change classesDecision-impact testVisible correction path
Four change classes
The first question is not “what version number should this get?” It is “did the public fact, method or permitted use change?”
CLASSIFY THE CHANGEWhat actually changed?Presentation · fact · decision logic · safe use
Factual correction
A published factual statement, source attribution, calculation or representation was materially wrong and needs correction.
Methodology change
A rule, threshold, classification, decision sequence, evidence requirement or output meaning changes.
Retirement / withdrawal
A page or method should no longer be used because it is obsolete, superseded or materially unsafe in its existing form.
The decision tree
- 01Did substantive meaning change?
If no, treat it as maintenance. Do not manufacture a method-version event for typography or layout.
- 02Was a factual statement wrong?
Correct the record and disclose the material correction where a reader could otherwise rely on the old statement.
- 03Did the decision logic change?
Create a new method identity, explain what changed and assess whether previous outputs need reinterpretation.
- 04Did the safe-use boundary change?
Update the limitation and consider whether existing pages, tools or handoffs need reopening.
- 05Is the old method still usable?
If not, retire or clearly supersede it rather than leaving an ambiguous historical version active.
What a material correction record should preserve
What changed
The specific fact, rule or output meaning—not just “page updated”.
Why it changed
Error, new evidence, clarified boundary, method evolution or retirement reason.
Decision impact
Whether the change can alter a prior classification, recommendation or safe-use boundary.
Affected surfaces
HTML, tool, workbook, PDF, schema, downloads or other components that need parity.
Effective identity
The new file/method/version identity after the correction.
Re-test state
Which direct tests were rerun and which remain pending.
Two failure modes to avoid
When should accepted work reopen?
Accepted work should not be destabilized by every later editorial preference. Reopening needs a material reason.
Material factual defect
A decision-bearing statement is wrong or unsupported.
Method inconsistency
Different surfaces implement materially different decision logic.
Serious accessibility failure
A required public task cannot be completed or read by an affected user.
Regression
A later change breaks a previously working route, asset, interaction or handoff.
Missing required evidence or asset
A claim, method, required asset or portable output cannot support the next authorized stage.
New authority
A formally accepted project decision explicitly supersedes the prior state.
Versioning is informative, not theatre
Semantic Versioning is a useful analogy because it connects version changes to change meaning. SERPIFAI does not claim strict SemVer compliance for editorial methodologies; the governing question is material decision impact.
| Change meaning | SERPIFAI treatment |
|---|---|
| Maintenance / patch-like | No decision logic change; correct or improve implementation/presentation. |
| Material but compatible evolution | Method gains or clarifies functionality without invalidating the central decision contract. |
| Breaking / major change | Core decision meaning, classification, required evidence or safe-use boundary changes enough that prior outputs may not be comparable. |
Report a possible error
Provide the route, the statement or behavior you believe is wrong, and the evidence that supports the correction. Do not send unnecessary sensitive information. A report is review input, not automatic publication authority: the public state changes only after classification, evidence review and the required release checks.
NON-COMMERCIAL NEXT ACTION
Report an error →Submit a correction request
A reported error should be classified before it is edited so factual correction, method change and maintenance do not get conflated.
Not every product improvement is a methodology change
The change class depends on what the user is allowed to conclude—not on how visible the interface change looks.
| Change | Normal class | Why |
|---|---|---|
| Make Guided mode the default | Product / presentation | The same protected method is easier to interpret. |
| Demote an exact score behind Analyst detail | Product / claim-safety | Authority is reduced, not changed, when scoring logic stays the same. |
| Add source-role coverage or Evidence Ladder | Evidence / product | Evidence acquisition and explanation improve without changing weights or gates. |
| Change a dimension weight or critical gate | Methodology change | The same inputs can now produce a materially different decision treatment. |
| Fix a broken label or inaccessible control | Correction / maintenance | The intended method was not meant to change. |
Evidence and source roles
COPE informs the value of visible post-publication correction; SemVer provides a useful change-meaning analogy. SERPIFAI applies these ideas to its own editorial/methodology governance rather than claiming journal or software-standard equivalence.