Safety

Limits you can inspect, not promises.

We’re working toward Artificial Superintelligence, so we want the safety of our tools to rest on things that can be checked. Here is our approach, and what isn’t solved.

How the languages are designed

Bounded behavior

Implemented profiles define specific limits and refusal behavior. Those boundaries are inspectable, but do not cover every risk.

Replayable results

Runs are designed to be replayed and inspected, so results can be compared and questioned.

Separated authority

PEGS generates tests but can’t score them. VECS can’t change its own criteria. IDNL reviews options but can’t execute them. CXAU audits but is read-only.

Honest accounting

MEMC tracks what context was dropped, APLD records lineage and reports what it couldn’t verify, and FVLR limits its claims to stated assumptions.

What isn’t solved

  • The languages have different maturity levels, and many capabilities remain limited prototypes. Passing internal tests does not establish independent conformance, security or production readiness.
  • Real enforcement depends on the systems around a language. Hosts grant capabilities, and independent controllers must enforce physical safety.
  • KCSL has an offline policy-checking prototype, not live security enforcement or access to keys and hardware.
  • Our tooling still depends on third-party languages.
  • No language can make Artificial Intelligence safe on its own. We don’t claim to have solved the safety of advanced AI or ASI.

See each language’s scope and limits →