06 Part-keyed parameters, continuous tuning and plant changes

1. One twin, parameters per context#

Context key: line; part (raw SCADA part name through a part-alias table); alloy; billet supplier or lot; die; heat-treatment recipe. Missing fields fall back through inheritance: part → part family → alloy → default prior, each with its uncertainty.

Group	Examples	Tuned by Stamped?
Heater	Coil efficiency, heat loss, billet mass and heat capacity, pyrometer offset, lag	Yes
Flow and press	Normal transfer time, cooling in transfer, force median and spread, first-parts count	Yes
Part-risk thresholds	Cold-edge band, slow transfer, force deviation, run size	Yes, always reviewed by the Stamped team
Heat treatment	Load response, quench heat-transfer curve, tank cooling, ageing constants	Yes, with strength results
Plant limits	Temperature windows, sort limits, written heat-treatment limits	No. The plant's own values

Rows are versioned in L2 (baselines.param_row) with source, date, data volume and confidence, signed and cached on the Plant Box, loaded at every part change, and stamped on every record.

2. Context lifecycle#

Param context lifecycle

How to read it.

Unknown part or context enters Learning; Candidate waits for Stamped approval while the switch is on.
Known rows re-validate on plant change or drift; Retired parts skip alerts until they return.
Writes stay off in Learning and Revalidate until refit passes.

Build now: Learning and Known with manual promotion. Later: auto-promote when require_internal_approval_new_part is off.

View Mermaid source

flowchart TB
    %% house-style: param-context-lifecycle
    subgraph states["Context states"]
        direction LR
        learn["Learning"] --> cand["Candidate"]
        cand --> appr["Approved"]
        cand --> learn
        appr --> known["Known"]
        known --> rev["Revalidate"]
        appr --> rev
        rev --> known
        rev --> learn
        known --> ret["Retired"]
        ret --> rev
    end
    gate{{"Confidence gate and replay"}}
    learn --> gate --> cand
    appr --> gate2{{"Probation passed"}} --> known

    classDef govc fill:#fff4d6,stroke:#c99a2e,color:#000
    classDef agentc fill:#e8f0ff,stroke:#5b7bd5,color:#000
    classDef loopc fill:#eef7ee,stroke:#4f9a4f,color:#000
    class gate,gate2 govc

State	Alerts	Actions and signals	Writes
Learning	Part-independent only	Line-level stop and start signals only	None
Candidate	Part-independent; part-specific in shadow	Part-specific in shadow, for the approval review	None
Approved (probation)	All	All, within stage gates	Confirmed writes only
Known	All	All	As the tag's stage allows
Re-validate	Part-independent; part-specific marked lower confidence	From the last approved row, marked lower confidence	None until refit passes
Retired	—	—	—

3. New-part flow#

Detect an unknown part name or a part without a row; enter Learning.
Show it on the L5 staff console and message the Stamped admin.
Learn online from the family or alloy prior with wide uncertainty; moving-horizon fit over the first runs.
Confidence gate (starting values, confirmed by replay): minimum pushes over several runs; 90% interval coverage of 85–95% on a held-out run; error no worse than the family prior (D14 DECIDED).
Propose the candidate row with its evidence and shadow recommendations.
While require_internal_approval_new_part = true (default), a named Stamped team member approves; the approval is a promotion record.
Promote; recommendations start under probation.

Turning the switch off is a recorded decision; candidates passing the gate and replay then promote automatically, still with a record and probation.

4. Continuous tuning#

Nightly refit for every context that ran recently.
Replay tests in intelligence-evals on recent and long history: not worse on error, coverage within band, no role pushed over its message budget.
Bounded change per parameter: inside bounds and passing replay promotes automatically; outside goes to the Stamped team.
Always reviewed: part-risk thresholds and any row for an AL3 tag.
Every change is a promotion record with one-step rollback.
Weekly drift report per context.

Model code goes through normal CI with reference tests; parameter rows go through this pipeline. Neither bypasses the other.

5. Feedback that tunes#

Follow-through outcomes (procedure fit, ranking), register-matched rejects (part-risk thresholds), strength results (quench and ageing calibration), operator replies (procedure fit, stop reasons), contact-probe checks (pyrometer offset).

6. Plant change catalog#

Change	Detected by	Response
New part	Name not in alias table or no row	Learning; console notice and admin message
Alloy, supplier or lot change	Job card if digital; heating response shift	Re-validate affected parts; ask the plant to confirm
Die change	Job card; force level step	Widen first-parts flag; re-learn force; no press writes until settled
Heater maintenance or coil change	Maintenance record, long stop, efficiency step	Re-validate heater; setpoint writes off until refit passes
Pyrometer replaced or recalibrated	Step at constant power	Reset offset; Re-validate; ask for a contact-probe check
Heater controller retune	Changed step response	Re-validate; writer re-checks limits on site
Recipe or written limits changed	Recipe tag or new limit entered by the plant	Update plant-owned limits; Re-validate heat-treatment rows
SCADA tags renamed or added	Tag mapping validation	Readings missing; state uncertain; admin maps tags; writes off for those tags
PLC program changed	Checksum or tag map change	Writer off; repeat site checks
Seasonal ambient or mains drift	Slow parameter drift	Nightly refit within bounds
New crew or shift pattern	Roster change	Watch follow-through and load per shift; re-accept procedures if the in-charge changes
Holidays and maintenance days	Plant calendar; no counters	Twin idle; excluded from refits and baselines
Mixed parts in one basket	Job card or several parts in the window	Record lists all parts; predictions use the most at-risk part
Partial data days	Completeness checks	Excluded from refits and acceptance measures; never counted as missed actions

7. Admin controls on the L5 staff console#

Pages for new parts (map aliases, assign families), candidates (approve or reject while the switch is on), drift (start a refit), settings (the switch and the bounds, changed with a reason) and history (promotion records, rollback). Every action records the person and the reason.