> ## Documentation Index
> Fetch the complete documentation index at: https://docs.events.intrace.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Assets

> Model assets for monitoring and understand the fields that drive matching

Assets are the root object for physical monitoring.

## Supported physical asset types

The first external version is built around locatable asset types used by the internal events investigation flow:

* `facility`
* `residence`

These are the asset types consumed by the physical threat pipeline when matching event proximity.

## Identity fields

Every asset should have:

* `asset_id` — your stable external identifier
* `name` — human-readable label
* `type` — asset type
* `status` — usually `active` or `archived`

## Location fields

For physical monitoring, put coordinates in `attributes`:

```json theme={null}
{
  "lat": 9.0765,
  "lng": 7.3986,
  "address": "Central District, Abuja",
  "country": "NG",
  "monitoring_radius_km": 12
}
```

Without usable coordinates, the platform cannot evaluate location-based physical threats for the asset.

## Monitoring config fields

### `threat_config`

Controls general threat-engine behavior:

* `enabled`
* `alert_classes`
* `custom_instructions`
* `monitored_event_types`
* `lookback_days`

### `physical_threat_config`

Controls physical/EP evaluation behavior:

* `enabled`
* `alert_classes`
* `custom_instructions`
* `monitored_event_types`
* `max_age_hours_by_category`

## Recommended pattern

* keep `asset_id` stable in your system
* use bulk upsert for full-sync workflows
* use per-asset radius overrides when category sensitivity differs by site
* archive instead of delete when you need historical continuity