Specify before optimizing
Answer each prompt on paper, then reveal the model answer. A genuinely good specification names inputs, outputs, dimensions, parties, trust, and tolerated approximation.
Computation
1. Write the score for corpus vector j with both indices clearly visible.
sj = ∑i=0D−1qivj,i.
2. What does top-k actually add beyond scoring?
It sorts the scores, resolves ties under a clear policy, and returns k winners.
3. Name two exact contracts an embedding comparison requires.
Shared model/preprocessing and shared dimension/coordinate order; normalization policy should also be completely explicit.
Privacy and cost
4. Which party may safely hold the secret key?
The trusted client. If the scoring server held it, the central value-confidentiality boundary would instantly disappear.
5. What can access-pattern leakage reveal to a server?
The selected or frequently selected corpus items, which can strongly correlate with a private query.
6. Why count rotations separately from additions?
A rotation implies a heavy automorphism and key switch with distinct evaluation keys, massive memory traffic, and high latency.
7. Why is normalization a preprocessing contract rather than a mathematical fact about dot products?
The dot product accepts vectors of any magnitude. Normalization is a deliberate architectural choice that makes direction dominate magnitude and makes unit-vector dot products equal cosine similarity.
8. Separate the loops clearly in one sentence.
Index i walks D coordinates to create one score; index j walks M corpus vectors to create the score collection.
Mastery check
Which is the exact hot-path objective for the next chapter?
Chapter 3 complete
The problem is now beautifully precise
We need M dot products over length-D embeddings, safely evaluated across a strict privacy boundary, with completely client-side ranking. Ordinary encrypted lane reduction would drop heavy rotations into the repeated score path. In the next chapter, we're going to derive a data layout that fundamentally changes the shape of that computation.
Repository layer · second pass
Can the problem statement survive implementation without hidden assumptions?
A useful specification gives dimensions, representations, trust boundaries, numerical tolerances, batch shape, and output semantics. It also states exclusions: embedding generation is outside the FHE circuit, ranking occurs after client decryption, and the initial target is exact corpus-wide scoring rather than approximate indexing.
Write acceptance properties before the construction. That prevents a clever packing trick from quietly changing the problem—for example by exposing the winner, comparing incompatible embeddings, or dropping candidates.
Reasoning chain
- 1
Specify typed inputs and provenance.
- 2
Specify authorized knowledge per party.
- 3
Define mathematical scores and ordering.
- 4
Set precision and failure tolerances.
- 5
Define batch limits and unsupported cases.
- 6
Turn every sentence into at least one test.
Worked trace
Turn a vague goal into properties
- Vague: “search encrypted vectors quickly.”
- Correctness: every decrypted target approximates q·vⱼ.
- Privacy: scorer lacks plaintext q and plaintext scores.
- Performance: scoring hot path uses no encrypted rotations.
Result. The properties are independently testable and reveal tradeoffs.
Executable lens · Python
Make the hidden state visible
def acceptance(query, corpus, decrypted, tolerance):
expected = [sum(a*b for a,b in zip(query,v)) for v in corpus]
assert len(expected) == len(decrypted)
assert all(abs(a-b) <= tolerance for a,b in zip(expected,decrypted))Retype this example, predict each intermediate value, and then change one input that touches a boundary.
Misconception clinic
Tempting mistakes
- Using “secure” without naming adversaries and assets.
- Treating performance as an unmeasured adjective.
Retrieval and transfer
Close the book first
- Write a one-page contract for D=512 and N=4096.
- Add a deterministic ranking rule.
- Name a non-goal whose accidental inclusion would distort the design.