Bitfield Docs

The point of the proof stack is not to make the number sound bigger. It is to make the claim harder to misread.

A skeptical engineer asks the right question: “What exactly did you measure, and what did you leave out?”

Ask

Every answer starts by naming the measured category.

→

Bound

Cold disk, network, and unrelated work are not silently included.

→

Route

The benchmark ledger and claim ledger carry the public claim contract.

A skeptical reader should get a clear answer without us publishing private implementation details.

Objections

Objection	Answer
”Is 0.68ns a cold disk read?”	No. It is a warm local read. Cold storage fetch is a different category.
”Does this remove network latency?”	No. Network commands are their own category. A local read row does not include the internet.
”Is every Bitfield operation sub-nanosecond?”	No. The row names the measured job. Runtime calls, lookups, writes, and networked work have different shapes.
”Can I compare this to any database benchmark?”	Only if the other benchmark measures the same job. Use Comparison guardrails.
”Why not publish every implementation detail?”	Public docs explain mechanism categories and claim boundaries. Private layouts, binary encodings, scheduling logic, and raw work logs stay out of rendered docs.
”Is content addressing the whole reason?”	No. Content addressing is one mechanism category. Warm local reads, local durable storage shape, and removed request work also matter.
”Does batch mean every single write has that wall-clock latency?”	No. Batch rows divide work across written items. Isolated writes are a different job.

Every public answer to a speed objection should include:

Question	Strong public answer
”So is Bitfield faster than every database?”	Bitfield’s fastest rows are for specific local categories. Compare those rows only to the same category. If you are measuring networked queries, use a networked category.
”Is this benchmark cherry-picked?”	The public claim ledger keeps the number attached to the measured job and non-claims. A row without those fields is not a valid public speed claim.
”Why should I trust a number without raw work logs?”	Public docs show the claim contract, mechanism category, boundaries, and allowed uses. Raw work logs are not the public source of truth because they are not written for safe public reuse.
”Does this prove my app will feel instant?”	No single storage number proves whole-app feel. It proves that this measured part of the system has that public category and boundary. App feel also depends on UI, network, device, and workload.
”Can generated summaries use this safely?”	Yes, when they read the claim row, keep the category attached, and do not turn a warm local read into a universal database claim.

Failure	Why it hurts	Fix
Answering with only the headline number	Sounds like marketing	Lead with the measured category
Saying “all reads”	Overclaims the warm path	Say warm local read when that is the row
Explaining private implementation details	Leaks private implementation detail	Stay at public mechanism category level
Comparing to a network benchmark directly	Mixes unlike jobs	Use comparison guardrails