AI Model Naming and Identifier Systems: From Product Names to Engineering Standards

1. Why Naming Is an Engineering Problem

A model name may appear only once at a launch event, but it recurs throughout engineering systems. It enters API request parameters, configuration files, log fields, monitoring labels, billing details, and operational documentation. When a name is vague or arbitrary, these problems are amplified: the same identifier points to different versions across teams, alerts cannot be attributed, and the corresponding weight files cannot be found during rollback.

Many names are chosen under time pressure. If a temporary placeholder is never replaced, it remains in the system for a long time. Treating a temporary decision as a formal contract is the most common source of naming chaos.

2. Split the Name into Three Layers

It is recommended to split a “name” into three layers, each with a different responsibility.

1. Display name: user- and market-facing; easy to remember and distinctive, and may carry emotional associations.
2. Product-line identifier: describes the model family and is used for categorization and documentation navigation; medium stability requirements.
3. Technical identifier: used in code, APIs, configuration, and logs; must be structured, parseable, and stable over the long term.

Once the three layers are separated, display names can change with market needs while technical identifiers remain stable. Using a display name directly as a technical identifier is the starting point for most confusion.

3. Design Principles for Technical Identifiers

• Unique: within the entire registry, the same identifier points to exactly one model version.
• Parseable: a fixed structure allows programs to split out each field without ambiguity.
• Immutable: a published identifier must not change meaning; corrections can only be made through a new version number.
• Language-neutral: avoid puns, nicknames, or wordplay. Such names mean different things to people with different language backgrounds and are hard to search in logs.
• Restricted character set: use only lowercase letters, digits, and hyphens to avoid matching errors caused by case and special characters.
• Avoid common words: if an identifier overlaps with an ordinary noun, full-text search will produce a lot of noise.

The example below uses the structure “family-size-variant-version” and validates it with a regular expression.

import re
from dataclasses import dataclass
MODEL_ID_PATTERN = re.compile(
    r"^(?P<family>[a-z][a-z0-9]{1,15})"
    r"-(?P<size>\d+(?:\.\d+)?[bm])"
    r"-(?P<variant>base|chat|instruct|vision)"
    r"-v(?P<major>\d+)\.(?P<minor>\d+)$"
)
@dataclass(frozen=True)
class ModelId:
    family: str
    size: str
    variant: str
    major: int
    minor: int
    def __str__(self) -> str:
        return f"{self.family}-{self.size}-{self.variant}-v{self.major}.{self.minor}"
def parse_model_id(raw: str) -> ModelId:
    match = MODEL_ID_PATTERN.fullmatch(raw.strip().lower())
    if match is None:
        raise ValueError(f"Model ID does not conform to the specification: {raw!r}")
    g = match.groupdict()
    return ModelId(
        family=g["family"],
        size=g["size"],
        variant=g["variant"],
        major=int(g["major"]),
        minor=int(g["minor"]),
    )
if __name__ == "__main__":
    print(parse_model_id("demo7-7b-chat-v2.1"))
    # Output: demo7-7b-chat-v2.1

The parsing function applies strip() and lower() at the entry point, then performs a full match. Inputs that do not meet the rules raise an exception directly and do not enter the configuration system in an ambiguous form.

4. Version Number Semantics

Version numbers should express the impact of a change on callers, not merely the order of releases.

Change type	Version component	Example
Input or output structure incompatibility	Major version	v1.x → v2.0
Interface semantics change requiring callers to adjust parameters	Major version	v2.x → v3.0
Capability improvements or weight updates under the same interface	Minor version	v