Jump to content

Calibration Dependencies: Standards and Process: Difference between revisions

From The Sovereign Games (MoA Lab)
← Older edit

Sovereign (talk | contribs)

3 user groups
3,708 edits
VisualWikitext
→Claiming Canonical Authority: Added new section == Claiming Canonical Authority ==
Structural pre-cal only. Fixed GameModule placement, canonical param name, invalid Maturity value, added inline comments, corrected template order, removed duplicate footer. Nonconformances logged first. Content calibration still pending.
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Development Notice
{{Development Notice
|status = Active Development
|status = Active Development
}}
{{GameModule
| type = Meta & Framework
| category = [[:Category:Meta & Framework|Meta & Framework]]
| Functional Layer = Governance
| Application Layer = Framework Infrastructure
| Version = 0.1
| Maturity = Developing
| Last Updated = 2026-07-13
| description = Defines how dependencies are tracked on Sovereign Games pages, including the visible Calibration Dependencies section and the hidden depends_on field in Admin Page Status.
}}
}}


Line 19: Line 8:


'''Note:''' This process will not be complete on first pass. It will take multiple calibration cycles across many pages before the visible/hidden split, anchor conventions, and ripple-search workflow are fully proven out. This page is a starting point, not a finished standard.
'''Note:''' This process will not be complete on first pass. It will take multiple calibration cycles across many pages before the visible/hidden split, anchor conventions, and ripple-search workflow are fully proven out. This page is a starting point, not a finished standard.
{{GameModule
| type = Meta & Framework <!-- options: Meta & Framework, Core Diagnostic, Builder & Sovereignty, Calibration & Accountability, Practical Application, Sovereign Strategies, Strategic Actionable Plans, Hidden Mastery, Framework Guidelines -->
| category = [[:Category:Meta & Framework|Meta & Framework]] <!-- must match an existing Category page -->
| Calibration Type = Governance <!-- displays as Functional Layer. options: Governance, Diagnostic Layer, Builder Layer, Calibration Layer, Application Layer, Strategic Layer, Framework Infrastructure -->
| Application Layer = Framework Infrastructure <!-- options: Multi-Layer, Framework Infrastructure, Individual, Institutional -->
| Version = 0.2
| Maturity = Development <!-- options: Experimental, Development, Confirmed, Field Validated, Reference Standard Candidate -->
| Last Updated = 2026-07-20 <!-- static only. Must match review_date. FORBIDDEN: magic words -->
| description = Defines how dependencies are tracked on Sovereign Games pages, including the visible Calibration Dependencies section and the hidden depends_on field in Admin Page Status.
}}


== Two Complementary Mechanisms ==
== Two Complementary Mechanisms ==
We use two different systems for dependency tracking. They serve different purposes and audiences, and are '''not''' meant to mirror each other exactly.
We use two different systems for dependency tracking. They serve different purposes and audiences, and are '''not''' meant to mirror each other exactly.


=== 1. Visible Calibration Dependencies Section ===
=== 1. Visible Calibration Dependencies Section ===
Placed on the main page (usually near the bottom, before the Resource block).
Placed on the main page (usually near the bottom, before the Resource block).


Line 47: Line 45:


=== 2. Hidden `depends_on` Field (Admin Page Status) ===
=== 2. Hidden `depends_on` Field (Admin Page Status) ===
'''Purpose:'''
'''Purpose:'''
* A '''strict, load-bearing subset''' of the visible list — only the pages whose substantive revision would require this page to be reviewed
* A '''strict, load-bearing subset''' of the visible list — only the pages whose substantive revision would require this page to be reviewed
Line 59: Line 56:


== Decision Rules ==
== Decision Rules ==
* The visible section should list '''all''' meaningful references that materially shaped the page — this is the complete record.
* The visible section should list '''all''' meaningful references that materially shaped the page — this is the complete record.
* The hidden `depends_on` field should list '''only''' load-bearing dependencies that would trigger a formal recalibration pass if changed — a filtered subset of the visible list, not an independent list.
* The hidden `depends_on` field should list '''only''' load-bearing dependencies that would trigger a formal recalibration pass if changed — a filtered subset of the visible list, not an independent list.
Line 65: Line 61:
* The hidden field can be populated gradually during calibration passes, prioritized by Core pages first.
* The hidden field can be populated gradually during calibration passes, prioritized by Core pages first.
* '''A blank `depends_on` field does not mean a page has no dependencies.''' It means no dependency-focused calibration pass has occurred yet. Do not treat a blank field as confirmation of "no dependencies" — check the visible section, which is the authoritative record.
* '''A blank `depends_on` field does not mean a page has no dependencies.''' It means no dependency-focused calibration pass has occurred yet. Do not treat a blank field as confirmation of "no dependencies" — check the visible section, which is the authoritative record.
== Rule: Core-Priority Changes Trigger Mandatory Ripple Review ==
'''Any substantive edit to a page with `priority = Core` in Admin Page Status must trigger a dependency-ripple check before the calibration pass is considered complete — not as an optional courtesy step, but as a required part of the edit.'''
=== Why This Rule Exists ===
Most drift-detection in this framework depends on someone actively revisiting a page. That works well for pages people continue to use and check. It fails for foundational, load-bearing definitions that everything downstream '''inherits without re-reading''' — a change at the root can propagate silently through years of dependent pages before anyone notices, because nobody has a reason to re-open the original page once their own page cites it and moves on.
This is not a hypothetical failure mode. A real-world case: a single-word legal definition changed with limited scrutiny, then propagated unexamined through decades of dependent policy, until courts ultimately ruled that the '''accumulated dependency itself''' — not the original change's legitimacy — justified leaving it standing. By the time anyone considered reversing it, the cost of unwinding the dependency chain exceeded the cost of the original error. This rule exists specifically to prevent that failure mode from having thirty years to develop before anyone notices.
=== The Procedure ===
Whenever a `priority = Core` page undergoes a substantive edit (not a typo/formatting fix — see [[Decision Records: Governance Memory]]'s trigger test for the same "substantive" threshold):
# Before the Calibration Report is finalized, run: <code><nowiki>{{#ask: [[Has dependency::PageName]] }}</nowiki></code> to generate the full list of pages that cite this one as load-bearing.
# List every page returned in the Calibration Report itself, under a '''"Ripple Check"''' heading — visible on the page, not just performed silently.
# For each dependent page, a follow-up review does not need to happen immediately, but the Ripple Check list itself must exist and be visible, so that '''failure to review a dependent page is a visible gap, not a silent one.'''
# If the dependency query returns zero results for a page marked Core, that is itself worth a second look — a foundational page nothing else cites yet may be mis-prioritized, or may simply not have accumulated dependents yet; note which explicitly.
=== Why This Is Enough, and Where It Still Falls Short ===
This does not guarantee every dependent page actually gets reviewed. It guarantees the '''list of what needs reviewing becomes visible and permanent''' the moment the root change happens, rather than requiring anyone to remember to generate it later. A QA reviewer or future contributor scanning a Core page's Calibration Reports can see, at a glance, whether Ripple Checks were run and whether their listed dependents were ever actually followed up on — turning "did anyone check the downstream effects" from an unanswerable question into a visible, auditable one.
'''This does not replace human vigilance — it gives vigilance something concrete to check.''' The rule assumes reviewers are trained to notice small changes on pages they visit (see [[Template:Admin Page Status/doc]]'s Worked Example and Common Mistakes) — the Ripple Check ensures that vigilance has a specific, complete list to apply itself to, rather than depending on someone happening to remember which pages depend on what.


== Claiming Canonical Authority ==
== Claiming Canonical Authority ==
If a page states it is "the canonical source" for a concept (a scale, a rule, a definition), that claim must be checked against the rest of the wiki '''before''' it's added, not after — a canonical-source claim is itself a load-bearing assertion and should be treated as part of `symmetry_check`-style Conceptual Review, not written in passing.
If a page states it is "the canonical source" for a concept (a scale, a rule, a definition), that claim must be checked against the rest of the wiki '''before''' it's added, not after — a canonical-source claim is itself a load-bearing assertion and should be treated as part of `symmetry_check`-style Conceptual Review, not written in passing.


Line 78: Line 94:


== When a Page Has No Dependencies ==
== When a Page Has No Dependencies ==
Some pages — particularly foundational or originating pages — may not depend on any other page's content. In this case, the Calibration Dependencies section should still be present, with an explicit statement rather than omission:
Some pages — particularly foundational or originating pages — may not depend on any other page's content. In this case, the Calibration Dependencies section should still be present, with an explicit statement rather than omission:


Line 89: Line 104:


== When to Create / Update Dependencies ==
== When to Create / Update Dependencies ==
* '''When creating or substantially revising a page''' → Build the visible Calibration Dependencies section. Do this as early as reasonably possible, ideally during the page's first calibration pass — do not defer it.
* '''When creating or substantially revising a page''' → Build the visible Calibration Dependencies section. Do this as early as reasonably possible, ideally during the page's first calibration pass — do not defer it.
* '''When a Core-priority page is substantively changed''' → Search the visible Calibration Dependencies sections of other pages (via `{{#ask: [[Has dependency::PageName]]}}` and/or manual backlink review) to find everything that references it. The hidden `depends_on` field tells you which of those hits are already flagged as urgent; it is not a separate search target.
* '''When a Core-priority page is substantively changed''' → Search the visible Calibration Dependencies sections of other pages (via `{{#ask: [[Has dependency::PageName]]}}` and/or manual backlink review) to find everything that references it. The hidden `depends_on` field tells you which of those hits are already flagged as urgent; it is not a separate search target.
Line 95: Line 109:


== Anchor Best Practices ==
== Anchor Best Practices ==
'''This section is intentionally being worked out in practice, not settled in advance.''' Anchors are already in use across the wiki (e.g. linking to specific sections of Reality Override Game or Conceptual Instruments), and the guidance below should be treated as a working draft to be refined as real anchor links accumulate and either hold up or break.
'''This section is intentionally being worked out in practice, not settled in advance.''' Anchors are already in use across the wiki (e.g. linking to specific sections of Reality Override Game or Conceptual Instruments), and the guidance below should be treated as a working draft to be refined as real anchor links accumulate and either hold up or break.


* '''Auto-generated heading anchors''' (the default — MediaWiki automatically creates an anchor from every section heading, e.g. `Page Name#Heading Text`) are acceptable and are what's currently in use across most existing pages. They are simple and require no extra markup.
* '''Auto-generated heading anchors''' (the default — MediaWiki automatically creates an anchor from every section heading, e.g. `Page Name#Heading Text`) are acceptable and are what's currently in use across most existing pages. They are simple and require no extra markup.
'''Known encoding gotcha:''' Colons inside heading text require percent-encoding (`%3A`) in the anchor link fragment to resolve reliably — an unencoded colon can fail to match the auto-generated heading ID depending on skin/version. Confirmed via direct testing on [[Decision Records: Governance Memory/Index]].
* '''Their known weakness:''' if the target heading's text is later edited, the anchor breaks '''silently''' — the link still resolves to the page, just not to the intended section, and nothing signals the break to either the editor of the target page or the reader following the link.
* '''Their known weakness:''' if the target heading's text is later edited, the anchor breaks '''silently''' — the link still resolves to the page, just not to the intended section, and nothing signals the break to either the editor of the target page or the reader following the link.
* '''Explicit anchors''' (<nowiki><span id="StableName"></span></nowiki>) placed at the start of a section, then linked as `Page Name#StableName`) are more robust — the anchor survives a heading text change, since it's decoupled from the heading itself. These are recommended for '''high-traffic anchor targets''' — sections that multiple other pages are expected to link into, particularly on Core-priority pages.
* '''Explicit anchors''' (<nowiki><span id="StableName"></span></nowiki>) placed at the start of a section, then linked as `Page Name#StableName`) are more robust — the anchor survives a heading text change, since it's decoupled from the heading itself. These are recommended for '''high-traffic anchor targets''' — sections that multiple other pages are expected to link into, particularly on Core-priority pages.
Line 107: Line 123:


== Best Practices ==
== Best Practices ==
* Use descriptive, specific anchors when referencing a particular part of a page, rather than linking to the whole page when only one section is relevant.
* Use descriptive, specific anchors when referencing a particular part of a page, rather than linking to the whole page when only one section is relevant.
* Prefer stable explicit anchors for high-traffic Core-page targets; auto-generated heading anchors remain acceptable elsewhere (see Anchor Best Practices above).
* Prefer stable explicit anchors for high-traffic Core-page targets; auto-generated heading anchors remain acceptable elsewhere (see Anchor Best Practices above).
Line 116: Line 131:


== Calibration Dependencies ==
== Calibration Dependencies ==
This page is not calibration-dependent on other pages. It defines the standard rather than relying on external content, though its reasoning draws on [[Reference Standards in Abstract Systems]] and [[Conceptual Instruments]].
This page draws directly on the following:
* [[Reference Standards in Abstract Systems]]
* [[Conceptual Instruments]]
* [[Template:Admin Page Status/doc]]


== See Also ==
== See Also ==
Line 125: Line 143:
'''See the Game. Refuse the Game. Build Better.'''
'''See the Game. Refuse the Game. Build Better.'''


This page is in '''Permanent Beta'''.
{{RelatedPages}}
{{Standalone Transparency}}
{{Calibration Dependent}}
{{Calibration Dependencies Display}}
{{Calibration Maintenance}}
{{Framework Reference}}
{{Calibration Procedure Reference}}
{{Tracking Logs Reference}}


[[Category:Meta & Framework]]
[[Category:Meta & Framework]]
[[Category:Site Maintenance]]


<div style="display:none;">
{{Resource
{{Resource
| Title = Calibration Dependencies: Standards and Process
| Title = Calibration Dependencies: Standards and Process
Line 136: Line 161:
| Category = Meta & Framework
| Category = Meta & Framework
}}
}}
</div>


{{Admin Page Status
{{Admin Page Status
<!-- Do Not Remove commented out Reference Options -->
<!-- === CORE STATUS === -->
<!-- options: Done, Needs review, Not started -->
| categorization = Done
| categorization = Done
<!-- options: Self-Assessment, Confirmed Rating -->
| calibration_review = Self-Assessment
| calibration_review = Self-Assessment
<!-- options: Experimental, Development, Confirmed, Field Validated, Reference Standard Candidate -->
| instrument_grade = Development
| instrument_grade = Development
<!-- options: Low, Moderate, High -->
| validation = Low
| validation = Low
| calibration_rationale = Defines a sound two-mechanism split (visible/complete vs. hidden/load-bearing) with the ripple-search decision rule now tightened to avoid redundancy. Anchor best practices are explicitly marked as a working draft, not settled. Not yet tested against a real triggered dependency pass.
| calibration_rationale = Structural pre-cal only. Fixed GameModule placement, switched to canonical Calibration Type param, corrected invalid Maturity value (Developing → Development), added required inline option comments, corrected mandatory template order, and removed duplicate footer. Content calibration not performed.
| review_confidence = Moderate
| review_confidence = High <!-- options: High, Moderate, Low -->
| review_date = 2026-07-13
| review_date = 2026-07-20 <!-- static only. Must match Last Updated -->
| reviewed_by = Sovereign
| reviewed_by = Sovereign
<!-- options: Core, Supporting, Peripheral -->
| priority = Core
| priority = Core
| review_threshold = 60
| review_threshold = 60
<!-- options: Yes, No, Not checked -->
| has_backlinks = Yes
| has_backlinks = Yes
<!-- options: Yes, Has red links, No, Not checked -->
| outbound_links_valid = Not checked
| outbound_links_valid = Not checked
<!-- options: Yes, No -->
| in_outline = Yes
| in_outline = Yes
<!-- options: Yes, No -->
| in_category_outline = Yes
| in_category_outline = Yes
<!-- options: Done, Needs review, Not started -->
| templates_complete = Done
| templates_complete = Done
<!-- options: Meets standard, Needs work, Not checked -->
| formatting_standard = Meets standard
| formatting_standard = Meets standard
<!-- options: Applied, Not applicable, Needs work -->
| symmetry_check = Not applicable
| symmetry_check = Not applicable
<!-- options: Yes, No, Not applicable -->
| self_report_flagged = No
| self_report_flagged = No
<!-- options: Yes, Needs work, Not checked -->
| terminology_consistent = Yes
| terminology_consistent = Yes
<!-- options: Confirmed by other party, Self-assessed only -->
| standing_check = Self-assessed only
| standing_check = Self-assessed only
<!-- options (multiple allowed, semicolon-separated): Breadcrumb-Open, Nonconformance-Open, Nonconformance-Open-With-Dependencies, Resolved-Unverified, Disputed, None open. "None open" valid ONLY alone. -->
| drift_report_status = None open
| drift_report_status = None open
| depends_on = Template:Admin Page Status; Reference Standards in Abstract Systems; Conceptual Instruments
| depends_on = Reference Standards in Abstract Systems; Conceptual Instruments; Template:Admin Page Status/doc
}}
}}

Latest revision as of 09:13, 20 July 2026

Welcome to the MoA–TSG Lab. The wiki is the bench. The work is Metrology of the Abstract. Adopt the tools or leave them on the rack — either way, the need doesn't wait.

  • Lab Note: A redlink is not a failure. It identifies Calibration Debt—work waiting to be measured, mapped, and calibrated.

CYCLE Calibration position

Status — Active Development

This page is a conceptual instrument under Permanent Beta. It declares a real calibration position, not a finished product waiting to ship. Checking continues; an edit is only required when evidence demands it. Stage: Seed to Fruit.

Feedback welcome — especially clarity, failure modes, and calibration gaps. Use discussion or Contribute.


Calibration Dependencies: Standards and Process

This page defines how dependencies between pages are handled in The Sovereign Games wiki to support traceability, calibration, and efficient ripple-effect reviews.

Note: This process will not be complete on first pass. It will take multiple calibration cycles across many pages before the visible/hidden split, anchor conventions, and ripple-search workflow are fully proven out. This page is a starting point, not a finished standard.



Sovereign-Games-OG-Image.jpg

Meta

Calibration Dependencies: Standards and Process

Type Meta & Framework
Functional Layer Governance
Application Layer Framework Infrastructure
Category Meta & Framework
Version 0.2
Maturity Development
Last Calibration 2026-07-20
Status Permanent Beta
Description Defines how dependencies are tracked on Sovereign Games pages, including the visible Calibration Dependencies section and the hidden depends_on field in Admin Page Status.

Core Principles

  • Reality gets final vote
  • See the Game. Refuse the Game. Build Better.
  • Permanent Beta

Navigation

Related


Two Complementary Mechanisms

We use two different systems for dependency tracking. They serve different purposes and audiences, and are not meant to mirror each other exactly.

1. Visible Calibration Dependencies Section

Placed on the main page (usually near the bottom, before the Resource block).

Purpose:

  • Show readers and maintainers what the page is built upon
  • Create natural MediaWiki backlinks
  • Make assumptions and sources transparent
  • Serve as the complete, honest search target when doing a ripple review — this is the list you search, not the hidden field

Example format: 

== Calibration Dependencies ==
This page was built using the following key references and standards:
* [[Permanent Beta]]
* [[Conceptual Instruments#Requirements of a Conceptual Instrument]]
* [[Reference Standards in Abstract Systems#Core Principle]]
* [[Diagnostic Inversion Test]]

Use anchors (`#SectionName`) when referencing a specific part of a page. See Anchor Best Practices below.

2. Hidden `depends_on` Field (Admin Page Status)

Purpose:

  • A strict, load-bearing subset of the visible list — only the pages whose substantive revision would require this page to be reviewed
  • Used for dashboards, queries, and prioritizing recalibration when a major page changes
  • Supports "fire alarm" prioritization for Core pages

This field should contain only the critical pages whose substantive revision would trigger a formal recalibration pass — not everything referenced, just what's urgent.

Example in Admin Page Status: 

| depends_on = Permanent Beta; Conceptual Instruments; Reference Standards in Abstract Systems

Decision Rules

  • The visible section should list all meaningful references that materially shaped the page — this is the complete record.
  • The hidden `depends_on` field should list only load-bearing dependencies that would trigger a formal recalibration pass if changed — a filtered subset of the visible list, not an independent list.
  • It is acceptable (and expected) for the visible list to be more complete than the hidden field, especially early in the project.
  • The hidden field can be populated gradually during calibration passes, prioritized by Core pages first.
  • A blank `depends_on` field does not mean a page has no dependencies. It means no dependency-focused calibration pass has occurred yet. Do not treat a blank field as confirmation of "no dependencies" — check the visible section, which is the authoritative record.

Rule: Core-Priority Changes Trigger Mandatory Ripple Review

Any substantive edit to a page with `priority = Core` in Admin Page Status must trigger a dependency-ripple check before the calibration pass is considered complete — not as an optional courtesy step, but as a required part of the edit.

Why This Rule Exists

Most drift-detection in this framework depends on someone actively revisiting a page. That works well for pages people continue to use and check. It fails for foundational, load-bearing definitions that everything downstream inherits without re-reading — a change at the root can propagate silently through years of dependent pages before anyone notices, because nobody has a reason to re-open the original page once their own page cites it and moves on.

This is not a hypothetical failure mode. A real-world case: a single-word legal definition changed with limited scrutiny, then propagated unexamined through decades of dependent policy, until courts ultimately ruled that the accumulated dependency itself — not the original change's legitimacy — justified leaving it standing. By the time anyone considered reversing it, the cost of unwinding the dependency chain exceeded the cost of the original error. This rule exists specifically to prevent that failure mode from having thirty years to develop before anyone notices.

The Procedure

Whenever a `priority = Core` page undergoes a substantive edit (not a typo/formatting fix — see Decision Records: Governance Memory's trigger test for the same "substantive" threshold):

  1. Before the Calibration Report is finalized, run: {{#ask: [[Has dependency::PageName]] }} to generate the full list of pages that cite this one as load-bearing.
  2. List every page returned in the Calibration Report itself, under a "Ripple Check" heading — visible on the page, not just performed silently.
  3. For each dependent page, a follow-up review does not need to happen immediately, but the Ripple Check list itself must exist and be visible, so that failure to review a dependent page is a visible gap, not a silent one.
  4. If the dependency query returns zero results for a page marked Core, that is itself worth a second look — a foundational page nothing else cites yet may be mis-prioritized, or may simply not have accumulated dependents yet; note which explicitly.

Why This Is Enough, and Where It Still Falls Short

This does not guarantee every dependent page actually gets reviewed. It guarantees the list of what needs reviewing becomes visible and permanent the moment the root change happens, rather than requiring anyone to remember to generate it later. A QA reviewer or future contributor scanning a Core page's Calibration Reports can see, at a glance, whether Ripple Checks were run and whether their listed dependents were ever actually followed up on — turning "did anyone check the downstream effects" from an unanswerable question into a visible, auditable one.

This does not replace human vigilance — it gives vigilance something concrete to check. The rule assumes reviewers are trained to notice small changes on pages they visit (see Template:Admin Page Status/doc's Worked Example and Common Mistakes) — the Ripple Check ensures that vigilance has a specific, complete list to apply itself to, rather than depending on someone happening to remember which pages depend on what.

Claiming Canonical Authority

If a page states it is "the canonical source" for a concept (a scale, a rule, a definition), that claim must be checked against the rest of the wiki before it's added, not after — a canonical-source claim is itself a load-bearing assertion and should be treated as part of `symmetry_check`-style Conceptual Review, not written in passing.

Before adding a canonical-authority claim to a page:

  1. Search the wiki for the concept name and for the phrase "canonical" near it.
  2. If another page already makes the same claim, resolve which page is the actual best home before publishing — do not let two canonical claims coexist even temporarily.
  3. If no other page claims it, the claim is safe to add.

If you discover an existing conflict (two pages already claiming authority over the same concept), this is itself worth a Calibration Report noting it as a specific finding — see Versioning's 2026-07-13 report for a worked example of how this was resolved in practice.

When a Page Has No Dependencies

Some pages — particularly foundational or originating pages — may not depend on any other page's content. In this case, the Calibration Dependencies section should still be present, with an explicit statement rather than omission: 

== Calibration Dependencies ==
This page is not calibration-dependent on other pages. It is a foundational/originating source.

This mirrors the "Not applicable" convention used elsewhere in the project (see Template:Admin Page Status/doc) — an explicitly stated absence is different information than a missing section. A missing section means "not yet assessed." An explicit statement means "confirmed none."

When to Create / Update Dependencies

  • When creating or substantially revising a page → Build the visible Calibration Dependencies section. Do this as early as reasonably possible, ideally during the page's first calibration pass — do not defer it.
  • When a Core-priority page is substantively changed → Search the visible Calibration Dependencies sections of other pages (via `` and/or manual backlink review) to find everything that references it. The hidden `depends_on` field tells you which of those hits are already flagged as urgent; it is not a separate search target.
  • During regular calibration passes → Review and update both the visible section and the hidden field as needed. Use the pass to move dependencies from "referenced in the visible list" to "confirmed load-bearing, added to `depends_on`" where appropriate.

Anchor Best Practices

This section is intentionally being worked out in practice, not settled in advance. Anchors are already in use across the wiki (e.g. linking to specific sections of Reality Override Game or Conceptual Instruments), and the guidance below should be treated as a working draft to be refined as real anchor links accumulate and either hold up or break.

  • Auto-generated heading anchors (the default — MediaWiki automatically creates an anchor from every section heading, e.g. `Page Name#Heading Text`) are acceptable and are what's currently in use across most existing pages. They are simple and require no extra markup.

Known encoding gotcha: Colons inside heading text require percent-encoding (`%3A`) in the anchor link fragment to resolve reliably — an unencoded colon can fail to match the auto-generated heading ID depending on skin/version. Confirmed via direct testing on Decision Records: Governance Memory/Index.

  • Their known weakness: if the target heading's text is later edited, the anchor breaks silently — the link still resolves to the page, just not to the intended section, and nothing signals the break to either the editor of the target page or the reader following the link.
  • Explicit anchors (<span id="StableName"></span>) placed at the start of a section, then linked as `Page Name#StableName`) are more robust — the anchor survives a heading text change, since it's decoupled from the heading itself. These are recommended for high-traffic anchor targets — sections that multiple other pages are expected to link into, particularly on Core-priority pages.
  • Practical rule while this is still being worked out: new anchor links to Core-priority pages should prefer explicit spans where practical. Existing auto-generated anchor links do not need to be retrofitted retroactively unless a linked page's heading is actually about to change — at which point, check `` or manually search for incoming anchor links before renaming the heading.
  • Do not create placeholder anchor links to sections that don't exist yet. This creates silent debt identical to a placeholder page link, but harder to detect, since the page itself still resolves correctly.

This section should be revisited and tightened once more pages have used anchors in practice and any breakage has actually been observed, rather than being finalized from theory alone.

Best Practices

  • Use descriptive, specific anchors when referencing a particular part of a page, rather than linking to the whole page when only one section is relevant.
  • Prefer stable explicit anchors for high-traffic Core-page targets; auto-generated heading anchors remain acceptable elsewhere (see Anchor Best Practices above).
  • Do not create placeholder links to non-existent pages or sections.
  • Keep the visible section honest — it should reflect actual intellectual dependencies, not just nice-to-have references.

This page itself follows the standards described above.

Calibration Dependencies

This page draws directly on the following:

See Also

See the Game. Refuse the Game. Build Better.



Structural Connections


Page Transparency & Calibration

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 Dependent

Pages that list this page as a load-bearing dependency:

Page Priority Instrument Grade Last Updated Cycle Status Drift Status
Distributed Instrumentation Core Experimental 2026-07-20 Current None open
Calibration Log: When to Create One Core Development 2026-07-13 Current Breadcrumb-Open
Template:New Page Seed/doc Supporting Experimental 2026-07-14 Current None open
Template:New Page Seed Supporting Experimental 2026-07-14 Current None open

If this page is edited substantively, review the list above per the Ripple Review rule — see Calibration Dependencies: Standards and Process#Rule: Core-Priority Changes Trigger Mandatory Ripple Review.


Calibration Dependencies

Pages this page relies on as load-bearing dependencies: Reference Standards in Abstract Systems • Conceptual Instruments • Template:Admin Page Status/doc If incorrect, edit the `depends_on` field in Admin Page Status — do not edit this section directly, it is auto-generated.



Calibration References

This page is calibrated against the following core standards and reference materials:



Page Construction & Maintenance References

How we construct, maintain, and utilize each page as a self-admin control panel.

  • Distributed Instrumentation — the architectural principle behind why this page (and every page) carries its own live instrumentation, rather than relying on a separate central dashboard.
  • Page Structure Calibration Checklist — the Step 0 structural pass every page should pass before content calibration begins; this page's own structure should be checkable against it.
  • Template:New Page Seed — the seed template this page's basic structure was built from.
  • Calibration Log: When to Create One — the decision procedure this page's own Talk-only vs. dedicated-log status was decided against.
  • Framework Features Reference — maintains consistency and traceability across the framework's structural features while avoiding unnecessary maintenance overhead; consult before introducing a new structural pattern this page might otherwise duplicate.



Calibration Procedure

In development. See Calibration Procedure for current status. No formal step-by-step procedure exists yet beyond the practices demonstrated across individual pages developed during the initial creation of this project.



Tracking & Log Pages




Page Reference

Title Calibration Dependencies: Standards and Process
URL https://www.thesovereigngames.com/wiki/Calibration_Dependencies:_Standards_and_Process
Description Defines how dependencies are tracked on Sovereign Games pages using both visible sections and the hidden depends_on field.
Category Meta & Framework




Retrieved from "https://www.thesovereigngames.com/index.php?title=Calibration_Dependencies:_Standards_and_Process&oldid=3244"