Corrections and Re-checks

How an error is fixed

An error is fixed in place and the page carries a dated note saying what changed. We do not delete the page, quietly swap the figure and pretend the earlier version never existed, because a reader who relied on the old text deserves to see that it moved.

The note is short: what was wrong, what it now says and the date of the change. If the error affected a ranking, we say so on the page where the ranking appears rather than only in a separate log.

The difference between a correction and an update

A correction fixes something that was wrong when it was published; an update changes something that was right when it was published but is no longer current. If a page said 1 lot of XAU/USD is 100 oz and that was correct, and the contract specification later changes, the change is an update, not a correction. If the page said 10 oz when the register said 100 oz, that is a correction. The distinction matters because a correction admits a fault and an update does not, and mixing them would let a real error hide inside a routine refresh.

The two are marked differently in the log and on the page. A correction carries the label error and shows the before and after text, because the reader needs to know what was wrong and what replaced it. An update carries the label update and shows only the new text plus the source that changed, because there was no fault to disclose. A clarification carries the label clarification and shows the original sentence and the rewritten sentence, because the fact did not change but the wording allowed a misreading. A reader can filter the log by these three labels, so the record of faults stays separate from the record of refreshes.

The test for which label applies is the state of the source register at the time of first publication, not the state now. If the register held the correct fact on the day the page went live and the page disagreed with it, the fix is a correction. If the register itself changed after publication, the fix is an update, even if the old page text now looks wrong to a new reader. That rule keeps the log honest: it records what the site knew and when, rather than rewriting history to make every past statement look like it was always an update.

What counts as an error worth logging

An error worth logging is any published statement that is factually wrong, internally inconsistent, or contradicts the source it cites. That includes a wrong instrument specification, such as stating 1 lot of XAU/USD is 10 oz instead of 100 oz, or a pip value of 0.1 instead of 0.01. It also includes a regulator caveat that omits one of the named licences, a funding method that is not actually supported, or a leverage figure that is not the stated cap. A typo that does not change meaning is not logged separately; it is fixed in the next pass and noted only if it altered a number, a date, or a named entity.

A number that cannot be traced to the source list is an error even if it looks harmless. If a page states a minimum deposit, a spread, a swap, or a commission figure that was never provided, that is a fabricated fact and must be logged as an error, not softened into an update. The same applies to any claim that a cost is competitive, tight, or low without a supplied number behind it. The test is simple: every number must map to a fact in the source register, and every qualitative cost claim must be replaced with what the cost consists of and what it depends on.

An error worth logging must be specific and reproducible. A reader report that says the page feels wrong is not enough; the report needs the page, the sentence, and what the correct fact should be according to the source register. If the source register itself does not cover the point, the item is not an error yet, it is a gap, and it goes to the update queue instead. Logged errors are limited to cases where the published text and the source register disagree, or where the text contradicts itself, so the log stays a record of corrections rather than a list of preferences.

Who decides, and in what time

The decision sits with the editor who owns the page, and the approval is recorded under that editor's role rather than a personal name. The editor checks the report against the source register, assigns one of the three labels, writes the log entry, and approves the deploy. A second reviewer is required when the change touches a regulator name, a leverage cap, or a currency code, because those are the facts most likely to mislead a UAE reader if they are wrong. The reviewer's approval is part of the same dated entry, so the log shows both the decision and the check.

The time target depends on the severity of the change, not on the length of the queue. A wrong number that could affect position sizing, such as a lot size, a pip value, or the margin figure of about $85.50 at 1:500, is treated as urgent and is targeted for approval within one business day of a verified report. A wording clarification or a non-numeric update is targeted within five business days. If a target is missed, the log entry records the actual approval date, so the delay is visible rather than hidden by a promise.

The editor cannot approve a change to a fact that is not in the source register, because there would be nothing to check it against. In that case the decision is to leave the page as it is and open a register gap, which is handled as an update once the fact is supplied. That rule stops an editor from inventing a number to close a report, and it stops a well-meaning fix from becoming a new error. The decision is always traceable to a register fact, a label, an approver role, and a date.

How to report one

Report an error by writing to [email protected] with the page address and the sentence or figure you believe is wrong. If you can, include the broker document that shows the correct position, since that lets us check it against the source rather than against another website.

We read every report. We cannot promise a reply within a set number of hours or days, but we will look at the source, make the correction if it is warranted and date the note.

Why the log stays public

The log stays public because a trading reference is only useful if a reader can see what changed and when, especially when the change touches a number. A reader who sized a 0.10-lot gold position using a margin figure of about $85.50 at 1:500 needs to know if that figure was corrected, updated, or clarified, and on what date. A private log would let the site quietly revise a leverage cap or a regulator caveat, and the reader would have no way to tell whether the page they read last month still matches the page today.

Public also means the log is readable without an account and without a request. It is a plain dated list, not a support ticket system, so a reader in the UAE can check a page's history on a phone before acting on a number. The log does not expose reader identities or report contents; it records the page, the change, the label, and the approval date. That separation lets the site be transparent about its own edits while keeping the reporting channel private, which matters when a reader reports an error and does not want their name attached to the correction.

The log stays public because the alternative is an honour system. A site that says it corrects errors but keeps the record private is asking readers to trust a claim they cannot check. Publishing the log turns that claim into something verifiable: the reader can count the corrections, see how quickly they were approved, and judge whether the pages they rely on are stable. That is the point of the log. It is not marketing and it is not a blog; it is the audit trail for every number and every named entity on the site.

How a Reader Can Trace Any Figure Back Through the Page History

A reader can check the history of a page by opening the public log and matching the page name, the date and the field. The log lists every correction, update and clarification in date order, with the old value, the new value and the label. Because the log is not edited after publication, a reader can compare a figure on the live page with the earliest logged value for that field and see every change in between. For a gold (XAU/USD) figure such as the margin on a 0.10-lot position, the log shows the dated sequence rather than only the current number.

The check works without an account and without contacting anyone. A reader who wants to verify a leverage statement can search the log for the phrase used on the page and read the dated entries around it. If a source changed silently, the log shows the date the change was detected and the date the page was brought into line, which are not always the same day. The log does not show who viewed the page or when, only what changed and when it was published.

A reader who finds a figure on the page that does not match any log entry can report it using the reporting route already described on this page, and the report is treated as a possible missing entry rather than a dispute about the figure. The reviewer then checks whether the change was logged under a different field name or date. If the entry is missing, it is added with the date of detection, not backdated to the date of the original change. The history therefore shows the page as it was corrected, including any delay in logging.

What we do when a source itself changes silently

When a source changes without notice, the page is frozen at its last approved state and the change is treated as an update pending verification, not as a correction. The editor records the date the discrepancy was noticed, the page affected, and the fact that the source moved, and the page carries a visible note that the figure is under review until the new source value is confirmed. Freezing first matters because the alternative is to chase a moving source and publish a number that may move again before a reader acts on it.

Verification means checking the new source value against a second authoritative reference where one exists, and against the source register. If the new value is confirmed, the page is updated and the log entry is labelled update, with the date the source changed noted separately from the approval date. If the new value cannot be confirmed, the page stays frozen and the old value is retained with the review note, because an unverified number is worse than a stale one. A silent source change never becomes a correction, since the page was right when it was published.

The reader sees the outcome in two places: the review note on the page while the check is open, and the dated log entry once it closes. If the source changed and then changed back, the log records both movements and the page returns to its earlier value, with the entry explaining the sequence. That record is the reason the freeze exists. It lets the site say plainly that a source moved, on what date it was noticed, and what the page said before and after, without pretending the original publication was a mistake.

Three Markers Used to Separate a Correction, an Update and a Clarification

A correction is marked with a dated correction note placed directly beside the corrected line, not only in a log at the bottom of the page. The note names the field that changed, shows the old value and the new value, and carries the date the change was published. An update is marked with a dated revision note that states the new information replaced older information because circumstances moved, and it does not carry an error label. A clarification is marked with a dated note that says the original wording was accurate but ambiguous, and it shows the rewritten sentence so a reader can compare.

The marker itself is deliberately plain: a date, a one-word label, and the field or sentence affected. For gold (XAU/USD) content, a correction note would name the exact figure that was wrong, such as a lot size or pip value, and show the corrected figure. A clarification note would show the old phrasing and the new phrasing side by side. An update note would state what changed in the market or in the source, without implying the earlier text was a mistake. The label is chosen by the reviewer, not by whoever reported the issue.

Each marker stays attached to the page for as long as the page exists, and the same marker appears in the public log with the same date. A reader who sees a correction note on a leverage example can search the log for that date and find the same entry. A clarification that later turns out to be a correction is not relabelled quietly; a second marker is added with its own date, so the sequence of labels remains visible. The three labels never overlap on the same line, and a line can carry more than one marker only if it was changed more than once.

A change is not always an error

A condition that has merely changed since we checked is a re-check, not an error. If a broker has altered a leverage cap, a funding route or a document since the date we recorded, the old figure was accurate when written and the right response is to re-read the source and update the page with a new date.

We treat the two differently on purpose. An error means we got it wrong; a re-check means the world moved. Both are recorded, but only the first is labelled a correction, which keeps the record honest for readers in the UAE who are comparing brokers over time.

How a correction is recorded and dated

A correction is recorded as a dated entry in the public log before the page text is changed, not after. The entry carries the date the correction was approved, the page path, the exact sentence before and after, the fact in the source register that governs it, and the kind of change, which is one of error, update, or clarification. The date is the approval date, not the report date and not the publication date, so a reader can see how long the fix took from report to approval. If a correction is later reversed, the original entry stays and a new dated entry explains the reversal.

The date format is fixed and unambiguous: day, month, year, written out, so a UAE reader and a reader in London read the same day. Each entry has a stable identifier made of the page path and the approval date, which means two corrections on the same page on different days get different identifiers. The log is ordered by approval date, newest first, and the page itself shows the date of its last approved correction at the top. A correction that touches a number, a currency code, a leverage cap, or a regulator name is flagged in the entry so a reader scanning the log can find the material changes quickly.

Recording happens in one place and one format, so there is no second private list that can drift from the public one. The entry is written before the edit is deployed, and the deploy is blocked if the entry is missing or if the before and after text do not match the page. That order matters because it prevents a silent edit: if the log entry and the page disagree, the page is treated as wrong until the entry is reconciled. The approval date is the only date that counts for the log, and it is the date shown to readers, not the date the report arrived or the date the draft was written.