# Versioned intelligence | Call1 Technical Features > How a candidate model is evaluated against a frozen holdout on your own deployment, what your approval gates, and how every verdict stays traceable. Source: https://call1.cc/features/versioned-intelligence --- [CALL 1](https://call1.cc/) [All features](https://call1.cc/features) [RFP reference](https://call1.cc/features#technical-reference) [Pricing](https://call1.cc/contact) [Talk to us](https://call1.cc/contact) [Features](https://call1.cc/features) / Versioned intelligence 06 / Model registry, evaluation, and controlled change # Upgrade the model without changing a verdict you already published. How a candidate model is evaluated against a frozen holdout on your own deployment, what your approval gates, and how every verdict stays traceable to the model that produced it. In this article Why it matters How it works Technical shape Data boundary Performance What it doesn't do What to validate ## Why it matters Speech, embedding, tone, and scoring models keep improving, and you should be able to take that improvement without reopening a year of QA decisions. Every component sits behind a versioned output contract, so you can swap in a better model underneath the workbench without changing the shape of a verdict. The failure worth guarding against is a model that ships on its own and changes results people have already reviewed. When an agent disputes a score from two months ago, “which model said that?” has to have an answer. Every verdict records the base model and adapter version that produced it, and re-scoring under a newer adapter writes a new result beside the old one. Your reviewers' corrections are the training data. Every confirm and override in the workbench is a labeled example for that question's adapter, and you approve what ships. Those labels accrue slowly, so a retrain triggers when enough new labels land on a question, not on a nightly clock. ## How it works 1. **Register what's running** Each speech, embedding, text, tone, fusion, and QA component carries an identifier, a version, a license record, runtime requirements, and the output contract it satisfies. That registry is what a verdict's lineage points at. 2. **Run the challenger beside the champion** The approved production model stays the champion. A candidate scores the same eligible calls at the same time, and its output stays out of the workbench, so your reviewers keep working champion verdicts while the comparison accumulates. 3. **Score it against a frozen holdout** The candidate is measured on a holdout set drawn from your own calls, which it never trained on: per-question accuracy, confidence calibration, disagreement with your reviewers' adjudications, throughput, and failure behavior on your hardware. A candidate that regresses on a compliance-critical question is not promoted. 4. **Promote when you approve it** Promotion is a named person's decision and an entry in the audit log. It changes the active version for calls scored from that point on. The version it replaced stays on the box for rollback and for reading older output. 5. **Read the lineage on any verdict** Each stored verdict keeps the base model version, adapter version, rubric version, and fusion policy that produced it. Months later you can answer which model scored a given call. Reprocessing writes a new versioned result and leaves the original in place. ## Technical shape ### The output contract Per-chunk and per-question schemas sit between the models and everything downstream. A model may change as long as it satisfies the versioned contract, so the workbench, the exports, and your rubric hold still when it does. ### What a verdict records Tier used, base model version, adapter version, rubric version, confidence, and the evidence span. The lineage is on the row, so “which model said that?” is a lookup. ### The serving seam One model backend protocol separates the runtime used in development from the one serving production. Application code requests a scoring task and does not depend on which runtime answers it. ### The evaluation record Candidate version, holdout version, per-question metrics, hardware, throughput, comparison date, approver, and the promotion decision. A model change on your deployment carries the evidence that authorized it. ### Adapters on a shared base Each semantic question is a small adapter over one resident base model. Edit the script behind one check and that adapter retrains; the other forty and the base underneath them stay where they are. ## Data boundary and privacy > Promoting a model changes how future calls are scored; the verdicts already on your record stay as they are. Evaluation and retraining both run on your deployment, against your calls and your reviewers' adjudications. Comparing a new speech, tone, or scoring model does not require call content to leave your boundary. An adapter trained on your calls can memorize what it was trained on, so it stays on the deployment that produced it. There is no adapter pooling across deployments today, and any export would take a validated sanitization step and your written approval. Model and adapter bundles arrive as signed offline files you can inspect and install without an outbound registry or a hosted control plane. An air-gapped deployment upgrades the same way every other deployment does. ## Performance ### Quality and throughput are judged together A candidate that wins on accuracy and doubles your processing lag is the wrong production choice. Promotion criteria include per-question quality, call-hours a day, memory headroom, and stability on the hardware you run. ### Challengers run on a budget Shadow evaluation gets an explicit window and a compute allowance. Production scoring keeps priority, so a comparison in flight does not push expedited calls past minutes or the rest past morning. ### Retraining has its own window Training and inference compete for the same GPU. Retrains run in the overnight window the capacity model reserves, and a retrain that overruns costs you scoring capacity the next morning. ## What it doesn't do - A promotion changes future scoring. It does not rewrite a verdict, an adjudication, or an audit-log entry already written. - Nothing promotes itself. Your reviewers' corrections train the adapter, and a person you name approves what ships. - Licensing gates a model as much as accuracy does. Research-only or ambiguous weights stay out of a commercial appliance whatever they score on a benchmark. - Corrections from the review queue only teach the model about calls it already flagged. Measuring what it missed takes a random sample of unflagged calls routed to a reviewer as an audit stream. - Reprocessing old calls under a newer model produces a second versioned analysis you can compare with the first. The original stays readable. ## What to validate before deployment 1. Which per-question metrics gate a promotion, and what regression on a compliance-critical check blocks one outright? 2. Who owns the holdout set, how is it kept out of training, and how often is it refreshed? 3. Which named roles may approve a model change, and where does that approval land in your audit trail? 4. How are model licenses, checksums, runtime dependencies, and rollback artifacts recorded for a reviewer who asks? 5. What compute may challengers consume before production processing lag moves? 6. Which learned artifacts, if any, may ever leave your deployment, and what test makes that safe? [Previous feature **Private deployment**](https://call1.cc/features/private-deployment) [Continue to **RFP reference**](https://call1.cc/features#technical-reference) ## Evaluate it in your environment. We'll map this feature to your data boundary, call volume, acceptance criteria, and operating responsibilities. [Talk to us](https://call1.cc/contact) [CALL 1](https://call1.cc/) Every call. Inside your boundary. [Pricing](https://call1.cc/contact) [hello@call1.cc](mailto:hello@call1.cc)