Designing Stable Run Identifiers

Why Run Identifiers Need a Design

A run identifier is often the first thing a team sees when locating or discussing a model fit. A name such as final2 may be short, but it does not say what model, data, or estimation settings it refers to. A name based only on the time of execution can distinguish some executions, but it does not explain what differs scientifically or computationally. A useful identifier should be stable, interpretable, and specific enough to separate runs that are meaningfully different.

Here, a model run means an execution of a specified model against specified inputs and analysis settings. The identifier design problem is to decide which features define a distinct run for the work at hand, and then encode those features consistently. The identifier is not a summary of whether the run succeeded, what estimates it produced, or when it happened.

This definition depends on a deliberate choice of identity fields. Stability does not mean that a name somehow captures every detail of a computation. It means the chosen fields and their formatting rules are explicit. If two datasets have different contents but are both called data.csv, a name that records only the filename cannot distinguish them. Stable naming therefore requires stable labels or versions for the model, data, and settings being identified.

Choose the Identity Before the Name

Start by deciding which differences matter for the scientific or computational question. In a typical estimation workflow, candidate identity fields might include a project or study label, a model version, a data version, the estimation method and important options, and a random seed when the seed defines a distinct stochastic replicate. Include fields when changing them should make the run a different candidate for review or comparison. Exclude fields that are incidental to the run's definition, such as the machine that happened to execute it, a display label, or the time it started.

The correct set is purpose-dependent. If a run is intended to reproduce a particular stochastic computation, the seed is often essential. If the computation is deterministic under the specified inputs and settings, adding an arbitrary seed field can imply a distinction that has no effect. Similarly, a model version should change when a model change is intended to define a new candidate; a cosmetic filename change need not create a new model identity if the content and versioning policy say otherwise.

A useful design separates run specification from execution occurrence. The specification describes the model, inputs, and settings. Re-running the same specification can therefore retain the same stable identifier. If a workflow also needs to tell separate execution attempts apart, that is a different identity problem and should not be solved by silently changing the specification identifier. A timestamp can be recorded as an execution detail, but it is not a substitute for specifying what was run.

Constructing a Readable Identifier

Use labeled fields rather than concatenating unexplained fragments. A grammar such as study=...|model=...|data=...|analysis=...|seed=... makes the role of each value visible. Choose a fixed field order, fixed separators, and a defined character policy. For example, a team could require lowercase ASCII letters, digits, and hyphens within values; use a reserved separator between labeled fields; and replace spaces consistently. If values can contain the separator, either escape it by a documented rule or prohibit it in field values. These choices prevent two different field combinations from being rendered as the same string.

Canonicalization is the process of converting equivalent input representations to one standard form before constructing the identifier. A rule might convert all field names and permitted text values to lowercase, trim leading and trailing spaces, and represent a missing value with an explicit token such as none. The rule must be applied consistently. Otherwise, for instance, FOCE and foce might generate different names despite being intended to mean the same setting, or a blank field might be confused with an omitted field.

Keep labels human-readable without relying on local shorthand that another analyst could interpret differently. If a method has a standard unambiguous name, use it or define a consistent short code in the naming convention. A compact code such as est1 is not informative unless its meaning is stable and documented. Shortening is useful only when it preserves unambiguous distinctions.

Why the Naming Rule Must Be Unambiguous

The central correctness requirement can be stated precisely. Let \(K\) be the ordered collection of fields selected to define a run, and let \(g(K)\) be the string produced by the naming rule. The rule is adequate over a set of intended runs if distinct run specifications in that set map to distinct identifiers. In other words, for any two specifications \(K_1\) and \(K_2\), if the workflow considers them different, then \(g(K_1)\ne g(K_2)\).

This condition is sometimes called injectivity over the intended scope. It explains why the choice of fields matters more than a decorative format. If the model version is omitted, two runs with different model versions can have the same name. If separators are not handled consistently, different values can also collapse to the same string.

For example, suppose an unsafe rule simply joins two values with a hyphen. The pairs (a-b, c) and (a, b-c) both become a-b-c. The formatting loses information even though both fields were nominally included. A labeled, delimited format with a restriction or escaping rule avoids this ambiguity.

Replicates, Mutable Results, and Alternatives

When stochastic computations are intentionally replicated, the seed can be part of the identity fields. Suppose the same model, data, and estimation settings are run with seeds 104729 and 104759. If those seeds define distinct planned replicates, the identifiers should differ at the seed field. Conversely, if an execution is merely repeated with the same seed and all other fields unchanged, it has the same specification identifier. The identifier alone should not be asked to distinguish separate attempts of that identical specification.

Some common alternatives are useful in limited roles, but each has a trade-off.

A digest can be used as a supplementary check or compact suffix, but it does not replace the need to define the run identity. If a readable name omits a scientifically important setting, appending a digest without explaining its inputs does not tell a reader what that distinction means.

Diagnostics and Common Failure Modes

Before adopting a naming convention, test it with pairs of specifications that should and should not have different identifiers. Change one field at a time: the model version, data version, estimation method, an important option, and the seed when relevant. Confirm that every intended distinction changes the name. Then submit equivalent values in different surface forms, such as uppercase and lowercase method labels or values with surrounding spaces, and verify that the canonicalization rule behaves as intended.

A practical review should also check for ambiguous abbreviations, missing-value conventions, delimiter handling, and overly long names that are likely to be manually truncated. If long names are unavoidable, keep the essential fields visible and use a consistent scheme rather than dropping fields ad hoc. An identifier that is truncated differently in two systems can lose the very distinction it was designed to preserve.

• Ambiguous labels: A name such as m3-d1-e2 is not self-explanatory unless each code has one stable meaning. Use explicit labels or a rigorously maintained code convention.
• Omitted versions: A model filename or dataset filename can be reused. Include a version or another stable distinction that changes when the relevant content changes.
• Unstable formatting: Different field order, case, or missing-value representation can give the same specification multiple names. Fix the order and canonicalization rules.
• Mutable outcome fields: Do not make the identifier depend on convergence status, objective-function value, or estimated parameters. These are results of execution, not inputs defining the intended specification, and may be unknown when the run is named.
• Timestamp collisions: Do not assume a timestamp string is unique. Its distinguishing power is limited by the values actually recorded and their resolution.

A useful naming convention is not necessarily the shortest possible string. It is a rule that analysts can apply consistently and that makes the intended differences inspectable without changing the name merely because the run was launched at a different time or produced a different outcome.