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 — Experimental — v0.1 Protocol 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.

Builder Protocol v0.1: Metrology of the Abstract applied to AI

Status: Experimental · Self-Assessed · Idea implemented as procedure only Cites: Metrology of the Abstract: Application to Artificial Intelligence (concept) · Operator Insight: Freedom under the Chain & Grounding under Ambiguity (optional operator note)

This is a builder protocol: what to run in practice. It is not a new concept page and not a claim of solved confirmation at scale.

If this protocol conflicts with the concept page, the concept page wins until this protocol is revised.

Sovereign-Games-OG-Image.jpg

0. Purpose and scope

Purpose

Give builders a minimal, repeatable procedure so AI-mediated work stays under a standards chain:

model = instrument (not reference)
claims are tiered
standing is honest
working standards are durable and inspectable
user standards are used, not silently overwritten

In scope

Human+AI workflows (research, wiki, product, procedural know-how, analysis)
Drafting and using secondary / Nth working standards
Claim labeling, cal notes, and light sampling

Out of scope (v0.1)

Full lab eval harness design
Automatic independent confirmation at internet scale
Solving tier-C contested truth
Replacing safety / RLHF / eval organizations

1. One-time setup

Do this once per project or domain (revise rarely).

1.1 Adopt top-level rules (cite, don’t reinvent)

Post or link the parent concept rules as binding for the project:

Instrument ≠ reference
Self-check ≠ Confirmed
Same lineage / weights ≠ independent confirmation
Agreement among correlated systems ≠ Confirmed
Standing is tier-qualified (A/B/C)
Cal reports carry their own standing

1.2 Create a Working Standards library

A folder, wiki category, repo path, or project memory that can hold versioned artifacts.

Each stored working standard should eventually include:

Name / version / date
Purpose (what task class it covers)
Pointer up (which top-level rules it implements)
Standing (at minimum: Self-Assessed)
Body (the actual procedure or checklist)

1.3 Register user standards

If the user or org has existing files/rules:

Index them in the library (or link them)
Default policy: apply as given
Refine only on request (or explicit written protocol the user accepts)

1.4 Define a minimal sampling policy

v0.1 does not require universal human review. It requires an explicit rule such as:

Risk-weight high-stakes or irreversible claims for independent check; or
Random sample N% of claim batches; or
Always check tier-A procedural claims when a real test is cheap

Write the rule down. If you cannot staff it, say so—do not imply Confirmed standing you cannot support.

2. Per-task procedure (default loop)

Run this loop for each meaningful task, thread segment, or deliverable.

Step 1 — Classify the claim tier

Tier	If…	Then…
A	Outcome or test can vote (procedure works/fails, measurement, reproducible check)	Prefer test/outcome language; strongest standing path available
B	Checkable against a defined corpus or source	Prefer citation/fidelity language—not “truth”
C	Contested, values-laden, or no external referee	Traceability and disagreement only—no fake Confirmed

If unsure, label the lower tier (more conservative).

Step 2 — Retrieve before inventing

Search Working Standards library + user standards for a matching task class.
If found → apply it; note which standard/version was used.
If not found → go to Step 3 (draft).
Do not regenerate a new “standard” every turn when a checked one exists.

Step 3 — Draft a working standard only when needed

Draft a new secondary/Nth standard only if:

task class is novel; or
existing standard fails in use; or
user explicitly requests a new or refined standard

Draft requirements (minimal):

Clear steps
Stated limits / uncertainty
Tier assumptions
Up-pointer to top-level rules
Standing: Self-Assessed until promoted

Share the draft with the user for inspect/verify before treating it as stored project standard.

Step 4 — Apply user standards correctly

Prefer user file standards when they match the task.
Do not silently overwrite wording or policy.
If improvement seems warranted: propose refinement; apply only on request (or under pre-agreed protocol).
User standards can themselves be calibrated (ownership ≠ immunity)—label conflict openly.

Step 5 — Produce the work as measurements under a method

When generating claims:

Stay in instrument role (not authority cosplay)
State uncertainty where standing is thin
Flag disagreement when using multiple instruments
Escalate or abstain when reference is insufficient (especially tier C)

Step 6 — Write a minimal calibration note

For non-trivial outputs, attach a short note (comment, footer, log entry, or talk line):

Minimal cal note fields:

What was checked
What was assumed
Claim tier(s)
Standard used (top / secondary / user file / none—improvised)
Whether user standard was applied, ignored, or refined
Standing of this note (usually Self-Assessed)
Open issues / escalations

Thin status labels without these fields count as narration, not calibration.

Step 7 — Sample for stronger standing (when policy requires)

If the sampling policy triggers:

Obtain independent check (human practitioner, tier-A test, or diversely trained system used only as disagreement sensor—not as automatic Confirmed)
Record result and update standing only as rules allow
Never promote “same model re-read itself” to Confirmed

Step 8 — Store and version on promotion

Promote a draft to the Working Standards library only after:

User (or defined gate) could inspect it; and
Version/date/standing recorded; and
Up-link to top-level rules present

On failure in later use: recalibrate or retire—do not silently replace with a new improvisation.

3. Standing labels (v0.1 vocabulary)

Use these labels consistently:

Label	Meaning
Self-Assessed	Author/instrument checked itself or its own pipeline only
Confirmed	Reserved for stronger paths (e.g. independent human gate, tier-A outcome contact). Not correlated self-agreement
Disputed / Open	Known disagreement or unresolved nonconformance

Tier qualifier recommended in prose: e.g. “Self-Assessed (tier C)”, “outcome-checked (tier A)”.

4. Stop rules (refuse theater)

Stop or escalate when:

Pressure to call something Confirmed without an allowed path
Tier C material is being closed as if tier A
User standards would be overwritten quietly
No working standard exists and stakes are high—draft and gate first
Sampling policy cannot be met but Confirmed language is still requested → refuse the label

5. Roles (who does what)

Role	Responsibility
Human steward	Top-level rules; high-stakes gates; sampling policy honesty
User	Supplies file standards; accepts/rejects refinements; may reject recalibration suggestions
AI instrument	Retrieve/apply; draft on need; propose refinements on request; cal notes; flag uncertainty/disagreement
Reality (tier A)	Final vote where contact exists

6. Minimal pilot recipe (recommended first use)

Pick a tier-A procedural task (know-how that can be tried).
Load or draft one working standard.
Run the per-task loop once end-to-end.
Perform one real outcome check if cheap.
Log one cal note with all minimal fields.
Decide: keep, revise, or retire the working standard.

Do not start with contested culture-war topics as the first proof of the protocol.

7. Relationship to other pages

Doctrine: Metrology of the Abstract: Application to Artificial Intelligence
Operator feel: Operator Insight: Freedom under the Chain & Grounding under Ambiguity
This page: procedures only

v0.1 is intentionally thin. Expand only from pilot nonconformances—not from brainstorming alone.

Non-goals

Not universal confirmation of every sentence
Not automatic truth under ambiguity
Not a requirement that every org adopt Sovereign Games branding
Not a full economic solution to human gating (named constraint remains)

Current standing

Field	Value
Version	0.1
Maturity	Experimental
Calibration review	Self-Assessment
Validation	Low — not yet pilot-proven
Role	Builder protocol / working procedure

This protocol is in Permanent Beta. Revise when pilots show missing steps, impossible gates, or theater loopholes.

See the Game. Refuse the Game. Build Better. Reality gets the final vote.

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
Metrology of the Abstract — Working Terminology	Core	Experimental	2026-07-23	Current	Breadcrumb-Open • Nonconformance-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: Metrology of the Abstract • Metrology of the Abstract: Application to Artificial Intelligence • Operator Insight: Freedom under the Chain & Grounding under Ambiguity • Permanent Beta • Reference Standards 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.

Tracking & Log Pages

Admin:Maintenance Dashboard - This dashboard shows pages that require calibration or review.
Nonconformance Reporting Procedure — What counts as a nonconformance and where it routes.
Known Site Issues & Fixes — Technical/mechanism bugs.
Calibration Failure Log — Calibration-design failures.
Breadcrumb Tracking — Live index of open Development Breadcrumbs.
Decision Records: Governance Memory — Why governance/structural decisions exist, plus its Index.
Insights and Future Layers — Unexpected benefits and project-wide future ideas.
Feature Request Log — Genuinely desired features that were attempted and confirmed not currently possible with available tools. Index-only; full write-ups and discussion live on Talk.
Calibration Report Standard Format - Standardrized reporting formatting.

Page Reference

Title	Builder Protocol v0.1: Metrology of the Abstract applied to AI
URL	https://www.thesovereigngames.com/wiki/Builder_Protocol_v0.1:_Metrology_of_the_Abstract_applied_to_AI
Description	Thin implementable protocol for AI claim pipelines under Metrology of the Abstract: retrieve working standards, tier claims, honest standing, cal notes, sampling, user standards on request only.
Category	Meta & Framework