Start with the evidence boundary.

OrdinateDB is Pre-release. This page separates product mechanisms and inspectable artefacts from contract-specific commitments and evidence that does not exist yet. It is written to support an honest technical or procurement review.

Evidence boundary

Different claims need different proof.

Architecture describes how the product is intended to behave. Source and specifications let an evaluator inspect that design. Operational results and contractual commitments require their own evidence; they are not implied by a diagram or a confident sentence.

claim → appropriate evidence

product behaviourspecification · source · repeatable test

deployment designtopology · configuration · recovery procedure

managed operationservice scope · operating record · contract

performancereproducible benchmark for the stated workload

Product mechanisms

What a technical evaluation can inspect.

licence and source: OrdinateDB is presented as Apache-2.0 software with no paid feature edition. Review the repository and licence as part of evaluation; the website is not a substitute for either.
interrupted linksSPEC 02 §6: Local acknowledgement, a write-ahead log, store-and-forward, idempotent forwarding and explicit gaps are the resilience mechanisms. Evaluate them with the failure cases relevant to your deployment. Architecture
quality and lineageSPEC 04 · SPEC 05: Quality, source identity, calculation versions and corrections are designed to remain queryable with the result they qualify. Review that behaviour through the public interfaces and product governance model. Product governance
identity and accessSPEC 10: OIDC identity, allow-only scopes, attributed changes and audit history form the proposed access-control boundary. An evaluator should validate the exact controls required by their environment.
data portabilitySPEC 03 §3.3 · SPEC 13: Documented APIs and Parquet-based long-term storage are intended to keep access independent of a managed service or proprietary export path. Test that exit path with your own tools and data shape.
documentation maturity: Written pages are distinguished from planned stubs. The API reference is generated from the checked-in contract, while product maturity is labelled Pre-release. Documentation

Contract boundary

Managed commitments belong in the agreement.

Topology, monitoring signals, maintenance process, backup policy, recovery objectives, response routes and responsibilities vary by deployment. Managed OrdinateDB records them in the service scope; this site does not publish a generic availability or response number.

How managed responsibilities are divided

Before an agreement

Define the operating boundary and named owners
Choose the deployment and recovery topology
State maintenance, backup and response procedures
Agree which records demonstrate that operation

Not claimed

Evidence that does not exist is not replaced with a target.

These may become publishable later. Until a reproducible package or recognised attestation exists, they remain outside the public case.

01Achieved throughput or stream-count benchmarks
02An achieved availability percentage or public service history
03Customer, fleet or production-deployment numbers
04Certifications or compliance attestations
05Published recovery results that are not available to link and reproduce

Project governance, product governance and security review answer different questions. Keep all three visible in an evaluation.

Project governance Product governance Security contact →