> ## Documentation Index > Fetch the complete documentation index at: https://docs.bijection.com/llms.txt > Use this file to discover all available pages before exploring further. # Model lifecycle > Register, evaluate, review, deploy and monitor models using existing Bijection execution and release owners. `@bijection/model-lifecycle` owns modeling objectives, immutable candidate registrations, evaluation associations, desired deployments and monitoring policies in private application tables. Model/scenario execution, pipelines, operations, approval, releases, files and datasets retain their native owners. The [component source](https://github.com/bijectionhq/model-lifecycle) contains the API, adapters, CPU controller and executable reference cases. ## Install in an application Create `lifecycleTables("modelLifecycle")` once, merge the result into the application schema and pass those same tables to `lifecycleApplication(options, tables, approval)`. Export the returned functions individually from `modelLifecycle.ts`. Supply an existing `operationApproval` with `target_id` as its resource argument. The application's access model still grants native read, preview and invoke permissions for these operations. The [Northstar integration recipe](https://github.com/bijectionhq/bijection/blob/main/examples/northstar/model-lifecycle.ts) provides a demand-model acceptance policy. The [document integration recipe](https://github.com/bijectionhq/bijection/blob/main/examples/http-compute/model-lifecycle.ts) connects a separate native Compute installation and a classification policy. These recipes require the application's actual custody, publication and authorization owners. They do not activate a provider or grant authority merely by importing them. Use the exported workspace helper so operations belong to the correct feature: ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} import { lifecycleWorkspace } from "@bijection/model-lifecycle/workspace"; const models = lifecycleWorkspace("modelLifecycle"); const workspaceFeatures = [models.feature]; const workspaceOperations = models.operations; ``` Merge these entries with the application's other features and operations. The reference recipes return both `feature` and `operations` for this purpose. Keep the lifecycle tables private. The official workspace exposes paginated objectives, candidates, suites, evaluation comparisons, work, promotions, deployment observations, predictions and outcomes through authorized queries. Every action opens the existing native operation dialog; promotion uses its review and approval flow. ## Register and evaluate A candidate binds its capability, implementation, input/output contract, preprocessing, postprocessing, canonical parameters and exact model-file references. Imported provenance is distinct from native-correlated training evidence. Small parameters use existing model artifacts; large weights remain governed files with independent custody. A suite fixes evaluator identity, baseline, selection and validation dataset versions, metric units, sample bounds and acceptance criteria. Different input digests alone do not establish independent observations: the configured evaluator must check their actual split. Missing metrics, incomplete populations, wrong units and undefined denominators cannot pass. External evaluator reports remain external evidence, not independent attestation of statistical correctness. `requestEvaluation` admits work through the configured native owner. `acceptWork` reads that owner's current result, checks the entire identity and retains report custody. It accepts no caller-supplied evaluation metrics. ## Review, publish and deploy `promote` rechecks the target revision, objective policy, current baseline, candidate, evaluation and custody in the accepting transaction. It submits the exact reviewed proposal through the existing source/release owner. Changing policy requires a new suite/evaluation. Selecting an experimental release does not install it in the live application. `requestDeployment` waits for actual publication evidence and submits a provider change through native work. A command acknowledgement does not establish model readiness. The serving source must independently report the selected candidate and release. Superseded work cannot replace the current deployment resource. `nativeComputeWork` adapts an installed `@bijection/compute` controller. `modelServingSource` declares the separate serving observations. Connections own account identities and credentials. A persistent serving deployment is distinct from the finite command that creates or changes it. ## Train, score and monitor `requestTraining` pins its declared inputs and configuration through the installed custody and execution owners. Its accepted result registers a candidate with the original native work identity. Training success does not approve business use. Batch scoring follows the same work protocol and retains its output separately. Trusted internal decoders record predictions with exact model/input/inference identities. Outcome corrections preserve the prediction association and check an expected revision. Initial quality monitors measure error for the selected candidate and expose missing-label or incomplete populations. Notification occurrences pass through the installed notification owner in the same transaction. Schedule the exposed `evaluateMonitor` operation through the existing Automations component when periodic checks are needed; this library adds no scheduler. `requestInference` provides this path for a native Compute installation: it checks the current published, ready target and retains the exact input version. Accepting the correlated result records its prediction automatically, including the selected candidate, subject and horizon. Native work retains the execution and its result. The reference CPU controller implements training, evaluation, immutable model deployments, batch inference, prediction, disable and persistent command recovery. Its scope is finite synthetic datasets and one process with a private durable directory. Production compute, model packaging and scaling remain provider-owned. ## Bounds and verification The initial monitor admits 256 predictions per window and reports larger windows as incomplete. Use dataset computation for broader populations. Lists page at most 50 records. Native file custody has a finite maximum seven-day grant; expiry never silently renews work. Cancellation alone does not prove remote termination or authorize releasing its input custody. Disable the provider, observe its disabled state and settle the command before `clearTarget` removes its desired binding. Unselected evaluations, suites and candidates have explicit retirement operations that release their independent custody. Authorized lists preserve redacted metadata after retirement or custody loss; retained parameters and inputs remain unavailable. Clearing a binding does not reverse an installed source release. Package checks exercise real JavaScript transactions with controlled execution evidence and a real HTTP controller, including controller restart. They do not qualify native reviews, file grants, PostgreSQL recovery, hosted release flows or provider failures. Run a dedicated Atlas campaign for those boundaries when qualification is requested. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.