Give the original and amended plans distinct identities
A plan is a set of conditions, not evidence that a trade happened. Save an original version with its source, capture time and stated period of use. Add an amended version as a second record linked to the first. Retain the original wording so a reviewer can compare the actual change.
Do not rename the old version after an amendment and then use the revised text to explain an earlier result. That would conceal which conditions were available at the decision time. An author’s stated effective time and your later observation of the amendment are separate facts.
Compare one decision field at a time
Useful columns include instrument, trigger condition, invalidation condition, expiry and the evidence required before the plan can be considered triggered. Mark a field as unchanged, revised, newly supplied or no longer stated. A blank amendment field should not automatically erase a condition unless the source explicitly says so.
| Fictional field | Version A | Version B |
|---|---|---|
| Trigger | Condition X | Condition Y |
| Invalidation | Condition Z | Unchanged Z |
| Effective instant | Not stated | Stated instant T |
Do not assign an amendment to an interval you cannot prove
Imagine version A was captured at 08:00 and version B at 08:30, but the amendment has no supported effective timestamp. The captures bound your observations; they do not identify the exact transition. An event at 08:15 cannot confidently be assigned version B merely because B was the next version you saved.
A complete date and offset matter for UK-local displays and UTC sources. Keep the source timestamp intact. If a supplied time is only a clock label, preserve the missing date or zone as an unresolved input rather than guessing it from your current location.
Keep the plan, a notification and an execution in separate rows
A changed trigger can explain why a hypothetical scenario differs under two versions. It cannot establish which version a person followed, whether an order was accepted or what price was filled. Those questions require their own evidence and identifiers.
Avoid adding a filled quantity or realised result to a plan row simply because a notification says the condition was met. Record it as a claim until the corresponding execution record is supplied. An HTTP success code also has a narrower meaning than an authenticated trade outcome.
Make the final comparison reproducible
Export the two source versions, the field-by-field differences, each known timestamp and the unresolved questions. A reviewer should be able to reproduce the comparison without relying on your summary sentence. If the original was never captured, say that the baseline is missing.
This journal is useful for understanding communication and process changes. It does not rank plan quality, calculate a verified return or recommend adopting either scenario. The example conditions are fictional and deliberately contain no live trading instruction.
The optional link below leads to this site's separate crypto signals and Telegram updates offer. The record method is usable without that offer. It does not independently verify the offer, establish country eligibility or turn the teaching example into an actual transaction.
Primary sources and scope
- RFC 3339: Internet timestamps
Full dates and explicit numeric offsets; a timestamp representation does not prove clock synchronisation. Checked 2026-10-21. - RFC 9110: HTTP Semantics, 202 Accepted
Accepted-for-processing does not establish completed processing. Checked 2026-10-21.