12-EFT.WP.Methods.Repro v1.0 | Chapter 7 Pipeline Card and Parameter Card

Home ／ Docs-Technical WhitePaper ／ 12-EFT.WP.Methods.Repro v1.0

Chapter 7 Pipeline Card and Parameter Card

I. Scope and Objectives

1. This chapter defines unified gauges for PipelineCard and ParamCard. The cards encapsulate the environment lock EnvLock, data dependencies, the operator graph, the randomness policy (rng_family/seed/stream_id), the time-base alignment parameters alpha, beta, and the reproduction gates gate.rep. They enable cross-site and cross-time reproducibility and auditing.
2. Objectives
   • Provide minimal required fields and optional extensions for both cards, covering versioning, signatures, manifests, and dimensional constraints.
   • Specify the generation, linting, signing, and publication flows Mx-39 → Mx-41, including exception and rollback strategies.
   • Bind to I30-* implementation prototypes for issuance, validation, diffing, signing, and materialized execution.

II. Terms and Symbols

• PipelineCard: a card object describing the artifact manifest and scheduling intent required for a reproducible run.
• ParamCard: a card object describing the set of algorithm/model/experiment parameters and their dimensional constraints.
• schema.version: the card schema version (semantic versioning).
• artifact: a named artifact with uri and hash(•) for content addressing.
• fingerprint: a cross-field digest used for audit trails and comparisons.
• EnvLock: see Chapter 5, the environment and dependency lock summary.
• alpha, beta: time-base mapping parameters, ts = alpha + beta * tau_mono.
• rng_family, seed, stream_id: the randomness policy (see Chapter 6).
• gate.rep: the reproducibility gate; delta_rep and R_coef are the core metrics.
• Collision mandate: T_fil vs T_trans must not be mixed; n vs n_eff must be strictly distinguished; dual arrival-time reporting must publish delta_form.

III. Postulates and Minimal Equations

1. P31-13 Card-as-contract postulate
   Given a PipelineCard and a matching ParamCard, with EnvLock enforced, the run’s outputs satisfy identical-distribution consistency constrained by delta_rep, R_coef, and spectral consistency audits.
2. P31-14 Dimensional consistency postulate
   Any parameter p_i that declares units and dimensions must pass check_dim( p_i ) and unit audits before publication. Illegal dimensionless usage (e.g., ln(length)) is forbidden.
3. S32-17 Repro gate and score synthesis
   • delta_rep = ( norm( y_new - y_ref ) / max( norm( y_ref ), eps_floor ) )
   • R_coef = 1 - delta_rep
   • score = w1 * R_coef + w2 * ( 1 - delta_psd ) + w3 * pass( gate.rep ), with w1 + w2 + w3 = 1.
4. S32-18 Card diff impact index
   For two cards with diff set D = { d_j } and item impact factors impact_j ∈ [0,1]:
   risk_index = ( ∑_j w_j * impact_j ) / ( ∑_j w_j ), used to prioritize regressions and drive rollback decisions.
5. S32-19 Dual arrival-time constraint (when declared by the card)
   Compute in parallel
   T_arr = ( 1 / c_ref ) * ( ∫ n_eff d ell ) and T_arr = ( ∫ ( n_eff / c_ref ) d ell ), then publish delta_form with gamma(ell) and d ell.

IV. Data and Manifest Gauges

1. PipelineCard — minimal required fields
   • Identity & version
     card.id, schema.version, created.ts, author, fingerprint.
   • Environment & time base
     env_lock_ref (reference to EnvLock), timebase = { alpha, beta, r_tb, window }.
   • Randomness policy
     rng = { rng_family, seed, H.name, H.version, stream_id_schema }.
   • Data & artifacts
     inputs = [ { name, uri, hash, role, window } ]; references = [ { name, uri, hash } ].
   • Execution graph & scheduling
     graph = { nodes:[ { id, op, version, container, entrypoint } ], edges:[ (u,v) ] };
     constraints = { hb, bp, resources, affinity } aligned to Core.Threads TS.*.
   • Gates & alerts
     gates = { gate.rep, tau_tb, tau_jitter, tau_psd, tau_var }; alerts = { on_fail: [action] }.
   • Arrival time (optional)
     arrival = { paths:[ gamma(ell) ], c_ref, media, report_delta_form:bool }.
2. PipelineCard — optional fields
   release.channel ∈ { canary, stable, LTS }; audit = { reviewers, signature }; notes; labels.
3. ParamCard — minimal required fields
   • Identity & version
     param.id, schema.version, scope (e.g., op_scope or module name), created.ts, author.
   • Parameter set
     params = [ { name, value, unit, dim, bounds, frozen:bool } ], where dim uses dimensional exponents (e.g., M^1 L^-1 T^-2).
   • Constraints & dependencies
     constraints = { check_dim:bool, monotone:[name], categorical:[name], coupled:[ (a,b, law) ] }.
   • Calibration provenance
     calib = { dataset_ref, method, uncertainty, fit.ts }.
   • Signature & fingerprint
     fingerprint, signature (sign later if needed).
4. ParamCard — optional fields
   priors = { name: distribution, hyperparams }; transform = { name: function }; release.notes.
5. Ingestion & traceability
   Both cards must record hash(•), fingerprint, and external uri. Any update yields a new schema.version and fingerprint; older versions become read-only and immutable.

V. Algorithms and Implementation Bindings

1. I30-2 emit_pipeline_card(state:any) -> dict
   • Assemble EnvLock, graph G = (V,E), rng, timebase, and gates.
   • Compute fingerprint = hash( fields_ordered ) and attach.
   • Return the PipelineCard and write an audit log entry.
2. I30-11 emit_param_card(source:any, scope:str) -> dict
   • Extract parameters with units and dimensions.
   • Run check_dim( p_i ) and bounds checks; on failure raise E_DIMENSION_MISMATCH.
   • Produce the ParamCard and its fingerprint.
3. I30-12 validate_card(card:dict) -> LintReport
   • Verify required fields, collision names, and dual-gauge declarations.
   • Cross-check: RNG policy vs Chapter 6; time-base vs Chapter 6 r_tb gate.
   • Emit failures, warnings, and pass:bool.
4. I30-13 diff_cards(card_a:dict, card_b:dict) -> ImpactReport
   • Field-by-field comparison to produce diff set D.
   • Estimate risk_index per S32-18; propose regression priorities.
5. I30-14 sign_and_publish_card(card:dict, key_ref:any) -> {uri:str, signature:any}
   • Sign the fingerprint and critical fields.
   • Publish to a controlled registry; return uri and signature.
6. I30-15 materialize_pipeline(card:dict, mode:str) -> RunPlan
   • Resolve the graph and constraints; bind resources and affinity.
   • Emit an executable RunPlan with TS.* observation points and alert choreography.
7. Typical exceptions
   E_SCHEMA_MISMATCH, E_ENV_DRIFT, E_TIMEBASE_SKEW, E_NONDETERMINISM, E_DATA_MISMATCH, E_BOUNDS_VIOLATION.

VI. Metrology Flows and Run Graph

1. Mx-39 card-emit-lint-sign
   • emit_pipeline_card → validate_card.
   • On pass, sign_and_publish_card; on fail, trigger alerts.on_fail.
2. Mx-40 param-freeze-verify
   • emit_param_card → validate_card (dimensions, bounds, coupling).
   • Dual-run comparison: require delta_rep <= gate.rep and delta_psd <= tau_psd; otherwise roll back.
3. Mx-41 plan-materialize-run
   • materialize_pipeline to produce a RunPlan with TS.* instrumentation.
   • Execute canary → stable tiered release per release.channel.

VII. Verification and Test Matrix

1. Structural consistency
   • Dropping any required field must yield validate_card.pass = false.
   • Collision-name or dual-gauge inconsistencies must hard-fail.
2. Dimensions and units
   • Inject dimensional errors; check_dim must catch them and raise E_DIMENSION_MISMATCH.
   • Enforce dimensionless input checks for log/exp/ln.
3. Randomness and time base
   • Card RNG policy inconsistent with Chapter 6 must raise alerts.
   • r_tb > tau_tb must trigger E_TIMEBASE_SKEW and block publication.
4. Diff and regression
   • The risk_index from diff_cards should correlate with observed delta_rep (e.g., Pearson ≥ 0.7).
   • High-risk diffs must force canary rollout and increased sample sizes.

VIII. Cross-References and Dependencies

• Chapter 5 EnvLock; Chapter 6 alpha, beta, rng_family/seed, and S_tt(f); Chapter 8 scoring and gates; Chapter 12 acceptance and publication flow.
• Core.Threads: TS.* metrics, hb, bp, and execution-graph constraints.
• Core.DataSpec: schema versions, manifest fields, and ingestion policy.
• Core.Metrology: spectral estimation S_xx(f), U_w, ENBW, and uncertainty gauges.

IX. Risks, Limits, and Open Questions

• Risks
  Implicit defaults not captured in ParamCard (shadow configurations); container entrypoints overriding card fields; secondary parsing of external data breaking hash(•) verifiability.
• Limits
  Some hardware features (e.g., denorm handling, atomic order) cannot be fully expressed at the card layer; defer to EnvLock details.
• Open questions
  Cross-domain calibration of risk_index and learning adaptive weights; hierarchical inheritance and conflict-merge strategies for ParamCard; normalized expression of dual T_arr gauges along multi-medium composite paths.

X. Deliverables and Versioning

1. Artifacts
   pipeline.card.json, param.card.json, impact.report.json, run.plan.json, signature bundle, and fingerprint index.
2. Versions and channels
   • schema.version follows MAJOR.MINOR.PATCH; MAJOR changes must ship a migration script and dual-run comparison.
   • Releases follow canary → stable → LTS; any failed gate reverts to the previous stable version and triggers Mx-40 re-verification.
3. Audit and archiving
   Cards and signatures, manifests, and scoring reports must be ingested together, preserving created.ts, release.channel, reviewers, and signature. For cards declaring T_arr, delta_form and the path gamma(ell) with d ell are mandatory publications.