# Models in the Console

The Create Model form asks for a model key, a file URL and an
attribute-generation method in one breath, which makes it hard to tell what the
file will contain from where the values live. They are two different things.

## A model describes what one item looks like

A **model** is a shape: a unique `key` plus a list of **properties**, each with a
name and a type (`string`, `int`, `float`, `date`, `boolean`, `json`, `any`,
plus the array types `Array<string>`, `Array<int>`, `Array<float>` and
`Array<date>`). It holds no values.

**Create Model** writes one file — `models/product.dcupl.json` for the model key
`Product` — containing that shape, and adds the file to `dcupl.lc.json` as a
`model` resource. Both halves matter:
a model file that is not declared in the loader config is never loaded.

The form's **Attribute Creation** picks where the properties come from:
**Manually (next Step)** opens an empty property list to fill in, **Data
Resource** infers them from a data file already in the project, and **Example
Data** infers them from CSV or JSON you paste.

## The rows usually arrive separately

```mermaid
flowchart LR
  M["model resource<br/>Product.dcupl.json"] --> C["dcupl core"]
  D["data resource<br/>model: Product"] --> C
  C --> L["Loaded model<br/>shape + rows"]
```

Values reach a model through a separate **data** resource in the loader config
that names this model key — a CSV or a JSON file. That is why the loader always
registers models before it parses data: a data resource is parsed against its
model (CSV columns get their types from it). A data resource with no matching
model is not dropped: by default the loader creates a model of that key and
infers its properties from the rows.

A model may also carry rows **inline**, in a `data` block inside the definition
itself. Those are not samples or fixtures: they are forwarded into exactly the
same load path as an external data resource. Use them for small, stable lookup
tables that you would rather keep next to the shape.

Two model files that declare the same key merge: properties and references
**accumulate** across the files, so one model can be assembled from several
files.

## References vs properties

A **property** holds a value on the item. A **reference** points at another
model, and is either:

- **`singleValued`** — one target item, such as an order's customer.
- **`multiValued`** — many, such as an order's products.

Once both models are loaded, an order reaches its products through that link
instead of copying their values into its own rows. Keep the shared data in one
model and reference it; that is what keeps queries across relationships cheap.

Attributes that fail validation are dropped rather than fatal — they surface in
the Quality Analyzer on the running app, not as a load failure. If a column you
expect is missing, look there first.

## Next steps

- [Importing data](/console/data-import) — the form that usually creates the data resource
- [Loader configuration](/console/loader) — how model and data resources are declared
- [SDK model reference](/sdk/api/models) — the full `ModelDefinition` field set