Trust
Everything your review will ask for.
The boundary between Cratis Build, Studio, and Assurance, together with current security, continuity, versioning, and operating practices. Where a formal policy does not yet exist, this page says so.
License
Cratis Build is open
Chronicle, Arc, Components and the operating tools that make up the Cratis Build runtime are developed in public under permissive open-source terms. There is no production feature key for using the runtime or operating your own event history. Check the license in each repository before adopting a package.
Studio and Assurance are commercial
Cratis Studio is the paid collaborative design and runtime- understanding product. It is preview software, and its maturity is stated on the product page. Cratis Assurance is paid access to our time and expertise through support, reviews, first slices and workshops. Neither is a license to operate Cratis Build.
Public Cratis repositories are at github.com/Cratis.
Continuity
What happens if we stop
Cratis Build is developed in public and is intended to run in your infrastructure. Build does not require a Studio subscription or a commercial feature key. Each repository states its own license, and each component's documentation describes its interfaces and storage.
Cratis Studio is a separate hosted, paid Preview product. Build continues without Studio. Studio provides export for supported model content; current formats, retention, and post-subscription access are described by the hosted product and its applicable terms.
Public source and data held in your infrastructure reduce vendor dependency, but they do not make transition work disappear. Your team would still need to assess maintenance, replacement services, data formats, and any migration appropriate to its deployment.
A support agreement can include a continuity commitment. The signed agreement defines its scope, handover, and any financial terms.
The practical claim is narrower: Build source is public, Studio is clearly separated, and leaving still requires an engineering plan.
Open operations
Workbench, CLI and MCP
Workbench, CLI, and MCP are developed alongside Chronicle. Current versions provide inspection and operational workflows for supported concepts; check the documentation for the capability and version you plan to use.
Repair is not a paid permission
A Studio seat or Assurance agreement is not intended to gate Build's available inspection and recovery tooling. Supported mutations should use domain commands or documented Chronicle operations so changes remain visible in the record.
Versioning and support windows
Semantic versioning, taken literally
We follow the industry-standard versioning scheme, and we apply it literally. Any change that could break something you rely on is labeled as a major change — even when calling it something smaller would be more convenient for us. That label is checked automatically before anything ships.
Why our major numbers are high
Some of our version numbers look high. That is not twenty rewrites — it is twenty changes we declared honestly on the day they shipped, rather than quietly folding them into something that sounds smaller. We would rather the number be honest than flattering.
What we haven't published yet
We're writing a formal support-window and long-term-support policy — which majors get security fixes, for how long, and what the upgrade commitment is. It isn't published, because we won't commit to a window we can't currently hold.
If you need to know where a specific version stands before you commit to it, ask us and you'll get a straight answer rather than a marketing one.
What it runs on
Runtime targets, database providers, and compatibility vary by product and version. Review the current compatibility documentation before adoption rather than assuming a universal support matrix.
Test builds
Public registries and pull-request feeds use versioned artifacts. Treat pull-request builds as test artifacts, and check package metadata and release notes before selecting a production version.
Current compatibility baselines are maintained in the documentation: version compatibility. Pin explicit package versions and image tags in anything you deploy.
Security
Reporting a vulnerability
Report it privately through the affected project, or email
oss@cratis.io
with a subject starting Security:. Please don't open
a public issue first.
What to include
Which product and version, what kind of issue it is, how to reproduce it, and what it would let someone do. There is no bounty program — we would rather say so plainly than imply one.
For going live safely, there is a full operational checklist covering security, storage, monitoring and backups: production readiness.
Governance
How decisions get made
Current repositories show changes, reviews, releases, and issue discussions in public. Practices vary by project and are not yet a single formal governance program. Security reports are handled privately first.
Roadmap
Public repositories and documentation show current work and maturity where maintained. Studio is consistently labeled Preview; a repository issue or plan is direction, not a delivery promise.
Data and privacy
What the software sends us
Cratis Build does not require a Studio seat or commercial feature key. Telemetry and outbound behavior can vary by component and configuration; review the documentation and network policy for the version you deploy.
What this website collects
This static site currently declares no analytics script. Third-party font hosting may still receive ordinary web requests from your browser. Review the page source and browser controls for behavior relevant to you.
If we work together
Anything you share under an engagement or support agreement stays confidential, and we won't name you as a customer without written permission. We don't want your credentials or your production data — and we'd rather you didn't have to trust us with them.
Company contact
Talk to Cratis
Cratis is founder-led and works in the open. For supplier or company information required for an evaluation, contact oss@cratis.io.
Who you'd be dealing with
Assurance is founder-led today. The signed agreement defines availability, points of contact, and escalation. More about us →
Terms
The support page lists the fixed-scope engagements and their prices. Ongoing support is agreed on request, and a signed agreement defines the commitments for any engagement.