44-EFT.WP.Data.ModelCards v1.0 | Chapter 1 Overview & Scope

Home ／ Docs-Technical WhitePaper ／ 44-EFT.WP.Data.ModelCards v1.0

Chapter 1 Overview & Scope

I. Chapter Purpose & Audience

• Purpose: Establish the role of the Model Card within the EFT data stack, minimum compliance requirements, usage boundaries, and how it interfaces with Dataset Cards, metrology, and citation anchors.
• Audience: Model development & training engineers, evaluation & calibration owners, deployment & platform engineers, compliance & safety auditors, external reproducibility and baseline maintainers.

II. Terminology & Citation Posture

1. Terminology source: Follow EFT Technical Whitepaper & Notes — Comprehensive Template v0.1; this volume only adds Model Card–specific increments (e.g., architecture/backbone, io_schema, calibration, robustness, fairness, safety). Cross-volume citations must carry “Volume + Version + Chapter/Anchor,” preferably to clause-level P/S/M/I anchors. Example: See "EFT.WP.Core.Equations v1.1" Ch.2 S20-1.
2. Inline symbols & math: Wrap all inline symbols in backticks (e.g., f_θ(x), p(y|x,θ), L(θ), T_arr, c_ref, n_eff); any expression with division/integral/composite operators must use parentheses and explicitly declare path gamma(ell) and measure d ell; no Chinese in formulas/symbols/definitions.
3. Two equivalent arrival-time forms (cross-volume standard):
   • T_arr = ( 1 / c_ref ) * ( ∫ n_eff d ell )
   • T_arr = ( ∫ ( n_eff / c_ref ) d ell )
     Whenever T_arr appears, record in the Model Card metadata: delta_form, path="gamma(ell)", measure="d ell".

III. In Scope

• Objects: Metadata and documentation requirements for any deployable model within EFT: task & IO modes, architecture & parameters, training-data references, preprocessing/features, objectives & optimization, evaluation protocol & metrics, calibration & uncertainty, robustness & fairness, safety & usage limits, deployment/resources, export & release.
• Relation to Dataset Cards: Model Cards reference—not duplicate—data facts; all data provenance, splits, and quality gates must reference EFT.WP.Data.DatasetCards v1.0.
• Relation to metrology/citation specs: Units/dimensions and anchors follow Core.Metrology v1.0 and the Citation & Cross-Reference Spec v0.1.

IV. Out of Scope

V. Deliverables & Compliance Gate

1. Deliverables:
   • model_card.yaml (or JSON) — compliant with this volume’s Schema & required fields;
   • export_manifest — includes version and references[];
   • Validation report: Schema/Lint checks, metrology checks, evaluation with significance, calibration with coverage, robustness & fairness items;
   • Reproducibility artifacts: frozen split references, random seeds & environment lock, inference/eval scripts with hashes.
2. Minimum compliance (must pass before release):
   • Required fields complete; type/regex & dependency checks pass;
   • io_schema is explicit and consistent with deployment interfaces;
   • Evaluation protocol uses frozen splits and references Dataset Cards;
   • check_dim passes (physical/time/frequency/performance units);
   • Citations use “Volume+Version+Anchor”; no shortcodes/aliases.

VI. Document Structure & Cross-Volume Dependency Map

1. Structure map:
   • Ch.3–Ch.5: field inventory and standard/extension fields;
   • Ch.6–Ch.7: task & IO; architecture & parameters;
   • Ch.8–Ch.10: training-data binding, preprocessing, objectives & optimization;
   • Ch.11–Ch.12: evaluation protocol & metrics; calibration & uncertainty;
   • Ch.13–Ch.14: robustness/shift/adversarial, fairness/ethics & usage limits;
   • Ch.15–Ch.16: machine-readable Schema/Lint and implementation binding & validation API;
   • Ch.17–Ch.18: examples and templates.
2. Dependency constraints:
   • Data facts & splits: reference DatasetCards v1.0;
   • Units/dimensions: reference Core.Metrology v1.0;
   • Path-dependent equations: reference Core.Equations v1.1.

VII. Naming & Field Style

• Naming: Keys use snake_case; reserved names (e.g., model_id, version, task, io_schema, architecture, evaluation, calibration, robustness, fairness, safety, deployment, resources, export_manifest) must not be repurposed.
• Conflict enforcement: T_fil vs. T_trans must not be mixed; n vs. n_eff strictly distinguished; no Chinese in formulas/symbols/definitions.

VIII. Machine-Readable & Validation Interfaces (Overview)

1. Schema & Lint: This volume provides model_card.schema.json and lint_rules.yaml (mandatory checks: version/anchor regex, frozen-split references, metrology/unit consistency, symbol conflicts, math guardrail).
2. Implementation-binding essentials:
   • Field see uses "Volume vX.Y:Anchor";
   • export_manifest includes version and references[];
   • Validation APIs cover structure, units, references, leakage audit, evaluation & significance, calibration & coverage, robustness/fairness items.

IX. Quality, Reproducibility & Audit

• Quality gates: Align thresholds with Ch.11–Ch.12 for evaluation/calibration; leakage = 0, randomness & repetition requirements satisfied;
• Reproducibility: Training/inference environments, dependencies, seeds, and scripts are replayable;
• Audit trail: Versioning & citation anchors, evaluation/calibration/robustness/fairness reports, and artifact hashes are traceable in the export_manifest.

X. Usage & Maintenance

• Usage: For public release and internal approvals, the Model Card is the single source of truth; when referencing Dataset Cards and Core volumes, cite only stabilized lines (e.g., v1.*).
• Maintenance: When field postures or dependencies change, follow Chapter 14’s release & versioning strategy to publish a new version and reflect citation deltas in the export_manifest.