Template/Doc Calibration Pattern
|
CYCLE Calibration position — 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. |
Canonical Question: How should a template and its documentation subpage be structured so they're calibrated as one unit, not two independently-maintained pages that can drift apart?
Template/Doc Calibration Pattern
This page documents the working pattern developed and tested on Template:New Page Seed and Template:New Page Seed/doc — use it as the reference for building any future template/doc pair.
Meta
Template/Doc Calibration Pattern
| Type | Meta & Framework |
|---|---|
| Functional Layer | |
| Application Layer | Framework Infrastructure |
| Category | Site Maintenance |
| Version | 0.1 |
| Maturity | Experimental |
| Last Calibration | |
| Status | Permanent Beta |
| Description | The reference pattern for how a template and its /doc page should be structured and calibrated together as one unit, developed and tested on Template:New Page Seed. |
Menu
Core Principles
- Reality gets final vote
- See the Game. Refuse the Game. Build Better.
- Permanent Beta
Navigation
Related
Core Principle
A template and its /doc page are not calibrated separately. The template holds the single, real Admin Page Status block. The doc page holds documentation content only, plus a plain link back to the template — it does not maintain its own independent status.
What Goes on the Template
This list covers what's universal to every template/doc pair. It is not exhaustive — a template with unique functional behavior may need additional, page-specific sections beyond these.
- The actual
{{Admin Page Status}}block — the single source of calibration truth. - A live Cargo query displaying that same status, for visibility without needing to open source code: `No results` — `limit=1` is required, not optional, since duplicate stored rows are a real, confirmed possibility (see Development Breadcrumb below).
- Diagnostic/navigation templates that help someone working on this template catch real problems:
{{AllTemplates}}(Template: namespace only),{{RelatedPages}},{{Calibration Dependent}},{{Calibration Dependencies Display}}. - A plain link to the doc page:
'''Full documentation:''' [[Template:X/doc]].
Exceptions — page-specific additions: if a template has behavior no other template shares (e.g. a live demonstration of its own output, a unique query result relevant only to how that template functions, a setup step specific to its mechanism), that content belongs on the template too, added as its own clearly-labeled section — not omitted just because it doesn't appear in the universal list above. State plainly why it's there, the same way this whole pattern states its own reasoning, so a future reader can tell "unique and intentional" apart from "accidentally added."
What Goes on the Doc Page
This list covers what's universal to every doc page. It is not exhaustive — a doc page for a template with unique functional behavior may need additional, page-specific sections beyond these.
- All actual documentation content — usage, field guides, examples, warnings.
- A plain pointer back to the template for calibration status: "Calibration status for this documentation is tracked on Template:X, not here." No query, no duplicate Admin Page Status block.
- Universal reference templates that don't help catch page-specific problems:
{{Framework Reference}},{{Calibration Procedure Reference}},{{Calibration Maintenance}}.
Exceptions — page-specific additions: if a template's actual usage needs a worked example, a rendered sample of its own output, or a demonstration specific to how that template functions, that content belongs on the doc page too, added as its own clearly-labeled section — not omitted just because it doesn't appear in the universal list above. State plainly why it's there, so a future reader can tell "unique and intentional" apart from "accidentally added."
Why the Split Is This Way
The diagnostic templates (dependency queries, related pages, all-templates nav) go on the template because that's the page someone is actually working on when a problem needs catching — this project has already caught two real bugs (a cycle-tracking flaw, a duplicate Cargo row) specifically because this information was visible in-place rather than requiring a context-switch to a separate doc page. The universal reference lists go on the doc because they're not diagnostic — they don't help catch anything specific to this page, they're just standing background material a reader consults once.
Known Issue: `Template:` Namespace Limitations
Two confirmed, unresolved limitations specific to building on this pattern:
- No working transparency footer template exists for `Template:` namespace pages. `Standalone Transparency` and `Subpage Hub-Linked Transparency` are both confirmed broken here, root cause unidentified. See Known Site Issues & Fixes. Until a fix exists, `Template:` namespace pages using this pattern will have no transparency footer.
- Cargo may store duplicate rows for a page across multiple saves — confirmed on `Template:New Page Seed`. `limit=1` on the status query is a required display-level workaround, not a fix; the underlying duplicate should still be cleared via `Special:CargoTables` "Recreate data" when possible.
Development Breadcrumb
This pattern has been tested on exactly one template/doc pair. It should be applied to at least one more before being treated as fully validated — watch specifically for whether the duplicate-row issue recurs, and whether a `Template:`-namespace-safe transparency solution changes this pattern once it exists.
Structural Connections
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 Dependent
Pages that list this page as a load-bearing dependency:
| Page | Priority | Instrument Grade | Last Updated | Cycle Status | Drift Status |
|---|---|---|---|---|---|
| Page Structure Calibration Checklist | Core | Development | 2026-07-14 | Current | Breadcrumb-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: Template:New Page Seed • Template:New Page Seed/doc • Known Site Issues & Fixes • Calibration Failure Log 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:
- The Sovereign Games Framework — Overall framework philosophy and operating principles
- Permanent Beta — Core maintenance and continuous improvement standard
- Reference Standards — Principles for traceable, confirmed standards
- Calibrating Conceptual Instruments — Methodology for evaluating and refining pages
- Civilizational Traceability Hierarchy — How standards should connect to reality across levels
- Diagnostic Inversion Test — Mandatory self-application standard
- Reality Game — Foundational reality-alignment tool
- Reality Override Game — Standing discipline against protecting an existing model rather than updating it
- Observable Behavior Rule — Standing principle that diagnostics evaluate observable actions, mechanisms, and consequences, not internal motive, belief, or intent
- One-Way Nature of the Sovereign Games — Anti-capture design principles
- The Royal Cubit Civilization (Strategy) — Long-term civilizational vision and metrology metaphor
- Conceptual Instruments — Overall direction and metrology metaphor
- Breadcrumb Philosophy — Standing discipline for making unresolved questions and provisional decisions explicit
- Calibration Dependencies: Standards and Process — Rule that visible and hidden dependency lists must match, and that dependencies describe genuine reliance
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.
See the Game. Refuse the Game. Build Better.