Trust / Product readiness
Trust is a product surface, not a badge.
API behavior in. Device-fit models out. Kolm should be judged by what a buyer can inspect: API control coverage, compiler artifacts, runtime target evidence, verifier receipts, export packets, and the readiness gates we refuse to market as shipped until they are proven.
01 / What can be checked today
Every serious claim needs a concrete inspection path.
This page routes reviewers to the actual surfaces: product controls, API docs, integration maturity, runtime target caveats, and the readiness ledger.
api control
Enterprise data plane controls
Ingress, egress, collection modes, export modes, governance stages, unknown-schema policy, routing, eval, compile, and audit controls.
Open control →compiler loop
Capture to signed artifact
Trace import, dataset/eval gate, compile job, signed artifact, verifier receipt, runtime target, and governance export.
See product →runtime targets
Target fit with caveats
Hosted GPU, serving engines, local runners, portable inference, device edge, browser package, BYOC, and restricted fleet paths are separated by proof state.
Target matrix →integrations
Source, sink, and export map
Gateway, eval, observability, GRC, SIEM, warehouse, runtime, and workflow connections are scoped by maturity instead of logo padding.
Integration map →category research
290+ mapped players
The compare page shows why Kolm must own the transition from observed API behavior to governed runtime artifact.
Compare stack →api reference
Developer proof path
Quickstart, endpoint reference, OpenAPI JSON, and product capability payloads make the control claims machine-readable.
API docs →02 / Open readiness gates
The strongest trust copy is clear about what is not done.
The closeout ledger has 8 open requirements. Marketing and product UI must not describe these as fully shipped until the status is promoted by evidence and verification commands.
- Benchmarksopen gate
- Certificationsopen gate
- Install channelsopen gate
- Runtime adoptionopen gate
- Format stewardshipopen gate
- SDK releaseopen gate
- Mobile packagesopen gate
- Browser channelopen gate
Open gate · an outline ring marks a requirement that is built locally but not yet proven in public. None of the gates below are claimable as shipped until their evidence is published.
P0 / needs public benchmark data
Benchmarking infrastructure
The harness and sample reports exist. Public multi-provider leaderboard data, raw JSON, commands, versions, hardware, latency, cost, and scoring context still need publication.
P0 / needs live certification
Compliance certifications
Security controls and evidence packet hooks exist locally. Formal SOC 2, ISO 27001, HIPAA, GDPR, FedRAMP, SBOM, and SLSA claims require live auditor or certification artifacts.
P1 / needs package release
One-line install
Install scripts and package-manager manifests exist locally. Public Homebrew, winget, apt, Docker, and direct installer channels need signed release artifacts and smoke tests.
P1 / needs external partner
Runtime adoption
Runtime and compute adapters exist locally. Native third-party support from outside projects or vendors is not claimable until merged, published, or externally attested.
P1 / needs external partner
Format stewardship
The public v1 spec exists. Neutral standards or foundation stewardship is not claimable until an external venue accepts the process.
P1 / needs package release
SDK depth
SDK source and metadata exist across languages. Package-manager availability stays gated until release artifacts are built, signed, and linked.
P1 / needs package release
iOS and Android packages
Swift, Kotlin, and React Native source exists locally. SwiftPM, Maven, and npm publication require release artifacts and CI package checks.
P1 / needs package release
Browser package channel
The browser runtime code exists locally. Public package metadata, integrity hash, CDN import URL, and smoke tests remain release-gated.
Source: product-readiness-closeout.json, generated from docs/product-sota-readiness.json.
03 / Enterprise control posture
Kolm's trust wedge is governed behavior, not generic security wallpaper.
Enterprise buyers expect SSO, SCIM, RBAC, audit logs, retention, redaction, usage controls, connector policy, export APIs, and evidence packets. Kolm keeps those controls attached to the compiler loop.
Ingress policy
API, gateway, streaming, webhooks, files, telemetry, warehouses, queues, browser events, MCP, A2A, and custom adapters enter with scoped capture and redaction rules.
Egress policy
Governance packets, SIEM/GRC exports, webhooks, warehouses, ticketing, logs, runtime targets, and audit events must leave with declared destination and receipt context.
Opaque by default
Unknown vendor schemas stay opaque until an adapter manifest declares structure. Kolm should not pretend semantic understanding where none has been verified.
Evidence before promotion
Artifacts, receipts, target recipes, hashes, policy decisions, and readiness states should travel outside the UI for buyers and auditors to check.
04 / Reviewer path
A reviewer should be able to disprove us quickly.
If a claim cannot survive inspection, it should be removed or moved to the readiness ledger. Five surfaces, in order, each ending in something you can open and check.
Open API control
Confirm channel, policy, governance, and export coverage in the account payload.
17channel familiesRead the API reference
Check the objects behind capture, compile, artifacts, receipts, and exports.
OpenAPIJSONRead the readiness JSON
See which benchmark, certification, package, and partner items stay unclaimable.
8open gatesSee the control path
How kolm connects source systems, policy gates, compile state, and proof exports.
290+mapped playersConfirm target fit
The runtime matrix separates targets by fit, recipe, receipt, and release gate.
8target paths1 / inspect controls
Open the API control center
Confirm the channel, policy, governance, and export coverage exposed by the account payload.
Control center →2 / inspect docs
Review the API reference
Read the quickstart and reference for the objects that support capture, compile, artifacts, receipts, runtime targets, and exports.
API reference →3 / inspect caveats
Read the readiness JSON
See which benchmark, certification, package, standards, and partner items remain unclaimable.
Readiness JSON →4 / inspect control path
See how Kolm connects the loop
Use the product position page to see how Kolm connects source systems, policy gates, compile state, runtime targets, and proof exports.
Why kolm →5 / inspect runtime fit
Confirm target support
Use the runtime matrix to confirm that target support is separated by fit, recipe, receipt, external adoption proof, and release gates.
Runtimes →legal & data
Read the data and legal posture
Subprocessors, data processing, business associate terms, service levels, and acceptable use are all published documents.
Subprocessors · DPA · BAA · SLA · SecurityMake every claim route to proof.
Start with one AI API namespace, put it under control, compile a signed artifact, and export the evidence packet. Anything not proven stays in the ledger.