D[AI]NGEN Desktop — Packaged release launched October 21, 2026 · Available for qualified deploymentsRequest Installation →
D[AI]NGEN

PUBLIC DOCUMENTATION

Product Truth Policy

D[AI]NGEN follows a simple rule: verified before marketed.

“Verified before marketed.”

Public product communication distinguishes between:

  • verified product surfaces and facts;
  • narrow validated behaviors with explicit scope;
  • preview functionality;
  • conceptual security models;
  • roadmap direction;
  • capabilities still under validation.

Validated behavior is a narrower layer

A validated behavior is a specific product statement supported by evidence in a defined flow or environment.

It is intentionally narrower than a broad capability category. For example, an evaluated browser upload flow can be described without claiming universal support across browsers, AI destinations, file types, or deployment environments.

The scope and limitation are part of the public claim.

Decision, Discovery, and enforcement are distinct

Discovery recommends configuration; it does not grant access by itself.

An administrator approves the AI-specific access scope.

A management decision is not treated as proof that the endpoint has applied the intended access state. Endpoint application is required before the state is considered effective.

Validated foundation is not fleet-scale administration

D[AI]NGEN has validated an initial central-management foundation in which administrative intent can be sent to an enrolled endpoint and applied locally.

That foundation does not by itself establish full fleet orchestration, group policy at scale, or a generally available enterprise-wide request workflow.

Redaction scope is explicit

Current validated behavior is limited to supported text findings that can produce a redacted copy in scoped evaluated flows.

Partial-document sharing and broader document-format redaction, including PDFs, remain later product direction and are not presented as a current broad capability.

What this means

A feature is not described as shipping simply because it:

  • appears in an internal build;
  • appears in an architecture discussion;
  • appears in a screenshot;
  • is visible in a demonstration;
  • exists in a prototype;
  • is planned for a future release;
  • is validated only in a narrower product flow.

Public claims are intentionally narrower than internal technical development.

This policy is designed to keep security communication precise and verifiable.