Skip to main content
k0rdent publishes four categories of content — API docs, changelog/release notes, product guides, and blog posts — using AI to draft, humans to review, and automated quality gates to enforce standards. Everything ships publicly as part of our build-in-public strategy to establish market leadership in AI infrastructure. Non-negotiable: A human reviews every piece of published content. AI accelerates — it doesn’t replace editorial judgment.

Content Types

Today there are 4 content types k0rdent AI is targeting

Future content types?

Style Guide

  • We are industry leaders, we want to be the authorative expert on AI, Kubernetes, and Cloud Native.
  • Always be humble, genuine, and authentic. We do not want to come off as know it alls, we want to share with the community.
  • Build in public, be transparent, and collaborative.
  • Always maintain an optimistic and professional tone but have fun and don’t be afraid to have some character. Make fun ascii art in protoype loading screens or setup AI experiements with super overkill specs for mundane tasks. Yes you should build an AI app that answers Slack messages on your behalf.

API Documentation

API Rules

  • OpenAPI v3.1.1 at least is required.
  • Use real world examples versus contrived examples.
  • It’s not good enough to just have auto-generated OpenAPI documentation.
  • The documentation should be a useful tool for developers to use.
  • It should have a good balance of technical detail and ease of use.
  • There should be helpful information on what the API is for, how to use it, and how to troubleshoot it.
  • There should be feedback loops for users to report issues or give feedback.
  • Must use OAS not just follow OpenAPI spec.
  • Use OpenAPI linters (spectral, inso, tbd what we standardize on).
  • Follow established common structures, request, and response envelopes.

Public documentation sites

  • docs.mirantis.com
  • docs.k0rdent.ai
  • docs.???.io

Changelog & Release Notes

Changelogs

Are for more technical or casual audiences which want to see a regular stream of updates being made to our products. Users should know that we’re working hard on regularly updating and improving the product.

Release Notes

May be on the same cadence as Changelogs or may not but the important part is that these are meant to be human readable and tell a story. A story about a critical feature or milestone we want to share. It can be a brand new feature we’re excited to share or about a decision point/experimental feature that we’d like to get our users feedback on. This is a more polished community interaction.

Channels

  • In-app notifications
  • Dedicated release notes or changelog pages or blog posts with a release notes or changelog tag
  • Social media posts
  • GitHub
  • ???

Product Documentation & Guides

Blog & Social Media