Detector
The detector model decides which raw classes are visible for each source and which class metadata can feed alert-rule options.
Model Library
Hearthlight’s Model Zoo feeds the mounted inventory and the stage bindings used at runtime. It exists so operators can change model selection without turning that choice into brittle one-off config edits.
Stage Coverage
The current repository describes the Model Zoo as the source for detector, tracker, heuristic filter, and anomaly detection options.
The detector model decides which raw classes are visible for each source and which class metadata can feed alert-rule options.
Trackers maintain continuity between frames so the runtime can pass stable motion and entity context downstream.
Filtering stages refine or gate runtime behavior before later steps consume those signals.
Local and API-backed anomaly stages can surface higher-level activity and object events after the earlier runtime stages finish their work.
Selection Rules
Hearthlight resolves the effective runtime model set in a stable order: a source-specific override wins first, then the saved default binding for that stage.
The current docs describe built-in models, third-party API-backed models such as Chatgpt and Claude, and future external plugin models that can appear after restart.
Operator Experience
Hearthlight keeps stable internal keys for storage and automation while presenting readable display names in the operator-facing surfaces.
Use the CLI to list templates and model options before startup.
hearthlight list-models
The onboarding flow can seed the mounted inventory with default models or specific registry keys through repeated `--mount-model` flags.
Contribute
Contributions can target the runtime’s registry-backed model flow or the dedicated model-zoo repository, depending on whether you are adding catalog coverage or model assets.