03-EFT.WP.Core.Parameters v1.0 | Preface

Home ／ Docs-Technical WhitePaper ／ 03-EFT.WP.Core.Parameters v1.0

Preface

I. Positioning & Objectives

• This volume focuses on defining, organizing, and governing the parameter system. Core objects include theta, Theta, prior(theta), post(theta|data), C_eq / C_ineq, lb / ub, and T_map.
• Goals: provide an implementation-ready parameter lexicon; rules for constraints and transforms; prior and inference conventions; and stable binding interfaces to the equations/metrology/terms volumes (I30-*).
• Principles: introduce no new physical laws or field equations. For field quantities, paths, arrival time, and related relations, cite Core.Terms and Core.Equations.

II. Intended Readers & Prerequisites

1. Reader profiles
   • Modeling & inference engineers: design prior / L / post and implement infer_*.
   • Domain scientists: supply the physically admissible domain Theta, bounds lb / ub, and constitutive hyper-parameters.
   • Platform & numerics developers: implement the I30-* interfaces and maintain regression baselines.
2. Prerequisite references
   • Terms & symbols: EFT.WP.Core.Terms v1.0.
   • Minimal equations & weak forms: EFT.WP.Core.Equations v1.1.
   • Units & metrology: Metrology. suite.

III. Scope & Non-Scope

1. In scope
   • Parameter naming & numbering; postulates and conflict tables; parameter domain Theta and constraints C_eq / C_ineq; invertible transforms T_map.
   • Prior libraries and hyper-parameter conventions; minimal links for MLE/MAP/MCMC; Fisher information and identifiability.
   • Covariance & uncertainty propagation; scenario governance & version traceability; cross-volume bindings and export formats.
2. Out of scope
   • Derivation and proofs of physical equations (see Core.Equations).
   • Construction of unit systems and legal metrology specifics (see Metrology.).

IV. Unified Notation & Formatting Essentials

1. Style conventions
   • All formulas, symbols, and definitions are English in plain text; wrap inline symbols in backticks, e.g., theta, Theta, prior(theta), C_eq(theta).
   • Any expression involving division, integrals, or composite operators must use parentheses, and must declare the path gamma(ell) and the measure d ell.
2. Two arrival-time conventions (cross-volume exemplar)
   • Constant-factored: T_arr = ( 1 / c_ref ) * ( ∫ n_eff d ell )
   • General form: T_arr = ( ∫ ( n_eff / c_ref ) d ell )
3. Conflict isolation (mandatory)
   Strictly distinguish T_fil vs T_trans; n vs n_eff; never use bare c—use c_ref.
4. Numbering & citations
   Postulates Pxx-?, minimal equations Sxx-?, metrology flows Mx-?, implementation bindings Ixx-?. Cross-volume citation uses the fixed form: “see companion white paper Energy Threads, Chapter x, S/P/M/I…”.

V. Cross-Volume Relationships & Interfaces

• With Core.Terms
  Inherit and reuse the definitions and writing rules for T_fil(x,t), rho(x,t), n(x,t), n_eff(x,t), gamma(ell), d ell, c_ref.
• With Core.Equations
  Use compute_jacobian(eqn, params) and check_dim(expr) for dimensional closure and sensitivities; use propagate_uncertainty_mc for output-side propagation.
• With Metrology.
  Register and validate units via check_dim; declare parameter defaults and dimensions (with units) at first occurrence.
• Implementation bindings (this volume’s interface family)
  I30-1 … I30-12: parameter registration & aliases; domains & constraints; priors & sampling; transforms & invertibility; inference & calibration; identifiability & covariance; uncertainty propagation; scenario/version management; import/export & regression.

VI. Deliverables & How to Use

1. Deliverables
   • Parameter registry (YAML/JSON): name, code, type, unit, role, default, bounds, prior, transform, see.
   • Prior and transform libraries: Normal/LogNormal/Beta/... and log/logit/softplus/zscore standardized entry points.
   • Feasible-set description: Theta = { theta | C_eq = 0, C_ineq ≤ 0 }.
   • Regression assets: export_params for export; compare_param_sets for diffs and baselines.
2. Minimal usage sequence
   • register_param and set_bounds to onboard parameters and declare bounds.
   • set_transform and set_prior to establish numerical feasibility and statistical conventions.
   • Choose infer_mle / infer_map / posterior_sample_mcmc to obtain a point estimate or samples of theta.
   • Use propagate_uncertainty_mc to transmit uncertainty to outputs; interface with compute_jacobian as needed.
   • Persist with export_params, then enter the regression baseline and scenario governance.

VII. Versioning & Traceability

• Version semantics
  From v1.0, adopt backward-compatible minor increments; extending parameter fields or augmenting prior families must not break existing scripts.
• Traceability & governance
  Manage scenarios via create_scenario / activate_scenario / diff_scenarios; record evolution with bump_version; see Appendix B for detailed change logs.

VIII. Reading Path & Example Cues

1. Recommended path
   • Read Chapter 1’s naming and numbering postulates (P31-*) to internalize conflict lists and alias strategy.
   • Configure lb / ub and C_eq / C_ineq per Chapter 3, and choose an appropriate T_map.
   • Select priors and likelihood per Chapter 4, and complete calibration via Chapter 6’s workflow.
   • Propagate uncertainty with Chapter 7, and onboard scenario/version governance per Chapter 8.
2. Arrival-time examples (cross-volume consistency)
   Any parameter touching T_arr (e.g., c_ref, hyper-parameters of n_eff) must use the fully parenthesized canonical form T_arr = ( ∫ ( n_eff / c_ref ) d ell ) with explicit gamma(ell) and d ell.

IX. Compliance Statement

• All parameter names, set names, function prototypes, statistics, constraints, and prior/posterior expressions are strictly English only; narrative prose may be in any language, but not the formal items above.
• Rules for dimensional closure, explicit paths, and symbol isolation remain source-consistent with Core.Terms and Core.Equations; violations are rejected by validate_param_set and check_dim.