Xema is extended by biomes. A biome adds capability through exactly three declared channels — there is no fourth, and none of them is code the platform loads implicitly:

1. The contribution protocol — typed, single-file envelopes ({ kind, id, manifest }) that a biome ships in its contributions directory or inline in its manifest. Each kind has a kernel-owned or host-owned manifest schema and is validated fail-fast at biome-discovery time. See contribution-kind.
2. Convention content directories — content discovered by on-disk presence. No declaration list; drop the files in the conventional directory and the platform seeds them at boot/install. The authoritative directory table is in Biomes → Manifest Reference.
3. The manifest — xema-biome.json, the biome's identity, target, dependency, and capability declaration. See manifest-extension-points.

The state of the contribution protocol

The public contract declares 41 contribution kinds. 36 are ingested today by a biome-host-api parser; 5 are not — they are either handled by a domain service directly, or reserved for protocol completeness with a different (content-directory) delivery path. Shipping a contribution of a kind with no ingestion path is a silent no-op, which is why the catalog states the fact per kind rather than implying uniform support.

Contract areas

Related concepts

• contribution — what a contribution is, conceptually
• biome — the unit that ships contributions
• manifest — the xema-biome.json contract
• capability — the call surface every contribution ultimately reaches
• object — how a contributed thing becomes addressable