A lockfile is the audit trail of an install. When biome:install@1 runs, the kernel resolves every contribution in the manifest to a concrete slug@version and writes the resulting map to an install.lock row keyed by (org, biome, version). Subsequent boots re-read the lockfile rather than re-resolving — so a biome that has been live for months continues to behave identically even if upstream sources change. Lockfiles only reference published versions (lifecycle); archived versions stay resolvable for as long as a lockfile names them.

Lockfiles are produced by the shared resolver in @xemahq/lockfile-resolver and written at three invocation boundaries: app deploy (POST /apps/:id/lockfile/refresh on app-platform-api), session creation (agent-session-api's SessionLockfileService, served at GET /sessions/:id/lockfile), and workflow-run start (the Xema workflow worker service's xemaEmitRunLockfileActivity, written as a REPLACE-versioned artifact). Each writer composes the resolver over the same four sources — kernel, capability, biome and object registry. See the Versioning page for the lockfile shape.