DRAFT2 (WIP)

Da-M-I-C-Us

A classification framework for AI solutions

Version 1.0 Draft 2· June 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 using compact, unambiguous codes

•    Allows organisations to define policies  outlining which classes of AI solutions are acceptable for their 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 clear 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. For each dimension it 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 applies 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 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-community 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. The common policy classes treat enhancement of the organisation’s own content differently from generative delivery (P5), rather than overloading the Use codes.

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.

<Data>-<Model>-<Infra>-<Code> (<version or date>)

Example:  WD-CM-MI-CC (Vendor LLM API, 2026-06)

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). All five dimensions are now definite. This is the object a policy is checked against.

<Data>-<Model>-<Infra>-<Code>-<Use> (<version or date>)

Example:  WD-CM-MI-CC-PU (Vendor LLM API, 2026-06)  [pipeline-tooling deployment]

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 retrieval corpora 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[b][c][d]  Commercial Model

WD-CM-MI-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. The dominant shape of general-purpose commercial AI.

Typical instances. General-purpose chat and coding assistants; image, video and audio generators offered as hosted services by major providers.

Key characteristic. Maximum capability with maximum opacity on training-data provenance; the rights risk is concentrated in any outputs that ship.

C2   Rights-Cleared Commercial Model

LD-CM-MI-CC

What it is. As K1, 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; the natural candidate where generated content must reach deliverables.

C3   Permissive Open Model

WD-OM-SI-OCb

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

WD-RM-SI-RC

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

Typical instances. Research 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

PD-PM-SI-PC

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

Typical instances. Studio-trained rotoscoping, matchmove or denoising models; internal forecasting; internal search and embeddings.

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

C6   On-Device Model

WD-OM-EI-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[e][f][g]

WD+PD-OM-SI-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 K3 plus a proprietary adaptation; the base model’s provenance survives in the composite.

9   Common policy[h][i]  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; studio-trained rotoscoping or matchmove models used through to final frames.

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 capped at PU: the contested-data risk attaches to outputs that ship, and here none do.

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: the moment a drafted paragraph ships to a client, the deployment is IU/DU and must qualify under P5.

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. Nothing under P4 touches production.

Typical instances. Reproducing a paper’s results; benchmarking a new checkpoint against the incumbent; 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   Rights-Cleared Generative Delivery[j]

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). The constrained Data value is the safeguard: only cleared- or owned-data models may contribute content that ships.

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)

Rule 1: Da{PD/LD} M{} I{} C{OC/CC/PC} Us{*}

Rule 2: Da{} M{} I{*} C{OC/CC/PC} Us{BU/PU}

In class terms: 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.