10 Best Practices: Defining Attributes for Robust Model Governance

Modern model-governance platforms such as MRM Vault live or die by the quality of the data you feed them. When attributes are thoughtfully defined, a model can be traced right from its birth through every risk checkpoint, validation test, and business decision it influences. Poorly designed attributes, on the other hand, leave regulators frustrated, owners guessing, and audit teams piecing together half-truths.

The following 10 principles offer a clear framework to guide stakeholders in designing meaningful and functional attributes - helping ensure that every input and output tied to a model can be interpreted, traced, and acted upon across its lifecycle.

Start with a clear Naming Convention: A good name should describe the purpose of the attribute. For example, "Model Use Case" clearly defines what is the business use case of the model that is to be built. A clear and consistent name helps prevent duplication and confusion by ensuring intuitive identification across the model inventory.
Use Unique Identifiers (Primary Keys): Each model should have a unique ID that distinguishes it from others - much like an employee ID or serial number. This allows systems like MRM Vault to cross-reference models and link related processes or artifacts efficiently.‍
Define the Attribute Type (Global, Local, or System): Define the type of attribute based on its scope and origin - whether it applies across the entire model inventory, is specific to a particular model or subprocess, or is automatically generated by the MRM Vault system:
1. Global attribute: Global attributes are variables that apply across the entire model inventory, ensuring uniformity in terms of recording information.
2. Local attribute: Attributes that are configured inside templates are called local attributes, as they are specific only to models created using those templates, whereas global attributes are available across the model inventory.
3. System attributes: Automatically generated by the system to support workflows and processes, these do not require manual configuration.
Specify the Data Type: Each attribute must have a defined data type - whether it's text, dropdown, number, date, or a multi-select option. This determines how it’s captured, validated, and displayed. For instance, “Validation Date” should use a date field, while “Model Owner” might be a dropdown tied to user roles.
Identify Required Information First: List all the information you want to track - such as model purpose, developer name, source system, or validation outcome - before building the structure. This helps avoid missing critical fields later.
Grouping: Arranging attributes in the logical sequence: Organize related attributes under logical tables or sections - like Model Metadata, Risk Details, Validation Metrics, etc. Grouping improves navigation and makes forms or reports easier to interpret.‍
Attribute Access Management: It is very important to control the attribute access and its editing rights. Not all attributes should be editable to everyone. Assign roles for who can edit certain attributes - for example, only Model Risk Officers or Model Validators might be allowed to update the “Risk Tier” field.
Categorization of model: Include attributes that help classify models - by business unit, model family, regulatory use, or complexity. This supports downstream analytics, monitoring, and reporting.
Define attribute relationship: Connecting attributes that show cause and effect - like linking a "Change Reason" to a "Version Number"- adds depth to your model data. These relationships turn static fields into a meaningful story, making it easier to trace model evolution and usage. For example, the same model might serve different use cases. A well-designed onboarding form captures its type, and once that’s known, it becomes easier to map related processes and connect all the right data points across the model’s lifecycle.
Conceal sensitive information: Use visibility controls to hide or unhide fields depending on the stakeholder or stage. For example, during external audits, certain internal-only notes may be hidden while key risk metrics remain visible.