Skip to main content
Safety at Vinci

Safety is part of the work.

Open-weight AI gives more people access to powerful tools. Harmful behaviour and misuse can put people at risk. We take that responsibility seriously, before and after release.

Three parts of our approach

Conceptual artwork of Vero reviewing different paths through a test.

Test before release.

In Foundry, our internal testing environment, we examine harmful requests and difficult edge cases. Release reviews consider safety, useful answers, and known limitations together. Each model card records the tests completed, results, and gaps.

Inside Foundry
An open book in the Vinci studio, an illustration of public principles.

Make the principles public.

The Vinci Constitution sets out the behaviour we train toward: honesty, useful answers, and refusing harmful requests. Our planned Vinci Charter will explain responsible use and the obligations we intend to set for customers.

Charter: forthcoming. Current terms and model licences apply.

Read the Constitution
Vero in a quiet research studio, representing continued work after release.

Keep learning after release.

We collect community feedback, continue internal testing, and document what needs improvement. Findings about harmful behaviour and alignment guide future model updates. Releasing a model is one step in that work.

Existing downloads do not change automatically; improvements need a new release.

Share feedback

Tests reduce uncertainty; they cannot guarantee safe behaviour in every situation. Check each model’s published results and limits before using it.

Illustrations are conceptual, not test results.

Read the research and its limits

Work, authority, and evidence

Vinci Contracts publishes types and validators for defining AI work, recording evidence, preserving approval boundaries, and expressing the scope of an assessment.

What this does not establish: These are Vinci implementations, not an adopted standard or certification. Schema validation alone does not establish enforcement by a consuming application.

Read the evidence

Model behaviour and useful answers

Character post-training studies examine unsupported assertions alongside grounded-answer accuracy and refusals. Technical Report 2 found improvements in unsupported assertions but no family met the complete utility-preservation bar.

What this does not establish: A lower judged fabrication rate is not a universal hallucination rate, and it can come with lost usefulness.

Read the evidence

Evaluation integrity

Technical Report 3 documents how an evaluator accepted incorrect programs. The research preserves the failed training result and the measurement failure, so neither becomes a misleading capability claim.

What this does not establish: A pinned, repeatable check can still measure the wrong thing. The replacement evaluator is not qualified.

Read the evidence

Execution and authority boundaries

The public Vinci Code demonstrations show approval, review, and explicit completion states. They make some limits visible during AI-assisted technical work.

What this does not establish: Local guards are not a security sandbox. Records of checks do not independently establish correctness; permissions and deployment still need review.

Read the evidence

Using a model responsibly

Review the actual model, provider, data path, permissions, and human responsibilities for the intended use. Canadian ownership alone does not establish Canadian data residency or the origin of every component. Software pages describe supported modes and their limits.

Published data and policy information

Found something we should test?

Tell us which model you used and what happened. Leave out personal information and secrets.

Contact the team