Which open-source alternative to Arize evaluations fits your workflow
If your renewal, licensing review or data control requirement touches Arize AX online evaluations, datasets and experiments, the practical answer is that no single open-source tool covers every one of those features, so you should pick by workflow. For production trace scoring with human review, self-hosted Langfuse is the closest match. For a Phoenix-based setup that keeps Arize's instrumentation, Phoenix runs its own LLM-based evaluations, versioned datasets and experiments. For CI gating before a release, promptfoo fits well. Each choice changes how evaluator templates, scores and review queues move, so decide the workflow first and then the tool.
Licensing is the first filter. Phoenix is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved, and it forbids offering the software to third parties as a hosted or managed service. Internal self-hosting is the use case its docs describe, but your legal team should read the Phoenix LICENSE file before standardizing on it. Langfuse core is MIT licensed outside its enterprise directories, and Opik is Apache-2.0 with evaluations included in the self-hosted platform. If an OSI license is a requirement, Langfuse or Opik narrows your choices, and you should confirm which features in your plan sit behind an enterprise key before you sign off.
Human review is the step most likely to need new tooling. Langfuse provides annotation queues and manual scores in its UI, which covers reviewer workflows that Arize users may run today, but you should confirm how your reviewers, roles and retention needs map to the self-hosted deployment. Promptfoo does not replace production review, so it works best as a pre-release gate beside whichever platform holds your traces. Ask your team to list every evaluator, dataset and review step they use in Arize AX, then test each one against the candidate tool before planning a migration.
Map each Arize evaluation capability to an open-source option
This table maps each Arize AX evaluation capability to the open-source option that covers it, with notes on gaps you should confirm before migrating. Read each row as a starting point: where the researched facts do not confirm a feature, the cell says so and names what to check with the vendor. The main takeaway is that Phoenix, Langfuse, Opik and promptfoo cover most evaluation needs, but annotation workflows and CI gating are split across tools.
| Arize AX capability | Open-source option | Coverage notes |
|---|---|---|
| Online evaluations on production traces | Langfuse or Opik | Langfuse runs LLM-as-a-judge scoring on live production traces. Opik offers online evaluation rules. Confirm trigger, sampling and latency behavior in your environment. |
| Datasets and versioned test sets | Phoenix | Phoenix lists versioned datasets in its README. Langfuse and Opik also provide datasets. Check that dataset versions map to your existing Arize exports. |
| Experiments against datasets | Phoenix, Langfuse or Opik | Langfuse runs experiments from the UI, SDK or OpenTelemetry. Phoenix and Opik list experiments in their feature sets. Confirm how each records run comparisons. |
| LLM-based evaluators | Phoenix, Langfuse or Opik | Phoenix offers LLM-based evaluations, Opik ships LLM-as-a-judge metrics for hallucination, moderation and RAG, and Langfuse supports LLM-as-a-judge. Port your evaluator prompts and confirm judge model settings. |
| Code-based evaluators | Langfuse | Langfuse documents code evaluators with scores sent via API or SDK. Confirm equivalent support for any custom Arize evaluators in Phoenix or Opik. |
| Annotation queues and human review | Langfuse | Langfuse provides annotation queues and manual scoring in the UI. Phoenix and Opik do not have a confirmed equivalent in the facts, so confirm review workflows, reviewer roles and queue exports before choosing. |
| Prompt-linked evaluation | Langfuse, Phoenix or Opik | All three link evaluations to prompts or traces in their documentation. Confirm that prompt versions attached to experiments survive the move, since prompt IDs and labels differ between tools. |
| CI regression checks | Langfuse experiments in CI or promptfoo | Langfuse CI/CD experiments can block deploys on regressions. promptfoo is a separate open-source option for CI gating. Confirm whether promptfoo's assertions can reuse your existing evaluator logic. |
| Self-hosted deployment of evaluation data | Phoenix, Langfuse or Opik | Phoenix self-hosts free with no usage limits. Langfuse needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage. Opik needs ClickHouse, MySQL and Redis. Confirm sizing for your trace volume. |
Which open-source evaluator fits which Arize workflow
Arize AX bundles tracing, online evaluations, datasets and experiments in one product. The open-source replacements split those jobs across tools, so the choice depends on where your evaluations run: on live traces, against datasets, inside a pull request, or in a human review queue. The cards below set out when each option fits and what it costs you.
Phoenix for in-house evaluation
Phoenix is the closest match for teams that stay on Arize's OpenTelemetry and OpenInference instrumentation. It offers LLM-based evaluations, versioned datasets, experiments and prompt management, and it self-hosts with no feature limits, using SQLite by default or PostgreSQL through PHOENIX_SQL_DATABASE_URL. The trade-off is the Elastic License 2.0, which is source-available rather than OSI open source and bars offering Phoenix to third parties as a hosted service. Have counsel confirm that your internal use fits those terms before you standardize on it.
Langfuse for production trace scoring
Langfuse fits teams that need LLM-as-a-judge scoring on live production traces, annotation queues for human review, and CI/CD experiments that can block a deploy on regressions. Its core is MIT licensed, but code in the ee directories sits under a separate enterprise license, and some governance features need an enterprise license key. The cost to plan for is the stack behind it: PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, which your team operates and upgrades. Confirm which annotation and evaluator features you need against the current docs.
Opik for metric-heavy evaluation
Opik is Apache-2.0 licensed, and its README states that the server, web application, tracing, evaluations and prompt management can be self-hosted without a commercial license. It ships LLM-as-a-judge metrics for hallucination, moderation and RAG, plus online evaluation rules that score traces as they arrive. It fits teams that want an OSI-licensed option with built-in metrics. Its infrastructure runs on ClickHouse, MySQL and Redis, so check that your operations team can run that combination, and confirm how its annotation and review features compare with your current queues.
Promptfoo for pre-deploy checks
Promptfoo is a CI-focused option for running prompt and model checks on every change, before anything reaches production. It fits teams whose main need is regression testing in pipelines rather than scoring live traces or managing human review. The trade-off is scope: it does not replace a tracing backend, so you will still need one of the platforms above for production observability. Confirm its current evaluator types, reporting and self-hosting details against its own documentation, since this page does not restate them.
How evaluation templates and scores move, by asset type
Online evaluators score production traces as they arrive. Their judge prompts, scoring scales and target spans are the parts most likely to differ between Arize AX and the open-source tools, because each platform attaches evaluators to traces through its own configuration. Langfuse runs LLM-as-a-judge scoring on live production traces and stores the results as scores. Phoenix provides LLM-based evaluations that run against traces and datasets, and Opik offers LLM-as-a-judge metrics for hallucination, moderation and RAG along with online evaluation rules. Treat the exported text of each judge prompt as a reference, not as a drop-in configuration.
- Judge prompts: Copy the template text and variables from each Arize evaluator, then rewrite the variable mapping for the target tool's trace fields.
- Score names: Choose names that match the old names where you intend to compare history, and record any renames in a mapping table.
- Scoring scales: Confirm whether the old evaluator returned labels, booleans or numeric values, and set the new evaluator to the same type.
- Span targeting: Re-create filters so each evaluator runs on the same span types it covered in AX.
- Backfill: Decide whether to re-score historical traces, which costs judge model calls and must be scoped in advance.
Before cutover, run old and new evaluators on the same sample of traces and check that the scores agree closely enough for your thresholds.
Datasets and experiments carry most of the reusable evaluation history. Phoenix supports versioned datasets and experiments, Langfuse supports datasets with experiments run from the UI, SDK or OpenTelemetry, and Opik provides evaluation metrics and experiments on its platform. Dataset rows usually export cleanly as tabular data, but experiment results depend on the evaluator that produced them, so the scores are only comparable if the evaluator is rebuilt faithfully. Export both the dataset and the experiment results from AX before you decommission anything.
- Dataset rows: Export inputs, expected outputs and metadata, then load them into the target as a new dataset with a version label.
- Experiment results: Keep the AX run outputs as static files, since they cannot be replayed without the original evaluators.
- Evaluator rebuild: Recreate each evaluator in the target tool and run it against the migrated dataset to produce a baseline.
- Run identifiers: Store the AX experiment name and ID in the new run metadata so each comparison can be traced back.
- Version history: Note that dataset versioning and experiment semantics differ by tool, so confirm how each handles edits to rows.
The comparison you need is between old AX scores and new baseline scores on the same dataset rows, not between the two tools' absolute values.
CI gates are the evaluations that block a release when quality drops. They are usually the simplest to move because they run from code, but they also depend most on thresholds and score names defined in pipeline files. Langfuse documents CI/CD experiments that can block deploys on regressions, and promptfoo is a common open-source choice for running prompt tests in CI. Phoenix and Opik can also run evaluations from code. The move is less about the tool and more about keeping the pass or fail rules consistent during the transition.
- Pipeline definitions: Find each job that calls AX evaluators and list its inputs, thresholds and failure conditions.
- Thresholds: Recalibrate thresholds on the new scores, because a judge with different wording may produce different distributions.
- Parallel runs: Run the old and new gates side by side for a period, and record where they disagree.
- Secrets: Move judge model API keys and tool tokens into your CI secret store, not into pipeline files.
- Score history: Write the score values from each run to a shared store with the tool name and evaluator version, so trend charts stay continuous.
When a gate is shadow-run, confirm the owner of each threshold has signed off on the new values before the old gate is removed.
Which human review steps need new tooling
Most of the Arize evaluation workflow can be moved to open-source tools, but the human review steps need explicit planning, because the tools differ in how much of the review process they cover. Those steps are labeling production traces, reviewer queues, correcting judge scores that a reviewer disagrees with, and sign-off before a prompt change ships. Map each one to a named owner and a tool before cutover, and decide which of them still happen outside the platform, for example in a ticket or a spreadsheet, so nothing falls through the gap.
Langfuse covers the most of this list directly. Its documentation describes annotation queues and manual scores entered in the UI, so reviewers can work through flagged traces and overwrite or confirm automated scores. Those manual scores can also be written through the API or SDK, which lets you keep a corrected score attached to the same trace. For Phoenix and Opik, you must confirm with each project whether annotation, reviewer assignment and score correction meet your needs, including how reviewers are granted access and whether corrections are kept separately from the judge's original score. Ask for a written answer on each point rather than assuming parity with Arize.
Before cutover, run a small pilot with the people who will do the real reviews, using a sample of recent production traces and the same judge prompts you use today. Measure whether reviewers can finish a batch, whether their corrections show up where the release owner looks, and whether sign-off is recorded in a way an auditor could follow. Use the pilot to settle the sign-off step itself, such as whether a prompt change needs a recorded approval in the tool or in your change management system, and document that decision before the old Arize review queues are switched off.
Running evaluations alongside the rest of your LLM stack
Most teams do not replace their whole LLM stack at once. Tracing, gateways, evaluators and CI checks often run side by side during a migration, and each pairing has one integration point where data can be double counted. The cards below name those points and the checks to run before evaluators are moved.
Phoenix evaluations beside Arize AX tracing
Teams that keep Arize AX for production tracing may run Phoenix's LLM-based evaluations against exported datasets or a separate Phoenix instance. Both products use the same OpenInference instrumentation, so one span can be sent to both backends. Check which endpoint each application exporter points to, and confirm that evaluation scores are written to one system of record so the same trace is not scored twice. Phoenix is licensed under the Elastic License 2.0, so confirm that internal use fits your terms.
LiteLLM logging to Langfuse or Opik
The LiteLLM AI Gateway can log requests to Langfuse, Datadog, OpenTelemetry and Prometheus. If the application also uses a Langfuse or Opik SDK, each model call may appear as two traces with different IDs. Decide which layer owns the trace: the gateway for model-level spans and logs, or the application SDK for agent steps. Then disable the duplicate callback and check that token counts and costs are not summed twice in dashboards.
Keeping a Portkey or LangSmith tracing layer
Some teams keep Portkey's gateway logging or LangSmith tracing while moving evaluators to Langfuse or Opik. Portkey's hybrid deployment keeps the gateway in your VPC and calls out to its control plane, so confirm which logs still leave the network. Where LangSmith tracing stays on, confirm whether its traces and the new evaluator's traces reference the same run, so scores are attached once and reviewers do not see two copies of the same output.
promptfoo in the existing CI system
promptfoo can run prompt and model test suites from a command line step, so it fits into a pipeline your team already operates. Its results are pass or fail assertions per test case, which are different from live production scores. Store the threshold and test set in version control, decide which pipeline gates a deploy, and avoid writing the same regression result to both promptfoo output and a Langfuse experiment, which would make dashboards disagree.
Scores written by two evaluators
When an LLM-as-a-judge rule in one platform and a metric in another both score the same production traces, the results can disagree and both appear in reports. Pick one evaluator per quality dimension, record the evaluator name and version as score metadata, and remove the old online rule before enabling the new one. Otherwise averages and alert thresholds will mix scores from two different judge models.
Human review queues outside the evaluator
Annotation queues in Langfuse and review workflows in other tools usually write human scores back to the trace. If automated judges and reviewers write to the same score name, reviewers may overwrite or be compared against the wrong run. Use separate score names for human and automated results, confirm how each tool stores reviewer identity, and check that exported datasets keep both values so you can measure judge agreement over time.
How to move evaluators, datasets and scores off Arize AX
This sequence moves Arize AX online evaluations, datasets and experiments onto a self-hosted platform while keeping scores comparable and human review intact before the Arize schedules are switched off.
Inventory evaluators, datasets and experiments
The evaluation owner lists every online evaluator, its judge model and prompt template, its sampling and filter rules, each dataset with its version history, and each experiment that a release or dashboard depends on. Record which annotation queues and human labels feed each evaluator. Confirm with Arize, in its current documentation or support channel, which formats its export tools produce for evaluator definitions, dataset rows and scores, because export options can differ by product tier and version. The output is a register that names each item, its owner and whether it must be carried over, rebuilt or retired.
Decide the target for each workflow
The platform owner maps each workflow in the register to a target. Phoenix covers LLM-based evaluations, versioned datasets, experiments and prompt management under the Elastic License 2.0, which is source-available rather than OSI open source and bars offering it to third parties as a hosted service. Langfuse covers LLM-as-a-judge on live traces, annotation queues, datasets, experiments and CI/CD checks under an MIT core with enterprise-only features outside it. Opik covers LLM-as-a-judge metrics, online evaluation rules and prompt management under Apache-2.0. Record one target per workflow, plus the license review that the legal team needs to sign off on. The output is a decision table approved by the owner of each workflow.
Stand up the self-hosted platform and its databases
The platform team deploys the chosen tool in the organization's own cluster or host. Langfuse requires PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and its production path is Kubernetes with Helm or Terraform. Opik uses ClickHouse, MySQL and Redis and deploys with Helm for production. Phoenix starts on SQLite by default and can use PostgreSQL through its configuration variables. Size the ClickHouse and object storage for the retention you need, and check the resource minimums in each project's scaling guide. Confirm that single sign-on and role mapping work before any user gets access. The output is a running instance with backups tested, health checks passing and access restricted to the right groups.
Repoint OpenTelemetry or OpenInference exporters
The application team changes the trace exporter endpoint and headers so new spans reach the self-hosted platform. Teams already using OpenInference instrumentation can keep the same instrumentation with Phoenix, since the README says it works with both Phoenix and Arize AX. For Langfuse and Opik, confirm which attributes and span names their OpenTelemetry ingestion maps to traces and scores, and test that attribute mapping on a staging service. Keep the Arize exporter in place for the moment so both paths carry the same traffic. The output is a trace in the new platform for each instrumented service, with inputs, outputs and token counts matching the Arize trace for the same request.
Recreate datasets and judge templates
The evaluation engineer rebuilds each dataset in the target tool, using the exported rows from the inventory step and reshaping columns where the target expects different field names. Rewrite each judge prompt, its score labels and its output parser in the target's evaluator format, and record the judge model and temperature settings alongside them. Where a Phoenix, Langfuse or Opik built-in metric matches an AX evaluator, compare the built-in definition with the original before using it, because the prompt text and scoring scale may differ. The output is a version-controlled set of datasets and evaluator definitions with a changelog that links each new evaluator to the Arize evaluator it replaces.
Run old and new evaluators side by side
The evaluation engineer runs the Arize evaluator and the new evaluator on the same sample of production traces for a period agreed with the evaluation owner. Compare scores per trace, look at disagreements, and check that the judge model you chose behaves consistently across the sample. Where the scales differ, document a mapping rather than forcing the two to match. Also run the new CI/CD experiment or regression check on a known good and known bad release candidate to confirm it blocks what it should. The output is a written comparison signed off by the evaluation owner, listing accepted differences and any evaluator that must be changed before cutover.
Move human review to new tooling
The quality lead recreates the review workflow in the target platform. Langfuse provides annotation queues and manual scoring in its UI, while Phoenix and Opik need reviewers to work through the review features each of them offers, so confirm those features cover the queue, assignment and label export you need. Migrate existing human labels as scores or dataset items using the exported data, and check that reviewer identities and labels survive the move. Set reviewer access through the platform's role model. The output is a working review queue in the new tool, with a test batch of historical labels reconciled against the Arize records.
Retire the Arize scheduled evaluations
Once the side-by-side comparison and review migration are signed off, the platform owner turns off the Arize online evaluators one at a time, starting with those that feed alerts and release gates. Keep a read-only copy of the Arize datasets, experiments and scores for audit and retention requirements, and confirm the retention terms for that export with Arize. Remove the Arize exporter from each service only after the new path has run without gaps. The output is a documented cutover record listing each retired evaluator, the replacement, the date of the switch and where the archived evaluation history is stored.
What drives the cost of self-hosted evaluation
The licence fee is the smallest line in a self-hosted evaluation stack. Phoenix carries no license fee under its self-hosting terms, Langfuse core is MIT licensed, and Opik is Apache-2.0 with the full platform, including evaluations, available without a commercial license. The recurring costs sit elsewhere: the infrastructure the platform needs, the LLM judge calls you pay your own model provider for, and the people who tune evaluators and review scores. Langfuse is the component with the most infrastructure to price. Its self-hosted deployment runs Langfuse Web and Worker containers alongside PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, and its scaling guide lists minimum resources for each. ClickHouse is usually the largest item, so the retention period and trace volume you expect should drive your sizing.
Some costs are one-time and others recur. Setup, the first evaluator and dataset migration, and the initial CI gate are one-time efforts. Running the cluster, storage growth, judge model tokens, upgrades and the review queue recur every month. Upgrades deserve a line of their own: Langfuse applies database migrations automatically within a major version, but major upgrades such as v3 to v4 follow separate guides that require newer ClickHouse, PostgreSQL and Redis versions and advise extra ClickHouse disk headroom during historic backfills. Budget that work for each major release, and confirm the current requirements in Langfuse's upgrade guide before you schedule it.
When you request a quote from a provider or implementation partner, ask for each component as a separate line: the license or support tier (Langfuse's Enterprise license key covers features such as audit logs, SCIM and data retention policies, and the Enterprise plan adds a support SLA), the infrastructure sizing for your expected trace volume, the upgrade and backup responsibilities, and the hours assumed for evaluator tuning and annotation review. Ask which judge models the quote assumes and whether judge tokens are excluded, since those are billed by your own provider. Confirm with each vendor which features require an enterprise key before you compare totals, because a free core deployment can still need paid features for SSO or access control.
Questions teams ask before replacing Arize evaluations
Can I offer Phoenix to my customers as a hosted service under the Elastic License 2.0?
No. The Elastic License 2.0 that covers Arize Phoenix forbids providing the software to third parties as a hosted or managed service. Running Phoenix for your own internal teams, in your own infrastructure, is the use the license is built around, and the Phoenix self-hosting docs describe it as free with no feature limitations, no license fees and no usage limits. Phoenix is also source-available rather than OSI-approved open source. If your product exposes LLM tracing or evaluation to customers, or you are a managed service provider, ask counsel to review the terms against your model, or choose Langfuse (MIT outside its ee directories) or Opik (Apache-2.0), which do not carry that restriction. See the Phoenix LICENSE file for the exact wording.
Which self-hosted option covers CI regression gates for LLM evaluations?
Langfuse and promptfoo are the strongest fits for blocking deploys on regressions. Langfuse documents CI/CD experiments that can block deploys when quality drops, alongside datasets, experiments run from the UI, SDK or OpenTelemetry, and code evaluators. promptfoo is a separate open-source CLI that runs evaluation suites inside a pipeline and fails the build on threshold breaches, so it works well when you want the gate in the repository rather than in the observability server. Phoenix provides LLM-based evaluations, versioned datasets and experiments, and Opik offers LLM-as-a-judge metrics and online evaluation rules, but confirm the exact CI gating behavior of each in your pipeline before you commit. Most teams keep one system as the source of truth for scores and use the other as the gate.
How long does an evaluation migration take, and what does it depend on?
No duration can be stated for this migration from the supplied facts, so treat any figure you hear, including from us, as something to confirm against a written scope. The main drivers are the number of evaluators and prompt templates you must rebuild, the size of your versioned datasets and whether you need historical scores, the number of applications that emit traces, and whether you need to run old and new evaluations side by side for a period. Work on infrastructure (Kubernetes, PostgreSQL, ClickHouse, object storage) also adds time if your platform team has not provisioned it. Ask any provider for a phased plan with the evaluation inventory as the first deliverable.
What does my team need to provide for the migration?
Plan for four kinds of input from your own team. First, owners for each evaluator and rubric, because the judgment behind a score is rarely written down in the Arize AX project. Second, access to the platforms that will host the new stack, such as a Kubernetes cluster, database and object storage accounts, and secrets handling. Third, a sample of production traces and labeled examples so the new judges can be checked against past human decisions. Fourth, a reviewer for the annotation queues, since human review steps must be re-created in whichever tool you choose. Engineers will also need to repoint instrumentation, so confirm who owns the application code changes.
Can we run this migration without an implementation partner?
Yes, if your team has Kubernetes or Docker operations experience, a clear evaluation inventory and someone accountable for scoring quality. Phoenix can run from a single terminal or Docker setup, and Opik and Langfuse have documented Docker Compose paths for testing. Production setups are heavier: Langfuse production uses Kubernetes with Helm or Terraform, and its self-hosted deployment runs Web, Worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage. Teams without that capacity usually bring in outside help for the infrastructure and evaluation rebuild, then run it themselves. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own environment under a written, fixed scope, and offers retainers for ongoing upgrades and support.
What does a Langfuse enterprise license key unlock?
A Langfuse enterprise license key unlocks a specific set of features in self-hosted deployments, not core tracing or evaluation. According to the Langfuse license key documentation, these include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, and the org management API with SCIM plus the instance management API. The core features and APIs, including evaluations, datasets and experiments, are in the MIT-licensed version without limits. Confirm your needs against that list. If audit logs or SCIM are required by your controls, budget for the key; the Self-Hosted Enterprise plan on the Langfuse pricing page also adds a named support engineer and a support SLA, so ask Langfuse for the current terms.
How do evaluation templates and scores move from Arize AX?
Templates and scores do not move automatically. Export your datasets and scores from Arize AX, then recreate each evaluator as a judge prompt in the new tool, because LLM-as-a-judge definitions are tied to the platform that runs them. Keep the rubric text, the judge model and the pass threshold in version control so the definition survives the move. Re-score a held-out set of past traces with the new judge and compare results with the old scores before switching production traffic, so you can see where the two disagree. Score history from Arize will usually stay in an export archive rather than in the new platform, so decide with stakeholders whether you need it queryable.
How DeployOpen scopes and delivers an evaluation platform replacement
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For evaluation replacements, we start from the evaluators, datasets and review steps you already run, then agree in writing what moves, what gets rebuilt and what stays manual.
How we scope
- Inventory every Arize AX online evaluator, dataset, experiment and annotation workflow your team relies on today.
- Decide which platform covers each item: Phoenix, Langfuse, Opik or promptfoo in CI, with the license terms for each.
- Agree a fixed scope, deliverables and timeline in writing before any work starts, with a quote following from that scope.
- Confirm which human review steps need new tooling, such as annotation queues, and who signs off on scores.
How we build
- Deploy the chosen platform in your cloud account, data center or air-gapped network, using the supported Kubernetes or Docker methods.
- Recreate LLM-as-a-judge evaluators and map score names, scales and thresholds from the Arize definitions.
- Repoint OpenTelemetry or OpenInference exporters and test that traces and scores arrive with the expected attributes.
- Wire evaluation experiments into CI/CD so regressions can be checked before a deploy, where the chosen tool supports it.
How we hand over
- Document the architecture, data stores, backup routes and each evaluator's prompt, model and scoring logic.
- Provide runbooks for upgrades, scaling decisions and access roles, including which features need an enterprise license key.
- Record the parity checks run between Arize outputs and the new platform, so reviewers can see what changed.
- Hand over credentials, configuration and evidence in a form your auditors and internal reviewers can read.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan major version upgrades as separate work items, with migration steps and rollback points agreed in advance.
- Re-run security testing of the evaluation stack and its AI components when models, prompts or integrations change.
- Confirm with your team which support tier, retainer scope and response expectations apply before engagement.
