Corrections and Updates

Errors are fixed in place, with a date

When we get something wrong, we correct it on the same page and add a dated note saying what changed. We do not delete the page, rewrite it silently, or let an old version stand while a newer one circulates elsewhere. The note stays visible so a reader can see the history.

A correction is not a marketing event and we do not bury it. If the error affected a ranking or a description of how a broker works for Philippine residents, the note says so plainly and the affected text is rewritten rather than patched around.

How to report an error

Report an error by writing to editor@palawanmirrorph.com with the page, the sentence and what you believe is correct. If you can point to the broker's own document and the date it was read, that is the most useful form of report and the quickest to verify.

We check the report against our source documents before changing anything. If we agree, the page is corrected and the note is dated. If we disagree, we will tell you why rather than leave the report unanswered.

The three change types and the mark each one carries

Every change on this page is marked as an error, an update, or a clarification, and the mark is visible in the history. An error mark means the prior text was wrong against the source. An update mark means the prior text was right on its date and the underlying condition moved. A clarification mark means the prior text was not wrong but could be read in a way that misleads, so the sentence was tightened without changing the fact. Three marks, three different meanings, and a reader can tell them apart at a glance.

The clarification mark is the one readers ask about most, because it is the easiest to abuse. We use it only when the underlying fact is unchanged and the edit removes ambiguity, such as making clear that a leverage figure is a cap and not a setting to aim at. If the edit changes what a reader would do, it is not a clarification; it is an error or an update and gets that mark. A clarification that quietly changes a number would defeat the whole log, so we treat that as a serious mistake and correct the mark as well as the text.

The marks are applied at the moment the change goes live, not retroactively. If we later discover that what we marked as a clarification was in fact an error, we do not relabel the old entry; we add a new entry saying the earlier mark was wrong and why. That keeps the history honest about our own process, not just about the facts. A reader checking the history sees not only what the page said but how we classified each change, including the times we classified one badly and said so.

When a source changes without saying so

When a source changes silently, we treat the page as unverified until we can re-check it against the source's current text, and we say in the log that the source moved without notice. A regulator page that changes a licence reference, or a contract specification that alters a lot size or pip definition, can invalidate a sentence overnight with no announcement. The page does not get the benefit of the doubt in that window. We mark it as under re-check, keep the prior text visible with its date, and publish the new text only once the source is confirmed.

Silent source changes are the hardest case because there is no announcement to cite, only a difference between what we recorded and what the source now says. We handle that by keeping our own snapshot of the source at the time of publication, so the comparison is against a record rather than memory. If the snapshot and the live source disagree, the log entry names both and dates both. That way a reader can see that the page was accurate against the old source and is being corrected against the new one, rather than being told the page was simply wrong all along.

We do not guess at the reason for a silent change. If a leverage cap or a funding rail changes without explanation, the log says what changed and when we detected it, not why. Speculation about a regulator's motive or a broker's intent would be exactly the kind of unsupported claim this page exists to avoid. The reader gets the fact of the change, the date we found it, and the corrected text. Anything beyond that is left to the source to explain, and we say so when the source has not.

What qualifies as a logged error on this page

A logged error is a factual statement on the page that is wrong against the source we relied on at publication. That means a price reference, a lot size, a pip value, a formula, a regulator name, a funding rail, or a leverage cap that does not match the record. A typo that changes no meaning is fixed quietly; a typo that changes a number readers act on is logged. The test is simple: would a reader following the page make a different decision because of it? If yes, it belongs in the log.

An error worth logging must be checkable against a named source, not against opinion. If we wrote that 1 standard lot of gold is 100 oz and the contract specification says otherwise, that is an error. If we described a margin figure at the applicable cap and the arithmetic does not reproduce, that is an error. If a reader disagrees with our emphasis or tone, that is not an error and we say so plainly. Logging is reserved for things that can be shown wrong, so the log stays short and credible.

Errors of omission count when the missing fact would mislead. A page that explains margin on a 0.10-lot gold position but never says the leverage figure is a cap, not a target, leaves a reader with a wrong mental model. We log that as an error of framing. What we do not log is every fact we chose not to include for length. The distinction is whether the page as written asserts something false or leaves a false impression on a point it chose to cover.

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

If a broker has changed a term, a platform detail or a document since the date we read it, that is a re-check, not an error. We record the read date for exactly this reason: a page can be accurate on the day it was checked and out of date later without anyone having made a mistake.

The distinction matters because it changes what we do. An error gets a correction note; a changed condition gets a fresh check and an updated read date. Either way, figures on this site are dated and should be verified with the broker before you act on them.

Where a correction ends and an update begins

A correction fixes something that was wrong; an update changes something that was right when written but is no longer current. If we stated the leverage cap that applies to the entity serving the Philippines and that cap later changes, the old sentence was accurate on its date and the new sentence is accurate on its date. That is an update, and it is marked as one. If the old sentence never matched the cap in force on its date, that is a correction. The distinction is whether the page was right then, not whether it is right now.

Updates are dated the same way corrections are, but the log entry says what moved: a regulator caveat, a funding rail, a reference price, a platform list. A correction entry says what was wrong. Mixing the two would let a genuine error hide inside a routine refresh, so we keep the labels separate even when both happen on the same day. A reader who sees an update knows the page kept pace; a reader who sees a correction knows the page was fixed. Both are useful, and they are not the same kind of useful.

The practical test a reader can apply: an update usually has a cause outside the page, such as a change in the entity serving this country or a change in the funding methods listed. A correction usually has a cause inside the page, such as a formula that did not reproduce or a figure that contradicted the source. When a change has both an outside cause and an inside mistake, we log two entries rather than one, so the record shows the update and the correction separately and neither is absorbed by the other.

How a correction is recorded and dated on the page

A correction is recorded as a line in the page history with the date it was made, the sentence before, the sentence after, and the source that settled it. The date is the date the fix went live, not the date a reader first wrote in. If the fix takes two days to verify, the log shows the live date and the report date separately. Readers in the Philippines reading on a Monday see the same date a reader in another time zone sees, because we date in a single reference calendar and do not shift it.

The record sits with the page, not in a separate announcements feed, so anyone reading the corrected sentence can see what changed without hunting. Each entry names the field affected — margin, lot size, pip value, regulator caveat, funding method — so a reader scanning the log knows whether the change touches their use case. We do not bury a margin correction inside a general note about housekeeping. The entry is specific enough that a reader can decide in seconds whether the earlier version affected a trade they already made.

Dating a correction also means dating the version it replaced. The page history keeps the prior text visible with its own date range, so a reader can see that between two dates the page said one thing and after a date it said another. That matters for anyone who read the page, funded an account through GCash or bank transfer, and later wants to know what the page told them at the time. The date is the anchor; without it a correction is just a different sentence with no way to tell which came first.

Why the correction log is kept public rather than internal

The log stays public because a reader who acted on an earlier version is entitled to see what changed and when. Gold trading at 1 standard lot equals 100 oz and one pip equals 0.01, so a wrong pip value or a wrong margin figure on a 0.10-lot position is not cosmetic; it changes what a reader expects to set aside. A private log protects the publisher. A public log protects the reader. We keep it public because the second is the point of a corrections page.

Public logging also keeps us honest in a way an internal note cannot. When every fix is visible with a date and a source, the temptation to quietly rewrite a sentence and move on disappears, because the history shows the prior text anyway. That discipline matters more on a page about margin and leverage than on a page about background, because a reader in the Philippines may be deciding how much to fund through GCash or bank transfer based on what the page says. The log is the reader's check on us.

Keeping the log public does not mean keeping every draft public. It means the corrections and updates that touch what a reader relies on are visible, dated, and specific. We do not publish internal debate, and we do not publish a reader's private message. We publish the fact that a sentence changed, what it said before, what it says now, and the source that settled it. That is the minimum a reader needs to trust the page, and it is the standard we hold the log to.

Why no correction entry is ever deleted from the history

Nothing is deleted because a deleted correction is indistinguishable from a correction that never happened, and that ambiguity is the thing the log exists to remove. If we removed an entry, a reader comparing the page today with a copy from last month would see a gap and have no way to tell whether the page was fixed or the record was cleaned. Keeping every entry, including the ones that show us in a bad light, is what makes the rest of the log believable. The history is cumulative by design.

Deletion would also break the date chain. Each entry is dated and each prior version has a date range, so removing one entry leaves a period with no explanation for a change that clearly occurred. A reader who funded an account through GCash or bank transfer on the strength of an earlier sentence needs that period accounted for. We would rather carry a long, unflattering history than a short, tidy one with holes. The length is the cost of the honesty, and we accept it.

The one thing we will remove is a reader's personal information, and we say so in the entry when we do it. A report that includes an account number or a name is logged with the substance of the report and the personal detail stripped. That is redaction, not deletion, and the log marks it as such so the distinction is visible. Everything else stays: the wrong sentence, the right sentence, the date, and the source. A corrections page that edits its own past is not a corrections page.

Who signs off on a change and how long it takes

A change is signed off by the editor who owns the page, and no correction goes live without that sign-off. The person who reports an error does not fix it alone, and the person who writes the fix does not mark it alone. That separation is deliberate: it stops a single writer from both making and grading the same change. The sign-off is recorded with the entry, so the history shows who approved it and on what date, without turning the log into a byline exercise.

The time from report to live fix depends on what has to be verified. A wrong pip value on gold, where one pip equals 0.01, can be checked against the contract specification and fixed the same day. A regulator caveat, such as the statement that FxPro is licensed by the FCA and CySEC and not by the SEC of the Philippines, is checked against the regulator's own record before anything changes. A margin figure at the applicable cap is recomputed before it is republished. We do not put a fixed number of hours on it because the honest answer is that it depends on the source.

What we will say is that a reported error is acknowledged and either fixed or explained within a short working window, and that the log entry carries both dates so a reader can see the gap. If a fix is waiting on a source that has not answered, the entry says so rather than going silent. A reader who reported something and hears nothing back is right to be skeptical, so we treat the acknowledgement as part of the correction, not as an optional courtesy. The sign-off closes the loop; the dates show how long the loop took.