Jev knowledge base·verified Sep 22, 2026

jev-latest vs jev-preview

Choose between Jev aliases and a pinned version. As of September 22, 2026, both aliases resolve to jev-1.13.0, but they can move.

the short answer

Use jev-latest for low-risk exploration, jev-preview only when deliberately testing the preview channel, and a pinned ID such as jev-1.13.0 for calibrated evaluators or consequential policies. As verified September 22, 2026, both aliases resolve to jev-1.13.0; that temporary equality does not make them interchangeable contracts. Log the resolved model and replay labeled traffic before accepting an alias move.

Verified
September 22, 2026
`jev-latest` target
jev-1.13.0
`jev-preview` target
jev-1.13.0
Production default
Pin after evaluation
Required log field
Resolved model ID

The Aliases Match Today but Express Different Intent

TypeSafe’s model page currently points both aliases at jev-1.13.0. That is a dated routing fact, not a promise that the aliases move together. jev-latest represents the current stable channel; jev-preview represents the newest preview channel. A versioned identifier names one evaluated artifact.

Choosing an alias delegates upgrade timing to the provider. That can be convenient in a playground and risky in a policy whose threshold was calibrated on a particular distribution. Read the current Jev model card before treating this snapshot as current.

IdentifierUseMain risk
jev-1.13.0Reproducible production and benchmark baselineRequires an explicit upgrade process
jev-latestExploration or low-consequence workflows accepting stable updatesBehavior can change without a code diff
jev-previewDeliberate pre-release evaluationCan introduce behavior not yet accepted for production

Use Different Identifiers at Different Lifecycle Stages

The recommendation depends on consequence, not a blanket ban on aliases. A disposable prototype can favor freshness; an audited evaluator needs repeatability. Keep the identifier in configuration rather than scattered through code so promotion changes one reviewed artifact.

EnvironmentRecommended referenceWhy
Playground explorationjev-latestConvenient access to the current stable channel
Preview evaluationjev-previewSurfaces candidate behavior without redefining production
Regression baselinePinned model IDMakes reruns attributable and reproducible
Production evaluatorPinned model ID plus approved threshold bundlePrevents silent behavior and coverage changes
Production policy signalPinned model ID with rollback targetConsequential actions need controlled promotion

A Model Change Can Invalidate More than Accuracy

A new model may change selected labels, probability calibration, confidence distribution, language slices, sensitivity to state length, latency and rate-limit behavior. Even a quality improvement can move the operating point: a threshold of 0.82 fitted on one version has no automatic statistical meaning on the next.

Version the complete measurement instrument: model, provider, question wording, criteria, state projection and threshold. If two of these change in one release, attribute regressions with a factorial test or change them sequentially. The confidence guide explains why preserving distributions is essential for this analysis.

Pin the Complete Evaluator Bundle

This is an application manifest, not a TypeSafe configuration file. Pinning only the model leaves other behavior-changing inputs implicit. Hash or version the question definition, candidate labels, state projector and threshold logic so a result can be reconstructed later.

Record requested and resolved model separately. A pinned request should resolve to itself; an alias request records both the channel and the artifact that actually served it. If the provider does not expose a resolved upstream version, record that absence rather than inventing one.

{
  "evaluator": "refund-requested@v4",
  "provider": "typesafe-direct",
  "requested_model": "jev-1.13.0",
  "resolved_model": "jev-1.13.0",
  "primitive": "noul",
  "question_version": "refund-requested-v4",
  "projection_version": "support-trace-v2",
  "threshold_version": "refund-bands-v3",
  "client_version": "<pinned-sdk-version>",
  "approved_dataset": "refund-heldout-2026-09"
}

A Safe Alias-to-Pinned Upgrade Pipeline

01DetectPoll or log the alias target and open a candidate release when it changes.
02ReplayRun old and new versions on frozen labeled and adversarial fixtures.
03Dual-runShadow current traffic and compare distributions, actions and latency.
04RecalibrateRefit thresholds on calibration data; keep test data untouched.
05Canary and pinRoll out gradually, record approval and retain rollback.
Resolve, replay, dual-run, approve and pin before a model change affects actions.
  1. Record the alias target, provider, SDK, timestamp and model returned by every response.
  2. Gate on task-specific errors and calibration, not aggregate agreement alone.
  3. Inspect disagreements manually, especially high-consequence and minority slices.
  4. Set rollback triggers for error rate, review volume, latency, cost and service failures.

Change One Layer at a Time When Possible

Use component comparisons for diagnosis and a whole-bundle comparison for the release decision. A factorial design can estimate interactions when several changes must ship together, but it multiplies runs and analysis. At minimum, do not call every changed outcome a “model regression” when the question or state changed too.

ComparisonWhat it isolatesWhat remains confounded
Old vs new model; same provider/question/stateModel-version effect on that routeProvider implementation details
Same model through two providersRoute and adapter effectAny undisclosed upstream differences
Old vs new question; same model/stateInstrument wording effectInteraction with future traffic
Old vs new state projection; same model/questionEvidence-selection effectChanges in source instrumentation
Whole old bundle vs whole candidate bundleEnd-to-end release impactWhich individual change caused it

Compare Versions on Decisions, Distributions and Operations

Use paired results on identical examples. Report the action transition matrix—old allow to new review, old review to new allow, and so on—because average accuracy can stay unchanged while operational behavior moves substantially. Inspect every transition involving a high-consequence slice.

Thresholds belong to a model-and-instrument bundle. Fit candidate thresholds on calibration data, freeze them, then estimate performance once on held-out data. The evaluator validation guide defines the scorecard and regression testing defines CI gates.

DimensionMeasure
Decision qualityPer-class precision/recall or task-specific error costs
CalibrationReliability plot, Brier/ECE and coverage at action bands
Behavior changeAgreement matrix and distribution deltas on identical examples
RobustnessBoundary, long-state, adversarial and multilingual slices
Operationsp50/p95/p99 latency, error/retry rate, throughput and actual tokens
Downstream effectActions, reviews, overrides and observed outcomes

Canary the Candidate with Explicit Stop Conditions

Set numerical values from the application’s evidence and risk appetite; the table does not prescribe universal thresholds. Start with shadow traffic, then route a small reversible segment. A canary without an owner, observation window and automatic or practiced rollback is only a smaller uncontrolled release.

SignalExample stop condition
Critical errorAny independently confirmed new false allow
Review loadQueue demand exceeds staffed capacity for two windows
CoverageScorable or automated coverage falls below approved floor
ReliabilityInvalid responses or timeouts exceed route budget
Latencyp95 end-to-end decision latency breaches the user-path SLO
CostObserved total cost per completed decision exceeds budget

Rollback Is a Data Operation as Well as a Deployment Operation

Keep the previous pinned model available in configuration and retain the question and threshold bundle that belonged to it. If a canary breaches a guardrail, revert the whole bundle. Reverting only the model while leaving a newly fitted threshold can produce a configuration that was never evaluated.

For Jev evals, preserve both versions’ results beside the same trace rather than overwriting history. For Jev policies, record which version generated the signal and which policy version converted it into an action. That provenance is necessary for incident reconstruction.

Detect Alias Movement Before It Becomes an Unexplained Metric Shift

A distribution shift after an alias moves may reflect an intended model improvement, a calibration change or a provider difference. It is still a change that needs attribution. The launch tracker supplies the public chronology; production logs remain the authoritative record of what each request used.

  1. Resolve each alias on a schedule through the supported model metadata or response field.
  2. Compare the observed target with the last recorded target.
  3. Open a candidate evaluation when the target changes; do not update the approved bundle automatically.
  4. Annotate dashboards with alias, provider and downstream model changes.
  5. Retain the old result series and migration report after promotion.

FAQ

Are jev-latest and jev-preview the same?

They both resolved to jev-1.13.0 on September 22, 2026, but they are distinct release channels and may diverge.

Should production use jev-latest?

A low-risk workflow may accept automatic stable updates. A calibrated evaluator or consequential policy should normally pin the tested version and adopt upgrades deliberately.

How do I detect an alias change?

Record the resolved model returned by the service and compare it with the approved version. Also monitor TypeSafe’s model documentation and release communication.

Do I reuse thresholds after an upgrade?

Not without evidence. Replay held-out data, inspect calibration and refit on a calibration split before approving the threshold for the new model.

Sources

Checked against the sources below on September 22, 2026. Model versions, prices and limits change.

  1. TypeSafe AI docs: Models
  2. TypeSafe AI docs: Jev 1.13 jaggedness
  3. TypeSafe AI docs: Introduction
  4. TypeSafe AI docs: Confidence
  5. TypeSafe AI: Introducing System One Models and Jev