Corrections Policy

Fixed in place, with a date

An error is corrected in place and marked with a dated note, rather than quietly deleted. The note says what was wrong and what it now says, so anyone who read the earlier version can see the change. We do not rewrite history by removing the trace of it.

This matters most with numbers. If a figure taken from a broker document was misread, the correction shows the old figure, the new figure and the date of the fix, so the arithmetic on the page can be followed from start to finish.

What counts as an error worth logging on this page

An error worth logging is any statement on this page that contradicts the facts we are allowed to state, or that presents a number as fixed when it depends on a condition we did not name. For example, if a paragraph said a gold position needs a specific margin figure without tying it to the applicable leverage cap, that is an error because the margin depends on the cap that applies to the FxPro entity serving Kenya. Likewise, naming a funding method not on our list, such as a bank transfer, would be an error. The test is simple: does the sentence misstate a given fact or invent one? If yes, it belongs in the log.

Errors also include omissions that change the meaning of a sentence. If we wrote that FxPro is regulated by the CMA of Kenya, that is wrong because the correct caveat is that FxPro is licensed by the FCA (UK), CySEC and FSCA — not by the CMA of Kenya. Leaving out the 'not by the CMA' part would mislead a Kenyan reader about local recourse. Similarly, if we described a pip as 0.01 for gold but failed to note that one standard lot is 100 oz, the reader cannot compute risk correctly. An omission that removes a necessary qualifier counts as an error, not a style choice.

A typo that changes a number or a currency code is always an error worth logging. Writing KSh instead of USD for the margin example, or stating a leverage ratio other than the cap that applies, would be a factual error even if it looks like a slip. We do not log pure formatting issues, such as a missing space after a comma, because they do not alter meaning. The distinction is whether a reasonable reader could act on the wrong information. If the answer is yes, the item goes into the log with a date and a description of what was wrong.

The difference between a correction and an update

A correction fixes something that was wrong at the time it was published; an update adds or refreshes information because the underlying facts have changed since publication. If we originally stated that the maximum leverage available in Kenya is the cap that applies to the entity serving this country, and later that cap changed, the change to the page is an update, not a correction. The original statement was accurate when written. A correction, by contrast, means the original statement was inaccurate even under the facts available then, such as naming the wrong regulator or misstating the pip value for gold as 0.1 instead of 0.01.

The distinction matters because it affects how the log entry is worded and how a reader interprets the history. A correction entry says 'this was wrong and is now fixed', while an update entry says 'this was correct then and has changed now'. For example, if a new funding method were added to our list, that would be an update because the previous list was not erroneous. But if we had omitted M-Pesa from the list when it was already a known funding route, that would be a correction. The log uses different labels so a reader can tell whether the page was ever inaccurate or simply out of date.

Updates are dated the same way as corrections, but they also carry a note about what changed in the world. If the margin example for a 0.10-lot gold position needed revision because the applicable leverage cap moved, the update entry would state the old figure, the new figure, and the date the cap change took effect if that date is known. We do not present an update as a correction, because doing so would wrongly suggest we had published a false statement. Keeping the two separate preserves trust in the log: a correction is an admission, an update is maintenance.

The three change types and the marks that distinguish them

Every change to this page is classified as one of three types: error, update, or clarification. An error means the previous text was factually wrong, such as stating a leverage ratio other than the cap that applies to the FxPro entity serving Kenya. An update means the facts themselves changed, such as a new funding method being added to the list that already includes M-Pesa. A clarification means the previous text was accurate but ambiguous, and we have reworded it to remove doubt. For example, if a sentence about the pip value for gold could be read as applying to a different instrument, rewording it is a clarification, not an error fix.

Each type is marked in the log with a distinct label and a short reason. The label appears at the start of the entry: 'Error', 'Update', or 'Clarification'. The reason explains what triggered the change in one sentence. For an error, the reason names the wrong fact and the correct one. For an update, it names the source that changed. For a clarification, it quotes the ambiguous phrase and the new wording. The page itself does not carry these labels inline; only the log does, so the reading experience stays clean. But the log entry is always linked from the page's correction notice, so a reader can see the type without hunting.

The marking also determines how the page's 'last corrected' date behaves. An error or update changes that date; a clarification does not, because the meaning was already correct. This distinction prevents the date from becoming meaningless through constant minor rewording. If you see a recent date, it means a factual change occurred, not just a tidy-up. The log entry for a clarification still carries its own date, so the history is complete, but the page-level date reflects only substantive changes. That way a reader scanning for freshness can trust that the date signals a real change in content, not cosmetic editing.

How to report one

Write to editor@kakamegagoldke.com with the page, the sentence and, if you have it, the broker document you are comparing against. The most useful reports quote the text as it appears and say what it should say instead. We do not promise a response time, but every report is read.

A report that comes with the source is far easier to act on than one that does not. If the point depends on a document, send the document name and the date you read it, and we will compare it with the copy we hold.

Why the correction log stays public and permanent

The log stays public because a reader in Kenya deciding whether to trust this page needs to see not only what it says now but also what it got wrong before. Hiding corrections would make the page look infallible, which is unrealistic for any reference that deals with changing facts like leverage caps and regulatory status. A public log lets you check whether a past error affected a decision you made, such as calculating margin for a gold position. It also holds us to a standard: if we know every fix will be visible, we are more careful about what we publish in the first place.

Permanence is part of the design. Once an entry is in the log, it is not removed even if the corrected text later becomes irrelevant. For instance, if a correction was made to the regulator caveat about FxPro not being licensed by the CMA of Kenya, that entry stays even after the caveat is stable. Deleting old entries would allow the page to quietly rewrite its own history, which defeats the purpose of a log. The log is append-only: new entries go on top, old ones remain below. That way the record is complete and a reader can trace every change back to the beginning.

Public also means accessible without a login or a request. The log is linked from the page itself, not buried in a separate portal. A reader can open it, search for a date, and see the exact wording that changed. We do not require an email address or any personal detail to view it. This matters because the page deals with trading costs and risk, and a Kenyan reader may want to verify a claim about margin or leverage before funding an account via M-Pesa. The log is there to be checked, not to be taken on faith.

A changed condition is a re-check

A condition that has merely changed since we checked is a re-check, not an error. If a broker alters its terms, its platform list or the leverage cap for the entity serving Kenya, the page was accurate when written and now needs re-reading. We treat that as maintenance rather than a correction.

The distinction protects the record. Calling a change an error would blur what we got wrong with what the broker changed, and a reader deserves to know which is which. When we re-check, we update the date we read the documents.

How a correction is recorded and dated

A correction is recorded as a dated entry in a public log that sits alongside the page, not buried in a comment thread. Each entry states the date the correction was made, the exact sentence or figure that was wrong, what it was changed to, and a reference to the fact or rule that the original text violated. The date is the day the corrected version goes live, not the day someone first noticed the problem. That way a reader can see when the page last changed and verify that the fix is live. The log entry remains visible even after the page is updated, so the history is not lost.

Dating a correction requires a fixed reference point, and we use the publication date of the corrected page version. If a correction is made on a Tuesday, the log entry carries that Tuesday's date and the page itself shows a 'last corrected' date that matches. We do not backdate corrections to the original publication date, because that would hide the period during which the error was live. Nor do we use vague labels like 'recently'. The date is a specific calendar day, and it is the same in the log and on the page, so a reader can cross-check without ambiguity.

The record also notes whether the correction was prompted by a reader report, an internal review, or a change in an underlying source. That note does not name individuals, but it tells the reader why the correction happened. For example, if the margin example for a 0.10-lot gold position at the applicable cap needed adjustment because the cap itself changed, the log would say 'source change' rather than 'reader report'. The date and the reason together form the minimum record. Nothing is considered corrected until that entry exists and the page reflects the new text.

Who decides on a correction and within what time frame

The decision to correct rests with the editorial lead for this page, who is the only person authorised to mark an entry as an error, update, or clarification. That person checks the proposed change against the fixed facts we are allowed to state, such as the instrument details for gold (XAU/USD, 1 lot = 100 oz, pip = 0.01) and the regulator caveat for Kenya. No change goes live without that sign-off. The time frame is within two working days of a report being verified. Verification means confirming that the original text was indeed wrong or outdated, not simply that someone disagrees with it.

Two working days is the maximum for a decision, not for the fix itself. Once the decision is made, the corrected text and the log entry are published together, normally on the same day. If the correction depends on a source we cannot verify quickly, such as a regulatory notice, the decision may take longer, but the log will show the entry as 'pending verification' with the date it was opened. That pending status is itself public, so a reader is not left wondering whether a report was received. The clock starts when the report is logged, not when it is first mentioned in an email or a call.

The time frame applies to all three change types. A clarification may be decided faster because it does not require checking a fact against an external source, but it still gets a dated entry. An update may take longer if the underlying change is not yet confirmed by the source we rely on. In every case, the log shows the date the decision was made and the date the change went live, which may be the same day. A reader can therefore see not only what changed but how quickly we acted. That transparency is the point of naming a time frame at all.