Talk:Calibration Failure Log
Page Transparency & Calibration
- Calibration Log & Decision Records (via Talk Page) — This page uses Talk-only calibration tracking. Full history of reviews, version changes, calibration decisions, and any governance reasoning behind structural decisions all live on the same Talk page, per Calibration Log: When to Create One and Decision Records: Governance Memory. Not every Calibration Log entry is a Decision Record — scan the Talk page's headings for entries specifically marked as decisions; the link itself being active only confirms this page has calibration history, not that a formal decision was ever recorded.
- View Current Page History — Complete edit history.
This page is under continuous calibration in line with the Permanent Beta principle.
Public Discussion Welcome
Questions, suggestions, feedback, disagreement, and proposed improvements are welcome on the Talk page.
Light rules:
- Prefer evidence and concrete examples over slogans.
- Apply Diagnostic Inversion Test when criticizing — the same standard to this page that you would apply elsewhere.
- Distinguish observation from conclusion.
- Calibration entries and Decision Records are maintenance records; public discussion belongs in ordinary Talk threads.
- This framework remains in Permanent Beta. Better calibration is always in scope.
Calibration Report — Calibration Failure Log — 2026-07-14
- Page: Calibration Failure Log
- Summary: A record of project-wide calibration failures — cases where a mechanism worked exactly as designed, but the design itself produced false or misleading calibration data. Distinct from Known Site Issues & Fixes, which covers technical/mechanism bugs.
- Reviewer: Sovereign, with Grok
- Review Type: Self-Assessment
Summary of Changes
- New page created. Establishes a formal, distinct category from Known Site Issues & Fixes: a mechanism can be technically correct, doing exactly what it was coded to do, and still be a calibration failure if the design itself produces false data. Neither "working" nor "broken" quite describes this category — "working as designed, wrongly designed" does.
- First entry logged: the `review_date`/`Last Updated` live-template date bug, co-identified by the project owner and Grok. Full nonconformance details (what/how found/severity/proposed resolution) recorded per the Nonconformance Reporting Procedure format.
- This page's own `review_date` field is deliberately set as a real, static value (`2026-07-14`), not the live template call being reported as broken — the page practices the standard it's documenting.
Reasoning / Rationale
The initial nonconformance finding was drafted without a clear home — it didn't fit Known Site Issues & Fixes' stated scope (technical bugs), and pointed at a "Breadcrumb Index" destination that doesn't exist. Rather than force the finding into an ill-fitting mechanism, or leave it homeless, a proper distinct log was built. The project owner correctly identified that a future Admin Control Panel will surface this kind of finding too, but only in aggregate/vague form (a status flag in a query) — this page is where the actual narrative, reasoning, and resolution trail lives in full, solid detail. The two are complementary, not competing: the control panel is for noticing something needs attention; this page is for understanding what it actually is.
Confidence / Certainty Level
High — the underlying bug (live-template date fields defeating cycle math) is confirmed and well-understood; the page's role and scope are clear and non-overlapping with existing mechanisms.
instrument_grade: Experimental (unchanged)
calibration_rationale: New page, first entry logged, not yet round-robin reviewed. The category distinction itself (calibration failure vs. technical bug) is sound reasoning but has only been tested against one real case so far. review_confidence: Moderate
What This Report Does NOT Claim
This report does not claim the underlying `review_date`/`Last Updated` bug has been fixed — it has not; resolution steps are logged but not yet executed. It does not claim this is the only calibration failure of this kind in the project; a sweep for similar issues has not yet been done.
Fields Changed
New page created. `drift_report_status = Nonconformance-Open-With-Dependencies` on this page, reflecting the first entry's project-wide scope.
Open Items
- The first entry's resolution steps (seed template fixes, checklist addition, `Last Calibration` rename, existing-page sweep) remain fully outstanding.
- Whether other fields in the project share this same live-template date pattern has not been checked.
- Relationship between this page's role and the future Admin Control Panel's aggregate view should be stated more formally once the control panel itself is built — noted here as a design intention, not yet documented as a standing rule anywhere else.
See the Game. Refuse the Game. Build Better.
Sovereign (talk) 03:04, 19 July 2026 (EDT)
Second Confirmed Instance: GameModule's "Last Updated" Field
What was claimed/built vs. what was actually true: `GameModule`'s public-facing `Last Updated` field has been using the same live `2026-07-29` pattern. Unlike `review_date`, this doesn't break a downstream calculation (nothing currently computes against it) — but it produces a different, arguably worse problem: a public reader sees "Last Updated: [today]" on every page view, permanently, whether or not the page was actually touched. This is publicly-visible misinformation, not just an internal tracking gap.
Rename required, not just a static-value fix: the field should be renamed from `Last Updated` to `Last Calibration`, resolving the ambiguity between "last time content was edited" and "last time a real calibration event occurred" rather than leaving that conflation in place under a corrected but still-ambiguous label.
Open design question, not yet resolved: should the renamed `Last Calibration` field on GameModule and `review_date` on Admin Page Status be the same underlying value (one fact, displayed publicly and internally), or genuinely separate facts (e.g., "last time any report was filed" vs. "last time a formal review cycle completed")? Not decided in this report — flagged for resolution before the fix is implemented.
Severity: Same wide-reaching scope as the primary finding — this field exists on every GameModule infobox project-wide. Sovereign (talk) 03:06, 19 July 2026 (EDT)
`Last Updated` and `review_date` Treated as Independent Fields, Causing Confusion — 2026-07-14
Status: Resolved (clarified and formalized)
What was claimed/built vs. what was actually true: No formal rule stated whether GameModule's `Last Updated` and Admin Page Status's `review_date` were meant to represent the same fact or two different ones. This ambiguity caused real confusion during a checklist revision — uncertainty about whether GameModule's field tracked "actual calibration cycle" or something else, and whether keeping both fields was redundant.
Resolution: Formalized as one real event viewed from two angles, not two independent facts. `review_date` is the computational input `Module:CalibrationCycle` and search/query features rely on — it's what certifies a page's calibration currency. `Last Updated` is the same date, displayed publicly in plain language. Both must update together, in the same edit, only when a genuine calibration occurs — never during pre-calibration checks or minor edits. Documented as a formal rule and checklist row on Page Structure Calibration Checklist.
How it was found: Direct question from the project owner while reviewing the checklist, following earlier discussion about the live-template date bug making date-field precision a live concern.
Severity: Moderate — not a technical failure like the live-template bug, but a genuine documentation gap that could have led to the two fields drifting apart with no rule to catch it.
Found by: Sovereign, 2026-07-14.
Next steps: Sweep existing pages to confirm `Last Updated` and `review_date` actually match where both are populated — not yet done. Sovereign (talk) 07:30, 19 July 2026 (EDT)
Display Rename Accidentally Changed the Underlying Stored Property (Has calibration type → Has functional layer) — 2026-07-14
Status: Resolved
Reviewer: Sovereign
What was claimed/built vs. what was actually true: `Has calibration type` was the original, long-standing stored SMW/Cargo property on `Template:GameModule`, used by 150+ pages. At some point, a change intended purely to rename the displayed label from "Calibration Type" to "Functional Layer" also, unintentionally, changed the actual underlying `#set` property to `Has functional layer` — a real property-storage change, not just a cosmetic one. Only a small number of pages built or saved after that change ended up storing under the new property name; the large majority continued storing under the original.
Consequence: A silent split existed — most pages storing calibration-type data under `Has calibration type`, a handful under `Has functional layer`, with no visible difference in how the page rendered, since the display label was consistent either way. Any query filtering specifically on one property name would silently miss pages using the other.
How it was found: Direct manual review by the project owner while working on the `Last Updated` → `Last Calibration` display rename, applying the same scrutiny to a neighboring field and catching that the earlier rename had gone further than intended.
Resolution: `Template:GameModule`'s `#set` call reverted to store under the original `Has calibration type` property, while keeping the displayed label as "Functional Layer" — confirming clearly that a display label and its underlying stored property name are two separate things, and one can be changed without the other. This same principle was applied correctly and deliberately for the simultaneous `Last Updated` → `Last Calibration` display change, which did not alter the underlying `Has module last updated` property.
Remaining gap, accepted rather than force-fixed: the small number of pages saved while the template stored under `Has functional layer` will retain that stored value until each page is next opened and re-saved, triggering a fresh `#set` under the reverted template. Per the project owner's standing rule against manual batch-retrofitting, this is left to resolve naturally through normal editing and Recent Changes, not a forced sweep.
Found by: Sovereign, 2026-07-14.
Next steps: None required — self-resolving. Worth keeping in mind if a future query built against `Has calibration type` returns fewer results than expected; check whether the missing pages are among the small affected set. Sovereign (talk) 12:09, 19 July 2026 (EDT)
Live-Template Date Fields Defeat Calibration Cycle Tracking — 2026-07-14
Status: Open — resolution not yet made
Reviewer: Sovereign, with Grok
What was claimed/built vs. what was actually true: Two fields — `review_date` (Admin Page Status) and `Last Updated` (GameModule) — were implemented using `2026-07-29`, a live template call that recalculates to today's actual date on every page render, rather than freezing at the moment a real event occurred. Both fields worked exactly as coded — the code itself was the wrong design.
Consequence 1 — `review_date`: Module:CalibrationCycle computes `Has_cycle_status` (Current / Due Soon / Overdue) from the gap between `review_date` and today. Since `review_date` always equals today, that gap is permanently zero — every affected page silently reports as perpetually "Current," regardless of actual staleness. This defeats the entire purpose of cycle tracking.
Consequence 2 — `Last Updated` (GameModule): No downstream calculation breaks, but the field is publicly visible and permanently, falsely claims "Last Updated: [today]" on every page view, regardless of whether anything was actually edited. This is public-facing misinformation, not just an internal tracking gap.
Proposed rename: `Last Updated` should become `Last Calibration`, resolving the underlying ambiguity between "last content edit" and "last calibration event" rather than leaving that conflation in place under a corrected but still-ambiguous label.
Open design question, not yet resolved: should the renamed `Last Calibration` (GameModule, public) and `review_date` (Admin Page Status, internal) be the same underlying value, or genuinely separate facts? Not decided.
How it was found: Direct discussion between the project owner and Grok, identified as self-defeating to the entire purpose of maintaining calibration cycles.
Severity: Wide-reaching — originated in Template:New Page Seed and Template:Calibration Maintenance Log, copy-pasted onto nearly every page built during this session. `drift_report_status = Nonconformance-Open-With-Dependencies` — affects essentially the entire current dependency graph, not a contained issue.
Resolution (not yet made):
- Fix both seed templates — replace live template calls with blank fields requiring real, manually-entered static dates.
- Add a check item to Page Structure Calibration Checklist confirming date fields are static, not live-calculated.
- Resolve the same-value-vs-separate-fields question for `Last Calibration` and `review_date`.
- Sweep existing pages to identify and correct which currently carry the live-template version.
- Confirm no other fields in the project use this same live-template date pattern.
Sovereign (talk) 12:12, 19 July 2026 (EDT)
Display Rename Accidentally Changed the Underlying Stored Property (Has calibration type → Has functional layer) — 2026-07-14
Status: Resolved
Reviewer: Sovereign
What was claimed/built vs. what was actually true: `Has calibration type` was the original, long-standing stored SMW/Cargo property on `Template:GameModule`, used by 150+ pages. At some point, a change intended purely to rename the displayed label from "Calibration Type" to "Functional Layer" also, unintentionally, changed the actual underlying `#set` property to `Has functional layer` — a real property-storage change, not just a cosmetic one. Only a small number of pages built or saved after that change ended up storing under the new property name; the large majority continued storing under the original.
Consequence: A silent split existed — most pages storing calibration-type data under `Has calibration type`, a handful under `Has functional layer`, with no visible difference in how the page rendered, since the display label was consistent either way. Any query filtering specifically on one property name would silently miss pages using the other.
How it was found: Direct manual review by the project owner while working on the `Last Updated` → `Last Calibration` display rename, applying the same scrutiny to a neighboring field and catching that the earlier rename had gone further than intended.
Resolution: `Template:GameModule`'s `#set` call reverted to store under the original `Has calibration type` property, while keeping the displayed label as "Functional Layer" — confirming clearly that a display label and its underlying stored property name are two separate things, and one can be changed without the other. This same principle was applied correctly and deliberately for the simultaneous `Last Updated` → `Last Calibration` display change, which did not alter the underlying `Has module last updated` property.
Remaining gap, accepted rather than force-fixed: the small number of pages saved while the template stored under `Has functional layer` will retain that stored value until each page is next opened and re-saved, triggering a fresh `#set` under the reverted template. Per the project owner's standing rule against manual batch-retrofitting, this is left to resolve naturally through normal editing and Recent Changes, not a forced sweep.
Found by: Sovereign, 2026-07-14.
Next steps: None required — self-resolving. Worth keeping in mind if a future query built against `Has calibration type` returns fewer results than expected; check whether the missing pages are among the small affected set. Sovereign (talk) 13:59, 19 July 2026 (EDT)
- Amendment, 2026-07-14: Completed and confirmed resolved. `Template:GameModule` reverted to store under the original `Has calibration type` and `Has module last updated` properties — display labels only changed ("Functional Layer," "Last Calibration"), not the underlying stored fields. All downstream references corrected: `Template:GameModule/doc`, `Page Structure Calibration Checklist`, `Template:New Page Seed`, and `Template:Calibration Maintenance Log` all now reflect the correct field/display mapping. All 150+ existing pages using the original property now correctly display "Functional Layer" and "Last Calibration" in the GameModule infobox — confirmed working, no site-wide breakage, all existing template calls throughout the site still function correctly.
- New, narrower issue identified during this fix, distinct from the original finding: a small number of newly created pages — built using the corrected seed template — are displaying blank or missing fields in their GameModule infobox despite the underlying data actually being present. Root cause not yet diagnosed. The reference block for the corrected seed template is:
:{{GameModule :| type = :| category = :| Calibration Type = :| Application Layer = :| Version = :| Maturity = :| Last Updated = :| description = :| contents = :}} :
- Note the parameter name shown here is `Calibration Type`, matching the original, corrected field mapping — not `Functional Layer`. If any newly affected page was built using a stale seed copy that still has the parameter named `Functional Layer` (from before this correction), that mismatch between the parameter used in the page and what the reverted template now expects would explain blank display fields directly — worth checking as the first, most likely cause before assuming something more complex is wrong.
- Resolution approach for affected pages: project owner will manually work through `Special:RecentChanges` and correct affected pages individually. Explicitly acknowledged as backtracking, and explicitly justified as an exception to the standing "don't force-fix, let it resolve through normal cycles" rule — these are critical, user-visible blank fields on live pages, not a benign latent data mismatch, and warrant direct correction rather than waiting for each page's next unrelated edit.
- Next steps: Confirm whether affected pages are using the stale `Functional Layer` parameter name rather than `Calibration Type`. If so, that is very likely the complete explanation and the fix is a straightforward parameter-name correction per page, not a deeper template issue. Sovereign (talk) 13:59, 19 July 2026 (EDT)
Full Resolution Report: Display Rename vs. Stored Property (Has calibration type / Has module last updated) — 2026-07-14
Status: Resolved Reviewer: Sovereign Note: This is a full, self-contained report of the same finding logged as an amendment to the original entry above. Read this if you want the complete picture without cross-referencing; the original entry above shows the actual sequence of discovery and correction as it happened.
What was found: An earlier display-label rename (intended to change "Calibration Type" to "Functional Layer" as shown on the page) had unintentionally also changed the underlying stored SMW/Cargo property from `Has calibration type` to `Has functional layer`. Since `Has calibration type` was the original property already used by 150+ existing pages, this created a silent split: most pages storing under the original property, a small number of newer pages storing under the new one, with no visible difference in rendering since only the display label was supposed to have changed.
Root cause: A display-label change and an underlying stored-property change are two separate things in this template system, and the earlier edit conflated them — changing the parameter name in a way that altered both simultaneously when only the display was intended to change.
Fix applied: `Template:GameModule` reverted so `#set` stores under the original properties (`Has calibration type`, `Has module last updated`) while keeping the display labels as "Functional Layer" and "Last Calibration" — correctly separating the two concerns going forward. All downstream references corrected: `Template:GameModule/doc`, `Page Structure Calibration Checklist`, `Template:New Page Seed`, `Template:Calibration Maintenance Log`.
Confirmed outcome: All 150+ existing pages using the original property now correctly display "Functional Layer" and "Last Calibration." All site-wide template calls continue functioning correctly. No site-wide breakage.
Second, narrower issue surfaced during this fix: a small number of newly created pages, built from the seed template, are showing blank or missing fields in their GameModule infobox despite the data being present in the page's wikitext. Leading hypothesis, not yet fully confirmed: these pages were built using a stale seed copy with the parameter still named `Functional Layer` rather than the corrected `Calibration Type`, creating a mismatch between what the page provides and what the reverted template now expects.
Resolution approach: project owner is manually correcting affected pages via `Special:RecentChanges`, explicitly as an intentional exception to the standing "let it resolve through normal cycles" rule — justified because these are critical, user-visible blank fields on live pages, not a benign latent mismatch.
Found by: Sovereign, 2026-07-14.
Lesson worth carrying forward: when changing a template parameter's display label, explicitly verify the underlying `#set`/`#cargo_store` call still references the original stored property name — a display rename and a storage rename are easy to conflate in one edit, and the two should always be changed independently and deliberately, never as a side effect of each other.
Next steps: Confirm the stale-parameter hypothesis on affected new pages. If confirmed, correct via the same manual sweep already underway. Sovereign (talk) 14:02, 19 July 2026 (EDT)
Calibration Report — Calibration Failure Log — 2026-07-20 (Structural Pre-Cal)
- **Page:** Calibration Failure Log
- **Summary:** Structural pre-calibration pass. Three nonconformances found and corrected.
- **Reviewer:** Sovereign
- **Review Type:** Self-Assessment (Structural only)
- Summary of Changes:**
- Synchronized `Last Updated` and `review_date` to `2026-07-20`.
- Added required inline HTML comments stating valid options on all fields.
- Reordered templates so the mandatory seven begin with `{ {RelatedPages}}`.
- Process Note:**
Nonconformances were logged before fixes were applied.
- What This Report Does NOT Claim:**
No content calibration was performed. The open `Nonconformance-Open-With-Dependencies` status is intentional and reflects the page’s purpose.
See the Game. Refuse the Game. Build Better. Sovereign (talk) 08:46, 20 July 2026 (EDT)
Calibration Report — Calibration Failure Log — 2026-07-24 (Development alignment)
| Calibration event | |
|---|---|
| Page | Calibration Failure Log |
| Date | 2026-07-24 |
| Report type / tier | Development alignment |
| Calibration objective | Remove redundant archive role; lock thin scar-index purpose |
| Reviewer | Sovereign; design challenge via prior round (overlap with NCR / Known Site Issues / Decision Records) |
| Method | Solo + structured comparison of logging homes |
| Standing (this report) | Self-Assessment |
| Standing impact | No Confirmed claim; priority Core → Supporting; purpose narrowed |
| Evidence basis | Role collision with existing logs; maintenance cost of duplicate full write-ups |
Summary: Page was acting as a parallel failure archive. Repurposed to a short project-wide scar index for “worked as designed, design wrong” lessons only, with mandatory pointers out and explicit non-goals.
Actions performed
- Replaced archive framing with scar-index purpose and comparison table
- Filing rules: reusable + short + no full report dump
- Compressed existing two entries to scar format
- Priority Supporting; Open Items discourage growth into report mirror
Fields and ratings (if changed)
| Field | Before | After |
|---|---|---|
| Version | 0.2 | 0.3 |
| Last Updated / review_date | 2026-07-20 | 2026-07-24 |
| priority | Core | Supporting |
| description | Project-wide log of design failures… | Thin scar index… not full report archive |
Open Items
- Add scars only when genuinely project-wide and not already only a Known Site Issue or Decision Record
- Optional dashboard one-line link
What this report is not claiming
- Does not merge this page into Known Site Issues (could still be done later).
- Does not assert the two seed scars are fully closed in the field — residuals may remain on instance pages.
- Does not create Confirmed standing.
See the Game. Refuse the Game. Build Better. Sovereign (talk) 10:18, 24 July 2026 (EDT)