Skip to content

alt text

AI/ML Project Naming Conventions

Introduction

Picking a suitable name for a project or related resource is sometimes the hardest part of building it. It may seem like there are infinite options, but are restricted by a few guidelines we tend to follow.

Warning

Try to follow the convention down to the punctuation! This includes the use of dashes (-) vs. underscores (_), e.g. your_project_name vs. your-project-name. Spaces are HIGHLY discouraged as they can cause unexpected behavior in lists.

Project names are always at the discretion of leadership. Names should be relevant to what the application is attempting to do, but not explain everything about it. For example, Spotlight is intended to "shine a light" on important information contained within large volumes of text. But the project isn't called "shine-a-light-on-large-text-blobs" or even an initialism of that (SALOLTB?) because it would be too hard to say each time. Spotlight is short, catchy, and relevant.

In the case where explaining the project in the name is needed, try to use an acronym or initialism of 5 or fewer letters where possible. We have two such projects currently that follow such a scheme:

  • Discrete Event Simulation (DES, pronounced "dee, ee, es")
  • Left Without Being Seen (LWBS, pronounced "el, double-u, bee, es")

An acronym is generally preferred so that it is easier to pronounce. See here for the difference between an acronym (NASA, pronounced "na-suh") vs. an initialism (DES, pronounced "dee, ee, es").

We only use letters such as a-z, A-Z, and numbers 0-9. Symbols and emojis are not allowed.

Name collision with other projects is inevitable, but we have a specific committee dedicated towards resolving these issues. Consultation with this committee is required for any project intended to be released to the wider CNH population. Generally, the first project to claim a name will keep it, even if more relevant projects to a name come up in the future.

Azure Resources

Azure resources have strict title length restrictions. It tends to vary by resource, but is generally between 24-32 characters. This makes it difficult to fit long project names into the set length.

There are a two boilerplate name components that must be included for every resource name. This is a requirement from our network and security team.

  • Environment = ["devtest"/"dev", "poc", "prod"]
  • Team = "aiml"

If the project name is too long, you may cut parts of the name starting from the bottom of the above list. Do NOT cut off parts of each terms (like "ai" instead of "aiml"). The only term that can be abbreviated is "devtest", for which you may use "dev" to save 4 characters.

It is also good to add the term "cnh" in the name for the resource for global Azure uniqueness where necessary, but it can be left off otherwise. An example might be for Key Vaults, which must have unique names across all of Azure. Including cnh helps distinguish that it's our resource.

Each Azure resource has a recommended abbreviation for the relevant resource. The abbreviation for the resource should always prepend the rest of the name.

Generally Azure resources will follow the following format: {resource-abbr}-cnh-aiml-{your-project-name}-dev. If the project name is ever left off, it means the resource is available to the entirety of the AI/ML team and treated as a global resource. A few examples for specific resources follow:

Container Apps, Jobs, Environments, and Instances

Template (App): ca-aiml-{your-project-name}-dev

Ex. ca-aiml-des-dev, ca-aiml-spotlight-api-dev

Template (Job): caj-aiml-{your-project-name}-dev

Ex. caj-aiml-lwbs-dev

Template (Environment): cae-aiml-{your-project-name}-dev

Ex. cae-aiml-dev

Template (Instance): ci-aiml-{your-project-name}-dev

Ex. ci-aiml-des-dev

Keep in mind that there is a 32-character limit for container apps. Without all the boilerplate name components (21 characters), this only leaves about 10-11 characters in which to fit your project name. Either abbreviate your project name or remove boilerplate as described in the section above.

Private Endpoints and Network Interfaces (NICs)

Template (Private Endpoint): pe-{resource-impacted}-aiml-{your-project-name}-dev

Ex. pe-kv-aiml-eus2-devtest, pe-oai-aiml-eus2-devtest

Template (NICs): nic-pe-aiml-{resource-impacted}-{your-project-name}-dev

Ex. nic-pe-kv-aiml-dev, nic-pe-oai-aiml-dev

Ensure you are setting the NIC to have this custom name when going through Azure Portal to create a private endpoint!

Key Vaults

Template: kv-aiml-{your-project-name}-dev

Ex. kv-cnh-aiml-dev
The maximum length for a Key Vault name is 24 characters. Without all the boilerplate name components (12-16 characters), this only leaves 8-12 characters for your project. Either abbreviate your project name or use an existing Key Vault to store keys, such as the one we have provisioned for the overall AI/ML group. If absolutely necessary, you may use a number extended to three digits (e.g. 003, 004, 112) instead of the project name as long as this is clearly documented and communicated.

Key Vault names must be globally unique across all of Azure. If it helps to include some of the boilerplate name components to make a name unique, try to do so.

Key Vault Secrets

Template: {resource-impacted}-{your-project-name}-{secret-name}

Ex. gh-private-runner-pat is the name for the PAT stored for the GitHub private runners project.

AI Foundries

Template: aif-aiml-{your-project-name}-dev

Ex. aif-aiml-dev

Tagging Azure Resources

Azure resources should be tagged with the following:

  • costcenter: 21840
  • managed_by: [pulumi if using Infrastructure as Code, {admin-username}@cnmc.org if deployed manually]
  • environment: [one of devtest, poc, or prod]
  • location: eastus2

Container Images

Containers are defined by a combination of an image name and tag. This tag should refer to one of the following from this list in order of priority:

  • Version Number: (Ex. v1.0.14, v0.0.1). See our version numbering doc for more information.
  • "latest": (If it contains the most recent updates, usually synonymous with "devtest" or "dev")
  • Environment: one of ["staging", or "prod"] if it is meant to be deployed in a specific environment. Note that "latest" is preferred over using "dev"
  • GitHub SHA: the randomly generated hex string provided by GitHub for the commit that produced the container image artifact
  • Datetime stamp: Using the Year, Month, Day, Hour, Minute, and Second separated by dashes (Ex. 2025-12-18-14-04-34)

Tags should not be combined. Only one of each tag should exist in a given container registry. Pushing a new image with the same tag will overwrite the previous image!

Template {your-project-name}:{tag}

Ex. spotlight-backend:v1.0.14, lwbs-ops-forecasting:latest

Databricks Resources

Catalogs

We are normally restricted to use of only the following schemas: devtest_team_aiml, qa_team_aiml, and prod_team_aiml. However, in the case where additional catalogs are created for your project, consult the Enterprise Data Platform team regarding what names are allowed. It is more than likely you will use the following template:

Template: {environment}_team_{your_project_name}

Ex. prod_team_criticality_index

Schemas

Schemas should be named after the project in question.

Template: {your_project_name}

Ex. beacon, missed_care_opportunities

All resources in a given schema should be named consistently. This applies to Tables, Volumes, Models, and Functions.

Tables

Template: {your_project_name}_{table_purpose}_{environment}

Ex. beacon_contentchunks_compliance_prod

Volumes

Template: {your_project_name}_{volume_purpose}_{environment}

Ex. beacon_docvolume_compliance_devtest

Models

Template: {your_project_name}_{model_purpose}_{environment}

Ex. beacon_npg_dev

Functions

Template: {your_project_name}_{function_purpose}_{environment}

Ex. beacon_fetch_documents_api_call_dev

Git Repos

Git repos are commonly used to hold code and other programming artifacts.

Template: edp-ai-{your-project-name}

Ex.

There are existing repos that don't follow this convention:

Ex.