Corrections policy

How an error is fixed

An error is fixed in place, with a dated note saying what changed and when. The page keeps its address, and the correction is visible to anyone who reads it afterwards. We do not delete a wrong sentence and pretend it was never there, because a reader who relied on it deserves to see the change.

The dated note is short: what was wrong, what it now says, and the date of the fix. Where the error came from a broker document that has itself been updated, the note says so. The aim is that a reader can trace the page's history without asking us.

How a reader checks what a page said before

A reader checks a page's history by opening the correction log linked from that page and reading the dated lines from oldest to newest. Each line names the change and its mark, so a reader can see that a leverage statement was updated on a given date or that a pip value was corrected. The log is ordered by date and is not paginated in a way that hides older entries behind a click.

For a page with many entries, the log groups by year and shows the count of error, update, and clarification marks at the top, so a reader can judge the page's record at a glance before reading individual lines. The counts are derived from the same dated entries and are not maintained separately, which means they cannot drift from the lines they summarise. A page with no entries shows an explicit zero rather than an empty space.

If a reader needs the exact wording of a superseded sentence, the log entry carries it, because the log is written to stand alone without an archive of old page versions. We do not require a reader to request access or to email us for the earlier text. The check is meant to take a minute, not a support ticket, and it works the same on a phone as on a desktop.

Why no page and no log entry is ever deleted

Nothing is deleted because a deleted page or a deleted log line destroys the reader's ability to check what we said and when. If a page is superseded, it is marked as superseded and left readable, with the log showing the date and the reason. A reader who bookmarked a margin example at 1:200 can return and see that the page has moved on, rather than finding a dead link and no explanation.

Deletion also hides patterns. If the same formula is corrected twice in a year, a reader should be able to see both entries and judge whether the page is reliable. Removing the first entry would make the second look like an isolated slip. We keep both, dated, and we do not merge them into a single tidy line that conceals the repetition.

The only content removed outright is material that was never a factual claim, such as a stray formatting artefact, and even then the log notes that a non-factual edit was made. A wrong rand amount, a wrong currency code, a wrong instrument code, or a wrong regulator name is never removed; it is corrected in place and the earlier wording stays visible in the log. The record is the product, not a by-product.

How a correction is recorded and dated on the page

Every correction is recorded as a dated entry in a correction log attached to the page, showing the date the error was confirmed, the sentence as published, and the replacement sentence. The date is the day we confirmed the error against a source, not the day a reader first mentioned it. If a reader reports an error on a Monday and we confirm it on a Wednesday, the log entry carries Wednesday because that is when the page could first be corrected responsibly.

The date format is the full calendar date in the page's own text, not a relative phrase like 'last week'. A correction to a margin example using the 1:200 retail cap would read as a dated line naming the old figure and the new figure, so a reader scanning the log sees what changed without opening an earlier version. We do not backdate an entry to make a page look cleaner, and we do not merge two separate corrections into one dated line if they were confirmed on different days.

Corrections are dated in South African time and are visible on the page itself, not buried in a separate changelog that a reader has to hunt for. If a correction changes a number that also appears in a table, the table is corrected and the log entry says the table was affected. A correction that touches more than one page is logged on each page it touches, because a reader arriving at any one of them should see the same dated record.

What Counts as an Error Worth Logging on Vaal Rules

A factual mistake in the published text is what qualifies as an error worth logging on Vaal Rules. That means a number, formula, instrument specification, regulator name, or funding method that is wrong compared with the source we cited. For gold (XAU/USD), a pip stated as 0.10 instead of 0.01, or 1 lot described as 10 oz instead of 100 oz, is a logged error. A typo that changes meaning also counts. A spelling slip that leaves the meaning intact does not. The test is simple: would a reader following the page make a different trading decision because of it? If yes, it is logged.

An error is not the same as a change in market conditions or a broker's terms. If FxPro changes its leverage cap, or a regulator updates a licence detail, the old text was correct when written and is not an error. Vaal Rules logs that as an update, not a correction. The distinction matters because corrections carry an admission that the page was wrong, while updates record that the world moved. For South African readers, the FSCA licence wording is a common example: if the entity serving your account changes, the page is updated, not corrected. Only a mistake in how we described that entity at the time would be a logged error.

Errors are logged only when they affect the substance of a page, not its presentation. A broken link, a missing rand symbol, or a heading that does not match its content is fixed quietly if the fix does not alter meaning. But if a page says a 0.10-lot gold position needs about $85.50 margin at 1:200 and the figure was copied wrongly, that is logged because the number drives a margin calculation. Vaal Rules does not log style preferences, alternative phrasing, or disagreements with our editorial angle. The log exists for readers who need to know whether a stated fact was ever wrong, and that standard keeps it useful rather than noisy.

Who confirms a change, and how long it takes

The person who confirms a change is the editor responsible for that page, and the confirmation happens after the claim is checked against the source we cited or a stronger one. The editor does not confirm from memory or from a reader's assertion alone. For a claim about which FxPro entity serves South Africa, the check is against the entity disclosure, not against a forum post, and the editor records which source settled it.

The time target is measured from the moment a report is received to the moment the page carries a dated log line. We aim to confirm or reject within five working days for a clear factual claim, and we say so on the page rather than leaving the reader guessing. A claim that needs a source we cannot reach may take longer, and in that case the page carries a note that the point is under review rather than a silent delay.

No change is made to a stated fact without a named confirmer in our internal record, even though the public log shows only the date and the change. That internal name is what lets us answer a later question about why a figure moved. If the confirmer cannot be established, the change waits, because an unattributed edit to a margin example or a leverage cap is exactly the kind of drift the log exists to prevent.

When a cited source changes without notice

When a source changes silently, we treat the page as potentially wrong from the date the source changed, not from the date we noticed. If a regulator page alters its wording on leverage caps without a changelog, our page that relied on the old wording is logged as an update dated to the change we can establish, and if we cannot establish the date, the log says the date is uncertain rather than inventing one. The reader is told what we know and what we do not.

The first step is to re-check every claim on the page that depended on that source, not just the sentence that prompted the check. A silent change to an entity disclosure can affect the regulator caveat, the funding description, and the leverage statement at once, so all three are re-verified before the log line is written. We do not patch one sentence and leave its neighbours resting on a source that has moved.

If the source cannot be recovered or archived, the page stops asserting the fact and says the point is unverified pending a replacement source. We do not keep a number in place because it used to be right. A page that says a figure is unverified is more useful to a South African reader than a page that repeats a stale figure with false confidence, and the log records the removal as an update with the reason stated.

How to report one

To report an error, write to editor@vaalrulesza.com with the page address, the sentence you believe is wrong, and, if you have it, the broker document or page that shows the correct position. A report with a source is checked faster than one without.

We will look at the source, compare it with what the page says, and either fix the page with a dated note or explain why the page stands. Either way the answer goes back to the person who wrote in, and a fix is published on the page itself.

What qualifies as a logged error on Vaal Rules

A logged error is a factual statement on a page that is wrong against the source we cited when we published it. If a page said gold pip value is $1 per pip on a 0.10-lot position and the correct figure is $0.10, that is an error worth logging because it misstates the arithmetic a reader may act on. Wrong regulator names, incorrect lot sizes, and reversed formulas also qualify; style preferences and missing opinions do not.

Only concrete, checkable claims enter the log. A claim that FxPro Markets Direct Costa Rica Latam SRL serves South African clients is checkable against the entity disclosure. A sentence saying gold is 'volatile' is not checkable and is not logged. The test is whether a reader could point to a source and show the page contradicts it; if no source can settle the point, it stays out of the log and is handled as a clarification at most.

Errors in rand amounts, currency codes, and instrument codes are logged even when the underlying point survives. If a page showed a margin figure in dollars where it should have been rand, the correction records the wrong unit and the right one. We do not log a page merely because a reader disagrees with our risk framing, and we do not log a broken link as a factual error unless the broken link removed the only support for a stated fact.

Correction versus update: how the two differ in the log

A correction fixes something that was wrong when published; an update changes something that was right when published but is no longer current. If a page said the maximum retail leverage available in South Africa is up to 1:200 and that was correct at publication, a later change to that cap would be an update, not a correction. The log separates the two because a reader needs to know whether we made a mistake or whether the world moved.

Updates are dated the same way as corrections but are labelled as updates and carry the reason the underlying fact changed. A page that quoted a reference gold price of approximately 4275.0 and later refreshes that reference would log an update naming the old and new reference. We do not relabel an old update as a correction to tidy the record, and we do not relabel a correction as an update to soften it, because the distinction is the reader's main signal about our reliability.

A single edit can contain both: a correction to a formula and an update to a figure the formula uses. In that case the log carries two dated lines, one correction and one update, each naming its own change. Mixing them into one line would hide which part was our mistake and which part was a change in conditions, so we keep them apart even when they land on the same day and touch the same paragraph.

Changed conditions are not errors

A condition that has merely changed since the check is a re-check, not an error. If a broker has moved its leverage cap, added or removed a funding method, or changed the entity serving South Africa since the date on the page, the page was right when it was written.

In that case the page is re-checked against the broker's current documents and the date is updated, without a correction note, because nothing was wrong. A correction note is reserved for a statement that was inaccurate at the time it was made.

Error, update, and clarification: the three marks used in the log

Each log line carries one of three marks: error, update, or clarification. An error mark means the published statement was wrong against its cited source. An update mark means the statement was right when published and the underlying fact has since changed. A clarification mark means the statement was not wrong but could be misread, and the wording has been sharpened without changing the fact, such as spelling out that 1 standard lot of gold is 100 oz where the original left the unit implied.

The three marks are not interchangeable and are never applied by feel. A clarification cannot be used to disguise an error, and an error cannot be downgraded to a clarification because the original sentence was vague. If a reader could have acted on the wrong reading, the mark is error. If the fact itself moved, the mark is update. The mark is chosen by the person who confirmed the change and is recorded with the date, so the reasoning is inspectable later.

Only these three marks appear in the log. There is no fourth mark for 'minor' or 'housekeeping', because a fourth mark would create a place to put changes we would rather not explain. A change to a heading or a link that alters no stated fact is not logged at all; a change to a number, a currency code, a formula, or a regulator name is always logged under one of the three marks.

The correction log stays visible to every reader

The log stays public because a reader deciding whether to trust a margin example needs to see how often the page has been wrong and how quickly it was fixed. A page that hides its corrections asks readers to take its accuracy on faith, and this site is built to avoid that. The log is linked from the page and is readable without an account, a payment, or a request to support.

Public logging also disciplines the writing. When every correction is dated and visible, the person writing about the FSCA licence caveat or the 1:200 retail cap knows the sentence will be checked against the log if it changes. A private log invites quiet edits; a public one makes the quiet edit impossible, because the dated line would still show the earlier wording and the reader would see the gap.

We keep the log public even when the error was small, such as a transposed digit in a rand amount that changed nothing else. The size of the error is not the point; the point is that a reader can reconstruct what the page said on any given date. We do not publish a separate 'major corrections only' log, because a threshold would let us decide which mistakes the reader is allowed to know about.