How we build, and what we refuse to build.

Norvaex is a small lab building a capable model from first principles. That is a serious responsibility, so our constraints are written down before the capability exists rather than after. These commitments are binding on us, and they do not expire when they become commercially inconvenient.

Last updated: this document is versioned with the model.

1. 01

   Controlled, staged development

   Capability is increased deliberately, one scale at a time. Every rung of the parameter ladder is trained, evaluated, and understood before the next begins. We do not scale ahead of our ability to measure what we have already built, and we publish honest state — including when progress is slow.

   • No scale increase without completed evaluation of the previous stage.
   • Internal red-teaming before any capability is exposed publicly.
   • Documented rollback path for every deployed model version.
   • Public roadmap reflects actual state, never projected state.
2. 02

   Security as architecture

   Security is a property of how the system is constructed, not a layer added at the end. The engine is written in C with explicit memory ownership, audited allocation paths, and no reliance on opaque third-party runtimes for core execution. Isolation between tenants is enforced at the process boundary.

   • Memory-safety auditing and fuzzing as part of the build, not a release gate.
   • Least-privilege execution with no ambient network access for inference workers.
   • Encryption in transit and at rest, with customer-scoped key isolation.
   • Full audit traces for agentic actions, retained under customer control.
3. 03

   Your data stays yours

   Customer data never becomes training data. There is no opt-out to find, because there is no collection to opt out of. We do not sell, rent, broker, or share customer data with any third party, and we do not use it to improve models for anyone else — including ourselves.

   • Customer inputs and outputs are never used for training or fine-tuning.
   • No sale, brokerage, or third-party sharing of customer data. Ever.
   • No cross-customer data flow of any kind.
   • Deletion is real deletion, propagated to backups on a published schedule.
4. 04

   No military or defense use

   Auxilium has never been used for military, defense, weapons, or intelligence-targeting purposes, and it never will be. We will not license it, sell access to it, or share data, weights, or derivatives with any military, defense contractor, or intelligence agency — in any country, at any price, under any structure.

   • No weapons development, targeting, or battlefield decision support.
   • No surveillance or population-monitoring deployments.
   • No licensing to defense contractors or intelligence services.
   • This clause survives acquisition, investment, and change of control.
5. 05

   Environmental responsibility

   Training large models costs real energy, and pretending otherwise would be dishonest. We treat compute efficiency as an environmental obligation, not only a cost line: a model written in C that needs fewer cycles per token needs less power for the same result.

   • Efficiency-first engineering to reduce energy per token trained and served.
   • Preference for low-carbon regions and off-peak scheduling for large runs.
   • Reported energy footprint for each major training run.
   • No wasteful redundant runs for benchmark or marketing purposes.
6. 06

   Built for people

   The purpose of this work is to be useful to the people who use it. Enterprise-grade does not mean enterprise-only — the same model, the same privacy guarantees, and the same refusal to monetise attention apply to a single developer and to a large organisation alike.

   • No engagement optimisation, dark patterns, or attention monetisation.
   • No advertising, ever, and no ad-derived profiling.
   • Accessibility treated as a requirement of the interface, not an add-on.
   • Same privacy commitments for individuals as for enterprise customers.