Skip to main content
Orbit’s public identity should be ambitious without becoming misleading. A consistent communications policy protects users, developers, partners, and the company itself.

​
22.1 Product status labels

Use clear labels such as:
  • Available: released and usable under documented conditions.
  • Beta: available for testing, with known limitations.
  • Experimental: being evaluated and not recommended for critical use.
  • Planned: an intended future direction without a release guarantee.
  • Concept: an illustration or proposal that has not been built as a working product.
  • Retired: no longer supported or available.
These labels should appear consistently in product pages, documentation, demos, and announcements.

​
22.2 Claims and evidence

Every significant claim should have an owner and a source of evidence. Statements about benchmark performance, uptime, customers, certifications, revenue, model size, or user counts must be verifiable and current.

​
22.3 Images and demonstrations

Use genuine screenshots for released features. Clearly label mockups, generated concept art, simulations, and prototype footage. Do not use a concept robot image in a way that implies a manufactured product is available.

​
22.4 Release notes

Release notes should explain what changed, who is affected, known issues, and any migration steps. Breaking changes should be announced with appropriate notice where possible.

​
22.5 Community and support

Support channels should have clear expectations and an escalation path. Public bug reports should avoid exposing credentials, private files, or security-sensitive details. Confirmed security issues should have a responsible disclosure route.