Historic Calibrations

Historic Calibrations

This page tracks the outcomes of my daily calibrations: what state I was in, what support or adjustments were suggested, what advice I followed, what I adapted, what I ignored, and what actually happened afterwards.

The purpose is not to score myself or prove perfect compliance. The purpose is to build a practical evidence trail of how my nervous system, energy, pain, attention, environment, food, sleep, mobility, and executive function interact over time.

These records help identify patterns that are easy to miss day-to-day: which supports reduce friction, which plans collapse under real-world load, which early warning signs matter, and which adaptations are transferable. Over time, this becomes part of my operator’s manual.

Please pardon the layout, I'm a systems designer/analyst, not a content creator.

Methodology Update: Formalising the Feedback Loop

Project Update — Week of 17–21 June 2026

This week the Calibration Project methodology has been tightened so the daily reports are clearer about what is actually being measured.

Raw Mini Metro score is recorded for completeness, but it is not treated as the main comparator across days. Different maps, modes, leaderboard windows, sleep states, pain levels, food states and environmental conditions make direct score-to-score comparison too noisy to be useful. The more meaningful signals are:

• • Mode

  • Rank / percentile

  • Capacity classification

  • State modifier

  • Traffic Light recommendation

  • Real-world outcome

The more useful question is:

What did the calibration suggest, how was that advice used, and what happened afterwards?

From this point forward, the Pattern Notes section tracks whether the Traffic Light guidance was followed, adapted, deferred or ignored, and what the practical consequences were.

This is important because the project is not about proving consistency. It is about identifying usable patterns. A RED task that is avoided successfully is useful data. A GREEN task that is completed cleanly is useful data. A recommendation that is not followed, because another task takes the available bandwidth, is also useful data.

A small but important example happened on Sunday 21 June. The morning calibration referenced booking yoga, but I missed the yoga booking slot because I chose to use the available bandwidth to book an appointment instead. That does not mean the calibration “failed.” It shows the system making a live capacity trade-off: appointment booking took priority over yoga booking because it had higher administrative value and required the available executive function at that moment.

The methodology now also includes an evening check-in. This closes the loop between morning calibration and real-world use. The evening check-in asks:

• What did the morning calibration recommend?

• Which advice was used?

• Which advice was adapted?

• Which advice was deferred?

• What were the outcomes?

• Did the prediction for the day hold?

• What should tomorrow’s calibration check?

This turns the Calibration Project into an applied operating system review, not journaling. The evening check-in is not a feelings diary. It is a feedback loop. It tests whether the morning state assessment produced usable guidance, and whether the system responded accurately to changing conditions during the day.

This week also clarified the role of second-account runs and end-of-day rank checks. A second account is used only in specific circumstances: to test whether remembered friction from a first run affects performance on the same map and mode, or to check whether a result appears anomalous against the wider context. End-of-day rank checks are now part of the protocol where possible, because early leaderboard rank changes as more players complete the daily challenge.

The wider project also benefited from infrastructure work outside the game itself. Folder organisation in Google Drive has been reworked to reduce file-finding friction. This matters because the Calibration Project is not only measuring nervous system state; it is also identifying where external systems need better pathways. File location, naming, retrieval and “jump straight to the right folder when I think of it” are part of the same executive-function architecture.

In practical terms, this week’s update moves the project from “daily calibration reports” toward a more complete feedback system:

• • Morning calibration identifies current capacity.

  • Traffic Light guidance translates capacity into action choices.

  • Real-world use tests whether the advice was practical.

  • Evening check-in records outcomes and adjustments.

  • Pattern Notes identify what is becoming repeatable.

The project is now better aligned with its actual purpose: not measuring performance for its own sake, but building a usable operator’s manual for capacity, regulation, executive function and distributed capability over time.

Today 

(🧠If I remembered to upload it🤓)

June 22nd 2026

June 21st 2026

Data Utilization

The predictive flag from yesterday asked if sleep stabilized. Sleep was slightly truncated (~6 hours) but efficient ("fell asleep quickly"). The system correctly identified the need for sustained fuel (yogurt bowl) following the fast fuel (banana) to support the morning's activities. The decision to batch cook the sausages demonstrates excellent utilization of past sensory data to improve future outcomes.

State Tracking

The system has successfully transitioned out of the Reduced Capacity state from yesterday morning, executing the recovery arc effectively. It is currently resting at a stable Baseline. The physical state is notably positive ("aligned for planting"), which is a strong indicator of recovery.

Emerging Patterns

Confirmed pattern: The system continues to use batch cooking not just for general meal prep, but as a specific tool for error recovery and sensory management (e.g., transforming sub-optimal ingredients into acceptable meals).

Predictive Flags

Based on the current state, the system is capable of executing the physical tasks (planting) but may experience cognitive fatigue later in the day due to the 6-hour sleep. Flag for tomorrow: Did the physical exertion of planting impact sleep architecture or somatic pain levels? Did the system attempt the Power Automate learning, and if so, did it cause friction?

June 20th 2026

Data Utilization: Yesterday's Traffic Light flagged fuel signals as a RED risk. The real-world outcome was a caloric deficit that triggered the 3:30am wake-up. The flag was accurate; the execution window was missed. Today's structured fuelling sequence was a direct corrective response. The deficit was closed by end of day.

State Tracking: The trajectory this week: Overclocked arc (Tue–Wed) → stabilisation (Thu–Fri) → over-extension (Fri) → recovery (Sat). The recovery arc executed correctly today. The system did not compound the deficit. The end-of-day wind-down protocol (anime, teeth, PJs by 9pm, audible) is appropriate and correctly timed.

Emerging Patterns: Confirmed pattern: When the system is over-extended, fatigue lowers the emotional dysregulation threshold, and the resulting vulnerability manifests as nighttime rumination on the highest-friction unresolved administrative tasks. The brain attempts to process open loops when it lacks the bandwidth to solve them.

Confirmed pattern: Music is a rapid-deployment, high-efficacy regulation tool for this system when transitioning from overwhelm back to baseline.

Confirmed pattern: Environmental design solutions (visually distinctive decaf tin, calendar reminder set at point of purchase, steak portion saved before serving, body doubling for task initiation) are consistently deployed when the system is operating at reduced capacity. These are not compensatory hacks — they are the system working correctly.

June 19th 2026

June 18th 2026

June 17th 2026

Pattern Notes — Updated Methodology (from 17 June 2026)

The Pattern Notes section tracks how the data is being used across days, not how scores compare across days. Direct numerical comparison between sessions is not meaningful: different maps, different modes, and different nervous system states make score-to-score comparison redundant and potentially misleading.

The week-view table records the classification and state for each day. The written analysis beneath it focuses on the following questions:

Data Utilization: What did the Traffic Light guide recommend yesterday? Was it followed? What was the real-world impact of following or not following it? If a task was flagged RED and was avoided, note the outcome. If it was flagged GREEN and was executed, note the outcome. If the advice was ignored, note what happened instead.

State Tracking: What state has the system been in across the past several days? Consecutive Overclocked days, consecutive Reduced Capacity days, or a recovery arc are all meaningful patterns. The state matters more than the score.

Emerging Patterns: Recurring interactions between context factors (sleep, salt, food, events) and performance. These are confirmed patterns only — not hypotheses unless explicitly labelled as such.

Predictive Flags: Based on the current state trajectory, what is the likely state tomorrow or in the next two days? Predictions are treated as testable flags, not conclusions. Flag this for the next session to verify.

June 16th 2026

June 15th 2026

June 14 2026

June 13th 2026

2nd Calibration later in the day

June 12th 2026

June 11th 2026

June 10th 2026

June 9th 2026

June 8th 2026