Services Overview
Services are the main runtime-facing layer used to interact with systems and data.
In practice, a service is the object that exposes the behavior of part of the tool. It usually sits between raw data and the rest of the runtime or editor workflow.
What to expect from this section
The service pages are reference-style documents. They are most useful once you already understand the feature area and want to know which runtime object is responsible for a specific part of the system.
When to read service docs
Read the service docs when you need to:
- understand ownership of a system
- find the right abstraction for a feature
- trace how a concept is exposed to the rest of the tool
- match runtime responsibilities to architecture concepts
Recommended prerequisites
Before diving into service pages, read:
How service pages are structured
Most service pages describe:
- what the service is responsible for
- where it fits in the larger system
- the main properties or data it exposes
- the public methods you are most likely to use or inspect
Important note for current versions
The current source uses a shared module bootstrap and service registry model. That means service ownership matters more than older docs implied.
For example:
- CivilAI is the canonical owner of world time when installed
- CivilAI is also the canonical owner of the shared item catalog when installed
- Dialogue can consume shared services and register fallbacks where appropriate