---
term: action
category: spatial
status: canonical
authority: varies — executed by service
---

Action

An executable interaction exposed by an object or surface. Actions connect user intent to service behavior.

Examples:
- open (the canonical verb for activating/selecting an object or result — see Forbidden)
- join
- navigate
- message
- save
- launch
- share
- pin

Sub-concepts:
- action target — the destination or system affected by the action (surface, service, object, route, external runtime)
- action provider — the service executing the action

Allowed:
- action
- [verb] action (e.g., join action, save action)
- action target
- action provider

Forbidden:
- command (implies CLI or OS context)
- operation (too technical)
- function (engineering term)
- button (UI implementation detail; not a model noun)
- event (avoid — event has a canonical social meaning; see: event)
- tap, click, press (input-modality-specific — tap presumes touch, click presumes a mouse; Elonn runtimes span web, android, desktop, and xr, none of which share one input modality. Use "open" as the runtime-agnostic verb naming this action instead.)

Notes:
- Actions belong to objects and surfaces, not to blocks or cards. A card may expose an object's actions, but the action is the object's.
- Do not use "event" to mean a user interaction or UI action. "Event" means a social event (see: event).
- "Open" is canonical for naming, documentation prose, and UI copy describing this action (e.g. "open a result," open_object, OpenObject) — not "tap"/"click"/"press." This is distinct from a runtime's own input-handling code, which may legitimately reference a literal device gesture or a platform event name (e.g. distinguishing a tap from a drag by pointer movement, or a DOM click event) — that is input-detection mechanics, not the action's name, and is unaffected by this rule.

Related:
- object
- surface
- event (distinct; social event — not a UI action)