# Activity model and lifecycle
URL: https://docs.awellhealth.com/docs/embed-and-host/activity-model-and-lifecycle

> For the complete documentation index, see [llms.txt](https://docs.awellhealth.com/llms.txt).



An **activity** is a single task a stakeholder completes in a care flow: a form, a checklist, a message
to acknowledge, or a custom extension action.

Activities are orchestrated by the backend and rendered by the embedded portal. The host app displays
activities; the care flow decides which ones exist and what happens next.

## Supported activity types [#supported-activity-types]

Navi renders forms, checklists, message acknowledgments, and activities produced by custom extensions.

## Lifecycle: build against events, not polling [#lifecycle-build-against-events-not-polling]

An activity moves through states as the stakeholder works on it, from becoming available, through
in-progress, to complete. Navi emits an event at each transition, which is how the host app reacts. See
[Events emitted by Navi](/docs/embed-and-host) for the full event reference.

The care flow can create and expire activities with no input from the stakeholder, so a UI that assumes
a fixed list will drift.

## Validation comes from the care flow, not the client [#validation-comes-from-the-care-flow-not-the-client]

Validation happens where the activity is defined. A form's rules come from the care flow design, so Navi
enforces the same rules everywhere the form appears.

There is no validation to reimplement in the client, and no way to override it from there. If a rule is
wrong, change it in [Studio](/docs/design-care-flows).

## Next steps [#next-steps]

**Next:** [Sessions and JWTs](/docs/embed-and-host/sessions-and-jwts) for how access is granted.
