Defense

A model update crosses organizations.

Updates cross organizations

Trained by one team, integrated by another, operated by a third.

An unexpected change is a security and operational risk

A different release, or the wrong destination, changes what the system does.

Reviewers need to read the evidence

What was approved, for where, and what the system reports running.

The workflow, in this area

1. Identify the release.
2. Bind approval to the release and destination. Destination-bound approval: test approval cannot carry into operations.
3. Integrate with a supported runtime.
4. Compare approved and reported.
5. Preserve discrepancies, missing evidence and recovery.

The builder should not be the only judge.

• Security software only. Vraelis does not decide how a system is used.
• Approval apart from the builder. In the experiment, release authorization separates publisher, deployer and approver roles. The trace keeps a receipt digest, not the approver's identity.
• A record kept in order. Every observation is kept, including ones that confirm nothing.

Not claimed

• No deployments in defense systems, and no customers.
• No contracts, security clearances or government authorizations.
• No access to classified or restricted environments.
• No certification, and no claim of fitness for operational use.
• No protection against adversarial inputs or perception attacks.
• No hardware attestation. Runtime identity is a worker self-report.