Custom Profile

---
name: custom-profile
description: Use when authoring a custom profile JSON for Aria Gen 2. A profile fixes which sensors are enabled and at what rate, resolution, and encoding — **the same profile works for both recording and streaming**, despite the historical "recording profile" name. Custom profiles carry real risks (thermal shutdown, fragmented data, MPS rejection), so this skill encodes the conservative authoring workflow plus the full released profile schema (top-level keys, per-sensor fields, enums, validation rules, rate-handling behaviors). Use whenever the user asks how to write a custom profile, modify a profile, define sensor rates, deploy a profile to the device, or asks what a specific profile field means.
---

# Custom Profile Authoring

A **profile** is a JSON-shaped configuration that fixes which Aria Gen 2 sensors are enabled, at what rate, resolution, and encoding. **The same profile applies to both recording and streaming** — historically called "recording profile" (and the Companion App still labels them that way), which is misleading; profiles are not recording-only. The device ships with **pre-defined profiles** validated for thermal, battery, and data quality — use these by default. Custom profiles are for cases where no pre-defined profile fits.

---

## Mental model

A profile is a **high-level intent**, not a literal sensor list. The device expands it: enabling a vertical (`vio`, `et`, `ht`) auto-adds its raw-sensor dependencies (cameras, IMU); unset fields fall back to defaults; illegal values reject the profile.

Key consequences:

- **Presence is meaning.** Many fields are empty-object toggles (`"button_state": {}`); present = on.
- **Omit prerequisites.** `et` alone is fine; `et_cameras` + IR LED are auto-added. Express intent, not plumbing.
- **Spelling matters.** Misspelled or unknown fields are **rejected outright** on upload.
- **Selection is by `name`**, not by filename, not by index, not by `type`.

---

## When NOT to write a custom profile