Source: https://guthlabs.ai/docs/instruments/bloom-filter-sizing-calculator/

instrument / verified-clean

# Bloom Filter Sizing Calculator

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Inspectable records

[01**Overview**Purpose and lifecycle](<https://guthlabs.ai/docs/instruments/bloom-filter-sizing-calculator/>)[02**Mechanism**Method and assumptions](<https://guthlabs.ai/docs/instruments/bloom-filter-sizing-calculator/mechanism/>)[03**Implementation**Binding and validation](<https://guthlabs.ai/docs/instruments/bloom-filter-sizing-calculator/implementation/>)[04**Qualification**Evidence and errata](<https://guthlabs.ai/docs/instruments/bloom-filter-sizing-calculator/qualification/>)

## Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

**Area**: Computing & Information

**Tranche**: tranche-5

**Evidence ID**: t5-134

**Ledger rows**: 1

No ledger note is attached.

## Review findings

Core sizing formulas are correct under the stated ideal assumptions, but the instrument is not fully specified. Exact ambiguity: the claimed actual false-positive-rate output has no formula, and neither m nor k has a defined integer-rounding policy. Verdict remains NEEDS_REVIEW until those behaviors and input constraints are documented.

### Formula and scope findings

- The formulas are standard for the continuous, ideal Bloom-filter optimum: m=-(n·ln(p))/(ln(2)^2) and k=(m/n)·ln(2).

- m is generally non-integer but the output claims a bit-array size; the specification does not define whether m is rounded, floored, or ceiled.

- k is generally non-integer but the output claims a hash-function count; the specification does not define whether k is rounded, ceiled, or constrained to at least 1.

- The specification claims an actual false-positive-rate output but provides no formula for it. The standard model formula is FPR=(1-exp(-k·n/m))^k, subject to integer m and k and independent uniform hashing assumptions.

### Unit assumptions

- n is a positive item count, dimensionless and normally an integer.

- p is a dimensionless probability supplied as a fraction strictly between 0 and 1, not as a percentage; for example, 1% must be entered as 0.01.

- m is measured in bits.

- k is a dimensionless count of hash functions.

- ln denotes the natural logarithm.

- The test vectors below use the continuous formulas without integer rounding; their ideal-model false-positive rate therefore equals the target p.

## Boundary hardening

**BREAK_CLAIMED** · SELF_FLAGGED

The specification permits boundary and zero-item inputs for which k or the actual false-positive rate is undefined, and it does not state whether p is a fraction or a percentage. A plain arithmetic implementation that lacks validation or an explicit unit convention can return misleading zeroes, NaN, or degenerate results.

## Errata and corrections

No applied erratum is attached to this unique-name record.

## Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

````
{
  "inputs": {
    "n": 1000,
    "p": 0.01
  },
  "expected_outputs": {
    "m": 9585.058377,
    "k": 6.64385619,
    "actual_false_positive_rate": 0.01
  },
  "working": "ln(0.01)=-4.605170186; ln(2)^2=0.480453014. m=-(1000×-4.605170186)/0.480453014=4605.170186/0.480453014=9585.058377 bits. k=(9585.058377/1000)×0.693147181=6.64385619. Ideal FPR=(1-exp(-(6.64385619×1000)/9585.058377))^6.64385619=(1-exp(-0.693147181))^6.64385619=(1-0.5)^6.64385619=0.5^6.64385619=0.01."
}
````

## Related workflows

No source-defined multi-instrument workflow membership is recorded.

## Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

- `VERIFIED_LEDGER.json · VERIFIED_CLEAN`

- `evidence-tranche5/tranche5-results.json`

- `BOUNDARY_HAZARD_CATALOG.json`