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.

Sovereign-Games-OG-Image.jpg

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.

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.

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:

Search the wiki for the concept name and for the phrase "canonical" near it.
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.
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.