docs(artifact): document labels

content/docs/guides/writing-workflows-yaml.mdx

@@ -94,6 +94,19 @@ outputs:
 Each artifact has an `id` (unique within the task's inputs or outputs) and a
 `path`. A task counts as complete when all of its `outputs` exist on disk.
 
+An artifact may also carry `labels`, a free-form `string: string` mapping the
+runtime never reads:
+
+```yaml
+outputs:
+  - { kind: file, id: scored, path: batch_017.parquet, labels: { subject: batch_017, role: measurement } }
+```
+
+They exist for whatever reads the workflow afterwards, not for the run
+itself: a UI grouping nodes, or a lineage query answering "everything derived
+from subject X." A domain expresses its own structure through labels instead
+of the runtime growing a field per domain.
+
 The **directory containing** each output is created before the task runs, so
 `path: "./out/model.pkl"` works even when `out/` does not exist yet. No task
 needs a `mkdir` step of its own.

content/docs/sdk/core/artifact.mdx

@@ -39,6 +39,11 @@ Each artifact:
   unique (see [DAG planning](/sdk/core/workflow#dag-planning) and
   [edges](/sdk/core/workflow#edges)).
 - Has a **path** identifying its location on disk
+- Carries optional **`labels`**: a `dict[str, str]` of free-form metadata
+  (`labels: {subject: batch_017, role: measurement}`). The runtime never
+  interprets them and they play no part in caching; they exist for whatever
+  reads the workflow afterwards, such as a UI grouping nodes or a lineage
+  query.
 - Defines:
   - How to **read** its contents back into a Python object
   - How to **write** a Python object to its file representation