Jump to content

Calibration Dependencies: Standards and Process

From The Sovereign Games (MoA Lab)

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

Meta

Calibration Dependencies: Standards and Process

Type Meta & Framework
Functional Layer
Application Layer Framework Infrastructure
Category Meta & Framework
Version 0.2
Maturity Developing
Last Calibration 2026-07-13
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


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.

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.

Calibration Dependencies

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


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 References

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



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.


See the Game. Refuse the Game. Build Better.

This page is in Permanent Beta.



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=2946"