Corrections and how we handle them

Errors are fixed in place, with a date

An error is corrected in the same place it appeared, and a dated note is added so a reader can see what changed. We do not quietly rewrite a sentence and leave the page looking as if it was always right. The date on the note is the date of the correction, not the date the page was first published.

This matters most on figures. If a cost description or a margin example was based on a document we misread, the correction says so and points to the document that settles it. A correction is not a rewrite of the whole page; it is a record that a specific statement was wrong and has been changed.

How a correction is recorded and dated in the public log

A correction is recorded as a new entry in the public log on the day the corrected text goes live, with the date of publication and the date of the fix shown side by side. The entry names the page, the section, the incorrect statement, the corrected statement, and the source used to verify the change. No entry is backdated to the original publication date, because the log is a record of when readers were told, not when the mistake was made. If the fix takes three days to verify, the log shows the fix date, not the date the error was first suspected.

The date format is day, month, year in plain English, for example 14 March 2025, so there is no ambiguity between UAE and international readers. Each entry carries a stable identifier made from the page slug and a sequence number, so a reader can cite it without linking to a moving page. The log itself is a single page listed in reverse chronological order, newest first, and each entry links to the current version of the corrected section. The original wording is kept in the entry, not in the live page, so the live page always shows the corrected text while the log preserves what was wrong.

Dating a correction also means noting the time zone used. All log dates are UAE time (GST, UTC+4), because the site is written for readers in the UAE and a date without a time zone can shift by a day for someone reading from London or New York. When a correction is made to a figure that depends on a live market input, such as the reference price of 4275.0 used in a worked example, the entry states the date and time the input was captured. This prevents a later reader from assuming the example used a price from a different session.

Why the correction log stays public and permanently visible

The log stays public because a reader deciding whether to trust a page about gold trading needs to see how the page has behaved over time, not just how it reads today. A page that has never been corrected is not necessarily better than one with a short, dated log; the log shows the site checks its own work. Keeping it public also removes the incentive to quietly fix errors, because a silent fix is indistinguishable from a page that was right all along. The log makes the difference visible and gives readers a way to judge the site's reliability for themselves.

Public logging also serves UAE readers who may be comparing information across several sources. If a page states that one pip on gold is 0.01 and a reader has seen a different figure elsewhere, the log entry can show which statement was corrected and on what date, with the source used. That is more useful than a private assurance that the site is accurate. The log is linked from every page it affects, so a reader does not have to hunt for it. It is not buried in a footer or hidden behind a login, because a log that is hard to find is effectively private.

The log stays public even when a correction is small, such as a typo in a currency code or a misstated date. The reason is consistency: if small corrections were private, readers would have to guess which fixes were considered too minor to disclose, and the log would become a curated selection rather than a record. Every entry is dated and permanent, and no entry is removed when a later correction supersedes it. A reader can therefore trace a statement through several changes and see the full sequence rather than only the latest version.

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

If a broker changes its terms, a funding route, or a cost after the date we read it, the old page was not wrong when it was written. That is a re-check, and we handle it by updating the figure and its date, not by logging an error. The distinction keeps the corrections record honest: it lists mistakes, not the passage of time.

This is also why every figure on the site carries the date it was read. A reader who needs the current position should confirm it with the broker, because the broker's documents are the live source and our page is a dated snapshot. When the snapshot is stale, tell us and we will re-check it.

The three kinds of change, error, update, and clarification, and how each is marked

Every change to a published page is marked as one of three types: error, update, or clarification. An error means the published text was factually wrong, such as stating a contract size other than 100 oz per standard lot for gold. An update means the text was correct when published but the underlying fact has changed, such as a new platform being added to the broker's lineup. A clarification means the text was not wrong but could be misread, so a qualifier or example is added without changing the factual claim. Each type has its own label in the log and its own note explaining the change.

The marking is visible in two places: in the log entry and, where practical, in a short note at the foot of the corrected section. An error entry reads corrected, an update entry reads updated, and a clarification entry reads clarified, each followed by the date. The note at the section level is kept short so it does not interrupt the answer-first flow of the page. A reader who wants the full original wording follows the link to the log entry. This two-level marking means a reader scanning the page sees that something changed, while a reader who wants detail can find it without leaving the site.

The three labels are not interchangeable, and the choice is made before the fix is published, not after. If a writer is unsure whether a statement was wrong or merely ambiguous, the default is clarification, because calling something an error when it was only unclear overstates the fault. If a source later confirms the statement was wrong, a second entry can reclassify it as an error with its own date; the original clarification entry stays in the log. This prevents retroactive relabeling and keeps the sequence of decisions visible to any reader who checks the history.

Correction versus update: how the two differ on this site

A correction fixes something that was wrong when it was published; an update changes something that was right when published but is no longer current. If a page said one pip equals 0.01 for XAU/USD and that was correct at the time, changing it later would be an update only if the instrument specification itself changed, which it has not. If the page said the margin for a 0.10-lot gold position at 1:500 was $85.50 and the arithmetic was wrong, fixing it is a correction. The distinction matters because corrections admit a mistake while updates simply keep the page current, and the log marks them differently.

An update is used when a fact changes at the source, such as a regulator altering its licensing disclosure or a broker changing the platforms it offers. If FxPro adds or removes a platform from MT4, MT5, cTrader, and FxPro Edge, the page is updated and the log entry says so without implying the earlier text was false. An update also covers a change in the maximum leverage available in the UAE, which is up to 1:500 on standard forex accounts within DFSA/SCA-compliant limits and varies by instrument. The earlier statement was accurate for its date; the update records that the condition moved.

Readers can tell the two apart by the label on the log entry. A correction entry includes the words corrected from followed by the original wording, while an update entry includes the words updated to reflect a change at the source and names the source. A correction always carries a note on what was wrong, even if the fix is a single character. An update does not need to explain an error because none is alleged. Both carry dates, both link to the live section, and both remain in the log permanently so the history is visible.

What qualifies as an error worth logging on a gold trading page

An error worth logging is any published statement that misstates a verifiable fact about gold trading, such as the pip value for XAU/USD, the contract size of 100 oz per standard lot, or the margin requirement at the maximum leverage available in the UAE. If the text says one pip equals 0.01 but the correct value is different, that is an error. If it quotes a price of 4275.0 when the reference price was 4270.0 at the time of writing, that is an error. The test is simple: can the statement be checked against a named source and found wrong? If yes, it belongs in the log.

Errors are not matters of opinion, style, or market interpretation. A sentence that says gold is volatile is not an error even if another writer would phrase it differently. A sentence that says the margin for a 0.10-lot gold position at 1:500 is about $85.50 is an error if the arithmetic or the stated leverage is wrong, because the figure can be recalculated from the given inputs. The log only records statements that fail a factual check, not statements a reader disagrees with or finds incomplete. This keeps the log short and useful rather than a running commentary on every edit.

An error can also be a missing qualifier that changes the meaning, such as stating a leverage cap of 1:500 without noting that it applies to standard forex accounts within DFSA/SCA-compliant limits and varies by instrument. If the omission makes a reader believe the cap applies to every gold position without condition, that is loggable. The same applies to a regulator caveat that is shortened until it misleads about which entity serves UAE clients. In each case the question is whether a reasonable reader would be misinformed by the text as published. If so, the correction is logged with the date the fix goes live.

How to report a correction

Write to editor@hattacopyae.com with the page address and the sentence you believe is wrong. If you can, say what the correct position is and where it is stated, such as the broker's own document or the regulator's public register. That lets us check the point rather than debate it.

We look at every report against the source. If the page is wrong, it is fixed in place with a dated note. If the page is right and the report is mistaken, we will say so and explain the basis, because a correction that is not owed would make the record less accurate, not more.

Who decides a change is needed, and the time frame for acting

The decision to log a change is made by the person who verifies the page against its sources, not by the original writer alone, so that a second set of eyes confirms the statement is actually wrong or outdated. That verifier checks the specific claim, such as the pip value of 0.01 for XAU/USD or the margin figure of about $85.50 for a 0.10-lot position at 1:500, against the named source and records the result. If the claim cannot be verified, it is treated as unconfirmed and either corrected to a qualified statement or removed, with the log noting which. No change is published without that verification step.

The time frame depends on the severity of the claim. A statement that could mislead a reader about margin, leverage, or the regulator caveat is checked and, if wrong, corrected within one business day of being confirmed. A statement about a platform name or a funding method is corrected within five business days. These are internal targets, not promises to readers, and they are measured from the moment the verifier confirms the problem, not from when a reader first reports it. The log entry shows the date the fix went live, so a reader can see how long the gap was.

If a reader reports a possible error, the report is acknowledged and the same verification process applies; a report does not by itself trigger a correction. The verifier may find the page was right and the reader misread it, in which case a clarification may be added and the log will say so. If the report is correct, the fix follows the same time frame as an internally found error. The person who decides is named by role in the log, not by personal name, so the record shows accountability without turning the log into a directory of individuals.