Deploy knowledge updates
Sequence learning, activation, evaluation, and rollback without overwriting another release.
Internalize manages adapter hosting and routing. Your release process decides which learned version should serve users and when. A stable subject lets applications keep one identity while that active version changes.
Record the current state
Read the subject before starting a release. Save its active version, revision, the new source revision in your own system, and the idempotency key for the learning intent. Preserve the prior version ID as the rollback target while it remains retained.
Do not assume the newest-created candidate is active. A previous candidate may have been saved with activation disabled or may have lost a concurrency race. Use active_version from the subject state.
Choose automatic or reviewed activation
For a simple serialized memory workflow, use activate: true and wait for both ready and activated. Admit the next dependent learning job only after the intended parent is active.
For a reviewed release, use activate: false. Inspect the returned validation and confirm that a candidate exists. Then read current routing and activate using expected_version_id. The comparison protects against another release changing the subject while you were reviewing.
Evaluate the exact release
The public API does not support inference against an inactive candidate or weighted traffic splitting between versions. An isolated subject can rehearse the source, but it does not validate the exact production artifact.
If your application requires an evaluation gate before exposing the new adapter to users, pause or gate user traffic in your application, activate the candidate, run the acceptance suite, and resume traffic only after it passes. Verify adapter_version on the evaluation jobs. Account for the fact that already-admitted requests keep their old snapshot.
Handle concurrent updates
Two learning jobs admitted from the same parent create separate candidates. They do not automatically merge. If one activates first, the other can finish ready with activation_conflict: true.
Decide which source should take precedence. If both updates are needed in sequence, you may need a deliberate new learning operation from the chosen active parent. Reusing an old idempotency key with revised source will return a conflict; a new intended update needs a new key and incurs its own successful-call fee.
Roll back
Read the current version and activate the retained previous candidate with that value as the expected version. Confirm the subject state after the write. New inference uses the restored route; queued or running work does not retroactively switch.
Rollback does not delete the unsuccessful release, erase completed answers, or refund prior charges. If the earlier adapter expired, the normal rollback path is unavailable. Inspect retention before relying on a version as a recovery option.
Keep a release record
Store source revision, subject, parent version, learning job, candidate version, validation totals, activation revision, evaluation evidence, and rollback target. These links make it possible to explain which knowledge produced an answer without exposing the source in routine logs.
The platform does not provide adapter export, alias creation, cross-subject cloning, or a public reset-to-base operation. Use the supported version and subject boundaries rather than building release scripts against private checkpoint paths.