10 · Operations and Governance
10.1 · Parameter tri-state governance
Every parameter in the system is registered and assigned exactly one of three governance states: frozen (permanently settled, changed only by a full method-change process), initial (initial-production-effective: the value is the production value, and a calibration study may later propose a change through the method-change process), and disabled (retained but not active). The registry is versioned, and every published artifact records the parameter version it was computed under. The tri-state discipline is what makes the V1 weights honest: they are not “placeholder awaiting calibration” — the registry's initial state is production-effective — but the door to calibration is a formal process, not a silent tweak.
10.2 · Version vectors
Reproducibility requires that every computation carry its own provenance. The system maintains six version vectors, each incremented when its domain changes, and each published artifact carries the full tuple:
Table 9. Version vectors: each published artifact carries the full tuple, so that “what was computed under what” is mechanical.
| Version | Domain | Incremented when |
|---|---|---|
| hyperparameters | any parameter changes state or value | |
| membership | the included or shadow set changes | |
| formulas | any composition formula changes | |
| governance decisions | an adjudicated decision is recorded | |
| flagship computation | the flagship formula or its inputs version | |
| source definitions | a source is added, swapped, or deprecated |
Two properties of the tuple matter. First, the tuple is monotone in time: versions never decrease, so the tuple is a total order over computations, and “compare two snapshots” is well-defined. Second, the tuple is fine-grained enough to localize: a source swap changes without implying a method change, and a reader can in principle see what kind of change happened without diffing every formula. The version tuple is the operational form of the paper's reproducibility posture.
10.3 · Settlement calendar and windows
The system settles twice daily in two closed-market windows (UTC 04:00–07:00 and 16:00–19:00), on the same structure and with equal weights for both windows. The anchor is frozen between settlements; the live signal only decays during closed windows (no injection, no renewal), and events that arrive during a closed window are batch-settled at the next opening. Reopenings are announced. The calendar is a governance object: changing the number or placement of windows is a method change with a version entry. The design reasons for two windows are stated in Section 5.7: they bracket the main activity periods of the two hemispheres and bound anchor staleness within a day.
10.4 · Dynamic membership operations
Membership changes follow the inclusion rules (Section 3.4) and a stated operational path: a candidate is evaluated at a settlement; if admitted, the admission takes effect at the next settlement and is disclosed with its rationale and its increment; the no-backcasting discipline (Section 3.5) prevents any retroactive restatement. When an admission changes a normalization extreme, the mechanical revaluation is handled by the BR-01 bridge (Section 6.10), which separates the mechanical from the fundamental component of the change. Shadow status is the intermediate tier: a shadow unit is evaluated and displayed but does not define normalization extremes or enter the centering mean (Section 3.3), which lets the system accumulate evidence about a candidate before the candidate's admission can move the scale.
10.5 · Suspension, hold, and recovery
Integrity events are handled by a graded mechanism. At the field level, a suspected bad value is held for re-verification while the most recent valid value continues in use (Section 9.1). At the settlement level, if the formal computation cannot be shown to be complete, valid, and reproducible — a P0-class integrity failure — the candidate settlement is held, no new formal version is submitted, and the last confirmed state remains published with a “settlement delayed” notice; the system keeps collecting and recomputing in the background. At the entity level, a single Originator may be suspended (frozen intraday and at settlement) on the decision of the arbitration committee, without changing its membership status — suspension is a quotation/governance state, not a membership state. Recovery requires a demonstrated root cause, a provable safety boundary, idempotent recomputation, and passed invariant checks. The graded mechanism is designed so that a fault is isolated at the smallest domain that contains it (the residual risks of Table 7 are the input to this design).
Back to contents | ← 9 · Data Dictionary, Pipeline, and Audit | 11 · FA Case Study: the 2026-08-29 Snapshot →