# Interpretations

Search Engineering · Course

Interactive edition: https://mutapa.dev/search-engineering/course/interpretations

Each chapter changes what the next stage can safely assume. These fifteen interpretations follow those consequences across the course.

## Part 1: Search Foundations

### Chapter 1: [What Is Relevance?](https://mutapa.dev/search-engineering/course/what-is-relevance.md)

A search system can optimize only the evidence it receives. When availability, context, or the user's actual task never reaches the judgment, a better score can reward a worse result.

### Chapter 2: [Corpus and Indexing](https://mutapa.dev/search-engineering/course/corpus-and-indexing.md)

Indexing decides which evidence will still exist when a query arrives. A tokenizer, retrieval unit, or compressed vector that removes a distinction also removes every later stage's chance to use it.

### Chapter 3: [Query Understanding](https://mutapa.dev/search-engineering/course/query-understanding.md)

The words in a query provide partial evidence of a task. Rewrites, structure, and domain language should recover missing context while preserving the request the user made.

### Chapter 4: [Retrieval](https://mutapa.dev/search-engineering/course/retrieval.md)

Lexical retrieval preserves exact names, phrases, and domain terms. Dense retrieval recovers candidates expressed in different language. Ranking can compare both, but it cannot restore a film that neither path admitted.

### Chapter 5: [Ranking and Fusion](https://mutapa.dev/search-engineering/course/ranking-and-fusion.md)

Every ranking stage spends more computation on fewer candidates. Its window makes exclusions permanent: once a relevant result falls outside it, a stronger downstream model cannot recover the loss.

### Chapter 6: [Generation](https://mutapa.dev/search-engineering/course/generation.md)

Fluency cannot establish support. The generator must work within the evidence and context it receives, preserve the link from each claim to a source, and refuse when the available passages cannot carry the answer.

### Chapter 7: [Evaluation and Feedback](https://mutapa.dev/search-engineering/course/evaluation-and-feedback.md)

Clicks and outcomes record what happened under the ranking that was shown. They become useful evidence only when the full impression survives and the team tests whether its interpretation predicts the outcome it claims to represent.

## Part 2: Agentic Search

### Chapter 8: [Agentic Orchestration](https://mutapa.dev/search-engineering/course/agentic-orchestration.md)

An agent adds a control loop around the existing retrieval system. Each inspection and retry inherits the quality, latency, and failure modes of the tools the loop can call.

### Chapter 9: [Plan and Route Complex Searches](https://mutapa.dev/search-engineering/course/plan-and-route-complex-searches.md)

A plan earns its cost by exposing dependencies and sending each question to a source that can answer it. The plan should change only when new evidence resolves a dependency or exposes another one.

### Chapter 10: [Maintain State and Recover](https://mutapa.dev/search-engineering/course/maintain-state-and-recover.md)

Recovery begins with verified work stored outside the model. A checkpoint lets the harness resume from known state, rerun only unfinished work, and preserve the failure and fallback that changed the evidence path.

### Chapter 11: [Authorize Agent Actions](https://mutapa.dev/search-engineering/course/authorize-agent-actions.md)

A model may retrieve information and propose an action. Permission comes from current identity and deterministic policy, while narrow tools and bounded approvals keep a bad proposal from becoming an unauthorized effect.

### Chapter 12: [Evaluate Agentic Search](https://mutapa.dev/search-engineering/course/evaluate-agentic-search.md)

The final answer hides the route that produced it. Evaluation must inspect steps, retries, handoffs, policy decisions, cost, and outcome so that a correct result reached through an unacceptable path still fails.

## Part 3: Governed Search

### Chapter 13: [Permissioned Retrieval](https://mutapa.dev/search-engineering/course/permissioned-retrieval.md)

Authorization begins before candidate generation. If restricted evidence reaches ranking, counts, caches, traces, or model context, removing it from the final display comes too late to prevent disclosure.

### Chapter 14: [Policy Through the Trajectory](https://mutapa.dev/search-engineering/course/policy-through-the-trajectory.md)

Authority must be current wherever protected evidence is used. Cache hits, delegated work, memory reads, and resumed checkpoints each create a new decision for the receiving boundary to make.

### Chapter 15: [Connectors and Trust Boundaries](https://mutapa.dev/search-engineering/course/connectors-and-trust-boundaries.md)

A connector crosses a trust boundary whenever it supplies a claim, record, or effect. Its contract must make identity, provenance, freshness, and commit status inspectable, then narrow, reconcile, or stop when one is unknown.