# Bitfield Docs

> World's fastest plug-in runtime and database for founders who can't afford to slow down when plans change.

These pages are public customer documentation. They describe the public product, public Runtime Kit surface, active-device language, and benchmark claim categories.

## Pages

- [Bitfield Docs](index): The public entry point for Bitfield docs.
- [Quickstart](start/quickstart): The shortest path from a Bitfield key to the first app-facing Runtime Kit calls.
- [Get your key](start/get-your-key): Explains what happens when you get a Bitfield key and activate your first device.
- [What is Bitfield?](concepts/what-is-bitfield): Explains Bitfield without assuming the reader already knows database or runtime vocabulary.
- [Database and runtime](concepts/database-and-runtime): Defines the public database and runtime model.
- [Storage shape](concepts/storage-shape): Explains local durable truth, memory-mapped local files, content identity, and the current view.
- [Content-addressed storage](concepts/content-addressed-storage): Defines content addresses and states what the public docs do not expose.
- [Slots](concepts/slots): Explains slots as named runnable doors that features can call without importing each other.
- [Active devices](concepts/active-devices): Defines active devices for pricing, keys, and account management.
- [JavaScript Runtime Kit](runtime-kit/javascript): Maps the public Runtime Kit flow from package boundary to prepared reads and named target requests.
- [Read data in React](runtime-kit/use-bitfield-data): Shows selectors, render states, request pairing, and what React components should not own.
- [Send a request](runtime-kit/send-request): Shows JSON, text, byte payloads, reply decoding, cancellation, and target-boundary mistakes.
- [Packages](runtime-kit/packages): Explains package sets, records, stored bytes, callable slots, validation rules, and safe package examples.
- [Local state](runtime-kit/local-state): Explains stored data, Runtime Kit package state, activation material, and what users should not hand-edit.
- [Workflow examples](workflows/index): Indexes complete package and Runtime Kit workflows that stay inside the public contract.
- [Package set with one record](workflows/package-set-with-one-record): Shows the smallest package boundary with one durable package record.
- [Package-owned file](workflows/package-owned-file): Shows how a package declares package-owned bytes without reaching outside its folder.
- [Callable package slot](workflows/callable-package-slot): Shows how a package declares a callable slot and how app code sends a request to it.
- [React surface for package data](workflows/react-surface-for-package-data): Shows the app-facing read and request shape without exposing package internals to React.
- [Build your own surface](build-your-own-surface/sdk-boundary): Defines the public SDK boundary pattern: simple app functions outside, Bitfield setup behind the plug.
- [Trials and billing](activation/trials-and-billing): Explains trial billing and active-device ranges without turning pricing into hidden math.
- [How Bitfield is this fast](proof/how-bitfield-is-fast): Explains warm local reads, memory mapping, content addresses, and non-claims.
- [Warm and cold paths](proof/warm-and-cold-paths): Defines warm local read, cold local read, content address lookup, durable batch write, runtime call, and network command.
- [Benchmark ledger](proof/benchmark-ledger): Lists public speed claims with the work category attached.
- [Measurement methodology](proof/methodology): Explains warm reads, cold reads, hash lookup, durable writes, and why each number needs its category.
- [Runtime Kit API](reference/runtime-kit-api): Reference for sendRequestToBitfieldTarget, useBitfieldData, payload conversion, selectors, return values, and public boundaries.
- [Claim ledger](reference/claim-ledger): Documents the public claim-ledger fields that keep speed claims honest.
- [Package boundary](reference/package-boundary): Lists the public package boundary fields and thing types.
- [Changelog](changelog/index): The public change log for docs and customer-visible product behavior.

## Public source categories

- bitfield-public-landing-copy: Product language for what Bitfield is, active devices, checkout, and proof framing. Freshness rule: review when public site copy changes.
- runtime-kit-js-public-contract: JavaScript Runtime Kit exports and app-facing API shape. Freshness rule: review when Runtime Kit package exports change.
- runtime-kit-package-boundary: Package boundary file, thing types, and local state language. Freshness rule: review when package boundary validation changes.
- bitfield-public-legal-pages: Public Terms, Refund Policy, and Privacy Policy routes. Freshness rule: review when legal page routes or checkout consent wording changes.
- bitfield-public-claim-ledger: Published benchmark numbers, categories, and non-claims. Freshness rule: review when claim-ledger.json changes.
- fastest-db-public-disclosure-cssot: Public mechanism categories for memory mapping, content addressing, durable append paths, warm/cold cache state, and forbidden private details. Freshness rule: review when benchmark mechanism language or public disclosure boundaries change.
- bitfield-docs-information-architecture: Docs navigation, page summaries, and reader-intent grouping. Freshness rule: review when docs.manifest.json changes.
- bitfield-public-workflow-examples: Machine-validated package and Runtime Kit examples used by public workflow pages. Freshness rule: review when workflow-examples.json, reference/package-boundary.schema.json, or examples/ changes.

## Public API surface

- `@bitfield/runtime-kit`: `sendRequestToBitfieldTarget(...)`
- `@bitfield/runtime-kit/react`: `useBitfieldData(...)`

## Benchmark boundary

- 0.68ns warm local read: warm-local-read. The data is local and already warm, so Bitfield can read known local bytes without sending a request to a separate database process. Not claiming: A cold disk read takes less than a nanosecond. A network round trip disappears. Every database benchmark measures the same job.
- 91.7ns hash lookup: content-address-lookup. Bitfield first resolves the content address, which means it uses the data fingerprint to find the bytes, then reads them. Not claiming: This is the same category as the H0 exact read. This includes networked application latency.
- 316ns durable batch write comparison: durable-batch-write. The measured work includes the saved-write contract for a batch, then divides the batch cost across the written items. Not claiming: Every single isolated write has 316ns wall-clock latency. This is the same category as a networked managed database write.
- 0.59ns batched engine write ceiling: batched-write-ceiling. This is the optimized write path divided across a full batch. It is a ceiling number, not a replacement for durable write comparison rows. Not claiming: A full saved write is always 0.59ns. This number should be compared directly to every vendor write benchmark.

Cold storage, network trips, and managed database requests are different categories from warm local reads.