Adding artifacts section to docs

content/docs/dvclive/how-it-works.md

@@ -81,13 +81,17 @@ find but that don't clutter your Git history or create extra branches.
 ### Track large artifacts with DVC
 
 Models and data are often large and aren't easily tracked in Git.
-`Live.log_artifact("model.pt")` will
+`Live.log_artifact("model.pt", type="model")` will
 [cache](/doc/start/data-management/data-versioning) the `model.pt` file with DVC
 and make Git ignore it. It will generate a `model.pt.dvc` metadata file, which
 can be tracked in Git and becomes part of the experiment. With this metadata
 file, you can [retrieve](/doc/start/data-management/data-versioning#retrieving)
 the versioned artifact from the Git commit.
 
+Passing `type="model"` or `type="data"` will add it to `artifacts` section of
+`dvc.yaml`, allowing DVC to understand what it is and show models in
+[Studio Model Registry](/doc/use-cases/model-registry).
+
 ### Run with DVC
 
 Experimenting in Python interactively (like in notebooks) is great for

content/docs/dvclive/live/log_artifact.md

@@ -3,7 +3,14 @@
 Tracks an existing directory or file with DVC.
 
 ```py
-def log_artifact(path: Union[str, Path]):
+def log_artifact(
+    path: Union[str, Path],
+    type: Optional[str] = None,
+    name: Optional[str] = None,
+    desc: Optional[str] = None,
+    labels: Optional[List[str]] = None,
+    meta: Optional[Dict[str, Any]] = None,
+):
 ```
 
 ## Usage
@@ -16,7 +23,13 @@ from dvclive import Live
 Path("model.pt").write_text("weights")
 
 with Live() as live:
-    live.log_artifact("model.pt")
+    live.log_artifact(
+      "model.pt",
+      type="model",
+      name="mymodel",
+      desc="Fine-tuned Resnet50",
+      labels=["resnet", "imagenet"],
+    )
 ```
 
 ## Description
@@ -26,6 +39,15 @@ Uses `dvc add` to track `path` with DVC, generating a `{path}.dvc` file.
 When combined with `save_dvc_exp=True`, it will ensure that `{path}.dvc` is
 included in the experiment.
 
+If `Live` was initialized with `dvcyaml=True` (which is the default), it will
+add an [artifact](/doc/user-guide/project-structure/dvcyaml-files#artifacts) and
+all the metadata passed as arguments to corresponding `dvc.yaml`. Passing
+`type="model"` will mark it as a `model` for DVC and will make it appear in
+[Studio Model Registry](/doc/studio) (coming soon).
+
+If `name` is not provided, the path stem (last part of the path without the file
+extension) will be used as the artifact name.
+
 ## Parameters
 
 - `path` - existing directory or file

content/docs/use-cases/model-registry.md

@@ -41,17 +41,21 @@ See also [Data Registry](/doc/use-cases/data-registry).
 </admon>
 
 To make a Git-native registry (on top of DVC or not), one option is to use [GTO]
-(Git Tag Ops). It tags ML model releases and promotions, and links them to
-artifacts in the repo using versioned annotations. This creates abstractions for
-your models, which lets you **manage their lifecycle** freely and directly from
-Git.
+(Git Tag Ops). It tags ML model releases and promotions. This creates
+abstractions for your models, which lets you **manage their lifecycle** freely
+and directly from Git.
 
 And to **productionize** the models, you can save and package them with the
 [MLEM] Python API or CLI, which automagically captures all the context needed to
 distribute them. It can store model files on the cloud (by itself or with DVC),
 list and transfer them within locations, wrap them as a local REST server, or
 even containerize and deploy them to cloud providers!
 
+To let your teams **collaborate** on project more efficiently, you can use
+[Studio](/doc/studio/user-guide/model-registry/what-is-a-model-registry) web
+application to organize, discover, version, promote models to production and
+track their lineage.
+
 This ecosystem of tools from [Iterative](https://iterative.ai/) introduces
 [GitOps] into your ML process. This means you can manage and deliver ML models
 with software engineering methods such as continuous integration (CI/CD), which

content/docs/user-guide/project-structure/dvcyaml-files.md

@@ -2,9 +2,9 @@
 
 You can configure machine learning projects in one or more `dvc.yaml` files. The
 list of [`stages`](#stages) is typically the most important part of a `dvc.yaml`
-file, though the file can also be used to configure [`metrics`](#metrics),
-[`params`](#params), and [`plots`](#plots), either as part of a stage definition
-or on their own.
+file, though the file can also be used to configure [`artifacts`](#artifacts),
+[`metrics`](#metrics), [`params`](#params), and [`plots`](#plots), either as
+part of a stage definition or on their own.
 
 `dvc.yaml` uses the [YAML 1.2](https://yaml.org/) format and a human-friendly
 schema explained below. We encourage you to get familiar with it so you may
@@ -13,6 +13,32 @@ modify, write, or generate them by your own means.
 `dvc.yaml` files are designed to be small enough so you can easily version them
 with Git along with other <abbr>DVC files</abbr> and your project's code.
 
+## Artifacts
+
+This section allows you to declare structured metadata about your artifacts.
+Although you can specify artifacts of any `type`, we are in the process of
+building a DVC-based [model registry](/doc/use-cases/model-registry) that will
+use any artifacts with `type: model`. Specically, they will appear in
+[Studio Model Registry](/doc/studio) (coming soon).
+
+```yaml
+artifacts:
+  cv-classification: # artifact ID (name)
+    path: models/resnet.pt
+    type: model
+    desc: 'CV classification model, ResNet50'
+    labels:
+      - resnet50
+      - classification
+    meta:
+      framework: pytorch
+```
+
+Artifact IDs
+[must](https://github.com/iterative/dvc/blob/main/dvc/repo/artifacts.py#L16)
+consist of letters and numbers, and use '-' as separator (but not at the start
+or end). The first character must be a letter.
+
 ## Metrics
 
 The list of `metrics` contains one or more paths to <abbr>metrics</abbr> files.