---
name: enrich-ontology
description: Map a Cartography node into the Ontology system using semantic labels (UserAccount, DeviceInstance, Tenant, Database, ObjectStorage, FileStorage) or canonical nodes (User, Device). Use when the user asks to add ontology mapping, expose a node as a semantic label, normalise identity / device data across providers, enable cross-module queries, or wire `_ont_*` properties.
---

# enrich-ontology

Cartography's Ontology system unifies data from multiple sources via two mechanisms:

1. **Semantic labels (recommended)** — adds labels (e.g. `UserAccount`) and prefixed properties (`_ont_*`) directly to source nodes during ingestion.
2. **Canonical nodes** — separate `(:User:Ontology)` / `(:Device:Ontology)` nodes that aggregate data from multiple sources.

Most modules only need semantic labels.

## Critical rules

1. **Mark primary identifiers `required=True`** in `OntologyFieldMapping` (e.g. `email` for `User`, `hostname` for `Device`). Records missing these are excluded from ontology node creation.
2. **For semantic labels, add the exported ontology label constant**, for example `ExtraNodeLabels([USER_ACCOUNT])`. Ontology constants are immutable `ExtraNodeLabel` values with `kind=LabelKind.ONTOLOGY`; the ontology system handles the `_ont_*` properties automatically.
3. **`special_handling` values are strings**: `invert_boolean`, `to_boolean`, `or_boolean`, `nor_boolean`, `equal_boolean`, `static_value`, `coalesce`. Boolean conditions inside `extra={"values": ...}` must also be strings (`"true"`, not `True`).
4. **Ontology mapping docs are generated.** Never hand-write `schema.md`: the `> **Ontology Mapping**` note is emitted from the node's `extra_node_labels`. Document the node in the model with a docstring and `PropertyRef` `description=` values.
5. **Module name `microsoft`** is the canonical source for Microsoft Graph. `entra` is still accepted as a backward-compatible alias during migration.

## Instructions

### Step 1 — Decide: semantic label or canonical node?

| Need                                                                                  | Use                |
| ------------------------------------------------------------------------------------- | ------------------ |
| Cross-module queries on existing source nodes (e.g. all `UserAccount` across systems) | Semantic label     |
| Aggregate one entity from many sources into a single canonical record                 | Canonical node     |

When in doubt, start with semantic label.

### Step 2 — Author the mapping

Add the mapping in `cartography/models/ontology/mapping/data/`. For users:

```python
# cartography/models/ontology/mapping/data/useraccounts.py
from cartography.models.ontology.mapping.specs import (
    OntologyFieldMapping, OntologyMapping, OntologyNodeMapping,
)


your_service_mapping = OntologyMapping(
    module_name="your_service",
    nodes=[
        OntologyNodeMapping(
            node_label="YourServiceUser",
            fields=[
                OntologyFieldMapping(ontology_field="email",     node_field="email", required=True),
                OntologyFieldMapping(ontology_field="username",  node_field="username"),
                OntologyFieldMapping(ontology_field="fullname",  node_field="display_name"),
                OntologyFieldMapping(ontology_field="firstname", node_field="first_name"),
                OntologyFieldMapping(ontology_field="lastname",  node_field="last_name"),

                OntologyFieldMapping(
                    ontology_field="inactive",
                    node_field="account_enabled",
                    special_handling="invert_boolean",
                ),
                OntologyFieldMapping(
                    ontology_field="has_mfa",
                    node_field="multifactor",
                    special_handling="to_boolean",
                ),
                OntologyFieldMapping(
                    ontology_field="inactive",
                    node_field="suspended",
                    special_handling="or_boolean",
                    extra={"fields": ["archived"]},
                ),
            ],
        ),
    ],
)
```

For devices the pattern is the same with `OntologyNodeMapping(node_label="YourServiceDevice", ...)`.

### Step 3 — Register the mapping

Add it to the dictionary at the bottom of the file:

```python
# Example: bottom of useraccounts.py
USERACCOUNTS_ONTOLOGY_MAPPING: dict[str, OntologyMapping] = {
    # ... existing mappings ...
    "your_service": your_service_mapping,
}
```

The mappings are auto-imported via `cartography/models/ontology/mapping/__init__.py`.

### Step 4 — Wire the semantic label on your node schema

For semantic labels, the node schema simply gains the extra label — Cartography injects `_ont_*` and `_ont_source` automatically at ingestion:

```python
from cartography.models.core.nodes import ExtraNodeLabels
from cartography.models.ontology.labels import USER_ACCOUNT


@dataclass(frozen=True)
class YourServiceUserSchema(CartographyNodeSchema):
    label: str = "YourServiceUser"
    extra_node_labels: ExtraNodeLabels = ExtraNodeLabels([USER_ACCOUNT])
    properties: YourServiceUserNodeProperties = YourServiceUserNodeProperties()
    sub_resource_relationship: YourServiceTenantToUserRel = YourServiceTenantToUserRel()
```

For canonical nodes, define a separate schema with
`extra_node_labels=ExtraNodeLabels([ONTOLOGY])` and a relationship to the
semantic-labeled source nodes. See `references/semantic-labels.md` for the
full template.

### Step 5 — `required` and `eligible_for_source`

`required=True` means: source records lacking this field are **excluded** from ontology node creation. Always mark the primary identifier required:

```python
OntologyFieldMapping(ontology_field="email",    node_field="email",       required=True)
OntologyFieldMapping(ontology_field="hostname", node_field="device_name", required=True)
```

`OntologyNodeMapping.eligible_for_source=False` means: this mapping links existing ontology nodes but cannot **create** new ones. Use it when the source lacks the required identifier:

```python
# AWS IAM users have no email, so they cannot create new User ontology nodes.
OntologyNodeMapping(
    node_label="AWSUser",
    eligible_for_source=False,
    fields=[
        OntologyFieldMapping(ontology_field="username", node_field="name"),
    ],
),
```

### Step 6 — Cross-entity relationships (e.g. user owns device)

For services that link users to devices, add a typed analysis statement to `cartography/analysis/ontology/analysis.py`:

```python
AnalysisStatement(
    match="MATCH (u:User)-[:HAS_ACCOUNT]->(:YourServiceUser)-[:OWNS]->(:YourServiceDevice)<-[:OBSERVED_AS]-(d:Device)",
    effects=(
        AddRelationship("u", "OWNS", "d", source_label="User", target_label="Device"),
    ),
)
```

See the `analysis-jobs` skill for typed analysis job syntax.

### Step 7 — Test

For semantic labels — assert `_ont_*` properties land on your nodes:

```python
def test_ontology_properties(neo4j_session):
    # after running your sync
    row = neo4j_session.run(
        "MATCH (n:YourServiceUser) RETURN n._ont_email, n._ont_source LIMIT 1"
    ).single()
    assert row["n._ont_email"] is not None
    assert row["n._ont_source"] == "your_service"
```

For canonical nodes — assert the ontology intel module produces them:

```python
def test_canonical_user_created(neo4j_session):
    row = neo4j_session.run(
        """
        MATCH (u:User:Ontology)-[:HAS_ACCOUNT]->(ua:YourServiceUser)
        RETURN count(u) AS user_count
        """
    ).single()
    assert row["user_count"] > 0
```

### Step 8 — Document the integration

Do not create or hand-edit `schema.md`. Sphinx generates it from the data model, including the `> **Ontology Mapping**` note for any node whose `extra_node_labels` carry an ontology label constant. Write the documentation in the model itself: a docstring on the node schema and `description=` on each displayed `PropertyRef`. Build the docs with `uv run ./docs/build.sh` and check the generated page.

## `special_handling` quick reference

| Value             | Description                                                | Extra params                              |
| ----------------- | ---------------------------------------------------------- | ----------------------------------------- |
| `invert_boolean`  | Inverts the boolean value (`true` -> `false`)              | None                                      |
| `to_boolean`      | Converts to boolean, treating non-null as `true`           | None                                      |
| `or_boolean`      | Logical OR over multiple boolean fields                    | `extra={"fields": [...]}`                 |
| `nor_boolean`     | Logical NOR over multiple boolean fields                   | `extra={"fields": [...]}`                 |
| `equal_boolean`   | `true` if value matches any of the specified strings       | `extra={"values": ["active", "bypass"]}`  |
| `static_value`    | Sets a static value, ignoring `node_field`                 | `extra={"value": "dynamodb"}`             |
| `coalesce`        | Sets the first non-null value from multiple fields         | `extra={"fields": [...]}`                 |

## Canonical node configuration (CLI)

```bash
cartography --ontology-users-source "okta,microsoft,gsuite"
cartography --ontology-devices-source "crowdstrike,kandji,duo"
```

## References (load on demand)

- `references/semantic-labels.md` — execution flow, available labels/fields, full canonical-node schema example, `eligible_for_source` deep dive.
