Versioning and status

These docs describe Culvii v1.0 — the first public release.

What versioning means here

Culvii has three things that version independently.

Component	Versioning	What changes mean
Culvii Kit  @culvii/kit	Semantic versioning. Current: 1.0.x	A breaking change to a primitive's interface bumps major. Adding a new primitive bumps minor. Bug fixes bump patch.
Culvii CLI  culvii	Semantic versioning. Current: 1.0.x	A breaking change to a command's behavior or flags bumps major. New commands or new flags that don't break existing ones bump minor.
Platform  the cloud	Continuously deployed	Public-facing changes that affect Kit or CLI behavior are gated behind opt-in version flags or a deprecation window.

Kit and CLI are released as a pair in v1. They may diverge in later versions if there's a reason; we'll say so explicitly when it happens.

What's stable in v1.0

Stable means: the interface is committed. We will not break it without a major version bump and a deprecation window.

• The agent, model, tool, and workflow primitives in Kit.
• All culvii CLI commands documented in the CLI reference.
• The OAuth login flow (culvii login) and the ~/.culvii/config file format.
• The API key model — ck_dev_…, ck_sandbox_…, ck_prod_… prefixes; SDK initialization via initConfig.
• Workflow lifecycle states: Draft, Published, Live, Disposed.

What's on the roadmap

Designed but not in v1.0. These are referenced in the docs only where it would mislead you not to mention them:

• Memory primitive
• Context and retrieval primitive
• Plan primitive (DSPy-style optimizer)
• Group primitive (multi-agent orchestration)
• Skill primitive
• Governance APIs — declarative permissions via permit(), programmatic policy controls
• Identity APIs beyond the auto-issued DID per agent
• Observability APIs beyond the built-in trace model
• Optimize, Messages, Test primitives
• Cost governance in the operator surface
• Smart Client Worker — running custom tool execution inside your network
• Per-organization SSO (Okta, Azure AD, Ping, SAML)
• Public Platform API with full reference

The full picture is on the Roadmap page. We don't put dates on it; we put intent and direction.

How we communicate breaking changes

When we ship a breaking change in Kit or CLI, we publish:

1. A migration guide in Changelog & migration.
2. A deprecation warning in the previous minor release that mentions what's changing and when.
3. A clear note in the release announcement.

We try to make the migration mechanical wherever possible. Where it can't be, we explain why.

What's not covered by versioning

A few things you should expect to evolve without a version bump:

• Documentation. We rewrite pages whenever we can do it better.
• The Console UI. Behaviors that the SDK or CLI depend on are version-stable; UI layout is not.
• Internal platform implementation. The interfaces are stable; what's behind them isn't, and that's intentional.

Filing bugs and feedback

Today, by email at support@culvii.com. A public issue tracker is on the roadmap.