Sai Charan Obuladinne

I visited a botanical garden with my family, and in the middle of the fall displays they had built a big maze from stacked hay bales. Pumpkins lined the edges. Kids ran through the passages, disappearing around one corner and reappearing at another. The whole place felt busy, playful, and just uncertain enough to make choosing a direction interesting.

Our group split. One group entered from one side of the maze; another started at the entrance on the opposite side. We did not plan an algorithm. We simply began exploring inward, taking turns and checking passages. Then, somewhere in the middle, the two groups found each other.

Watching that happen, I realized we had just acted out bidirectional breadth-first search with real people in a real maze. Instead of making one group cover every promising path from a single entrance, we had two search waves moving toward each other. The meeting point connected the route.

First, picture ordinary BFS as a spreading wave

Breadth-first search, or BFS, starts where you stand and explores level by level. First it checks every place one step away, then every place two steps away, then three. Imagine dropping a pebble into still water: the ring expands evenly in every direction. In code, a queue keeps that order honest, and a visited set prevents the search from walking the same passage twice.

On an unweighted graph — where every edge counts as one step — that level-by-level discipline guarantees a shortest path. It will not wander ten turns deep while ignoring a solution only four turns away. But the wave can become enormous. If every junction offers several new choices, each level may contain many more states than the last.

The twist: send a second wave from the goal

Bidirectional BFS uses the same idea twice. One search begins at the start. A second begins at the known goal and works backward. Each keeps its own frontier, visited set, and parent links. When a state visited from one side appears in the other side's visited set, the two waves have touched. Follow the parent links back toward both ends, join the two halves, and you have the complete path.

That is exactly what our groups did. One side of the hay maze was the start; the other was the goal. Every passage could be walked in either direction. When we met, we knew how to connect the entrances without asking one group to search the whole maze alone.

Don't search the whole maze from one end. Start a second search from the other end and meet in the middle.

Why half the depth changes almost everything

The advantage is not merely “two groups are twice as fast.” Search spaces grow exponentially. If each state branches to about b new states and the shortest solution is d steps deep, a one-directional BFS explores on the order of b^d states. Bidirectional search asks each side to cover roughly half the distance, so the work is closer to b^d/2 from each end, or about 2 · b^d/2 in total.

Take a small-looking example: three choices per step and a solution ten steps away. A one-directional estimate is 3¹⁰, or about 59,049 nodes. From both ends, each search travels only five levels: 2 × 3⁵ = 2 × 243, or about 486 nodes. That is under one percent of the one-way estimate. Meeting in the middle cuts the exponent in half.

When meeting in the middle works

The technique has two important requirements. First, you need to know the goal state up front; “find anything interesting” does not give the reverse search a place to begin. Second, you must be able to search backward from that goal. The moves do not always have to be physically reversible, but the algorithm needs a way to generate predecessor states. Our maze is the friendly case: both entrances are known, and every passage is walkable both ways.

In an implementation, it is also wise to expand the smaller frontier at each step. That keeps the more rapidly growing side from dominating memory. And, as with ordinary BFS, the shortest-path guarantee assumes unweighted edges; weighted roads or transitions call for bidirectional versions of Dijkstra's algorithm or A*, with more careful stopping rules.

Where engineers use it

The pattern appears anywhere a forward-only search threatens to explode. In a social graph, one wave can start from you and another from a distant person to find the shortest chain of connections — the familiar “degrees of separation.” Route-finding systems can search from origin and destination. Word ladders can grow transformations from both words. Puzzle solvers use it for spaces such as the 15-puzzle and Rubik's Cube, where the target arrangement is known and legal moves can be reversed.

The broader lesson stayed with me after the botanical garden. The fastest way through a maze — or a search space — is often not to push harder from one end. It is to start from both ends, keep the waves disciplined, and let them meet in the middle.

It's tempting to measure an insurance AI assistant one request at a time: trim this prompt, shorten that answer, count the tokens. But an adjuster or underwriter doesn't ask one question. Working a single claim, they run a whole session — check coverage, compare the repair estimate, draft a reserve rationale, write the payment or denial letter. And each turn typically re-sends the same thing: the policy terms, the coverage rules, the claim history, the adjuster's notes, and a growing transcript. If each turn carries tens of thousands of tokens of mostly-unchanged policy and claim context, one resolved claim has paid for that context a dozen times over — and almost none of it changed between turns. The model re-reads the same policy a dozen times. Optimizing a single call cannot see this; the real waste is re-transmission.

So reframe the metric. The unit that matters is cost per resolved claim, and its dominant term is repeated context. The fix is a shift in mindset: treat context as state you maintain, not a payload you rebuild.

Stop optimizing the wrong unit

The naive move is to compress every prompt as small as possible. It helps a little and hides the real problem. A ten-turn claim session with a tightly-trimmed context still re-sends that policy and claim nine more times than it needs to. You cannot compress your way out of paying for the same policy over and over — you have to stop paying for what didn't change.

Put the working context outside the model call, in a fast store keyed by claim (and adjuster session). Redis is a natural fit: millisecond reads, TTLs, and structures richer than a flat string. Each turn reads from and writes to this store, and the model call carries a reference to stable state plus only the turn's delta. The store becomes the single source of truth for what the assistant knows about this claim right now.

Make the context addressable

A flat blob is hard to update and harder to invalidate. Instead, mirror the claim as a tree — the policy at the root (coverages, limits, deductibles, endorsements, exclusions), then the claim (FNOL and loss facts), then the evidence as leaves: repair estimates, photos and their metadata, adjuster notes, correspondence, payments, and any attached medical records. Each node holds its content, or a summary, plus a content hash. Now it is addressable: point at policy › collision › deductible or claim › estimate #2. Borrow from Merkle trees and derive each node's hash from its children, so adding one estimate changes hashes only along one path from leaf to root.

Order the prompt stable-first: system instructions and coverage rules, then the policy as it stood on the date of loss (which does not change mid-session), then the volatile tail — the newest note, the last document, the latest tool result. Providers' prompt caching rewards exactly this shape: an unchanged prefix is billed at a fraction and skips recomputation. Between turns, compare hashes and hand the model only the subtrees that moved, plus a compact manifest of what stayed the same. The claim pays full price once and deltas after that.

Even the first turn shouldn't dump the entire claim. Attach an embedding and a one-line summary to each node, and for a given question pull only the relevant subtrees. A coverage question opens the policy's coverages and exclusions; a bodily-injury question opens the medical records; a repair dispute opens the estimates and photos — while the rest stays as summaries the assistant can expand on request.

Invalidation is the safety system

Caching is easy. Knowing when a cached node has gone wrong is the hard part, and in insurance a stale read is not just a wrong edit. If the assistant answers a coverage question from a cached policy that has since been endorsed — or from the wrong policy version — it can quote the wrong limit or miss an exclusion. That is a real coverage error, not a typo, with bad-faith and compliance exposure behind it. Tie invalidation to events: a new document, an endorsement, or a status or reserve change dirties the affected nodes. Separate the immutable — the policy as it stood on the date of loss, statutory rules — from the volatile — current reserve, status, latest note — so stale volatile data can never poison a coverage decision. When confidence is low, prefer a cheap re-read of the source of record over a fast wrong answer.

Treat context as state you maintain, not a payload you rebuild.

Tier memory by working value

Not every claim deserves full fidelity in memory. Three tiers keep the working set small: hot (the claim being worked now, full context in memory), warm (recently touched claims, summaries kept), cold (everything else, rehydrated on demand). Eviction is priority-based — recency × relevance × cost-to-rebuild — with TTLs so a claim that goes quiet releases memory. Promotion is lazy: a cold claim opened twice gets summarized into warm; a warm claim that's worked gets rehydrated to hot.

Measure the resolved claim

Per-call token counts will mislead you. Track the numbers that reflect the reframing: cache hit rate (context served from the store versus re-sent), tokens per resolved claim, and — critically — a staleness guard that flags when the cache fed the model a policy version that doesn't match the date of loss. A cheaper claim that produces a wrong coverage decision is not cheaper; in insurance it is a bad-faith and compliance risk.

If you're building a claims or underwriting assistant, start by logging how many tokens you re-send that never change within a claim. That number is usually the whole business case — and the policy-version guard is the part that keeps it safe.

A Merkle tree is a hash tree: every leaf holds the cryptographic hash of one data block, and every parent holds the hash of its children concatenated together. The single hash at the top—the root—is a fingerprint of the entire dataset. Change one byte anywhere, and the hashes on that leaf’s path to the root change.

That property makes Merkle trees a workhorse of replica repair. When two database replicas diverge, re-sending the whole dataset just to discover the difference is wasteful. Instead, each side builds or maintains a Merkle tree over the same key ranges and compares root hashes. Equal roots mean the replicas agree for those ranges. Different roots send the replicas down the tree, comparing child hashes until they reach the exact leaf ranges that disagree. Only the differing data is exchanged and repaired. This is anti-entropy—the same broad idea used by repair mechanisms in systems such as Cassandra and Dynamo-style stores.

Consider two replicas that each hold eight claim rows, keyed 1–8. On replica B, row 5 was updated but the change never replicated. Both sides hash each row into eight leaves, pair them into four parents, then two, then one root.

The roots differ, so the replicas compare the root’s two children. The left halves match and can be pruned from the search; the right halves differ. They descend through the right half, compare its children, and arrive at the pair containing rows 5 and 6. One more comparison isolates leaf 5. Replica A sends only row 5 to replica B—one row instead of eight.

For a balanced tree with one divergent leaf, that search crosses O(log n) levels instead of performing an O(n) row-by-row comparison. The trees themselves still have to be built or maintained, and multiple differences require exploring multiple branches, but the comparison work stays focused on the ranges that changed.

The pattern appears wherever fingerprints are cheaper than full copies. Git’s content-addressed object graph uses Merkle-DAG ideas to identify and exchange repository objects. Blockchains use Merkle trees to verify that a transaction belongs to a block without requiring every transaction in the proof. I used the same concept at the claim level in “Stop Re-Sending the Claim File”: verify the claim file’s integrity from its root hash instead of transmitting the whole file again.

When the cost of finding differences dominates, hash the structure, compare the roots, and let the tree point to exactly what needs fixing.

Insurers are in the business of long time horizons. A physical-damage auto claim you settle this month leaves behind a file that stays sensitive for years — the policyholder's name, address, driver's license, and Social Security number; the VIN and photos of the damaged vehicle; repair estimates, total-loss and salvage records; bank and payment details; and, when an injury rides along with the claim, medical records attached to it. That file doesn't stop being sensitive when the check clears. Litigation, subrogation, fraud review, and retention rules keep it alive for years, and the identity data inside it is sensitive for a lifetime.

Now pair that with a quiet fact about cryptography: the encryption protecting that file today may not protect it forever. This is Harvest Now, Decrypt Later — HNDL. An adversary copies the encrypted data now, keeps it with its context, and waits for the ability to read it. Nothing about that collection looks like a breach; there is often no detectable event at all. For a carrier, the data's secrecy lifetime routinely outlasts any quantum timeline, so the confidentiality failure has already begun — the decryption is simply scheduled for later. The uncomfortable truth: encrypted data can outlive the assumption that protects it.

The lock survives; the hinge does not

The reassuring half is that symmetric cryptography survives — AES-256 faces only Grover's algorithm, which weakens but doesn't break it. The problem is what sits in front of it. That claim file is sealed with a symmetric cipher whose key was established through a public-key mechanism, and RSA and elliptic-curve systems are exactly what Shor's algorithm dismantles. Recover that key-exchange layer later, reconstruct the symmetric secret, and the recorded data opens. The strong lock is bolted to a hinge that rusts on a known schedule.

The confidentiality failure has already begun — the decryption is simply scheduled for later.

Confidentiality has a migration clock

The planning question isn't "when will a quantum computer arrive?" It is whether the years a claim file must stay confidential, plus the years it takes to migrate a large carrier and its vendors, exceed the time until that capability might exist. Mosca's inequality states it plainly: if data must stay secret for x years and migration takes y years, you are exposed once quantum capability could arrive within x + y. For an insurer, x is measured in decades and y in years — the sum clears almost any horizon. And forward secrecy won't save you: a captured session still holds an ephemeral key-exchange problem a future quantum solution can undo, and the metadata alone — who filed, when, claim amounts — carries value on its own.

Not all data has the same half-life. A payment authorization loses value in minutes. A claim file — PII, VIN, damage photos, adjuster notes, and any attached medical records — stays identifying and exploitable for years. A Social Security number is effectively permanent. And a retention schedule is not a confidentiality period: it says how long you must keep the file, not how long its contents can hurt the policyholder — and an attacker's copy survives your lawful deletion.

Crypto agility begins with inventory

Swapping one algorithm for another is the easy half; the decisive half is whether you can find the vulnerable cryptography at all. Systems that label algorithm identifiers, key versions, retention periods, and data owners can locate what must move and prove it moved. A checklist that re-issues only public-facing certificates sails past code signing, database key-wrapping, backups, and the tunnels to repair networks, salvage vendors, and medical-bill review. Agility is observability and governance before it is a compiler flag.

Because you can't un-leak a claim file, the most useful milestone is blunt: the date after which high-priority new data no longer relies solely on quantum-vulnerable key establishment. The standards are ready — in 2024 NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). And the obligations carriers already answer to point the same way: the GLBA Safeguards Rule, the NAIC Insurance Data Security Model Law, HIPAA for the medical portions of a claim, and state breach-notification laws — none of which care when the attacker finally reads the data, only that you protected it for its promised life. Hybrid schemes offer a controlled bridge while interoperability matures.

The starting gun has already fired

The first large quantum computer will be a milestone, not a starting gun. For an insurer, the decisive event may already be behind us — a quiet copy of a claims archive, a stolen backup export — made years before anyone can read it, and impossible to recall. So the exercise isn't defending against a 2032 machine; it is deciding, today, which of your claim files would still harm a policyholder then, and shrinking that set before it is collected: minimize what you retain, protect new exchanges with standardized post-quantum cryptography, re-protect stored archives, and build the agility to do it again. The one thing you will never get to do is un-file the claim.

Consider the most thankless check a claims system runs: deciding, for every new claim, whether it has been seen before. At first notice of loss, an insurer wants to know whether this VIN, this claimant, this device, or this exact document has already appeared — in its own claims history, in a cross-industry fraud and duplicate database, or on a watch list. The overwhelming majority of claims are legitimate and new, so that check almost always comes back "no." But proving "no" is expensive: it means querying enormous datasets, often through an external shared service that charges per call and adds latency. Multiply that by every claim that flows in, and you are spending real time and money to confirm, over and over, that nothing is wrong.

The obvious fix — keep a full in-memory index of everything ever seen — is too large to hold for hundreds of millions of records. The clever fix is to ask a smaller question. We rarely need certainty that a claim is a duplicate or is on a list — the full lookup will confirm that anyway. What we need is a cheap, reliable way to know when a claim is definitely not on the list, so we can skip the lookup entirely. That asymmetry is the whole idea behind the Bloom filter.

A few hashes, a few bits, no stored keys

A Bloom filter is a fixed array of bits, all starting at zero, plus a few independent hash functions. To add a key — a VIN, a claimant ID, a document fingerprint — you hash it with each function to get several positions in the array and set those bits to one. To test a key, you hash it the same way and look at those positions. If any of them is still zero, the key was certainly never added. If all of them are one, the key is probably present. That is the entire mechanism: a few bit-sets on insert, a few bit-reads on query, and no stored keys at all.

Because it stores bits rather than keys, the structure is astonishingly compact — on the order of ten bits per element for a one-percent error rate, whether the key is a short VIN or a long document hash. A filter covering a million keys fits in about a megabyte and answers every membership test from memory.

The error points only toward more work

The magic isn't that the filter is small; it is where it is allowed to be wrong. All-ones can happen by coincidence — other keys may have set those same positions — so the filter occasionally says "probably present" for a key it never saw. That is a false positive. But a false negative is impossible: if a key was added, its bits were set, and they are never cleared, so the filter can never claim a key it holds is absent.

For a claims pipeline, that one-sided error is exactly the right shape. A false positive is harmless: you run the full duplicate-or-fraud check you would have run anyway, and it comes back clean. A false negative would be the dangerous case — waving through a real duplicate or a flagged claimant — and the Bloom filter structurally never does that. You can trust the "no." Skipping the expensive lookup is safe precisely because the only mistake the filter can make is to occasionally send you to do more work, never less.

A false positive is harmless — you run the check you would have run anyway. A false negative would wave through a real duplicate. The Bloom filter structurally never does that.

Tune memory, not the safety property

Three quantities set the behavior: the number of bits, the number of hash functions, and the number of keys. Add more keys to the same array and more bits flip to one, so false positives rise; spend more bits per key and they fall. The trade is direct and tunable — you buy a lower false-positive rate with memory, not with more lookups. One consequence surprises people: a standard Bloom filter cannot delete. Clearing a key's bits might clear a bit another key relies on, reintroducing the one error it must never make. If a claimant must come off a set, a counting Bloom filter uses small counters instead of single bits, or you simply rebuild the filter when the reference data is refreshed — which suits a watch list that is regenerated on a schedule anyway.

Fast-track the honest majority

Put a Bloom filter of "keys already seen or on the watch list" in memory beside the intake service — VINs, claimant identifiers, device and telematics IDs, document fingerprints. On every first notice of loss, test the filter first. "Definitely not" — the common case for honest, novel claims — skips the expensive cross-database and historical query and lets the claim fast-track into the pipeline. "Maybe" — the rare case — escalates to the full duplicate and fraud investigation. Most legitimate claims clear intake without ever touching the costly lookup, and the filter is cheap to rebuild whenever the reference sets change.

The pattern beyond intake

Once you see the pattern — a cheap, trustworthy "no" that lets you avoid an expensive lookup — it shows up all over a carrier's systems. Document and photo pipelines can ask "have we already ingested this exact file?" before deduplicating. A cache can avoid storing rarely-read policy documents by only keeping an object the second time it is requested. Notification systems can skip re-sending a message they've probably already sent. In each case the structure answers a common, cheap "no" instantly and defers only the rare "maybe" to the real, expensive check. (The same Bloom filter, incidentally, is what lets the claims datastore itself skip disk reads for records that don't exist — the idea started in storage engines.)

A Bloom filter is a small idea with a sharp edge: give up exactness, but only about the answer you can afford to be wrong about. When "not on the list" is the common case and a mistaken "maybe" costs only the check you were going to run anyway, a probabilistic filter beats an exact index on both memory and speed. The next time your intake pipeline spends real time and money confirming that a claim is clean, ask whether one byte of bits could have answered first.