Use an exact reviewed source commit
The crate remains 0.1.0-dev and experimental. Inspect the workflows and qualification records for the exact source commit before treating a result as evidence.
The repository does not promise stable persisted formats, supported upgrade paths, performance, real-time behavior, high availability, or portability across an announced platform matrix.
Use the deliberately limited profile
The current profile includes one fenced writer, explicit persisted limits, append-only family activation over a retained checkpoint, snapshot and serializable transactions, ordered scans, atomic groups, explicit checkpointing, caller-selected compaction, cacheless reopen, and caller-triggered read-only replica refresh.
Object storage remains the sole authority for acknowledged durable state. Listing, memory, and local caches do not establish visibility.
Keep evidence attached to its gate
| Gate | Current question |
|---|---|
| Deterministic suite | Does the exact source satisfy repository, format, engine, client, crash, Files, showcase, and adapter assertions? |
| Provider matrix | Does the shared public workflow pass three times on each of six maintained implementations? |
| TLA assurance | Do bounded models, probes, witnesses, proofs, and maintained trace replays satisfy their recorded invariants? |
| SPARK proof | Do selected deterministic policy, format, bounds, and transition units prove without assumptions or justified checks? |
| Getting started | Can a fresh public clone build and retain a real Files root through family extension and reopen? |
These gates answer different questions. A green model does not prove the full Ada implementation. A provider run does not qualify every S3 service. A local proof does not establish performance.
Use the maintained provider boundary
The complete public workflow runs against RustFS, SeaweedFS, MinIO, Flyology memory, Flyology Files, and Flyology SQLite. Each provider lane supplies storage semantics beneath the same database oracle.
This matrix supports S3-compatible and provider-neutral behavior within the maintained configurations. It is not general cloud-service qualification. Applications own endpoint, credentials, bucket, prefix, retry, cleanup, and retention policy.
Schedule every maintenance action
The library exposes explicit checkpoint and compaction mechanisms. It has no automatic maintenance, identity generation, compaction selector, garbage collection, history pruning, cleanup, or retention service.
Current compaction retains predecessor objects. Long-running deployments need an application maintenance and storage-retention plan before they can bound object growth.
Do not infer excluded product behavior
- No family rename, drop, reorder, or reconfiguration.
- No mutable database configuration, TTL, codec, migration, or version-upgrade policy.
- No automatic writer promotion, replica registration, polling, lease, or retention coordination.
- No automatic maintenance, background retry, provider cleanup, or garbage-collection policy.
- No operational cache implementation, backup/restore command, scrub/repair tool, or metrics service.
- No stable persisted-format promise, performance claim, or supported-platform matrix.
- No coverage for termination inside Commit; durable authority starts only after returned
Outcome_Unknown.
Report one concrete boundary
Use the public issue tracker for defects and design proposals. Include the exact source commit, provider, dependency commits, limits, operation sequence, outcome codes, and retained diagnostics.