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

# Integration overview

> Extend HumaLike through independent, versioned provider domains.

HumaLike works standalone and keeps server-specific behavior behind providers.
A provider is a Lua descriptor registered by a separate resource through a
public export.

## Domains

| Domain        | Side   | Responsibility                                                  |
| ------------- | ------ | --------------------------------------------------------------- |
| `player`      | Server | Character identity, loaded state, jobs, duty, notifications.    |
| `inventory`   | Server | Add an item to a character inventory.                           |
| `dispatch`    | Server | Translate a neutral incident into the server's dispatch system. |
| `actions`     | Server | Execute server-specific NPC actions.                            |
| `interaction` | Client | Add/remove NPC interaction options and show progress.           |

Domains are deliberately independent. A player adapter must not also choose an
inventory, dispatch, action, or interaction implementation.

## Selection

Providers declare a name, API version, priority, and optional availability
callback. `auto` selects the single available provider with the highest
priority. A tie is `ambiguous`; HumaLike does not guess.

Provider callbacks run in the resource that registered them, so they can use
that resource's local framework object and exports.

## Ownership and lifecycle

* Provider names are owned by the registering resource.
* A different resource cannot replace that provider name.
* Re-registering the same name from the same resource is idempotent.
* Stopping the owner automatically removes its providers.
* Starting or stopping a watched dependency reevaluates availability.
* Restarting HumaLike creates a new runtime epoch and emits
  `humalike:integration:ready` on both server and client.

Listen for the ready event and register again. This supports either resource
starting first and makes individual restarts safe.

## What belongs in a bridge

* Framework-specific player lookups and job rules.
* Inventory calls and item allowlists.
* Dispatch event translation.
* Custom action validation and execution.
* Target-system or UI integration.
* Translation of server roleplay events to HumaLike's neutral events.

Do not copy HumaLike internals or modify the released directory. Start with the
[custom bridge guide](/ai-npc/integrations/custom-bridge).

## Next

* [Build a custom bridge](/ai-npc/integrations/custom-bridge).
* [Read the provider API](/ai-npc/integrations/provider-api).
* [Report server roleplay events](/ai-npc/integrations/world-events).