Da-M-I-C-Us

A classification framework for AI solutions

Version 1.0 Draft 2· September 2026

Da-M-I-C-Us classifies AI solutions along five dimensions: Data, Model, Infrastructure, Code and Use,  so that an organisation can describe any AI capability precisely and state which classes it permits for its own operations, its partners and its vendors. The framework separates what a solution intrinsically is from how a given organisation deploys it and provides a catalogue of common classification classes and common policy classes covering the everyday adoption scenarios.

Visual Effects Society · Technology Committee
Michele Sciolette, …

1   Motivation

The lack of a suitable classification of AI solutions is a barrier to responsible adoption in a corporate environment.

The term “AI” is regularly used to reference an incredibly broad range of solutions: from narrow AI tools developed in-house, trained exclusively on corporate internal data and running on infrastructure the organisation controls, to large generative models trained on web-scale datasets and consumed as multi-tenant cloud services. Policies written at the level of “AI”, “Gen AI” or “machine learning” cannot distinguish between these, so they either over-block or under-protect.

Blanket contractual clauses such as “no AI use is permitted on this project”, and reporting requirements such as “declare any use of AI”, are no longer meaningful: AI capabilities are now embedded inside everyday tools, often without the end user’s awareness. What organisations need to express is which classes of AI capability are acceptable, and for which purposes.

Da-M-I-C-Us has two objectives:

•    Classify AI solutions based on key criteria that are relevant to adoption in a corporate context, describing these classes with compact, unambiguous codes

•    Define policies  outlining which classes of AI solutions are acceptable for an organization’s internal operations, partners and collaborators

2   Inspiration

This work is loosely inspired by the Creative Commons’ CC licenses. Their copyright licenses not only identify all the key criteria that are important for copyright holders and end users, but also associate them with clear definitions and codes, making them easy to understand and remember. These basic elements are combined to identify well defined copyright license types.

3   The framework at a glance

The core idea of Da-M-I-C-Us  is that classifying an AI solution requires us to identify where it is positioned in the broad space of all AI solutions, referencing the criteria that are relevant to adoption within an organisation. To achieve this, we:

• define a set of key criteria, or dimensions, that should be considered when assessing an AI solution
• for each dimension, define a set of options, or positions, identified by simple, easy-to-remember codes.

Combining these two elements, each solution is classified by stating its position for each dimension and each policy is defined by stating which positions are permitted for each dimension.

Modern products often bundle many AI capabilities. In that case, the classification should be applied to each individual capability and potentially be combined to classify more complex solutions.

Da-M-I-C-Us  defines five dimensions, Data, Model, Infrastructure, Code and Use. Each one of them defines one of the key aspects that should be considered when assessing a solution: which data was used to train the system? Who owns the models and what restrictions are in place? Where is the data processed during inference? Who owns the relevant code and what restrictions are in place? What is the solution used for?

For each dimension Da-M-I-C-Us defines a small set of options, identified by a unique two letters code.

Intrinsic dimensions and the deployment dimension
The five dimensions are not all of the same kind. Data, Model and Code, and usually Infrastructure, are intrinsic: they are fixed by how a solution is built and distributed, so a vendor or analyst can state them without knowing who will use the tool and how. Use is different in kind: it is a deployment property that records how a particular organisation applies the solution rather than anything inherent to it. Infrastructure can fall on either side: certain solutions are only available via one infrastructure model, while others, mostly when the weights are portable, can be deployed using different infrastructure models. The dividing line is whether a dimension can be stated from the solution alone (Data, Model, Code, and usually Infrastructure) or only once its use is known (Use, and sometimes Infrastructure).

Classifications and Policies
With this in mind, the framework supports three types of statements:

• Solution Classification: the intrinsic dimensions only (Data, Model, Infrastructure, Code), with Use left unset. It records what a solution is. The vendor of the solution may publish the string of the codes representing the positioning of the solution
• Deployment Classification: a solution classification with the Use value added, describing how a specific organisation adopts it
• Policy: the set of classifications an organisation permits. Unlike a classification, which fixes one option per dimension, a policy is normative and may list alternatives or use wildcards

On this foundation the Da-M-I-C-Us framework also defines common classes, given descriptive names so that they can be identified quickly.  A successful adoption of this framework would result in the common classes defined in section 8 and 9 to become generally well understood and adopted for classifications and policies.

3.1 Icon scheme

The icons used in the document below are color coded to mean the following:

4   The five core dimensions

The Data dimension captures the rights status of the data used to train the model(s), which drives copyright and provenance risk in the outputs.

Fine-tuning and retrieval. A capability built on a foundation model and adapted with additional data is a composite: write the base first, then the adaptation, joined by “+”. A vendor model of undisclosed provenance fine-tuned on studio data is UD+PD.

The Model dimension captures who holds the weights and under what terms they may be used. The four options are mutually exclusive.

The Infrastructure dimension captures who controls the security boundary at inference time. Where weights are portable, the adopter chooses this value; where the solution is distribution-locked (a closed-weights service), the vendor fixes it.

The Code dimension captures the rights attached to the software implementing the capability. This is particularly relevant given the research practice of publishing reference implementations with unclear or restrictive licences.

The Use dimension is different in kind from the other four: it is a property of how an organisation deploys a capability, not of the capability itself. A vendor cannot state it; only the adopting organisation can. It is therefore absent from a capability classification and present in a deployment classification.

Assign the code by walking the questions in order:
(1) Does any model output enter the production workflow at all? If no → BU.
(2) Does any model-generated content persist into the deliverable? If no → PU.
(3) Has the content that persists been substantially reworked by human authors? If yes → IU; if no → DU.

Enhancement of own content. Tools that transform the organisation’s own material rather than synthesising new content from training data (denoisers, upscalers, ML rotoscoping, motion-blur removal) formally land in DU  when their output persists into frames. They are nevertheless a different risk profile from generative synthesis, because the creative substance originates in the organisation’s own inputs.

5   Code registry

All codes are globally unique. The core registry is shown below; organisation-specific codes (and the optional-extension codes of Appendix A) must not collide with it.

6   Classifications and policies

The framework produces two fundamentally different kinds of artefact:

• a Classification  is a factual statement about what something is  or how it is being used;
• a Policy  is a normative statement about what an organisation permits.

They look superficially similar but answer different questions, are written by different parties, and use different notation. A classification never contains alternatives or wildcards; a policy routinely does. Anything containing “/” or “*” is a policy.

6.1   Solution classification (intrinsic; vendor-publishable)

Describes what a solution is, independent of any particular user. It carries the intrinsic dimensions, Data, Model, Code, and the Infrastructure on which the solution is offered. It does not carry a Use value, because Use is not a property of the artefact. This is the string a vendor can publish in its documentation. A third-party tool described without a Use value is precisely a capability classification.

Da:<Data>-M:<Model>-I:<Infra>-C:<Code>

Example:  Da:WD-M:CM-I:MI-C:CC

6.2   Deployment classification (adds the deployment dimension)

Describes how one organisation uses  a capability. It takes a capability classification and supplies the missing Use value (confirming Infrastructure where the adopter chose it), defining all five dimensions. This is the object a policy is checked against.

Da:<Data>-M:<Model>-I:<Infra>-C:<Code>-Us:<Use>

Example:  Da:WD-M:CM-I:MI-C:CC-Us:PU

6.3   Policy expression (normative; the permitted set)

Describes the set of classifications an organisation accepts. Each dimension lists permitted codes separated by “/”; “*” permits any value. A deployment classification matches  a policy if, for every dimension, each of its values (including each member of a “+” composite) is in the permitted set. A policy may contain several rules; matching any one rule is sufficient.

Rule:  Da:PD/LD-M:*-I:SI/DI-C:OC/CC/PC-Us:BU/PU/IU

Because a capability classification has no Use value, a policy that constrains Use can only be evaluated against a deployment classification. A vendor’s published string is checked against the Use-free part of the policy, with the Use constraint applied when the organisation decides how to deploy. This is the formal version of “the same tool may be allowed for one purpose and not another”.

7   Composite and embedded systems

Because AI capabilities are increasingly embedded inside larger tools and chained into pipelines, a monolithic classification of a whole product is rarely meaningful. When classifying complex systems and applications, the following rules apply:

Classify capabilities, not host applications. A DCC package with an embedded generative-fill feature receives a classification for the generative-fill capability; the non-AI parts of the host are out of scope. A product exposes as many Da-M-I-C-Us strings as it has distinct AI capabilities, and a policy can permit some features of a product while prohibiting others.

Pipelines take the high-water mark. When several capabilities are chained (e.g. an open-weights model pre-processing data for a multi-tenant service), the pipeline’s effective classification takes, per dimension, the most restrictive-to-policy value among its components, e.g. Data includes WD if any component was trained on web-collected data; Infrastructure is MI if any component runs as a multi-tenant service. Component classifications should be retained alongside the aggregate.

Adaptation composes with “+”. Fine-tunes, LoRAs and similar solutions compose within the Data (and where relevant Model) dimension as described earlier, preserving both the base and the adaptation in the string.

8   Common classification classes

Classification classes name the recurring shapes  of AI solutions in the market. Each is a capability classification (Data-Model-Infrastructure-Code, with no Use value) given a descriptive label, so that a common solution can be referred to by name. They are factual descriptions, not permissions and whether any of them is acceptable for a given purpose is a matter for the policy classes.

C1     Frontier[c][d][e]  Commercial Model

Da:WD - M:CM - I:MI - C:CC

What it is. A large, general-purpose model trained on web-collected data, with closed weights, served as a multi-tenant API or web application, on closed source.

Typical instances. The dominant shape of general-purpose commercial AI. Chat and coding assistants; image, video and audio generators offered as hosted services by major providers.

Key characteristic. Maximum capability with opacity on training-data provenance

C2     Rights-Cleared Commercial Model[f]

Da:LD - M:CM - I:MI - C:CC

What it is. Similar to C1, but the provider documents or warrants a licensed or owned training corpus.

Typical instances. “Commercially-safe” generative image and video tools; licensed voice synthesis; generators trained on stock or owned libraries.

Key characteristic. Provenance risk is materially reduced; preferable where generated content must reach deliverables.

C3     Permissive Open Model[g]

Da:WD - M:OM - I:SI - C:OC

What it is. An open-weights model under a permissive licence, self-hostable, with open source, trained on web-collected data.

Typical instances. Permissively-licensed open LLMs and diffusion models run on owned infrastructure.

Key characteristic. Full deployment control and no vendor dependency; the residual risk is the base model’s web-data provenance.

C4   Restricted Open Model

Da:WD - M:RM - I:SI[h]  - C:RC

What it is. An open-weights model whose licence restricts use (non-commercial, field-of-use or geographical  limits), often with restrictive source terms.

Typical instances. Research project checkpoints; non-commercial community models; “open but not for commercial use” releases.

Key characteristic. Usable for evaluation; production use requires a licence upgrade or commercial negotiation.

C5   In-House Proprietary Model

Da:PD - M:PM - I:SI[i]  - C:PC

What it is. A model built, trained and owned entirely in-house on proprietary data, self-hosted, on proprietary code.

Typical instances. Internal forecasting or classifier model; Internal computer vision or image processing solutions e.g. image denoising.

Key characteristic. The lowest external risk: no third party touches the data, the weights or the code.

C6     On-Device Model[j]

Da:WD - M:OM - I:EI - C:OC

What it is. A model that runs locally on end-user hardware rather than a server.

Typical instances. On-device speech-to-text; mobile and workstation-local vision models; embedded inference.

Key characteristic. Inputs never leave the device; provenance still depends on the base model from which it is built.

C7     Self-Hosted Adapted Model

Da:WD+PD - M:OM - I:SI - C:OC

What it is. An open base model adapted on proprietary data and self-hosted. A composite: open base plus proprietary adaptation.

Typical instances. Studio LoRAs and fine-tunes of open models run on owned infrastructure.

Key characteristic. The deployment control of C3 plus a proprietary adaptation; the base model’s provenance survives in the composite.

9   Common policy  classes

Policy classes name the recurring stances  an organisation can take. Each is a policy expression over the five dimensions given a descriptive label, so that a policy can be written using class names, e.g. “Business Operations Support is permitted; Rights-Cleared Generative Delivery requires approval”. Each class states what it permits, typical instances, and an explicit boundary naming the adjacent class that picks up an excluded case. Classes may overlap by design; the boundary notes prevent the gaps.

P1   Self-Hosted Proprietary

Da:PD/ND - M:PM - I:SI - C:PC/OC - Us:*

What it permits. Capabilities built, trained and operated entirely in-house, proprietary (or no) training data, organisation-owned weights, self-managed infrastructure,  for any use. The reference low-risk stance for confidential workflows.

Typical instances. In-house forecasting, scheduling, search; image denoising trained on proprietary data.

Boundary. Excludes anything adapted from an external base model, e.g. a fine-tune of an open model falls under P3 or P4, because the base’s Data value survives composition. Open frameworks (OC) used to build the capability are permitted; open weights are not.

P2     Business Operations Support

Da:* - M:CM - I:MI/DI - C:CC - Us:BU/PU

What it permits. Commercial vendor-hosted assistants and productivity services, consumed under an organisational agreement, used anywhere short of generated content persisting into deliverables. Training-data provenance is unconstrained precisely because Use is limited to supporting operations and the output of the system is not present in any deliverable

Typical instances. Chat and coding assistants for internal work; meeting transcription and summarisation; document drafting for internal consumption; ticket triage; research and pipeline tooling.

Boundary. Excludes consumer/free tiers and personal accounts accessed without an organisational agreement. Excludes any deployment where output reaches a deliverable.

P3   Self-Hosted Open Model

Da:* - M:OM - I:SI/EI - C:OC - Us:BU/PU/IU

What it permits. Permissively-licensed open-weights models, self-hosted or on-device, for any use short of unmodified delivery. Self-hosting removes the input-handling and vendor-dependency concerns; what remains is the training-data provenance of the base model, which is why Use is capped at IU.

Typical instances. Open LLMs on the render farm for pipeline tooling and agents; open image and video models for concept reference and previs; open speech and embedding models inside internal services; studio fine-tunes of open bases.

Boundary. Excludes restricted-licence weights (RM),  those go to P4. Excludes DU: an open model’s output shipping unmodified in a deliverable must qualify under P5, which requires evidencing the base model’s data provenance.

P4   Internal Evaluation Only

Da:* - M:OM/RM - I:SI - C:OC/RC/UC - Us{BU}

What it permits. Research releases, such as papers with code, restricted-licence checkpoints, unlicensed reference implementations, are admitted for internal evaluation only, on self-managed infrastructure so that no confidential material leaves the organisation during testing.

Typical instances. Reproducing a paper’s results; testing an unlicensed implementation to decide whether to seek a licence.

Boundary. Excludes production use of any kind. No-licence (UC) code confers no usage rights at all; membership here flags it for legal follow-up, it does not cure it.

P5     Cleared Deliverable Creation

Da:LD/PD - M:CM/PM - I:* - C:CC/PC - Us:IU/DU

What it permits. Generative content that reaches deliverables, where the training data is rights-cleared (LD) or the organisation’s own (PD).

Typical instances. Commercially-safe image and video generators used for final content; licensed voice synthesis in final mixes; generative fill from providers documenting their training set; in-house generative models trained on owned libraries.

Boundary. Excludes WD/UD bases in any position of a composite. A WD+PD fine-tune does not qualify, however clean the adaptation. Enhancement-type features, whose content originates in the organisation’s own inputs, are assessed separately.

10   Policy examples

With the catalogue in place, policies become short and legible. These are policies (normative); they are checked against deployment classifications.

Internal adoption policy (illustrative)

Permitted:   P1, P2, P3, P4

By approval: P5 (legal sign-off per deployment)

Note:            consumer/unmanaged access is excluded (outside all classes)

Partner / vendor guidelines (illustrative)

Policy 1:         Da:PD/LD - M:* - I:* - C:OC/CC/PC - Us:*

Policy 2:         Da:* - M:* - I:* - C:OC/CC/PC - Us:BU/PU

rights-cleared-data terms (P5) for anything

reaching delivered material; otherwise anything short of

deliverables (P1, P2, P3, P4).

Partners may use anything on rights-cleared data, or anything at all provided no generated content enters the material they deliver. Each delivered deployment classification is checked against the rules mechanically. Because partners’ published strings are capability classifications, the Use constraints in these rules bind at the point the partner decides how to deploy.

Appendix A   Extensions to the Framework

While the Da-M-I-C-Us framework defines the core set of Data, Model, Infrastructure, Code and Use dimensions, it is easy to see how the general approach could be extended to include additional criteria that may be relevant to a specific industry or category of users.

For example, the framework could be extended to include the following criteria:

·       Confidentiality -  this could classify the solution based on whether they are able to generate or represent different classes of data based on their availability Public Data, Confidential Data, Critical Data

·       Societal Risks - this could classify the solution based on societal risks, from low to high

·       Ethical Risks - this could classify whether the solution is to be considered ethical based on a well defined set of criteria

In addition, a specific industry may define additional options for one of the existing dimensions to accurately capture their requirements. For instance the Music industry may be interested in separating the use case where a solution is used to replicate or reproduce the voice of a singer or not. In this case, one or more options may be added to the list of options.

[a]Should this really be “OW” = Open Weights, and have the option of a true “Open” model too (i.e. where the data and training mechanism is open source too?). We might almost want to specify if this is MOF compliant?

[b]Everything we have so far is relatively agnostic to the industry, but for this particular dimension, I am seeing some differences with how we consider generative elements affecting only background visuals vs actors.

I wonder if we should consider splitting this into:

BU - Direct use for background creation

AU - Direct use on actors

If we could find a more generic term than “Actors” it would be ideal

[c]Is there something significant about it being a “Frontier” model? It makes me think of Bleeding edge models, which I dont think is what you are thinking? Would “Standard Commerical model” or “Opaque Commercial model” make more sense?

[d]Valid point. With this Class, we really want to capture the OpenAI, Claude, Gemini etc. Simply calling it Standard Commercial model or Opaque model could then be referencing something that is self hosted etc.  

You are right though, it does not necessarily mean “State of the Art” in this context

Could be “Online Commercial Model”?

[e]That seems better.

[f]Should this have the option of being run locally? Or dedicated single tenant?

[g]Do we assume that if its “SI” Self managed that it could be “DI, MI or EI”? It feels like this should be I:*?

[h]I wonder if it should be I:* too? Or at least I:SI/EI/DI

[i]Another one for I:SI/EI/DI

[j]If we do open up the others, perhaps this one goes away. It feels potentially wrong to say this is just “local” and not I:SI too? Similarly with the “Da” restrictions?