Corrections and Updates

How an error is fixed

An error is corrected in place and marked with a dated note at the point of change, so a reader can see both the current text and what it replaced. We do not delete a page to hide a mistake, and we do not swap a figure without saying so. The note is written in plain language: what was wrong, what it now says, and the date.

This matters most with numbers that a reader might act on, such as a margin example or a statement about which entity serves the Philippines. If a worked figure such as the $85.50 margin on a 0.10-lot gold position was stated with the wrong arithmetic, the correction shows the corrected arithmetic rather than a bare apology.

What We Do When a Source Itself Changes Silently

When a source changes without announcing it, we treat the page as suspect until we have re-verified the affected claim, and we log the outcome even if the page's wording turns out to need no change. A silent change means the ground moved without notice, so a reader who relied on the page in the interval deserves a dated record of when we last checked. The entry in that case is an update, not an error, because the page was correct when written and we have simply confirmed or refreshed it. What we do not do is wait for a reader to notice first.

A silent source change is detected by re-checking rather than by monitoring, which means the schedule matters more than the alerting. We re-verify the claims that carry the most weight, the regulator caveat, the leverage cap applied by the entity serving the Philippines, the instrument specification, at a regular cadence rather than only when something looks wrong. The cadence is set by how much a claim could cost a reader if it went stale, not by how easy it is to check. The regulator caveat that FxPro is licensed by the FCA (UK) and CySEC and not by the SEC of the Philippines is checked directly, because a paraphrase of it is not a check.

When a silent change is found, the log entry says what we found and when we found it, and distinguishes the date of discovery from the date the source changed if the latter can be established. Often it cannot, and we say so rather than guess. An entry that honestly reads as discovery on one date with an unknown effective date is more useful than a confident wrong one. We also note whether the intervening period could have misled a reader, because that determines whether the fix is logged as an update alone or as an update plus a clarification of the surrounding text.

A silent source change sometimes reveals that our own wording was vaguer than it should have been, which is why the response is not purely mechanical. If a source moved and our sentence happened to remain true only because it was imprecise, we tighten it and mark that part as a clarification, separately from the update. The two marks sit side by side with the same discovery date. This is the case where the three-mark scheme earns its keep, because a single merged entry would hide the fact that one part of the change was the world moving and another part was us being sloppy.

The Difference Between a Correction and an Update

A correction fixes something that was wrong; an update records something that changed outside the page. If we said the pip value for gold was 0.10 and it is 0.01, that is a correction, because the page was never right. If the broker adds a platform or a regulator changes a rule and the page follows, that is an update, because the page was accurate when written and the world moved. The distinction matters because it tells a reader whether to distrust the page or simply to check its date. Both are logged, but they are not the same kind of event and they are not marked the same way.

A correction implies a failure on our side; an update implies none. When we correct, we are saying the page misled someone for some period, and the entry should be read as an admission of that. When we update, we are saying the page was correct for its time and has been brought forward. This is why we never dress a correction as an update. Relabelling a mistake as a refresh is the single most common way a corrections log becomes decorative, and it is exactly the habit this page exists to prevent. The label is chosen by what actually happened, not by what reads better.

A correction changes the substance of a sentence; an update often changes only its currency. If a page states the regulator caveat that FxPro is licensed by the FCA (UK) and CySEC and not by the SEC of the Philippines, that sentence is either right or wrong, and any change to it is a correction. If a page lists local funding through GCash and bank transfer and the broker adds a rail, the sentence was right before and is right after; that is an update. Readers can use the label as a rough severity signal: corrections deserve a second look at the surrounding text, updates usually do not.

A correction and an update can land on the same day and still be logged separately. We do not merge them into one entry, because merging hides which part was our failure and which part was the world changing. A single pass over a page might produce one correction to a margin example and one update to a platform list, and the log will show two entries with the same date and different labels. That granularity is deliberate. It costs us a little tidiness and gives a reader a precise account of what happened, which is the trade we would make every time.

Why the Log Stays Public

The log stays public because a page that claims to be accurate is worth nothing if the claim cannot be checked. Anyone can write that they correct errors promptly; only a visible log demonstrates it. Keeping it in the open means a reader in the Philippines deciding whether to fund an account through GCash can see how often this page has been wrong and about what. That is information they are entitled to and that we would rather they have than not. A private log would protect our reputation at the reader's expense, which is the wrong way round.

The log stays public because trading content is high-risk and errors here cost money. A wrong lot size or a misstated margin figure is not a cosmetic defect; it changes how much a reader risks on a gold position where one standard lot is 100 oz. When the cost of being wrong is measured in pesos, the record of past wrongness belongs in front of the reader, not in an internal file. We accept that this makes our mistakes permanently visible and searchable. That visibility is the point, and it is also the reason we take the original accuracy seriously.

The log stays public because it disciplines the writing. A correction that will be dated and displayed changes how a claim gets checked before publication. It is easy to be casual about a regulator caveat when nobody will ever see the fix; it is much harder when the fix will sit on the page with a date next to it. The public log therefore does double duty: it informs the reader and it constrains the writer. Both effects run in the same direction, toward fewer errors and faster acknowledgement of the ones that happen.

The log stays public because readers share pages. A screenshot of a paragraph can travel further than the page it came from, and once it does, the original page is the only place where the correction can catch up with it. A public, dated entry lets someone holding an old screenshot find the current text and see what changed. That function only works if the log is open to anyone, including people who never visit the site directly. A log behind a login or buried in a footer fails exactly the reader who needs it most, so it stays where it can be found.

How a Correction Is Recorded and Dated

A correction is recorded as a dated entry in the page's change log, written at the moment the fix goes live rather than when it was first noticed. Each entry carries the date, the section affected, the old wording in short form, the new wording in short form, and the kind of change it is. The date is the publication date of the corrected text, not the date of the original mistake, because a reader needs to know when the page last became accurate. Where a correction follows a reader report, the entry notes that a report prompted it, without naming the reader.

A correction is dated to the day, in plain calendar form, with no rounding to a month. The entry sits on the page itself and in the log, so a reader who arrives months later sees the same date in both places. We do not backdate an entry to make a page look as though it was right all along, and we do not forward-date one to batch several fixes together. If a correction about the leverage cap applied by the entity serving the Philippines goes live on a Tuesday, the entry says Tuesday, even if the underlying change was noticed the previous week.

A correction records what the page said before, not only what it says now. That is the part most sites skip, and it is the part that makes the log useful, because a reader who saved or screenshotted the older text can match it to the entry and see exactly what moved. The old wording is kept short, a clause or a figure, enough to identify it. We do not reproduce an entire retired paragraph, since the point is identification rather than archive. For a figure like the $85.50 margin on a 0.10-lot gold position, the entry would show the old number and the new one side by side.

A correction is written in the same plain English as the page it corrects, with no hedging and no euphemism. We say what was wrong. We do not write that a figure was refined or that language was adjusted when the truth is that the page stated something incorrect. The entry also states whether anything downstream changed as a result: whether a worked example was recalculated, whether a related page was corrected in the same pass, or whether the fix was contained to one paragraph. That last detail tells a reader whether they need to re-read more than the corrected line.

What Counts as an Error Worth Logging

An error worth logging is a statement on this page that was wrong when it was published, or that became wrong because the facts behind it changed and we did not follow up. That covers a wrong instrument specification, a misattributed regulator, a leverage figure that no longer matches the cap applied by the entity serving the Philippines, or a funding method listed that the broker no longer supports. It does not cover a reader disagreeing with our emphasis, a preference for a different platform, or a market opinion that aged badly. Those are not factual failures, and logging them would dilute the log until it stopped meaning anything.

An error worth logging must be traceable to something checkable: a specification, a regulator's own published position, a platform list, or a funding rail. For gold (XAU/USD) that means the contract size of 100 oz per standard lot, the pip value of 0.01, and the reference price we quote around 4275.0 are all in scope, because each is a fact someone can verify independently. If we wrote that 1 lot was 10 oz, that is a loggable error. If we wrote that a ₱50,000 account is enough to trade 0.10 lots comfortably, that is an opinion and belongs in a rewrite, not a correction.

An error worth logging must have mattered to a reader's decision. A typo in a heading, a broken link, or a misformatted peso sign gets fixed quietly and does not enter the log, because nothing downstream depended on it. A wrong margin example does matter: we state that a 0.10-lot gold position needs about $85.50 margin at the applicable cap, and if that figure were attached to the wrong lot size a reader sizing a position through GCash funding could take on exposure they did not intend. That is the threshold. Severity, not embarrassment, decides what gets a dated entry.

The test is whether a careful reader could have acted differently had the page been right. Errors that change position sizing, funding expectations, or which regulator actually supervises the broker pass that test. Errors that change nothing a reader would do fail it. We apply the same test to pages about MT4, MT5, cTrader and the FxPro app, since a wrong platform claim can send someone to install software they cannot use with their account. When in doubt, we log it rather than argue about it, because an unnecessary entry costs a reader nothing while a missing one costs them trust.

How a Reader Can Check the History of a Page

A reader checks a page's history by opening its change log and reading the entries in date order, oldest first, paying attention to the mark on each one. The log sits with the page rather than in a separate archive, so the history of what you are reading is available where you are reading it. Each entry names the section affected, so you can go straight to the paragraph that moved rather than re-reading the whole page. That is the whole method: find the log, read the dates, follow the section names. No account or request is needed.

A reader checking history should start with the most recent entry and work backwards until the dates are older than the claim they care about. If you are relying on the leverage cap applied by the entity serving the Philippines, you need the page's state as of your reading, which means the latest entry touching that claim, not the oldest. Working backwards answers the practical question, which is whether anything has moved since the version you saw. Working forwards answers a different question, about how the page got here, and both are worth doing at different times.

A reader checking history can cross-check a logged correction against the thing it cites. If the log says a regulator statement was corrected, the check is the regulator's own published position, not this site's summary of it. If the log says an instrument specification was corrected, the check is the contract terms for gold at 100 oz per standard lot and 0.01 per pip. This is the reason entries name their subject concretely instead of saying a figure was adjusted: a named subject can be verified by someone who does not trust us, and an unnamed one cannot.

A reader checking history should treat an empty or very short log as information, not reassurance. A page that has never been corrected may be immaculate or may be unmaintained, and the log alone cannot tell you which. What distinguishes them is whether the entries that do exist are specific: a real log names sections, shows old and new wording, and dates each change to the day. A log of vague reassurances is a decoration. Read the specificity, not the count, and if a claim you depend on has no entry either way, verify it at the source before you act on it.

A changed condition is a re-check, not an error

If a broker has changed a term since we read it, the original page was not wrong at the time it was written, and we treat that as a re-check rather than a correction. The page is updated to the current position and the date is moved forward, with a note that the condition changed rather than a claim that we had made a mistake.

The distinction is worth keeping because it tells a reader how much to trust a date. A correction means we got it wrong; a re-check means the world moved. Both are visible on the page, and neither is hidden, so a reader can judge how fresh the figure is before relying on it.

The Three Kinds of Change and How Each Is Marked

Every change to this page is marked as one of three kinds: error, update, or clarification, and the mark is visible in the log entry itself. An error mark means the page stated something incorrect and now states something correct. An update mark means the page was correct when written and the underlying fact moved. A clarification mark means the page was correct but ambiguous, and the wording has been made harder to misread. The three marks are used consistently across the site so that a reader who learns them once can read any page's log without relearning the scheme.

An error mark is the strongest of the three and is never used loosely. It carries the old figure or clause and the new one, plus the date the incorrect text was published if that can be established. We do not soften an error into a clarification because the wording sounds less damning. If a page said the maximum leverage available in the Philippines was something other than the cap applied by the entity serving this country, that is an error, full stop, and it gets the error mark. The mark exists to be uncomfortable, and we let it be uncomfortable rather than dilute it.

An update mark is used when nothing was wrong and something moved. It records the date the change took effect where that is knowable, and the date we reflected it, which are often different. An update to a platform list covering MT4, MT5, cTrader and the FxPro app would show both. Updates do not carry an apology, because none is owed, but they do carry the same date discipline as corrections. A reader scanning the log can treat update marks as a signal that the page is being maintained, and error marks as a signal that it once misled, and the two signals are kept visibly separate.

A clarification mark sits between the other two and is the one readers should read most carefully. It means the sentence was defensible but could reasonably have been read two ways, and we have removed the ambiguity. It is not an admission of a factual error and it is not a routine update; it is a recognition that clarity failed. We mark it separately because collapsing it into either neighbour would misreport what happened. If a paragraph on position sizing could be read as implying a guarantee, a clarification rewrites it to remove that reading, and the mark says so plainly.

Why Nothing Is Deleted

Nothing is deleted because a deleted entry is indistinguishable from an entry that never existed, and that ambiguity destroys the value of the log. If a correction can be quietly removed, a reader has no way to tell a clean record from a scrubbed one, and the log stops being evidence. So retired wording stays, superseded figures stay, and entries that turned out to be unnecessary stay with a note saying so. The log only grows. A log that can shrink is not a log; it is a marketing page wearing a log's clothes.

Nothing is deleted because the older text is what a reader may be holding. Someone who screenshotted a paragraph, saved a page, or quoted it in a group chat has the old version, and the only way to reconcile that with the current page is to keep the old version visible in the record. This matters more for figures than for prose: a reader who sized a gold position using an older margin figure needs to find that figure in the log and see what replaced it. Deleting the old wording strands exactly the reader the log is meant to serve.

Nothing is deleted because removal would let us hide the pattern rather than the instance. One correction is an event; a cluster of corrections on the same claim is a signal about how that claim gets written, and a reader can only see the cluster if the entries accumulate. Keeping everything means a reader can count how often a particular statement has moved and decide how much weight to give it. That is a judgement we should not be able to make on the reader's behalf by pruning the record. The pattern is the reader's to read, and pruning is how a site takes that away.

Nothing is deleted because the cost of keeping an entry is near zero and the cost of removing one is a loss of trust that cannot be recovered. Storage is not the constraint; credibility is. We accept that the log will accumulate entries that look unflattering years later, including corrections to things we were confident about. That is the honest shape of a maintained reference page. A page that has never been wrong is not a page that has been carefully checked; it is a page whose mistakes were removed before anyone could count them.

How to report one

Send the report to [email protected] with the page address and the sentence you believe is wrong. If you can, say what the correct version should be and where you saw it, such as the broker's own document and the date you read it. That lets us check the source rather than guess.

We look at every report, but we only change a page when the evidence supports the change. A report that turns out to be a difference of opinion, or a claim we cannot verify against the broker's documents, will not result in an edit, and we will say why rather than pretend it was fixed.

Who Decides, and in What Time

The decision to log a change rests with the person who maintains the page, and it is made against the three-mark scheme rather than by feel. That person decides whether a report describes an error, an update or a clarification, drafts the entry, and publishes it with the fix. There is no committee and no queue of approvals, because a queue is where corrections go to age. The same person is accountable for the original text, which keeps the incentive honest: the person who must date the fix is the person who benefits from getting it right the first time.

The time to act depends on severity, and severity is judged by what a reader could do wrong in the meantime. A wrong margin figure, a wrong lot size, or a misstated regulator caveat is treated as urgent and is fixed and logged as soon as it is confirmed, ahead of any other work on the page. A wording ambiguity that could be misread but has not yet misled anyone is handled in the next scheduled pass. We do not publish a fixed hour count, because promising a number we might miss would be worse than describing the rule we actually follow. The rule is severity first, then everything else.

Confirmation comes before publication, and confirmation means checking the claim against its source rather than against another page on this site. For a regulator statement, that means the regulator's own published position, not a summary of it. For an instrument specification, that means the contract terms, not a forum post. We would rather publish a correction a day later and be right than publish it immediately and be wrong twice. A reader report that cannot be confirmed is not logged as an error, but it is not discarded either; it stays open until it can be settled one way or the other.

Anyone can raise a change, and no report is filtered by the reporter's credentials. A reader who has never traded gold and a reader with a funded account get the same treatment, and a report that turns out to be mistaken gets a reply explaining why rather than silence. We do not require an account, a deposit, or any relationship with the broker to have a report considered. The only thing that moves a report forward is whether the claim can be checked against a source, which is a property of the claim, not of the person making it.