A marina's 200-page slip-policy binder will not fit in one model sitting. Staff split it into overlapping passages before anyone builds a prompt or a retrieval index. They are not training a new model and are not turning the pages into meaning-vectors yet. Which step is this?

Staff splitting a 200-page marina slip-policy binder into overlapping passages before prompting or building a retrieval index are performing chunking: dividing a long source into workable pieces. The binder will not fit in one model sitting, and the team has not yet embedded pages or trained weights. Chunking is the document-preparation step that makes later embedding, retrieval, or multi-pass prompting feasible without pretending the entire policy fits in a single context window.

Embedding the binder as a single meaning vector skips the stated step and usually fails for long policies. One vector over a 200-page binder collapses too much detail; the team said they are not turning pages into meaning-vectors yet, and they are splitting first.

Fine-tuning model weights on the whole binder is a training action. The marina staff are preparing text segments for use with an existing generative or retrieval workflow, not running a weight-update job on the policy corpus.

Raising temperature so the binder fits in one window misunderstands both controls. Temperature changes randomness of generation; it does not expand context capacity or make 200 pages fit. Fitting is a context-window and chunking problem, not a sampling-parameter trick.

Exam caveat: chunk boundaries matter—cutting mid-clause can strand definitions away from the rules that use them, which later hurts retrieval quality even when chunking was the right high-level step.

Operational check: chunk on policy section headings with modest overlap, keep a chunk-id to page-map, and verify a sample query about slip fees retrieves the passage that still contains both the fee rule and its defined terms.