Reproducible training turns experiments into auditable candidates

The AI lifecycle standard describes processes for managing AI systems and explicitly covers acquisition as well as development. GFT's proposed registry translates lifecycle control into named candidate states. The state names below are a factory design choice; they are not a certification claim or a prescribed state machine taken from the standard.[S13]

Candidate means the bundle has been registered, including known gaps. Validated means the agreed checks passed for a stated scope, with the evidence linked. Approved means the authorised owner accepted a particular scope and set of conditions. Deployed means that an identified operating endpoint has confirmed that version is active. Suspended means use is halted while the record is retained. Retired means the candidate is withdrawn from further authorised use, subject to the retention policy. GFT recommends recording rejection as a decision outcome against a candidate, rather than erasing the candidate itself.

Keep release readiness distinct from active use. An approval record should specify the candidate digest, permitted line or planning process, conditions, approver and effective window. A deployment record should identify the actual service, device or batch job and confirm its loaded wrapper and configuration. An approved model can have no deployment, and a deployment may fail to activate the approved bundle. Until endpoint confirmation exists, report the state that is evidenced. Do not infer production status from a registry label alone.

For a small factory, GFT proposes a current-state table backed by an append-only transition history. Every transition records the prior state, new state, reason, actor, time and supporting evidence. Corrections append a resolving entry instead of rewriting the original decision. The technical custodian protects storage and access; the operating owner controls scope and acceptance. Where a person holds overlapping roles, record the arrangement and obtain the review required by the consequence of the intended use. The next chapter defines release scrutiny in detail.

The model-record fields in Exhibit 45 are a derived design checklist. Their inputs are lifecycle control, provenance, data-quality management, indicator definition and human judgement over thresholds. Mapping each principle to an inspectable record does not establish that a candidate already satisfies it.[S04][S09][S11][S13][S38]

Retention is part of the model record. GFT recommends recording whether worker-level information is present, where restricted evidence is held and who may access it. Do not copy personal records into an unrestricted registry to make lineage convenient. Preserve the minimum permitted evidence needed to explain decisions, and link to controlled material where appropriate. If deletion or contractual limits prevent later reconstruction, record what can no longer be reproduced and reassess continued use. Legal applicability and retention periods require qualified advice; this chapter supplies an engineering record design, not legal advice.

Microsoft's maturity model recommends gradual capability development and describes both organisational and technical dimensions. GFT uses that advice to separate necessary evidence from optional automation. A factory should choose software only after defining which recurring record or decision it must sustain.[S16]

The proposed starting stack comprises version control for code and definitions, controlled storage for snapshots and artefacts, a structured run log and a registry with transition history. These are capabilities, not a mandatory procurement list. A disciplined directory structure and validated structured files may initially provide several capabilities together. Give the custodian a documented export and restoration procedure. If a platform is adopted later, preserve the identifiers and relationships so historical candidates remain intelligible outside its interface.

Plain portable records need an explicit schema. GFT recommends mandatory fields for identity, parent identity, record type, creation time, responsible role, content location, digest and access classification. Domain-specific records then add partitions, metrics or approval conditions. State the schema version in every export. Validate references before accepting an import and flag a missing dependency rather than dropping it silently. A portable model file without its label mapping, feature contract or evaluation keys is an incomplete transfer under this proposed protocol.

Make recovery part of the reconstruction exercise. Ask a colleague to start from an approved identifier on a clean permitted environment, retrieve the package, verify integrity and rerun its evaluation. Record missing instructions, inaccessible files and unexpected manual choices. The colleague need not repeat a costly full training job every time to reveal a broken evidence chain. Define when training reruns are warranted, such as an unexplained result difference or material environment change, and distinguish that exercise from rescoring the stored artefact.

Automation should remove repeated transcription and enforce declared rules. GFT recommends beginning with manifest generation, reference validation and automatic capture of actual run inputs. Leave disputed operational meaning and acceptance with the responsible people. A scheduler can repeat a mistaken query more efficiently; it cannot resolve who owns the definition. Similarly, an automatic registry update should not transform completion of training into approval. Record the automation's own version because it participates in the evidence chain it creates.

The factory should also define an exception route. If an urgent investigation uses an incomplete experimental package, label it exploratory and prohibit it from acquiring release status through convenience. Assign an owner and a clear condition for completing or abandoning the record. Preserve whatever learning is reusable without presenting the investigation as an accepted candidate. This keeps the system workable during operational pressure while retaining a meaningful distinction between exploratory work and evidence suitable for a release decision.

Close the reconstruction exercise with an evidence receipt. GFT proposes a short record stating who attempted it, which package and environment they used, what they could retrieve, which checks they executed and what remains unresolved. Record whether they rescored a stored artefact, rebuilt the wrapper or repeated training, because those exercises support different claims. The receipt gives the release reviewer a bounded statement of work actually performed. It should never be titled independent validation unless the assigned reviewer also performed the separate validation work.

Acquiring a model changes which evidence the factory can obtain, but does not remove lifecycle responsibility. The AI lifecycle standard's public abstract explicitly includes acquired systems. GFT therefore recommends applying the same candidate identity and local evaluation discipline to a bought model while recording the limits of access to its internal development process.[S13]

For a bought inspection system, record supplier, product, model identifier, wrapper version, input requirements, class mapping, licence terms and update channel. Preserve the documentation version supplied with the product and distinguish supplier claims from locally observed results. Record whether training data, training code and weights are accessible. Unknown should remain unknown. Do not infer local reproducibility from a vendor's training claim or describe a local test as independent reconstruction of an inaccessible training pipeline.

The procurement requirement should specify notification of material changes and the evidence needed for revalidation. GFT recommends defining materiality to include preprocessing, defect taxonomy, thresholds, model weights and the service contract that determines outputs. Where an update cannot be pinned, log the provider's available version markers and dates, then describe the remaining uncertainty. An endpoint name that stays constant while behaviour changes is not sufficient candidate identity for the proposed protocol. The owner must decide whether that uncertainty is tolerable for the intended decision.

Keep the locally used configuration inside the package. A purchased model may still be tuned through thresholds, calibration, prompts or operating recipes. Preserve those inputs and any local adaptation data with their rights and lineage. A tuned derivative gets a new identity linked to its supplier base. GFT recommends running the same fixed local evaluation on the actual delivered interface, including its preprocessing and abstention behaviour. This tests the system the factory will receive rather than a selectively exported component.

Agree an exit route before dependency becomes difficult to reverse. Where rights permit, retain the last approved local artefact and the environment required to read it. Where a remote licence or service prevents that, document the feasible fallback, including a return to the approved manual procedure. Do not promise recovery of a supplier service the factory cannot restore. Link the fallback evidence to the candidate record; the following chapter addresses the operational rehearsal and authority needed before release.

The handover should expose contractual dependencies alongside technical ones. GFT recommends recording whether access to historical predictions, model versions or evaluation exports ends when a subscription lapses. Obtain an export before that boundary and verify that its identifiers still resolve to the retained local evidence. If a service cannot provide the evidence required for the intended use, the owner can narrow the scope, negotiate a different arrangement or decline the candidate. Recording that constraint early protects the factory from mistaking a convenient interface for a controllable operating asset.

GFT's programme sequence connects early bought vision and later history-dependent forecasting through the same record discipline. This chapter proposes that common discipline; it does not claim either system has been trained, validated or deployed by GFT. The practical distinction is evidence availability. A bought system may offer limited training visibility but still needs a traceable local test. A locally trained forecaster must preserve its historical information boundary as well as its code. Both hand the release reviewer an identifiable artefact, an explicit scope and an honest account of what remains unknown.