Start with a question, not an interpretation
A repeatable protocol begins before the session. Define what you are trying to observe in plain language. “I want something good to happen” cannot be evaluated. “For the next seven days I will track whether I complete my planned outreach and how focused I feel before and after each session” can.
Record a baseline
Before introducing the session, record the state you want to compare: a subjective rating, completed actions, frequency of an event or another relevant measure. Without a baseline, normal variation can easily be mistaken for an effect.
Freeze the session settings
Choose the witness, target, intention, duration, matrix mode, sound and optional visual features before starting. If a different combination is used every time, there is no stable protocol to compare.
Change one thing at a time
If you want to explore whether a sigil, sound layer or rapid intention display changes subjective focus, vary that component while keeping the others as constant as practical. This is a simple way to reduce confounding.
Define the observation window
Decide when the result will be reviewed. A goal with no time boundary can be retrofitted to almost any later event. The window can be minutes for an immediate state, days for a behaviour or longer for a project outcome—but it should be chosen in advance.
Record null results
A log that contains only impressive sessions is not a log; it is a highlight reel. Keep sessions where nothing happened, where the result went in the opposite direction and where the user forgot or failed to take the planned action.
Separate three result types
Immediate subjective result: what the user felt. Behavioural result: what the user actually did. External outcome: what later happened in the world. Keeping these separate makes interpretation much cleaner.
Why a pre-defined outcome matters
If success is defined only after a session is complete, almost any event can be reframed as confirmation. A more honest approach is to decide in advance what will count as a change. That may be a completed action, a subjective rating, the number of repetitions or another clearly defined outcome.
The measure does not have to be perfect. What matters is that it is written down before the result. This reduces the temptation to change the rules to fit what already happened.
Control days are not wasted time
If we want to know whether a protocol adds anything, it is useful to include days without an active session or with a neutral procedure. This is not the same as a laboratory control, but it can quickly show whether an apparent change is also present during normal variability.
For a personal experiment, a simple pattern may be enough: several baseline days, followed by repeated use of the same protocol and a pre-defined review period.
Protocol version is part of the result
If the algorithm, duration, sound, visual mode or wording of the intention changes, the protocol has changed too. Saving a version therefore matters. Later comparisons become much more defensible because we know whether we are comparing the same procedure or two different ones.
Review only after the window closes
When reviewing, ask whether the predefined criterion was met and what other explanations exist. Avoid changing the criterion because a different interesting event occurred. This is a lightweight form of preregistration and is far more informative than retrospective storytelling.
What repeatability can and cannot prove
A repeatable digital workflow can show that the software behaves consistently and that the user followed a stable protocol. It does not by itself prove that any external effect was caused by radionics. That stronger question requires appropriate controls and independent evidence.