# Compatibility and launch status

Separate documented contracts from verified hosted behavior.

Source: https://docs.minds.sh/docs/operations/compatibility



This documentation was checked against the current repository and an authenticated Minds walkthrough on **September 12, 2026**. Source coverage, a working documentation build, and a successful live product workflow are different kinds of evidence.

## What the audit established [#what-the-audit-established]

| Area                  | Evidence                                                                                                           |
| --------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Sign-in               | The supplied test account reached the authenticated chat workspace                                                 |
| Helm setup            | Region and name steps were exercised and captured                                                                  |
| Account navigation    | Organizations, settings, agent setup, and instance-dependent views were inspected                                  |
| Organization retest   | Fresh sign-in and organization listing passed after the reported IAM URL correction                                |
| First instance        | Dedicated Firecracker creation remains unverified; initial create returned 500                                     |
| Connection retest     | Repaired live configuration step labels snippets as templates and key minting as unavailable                       |
| Instance API          | Every registered HTTP operation inventoried with source inputs and handler evidence                                |
| SDKs and terminal     | Public declarations and connection paths inventoried; compatibility gaps identified                                |
| Runtime certification | No successful newly provisioned hosted instance, full API exercise, or Firecracker VM mapping proved in this audit |

## Current issues that affect a first integration [#current-issues-that-affect-a-first-integration]

| Area                   | Observed or source-confirmed limitation                                                                                                                                            |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Provisioning           | Organization lookup is repaired and retested; dedicated Firecracker creation remains pending                                                                                       |
| Runtime model          | Local customer creation now delegates to ensure and fails closed when unconfigured; the hosted app is reported on the earlier Render path. Firecracker lifecycle still needs proof |
| Upgrade                | Local ensure integration returns Pro metadata without an explicit resize instruction; capacity changes and exact identity preservation remain unverified                           |
| Preflight              | Still checks legacy Render/Cloudflare configuration rather than the new ensure dependency                                                                                          |
| Instance-owner access  | Some engine controls require internal-only authority; scoped customer access to the complete instance API is not yet established                                                   |
| Helm actions           | The implemented submission allowlist supports instance provisioning; arbitrary engine actions are not established                                                                  |
| Agent wizard           | The repaired configuration step clearly has no live key; a real durable connection is still unavailable                                                                            |
| Standalone MCP         | The audited backend uses in-memory storage even when an endpoint is supplied                                                                                                       |
| CLI/SDK authentication | Default Bearer transports do not satisfy the secure daemon's required capability header                                                                                            |
| Settings               | Failure visibility repair reported deployed; actual persistence remains unverified                                                                                                 |
| Recovery and training  | Some checkpoint and BPTT routes report acknowledgments or completion without doing the advertised work                                                                             |
| Telemetry              | Some statistics and region-health paths return placeholders or fallbacks                                                                                                           |
| Management authority   | Billing, region creation, and idempotency boundaries need correction and isolated verification                                                                                     |
| Secondary protocols    | gRPC and Arrow Flight authority must be verified before public exposure                                                                                                            |

Organization retest followed the reported deployment `dpl_9qjWTeTL5oqT13aF78pgbiYxqzeV`. The connection-template retest followed the reported superseding deployment `dpl_GzyjT4w7buf2e1yqPKFJy6tLSJbr`. Deployment IDs were supplied by the engineering coordinator; browser checks independently verified the behavior described above.

These findings were sent to the Minds engineering coordinator for fixes, validation, and redeployment. A team acknowledgment is not a closed issue. A limitation should be removed from these docs only after the repaired revision and the relevant workflow have been checked.

## Go deeper [#go-deeper]

* [Instance coverage and implementation limits](/docs/api/instance/coverage)
* [SDK and harness compatibility](/docs/developers/compatibility)
* [Troubleshooting](/docs/operations/troubleshooting)

The reference intentionally includes incomplete registered endpoints so consumers can see their actual behavior. Do not treat complete route coverage as a promise that every operation is ready for production use.