Skip to content
Join us

Getting started

Vraelis Contour release security

Understand the intended release workflow, recipient responsibilities and limits of the private reference experiment.

Outcome
Distinguish release identity, approval, readiness, managed loading and acceptance evidence.
Does not do
Vraelis Contour is in private development. Release evidence does not establish model safety or protection against a compromised host.

Vraelis Contour is our first product direction within a wider AI cybersecurity company. Its intended users are release, platform and security engineers at robotics suppliers and system integrators. The candidate job is connecting an approved model-bearing release to its receiving environment and an explicit acceptance outcome.

The release unit

Define the complete unit the recipient accepts. It may include the model, preprocessing, configuration, calibration and runtime dependencies, or form part of an application, container or firmware release. Checking a model alone cannot establish compatibility of the whole system.

The intended workflow

  1. Identify the exact release and the assessments that apply to those artifacts.
  2. Establish the recipient authority and bind approval to the release and its destination.
  3. Check candidate compatibility before accepted rollout under the agreed operating policy.
  4. Record what the managed runtime reports loading and preserve failed or uncertain activation.
  5. Let the recipient decide acceptance, continued operation, withdrawal and recovery.

Supplier and recipient responsibilities

The supplier identifies and delivers the release. The recipient owns destination authorization and acceptance. The runtime operator controls installation and recovery. These responsibilities may belong to different organizations; a supplier signature does not grant permission to change a customer's system.

Current reference experiment

A small private ONNX CPU experiment exercises signed model/configuration bindings, destination-bound approval, real synthetic model execution and desired-versus-loaded session reports. It also exposes interrupted activation and an authorized release that fails to load. It is a reference experiment rather than an available robotics integration.

What the evidence establishes

  • A signature authenticates an endorsement of particular bytes; it does not establish benign behavior or absence of backdoors.
  • Loaded-session evidence is a managed-service self-report. The host and worker are trusted; this is not independent attestation.
  • A missing or inconsistent observation remains unresolved. Authorization and successful activation are separate events.
  • Signer revocation and withdrawal of an already running release are separate policy decisions.

Evaluation before integration

A useful evaluation starts with a recurring recipient problem and compares existing signing, deployment, scanning and logging tools. Define the threat, required evidence, availability, recovery and total integration effort before testing a new control. Public workspace access remains closed.