Evidence And Readiness

What Evidence Means

Readiness depends on the resolved cell, runtime contract, safety boundaries, adapter behavior, operator approvals, and evidence trail for the deployment path being considered.

Evidence is the record of how a proposed behavior was evaluated.

• Runtime contract references
• Selected OEM compatibility pack
• Safety-zone configuration
• Preview or replay metadata
• Adapter readiness results
• Soak or stability records
• Operator approval records
• Blocked checks and refusal reasons
• Deployment proposal summaries

Why Evidence Matters

Evidence is useful because it turns autonomy from a black-box claim into a reviewable operational record.

Robotic systems fail when intent, control, and safety are treated as one opaque loop.

• What the system believed
• What it proposed
• What was allowed
• What was blocked
• Who approved live operation
• Why the system refused or escalated

Deployment Readiness Report

A Deployment Readiness Report summarizes the readiness state for one deployment path: the active deployment, runtime target, deployment blueprint, OEM compatibility pack, conformance evidence, soak evidence, replay artifacts, and safety intervention history.

The report is designed to answer three questions before production is considered: what has been validated, what evidence exists, and what still blocks readiness.

Xolver does not infer readiness from a successful demo alone. Simulator results, bench tests, hardware-loop validation, operator approvals, and production gates remain separate evidence classes.

Readiness Labels

Readiness labels are explicit status markers shown in Console and evidence records. They are conservative by design and can move backward when evidence expires, a deployment blueprint changes, or a blocking safety event appears.

• demo_only: useful for demonstration or preview, with no claim of deployment readiness
• simulation_validated: validated in supported simulation with replay and evaluator artifacts
• bench_ready: ready for controlled bench evaluation under supervision
• hardware_loop_validated: hardware-loop behavior has evidence for the scoped cell and runtime target
• production_blocked: production cannot proceed because one or more required readiness checks failed
• production_ready: required evidence and gates are present for the scoped production path

Evidence Inputs

A readiness decision combines multiple evidence inputs. Missing inputs are reported as missing rather than guessed from adjacent signals.

• Active deployment and deployment blueprint
• Runtime target and runtime contract references
• OEM compatibility pack and maturity tier
• Conformance results for the selected pack, skills, and adapter behavior
• Soak or stability evidence for the scoped operating envelope
• Replay, evaluator, telemetry, and provenance artifacts
• Safety intervention history, refusals, stops, recoveries, and operator approvals

Production Blockers

Xolver does not casually call a deployment production-ready. Production blockers are reported directly so operators, integrators, and reviewers can see why readiness has not been reached.

Common blockers include missing active deployment, missing runtime target, missing hardware evidence, missing conformance evidence, missing soak evidence, disabled live actuation gate, unresolved safety interventions, stale OEM pack maturity, or a deployment blueprint that no longer matches the tested configuration.

Safety Intervention Taxonomy

Safety interventions are part of readiness, not separate incident trivia. A deployment that repeatedly stops, refuses, or requires supervised recovery should not be promoted without explaining those events.

• Refusal: no valid safe action was available under the active contract
• Constraint stop: a hard safety constraint blocked or halted motion
• Watchdog stop: runtime health, timing, or signal freshness crossed a hard limit
• Operator hold: a human approval, pause, or reset gate was required
• Recovery action: an approved retry, replan, perception refresh, safe-pose move, help request, or abort
• Escalation: the system preserved evidence and required engineering or safety review before continuation

Preview Ready

The cell draft is coherent enough to generate non-executable previews.

Preview readiness may include valid metadata, selected skills, workspace references, and safety-zone definitions. It does not imply permission to move hardware.

Bench Ready

The cell has enough evidence for controlled bench evaluation.

Bench readiness may include adapter readiness records, simulator-backed baselines, soak/stability evidence, and commissioning-stage checks. It still requires controlled supervision.

Supervised Live Ready

The deployment has operator approval, live-actuation gates, hardware-specific checks, and safety I/O validation.

This stage is intentionally conservative. Xolver requires evidence and explicit approval before physical behavior can move beyond preview.

Production Ready

Production readiness is path-specific and depends on real cell validation, operational policy, safety integration, and deployment evidence.

Xolver does not treat simulator-only results as production certification.

This supports safer pilots, clearer operator review, and more disciplined expansion from shadow evaluation to active control.