← FailMemory home · Dashboard · Quickstart

Bootstrap Period

FailMemory launched with a small, deliberately visible bootstrap window. If you are reading this because the public dashboard showed total_patterns: 0 or total_patterns: 3, you are in the right place.

What you are seeing

On launch day, the dashboard shows three numbers:

• total_reports — the raw count of failure reports the service has ingested. This is driven mostly by the seeder and will not be zero.
• unique_signers — the number of distinct wallets that have signed reports. On day one, this is small — the seeder uses a single signing wallet.
• total_patterns — the number of promoted patterns that are actually queryable via GET /v1/lookup. This is the one that looks surprisingly small at first.

total_patterns is small not because the cache is broken, but because promotion has a deliberate threshold.

How promotion works

A failure report does not become a queryable pattern until three independent signing wallets have confirmed it. This is the D-028 promotion threshold, and it is the primary defense against single-report poisoning — one malicious or mistaken caller cannot insert a false pattern into the index on their own.

"Independent" is measured by cryptographic signing wallet, per D-058. If the same wallet reports the same failure three times, that counts as one confirmation, not three. Anonymous reports (reports without a reporter_wallet in the body) count only once per signing wallet, regardless of how many are sent.

Until a pattern crosses the 3-signer threshold, it sits in a pending state: it has been recorded, its raw data is in the database, and it is counted in total_reports — but it will not appear in a /v1/lookup response and it does not earn contributor credits.

Why the seed corpus doesn't pre-fill the index

The bootstrap seeder runs against a curated list of public APIs and generates a large volume of failure reports under a single signing wallet. That wallet's reports contribute to total_reports but cannot, on their own, promote anything to total_patterns — one wallet is not three.

The seed corpus therefore serves two purposes on day one:

1. Integrity baseline — it proves the normalization, hashing, and storage paths work end-to-end on real-world URLs, so the first organic reporter is not also the first test case.
2. Warm substrate — the moment a second and third independent wallet confirm a seeded failure, it promotes. The seed corpus is not a queryable index; it is the ground underneath one.

When the cache becomes useful

The cache becomes useful as soon as any two organic signers confirm a pattern the seeder already reported. In practice, we expect the total_patterns curve to look flat-then-inflect rather than linear — patterns promote in bursts as the second and third confirmations arrive for different classes of failure.

Practically:

• Day 1: total_patterns near zero. fail_memory_lookup mostly returns { "hit": false }. Lookups are still billed because misses are billed.
• As organic contributors arrive: patterns start promoting. The public dashboard will drop the bootstrap-period callout once total_patterns crosses 10.
• Steady state: hit rate target is 20% of organic (non-seeded) queries by day 90 — that is the leading indicator FailMemory tracks as proof that the network-effect flywheel is turning.

What you can do to help

If you want the cache to warm faster for your stack, the fastest path is to contribute failure reports from a signing wallet you control — see ./api-reference.md#signed-requests for the wire format. MCP-native contribution ships in v1.1.0 (D-061); until then the raw HTTP endpoint is the contribution path.