A courts department's Bedrock knowledge base keeps returning outdated guidance because newly filed procedural documents aren't reflected in retrieval results. Before launch, the team is designing the chunking and embedding configuration for the ingestion pipeline. Which approach best supports timely, accurate coverage of new documents?

A RAG pipeline is only as fresh as its last embedding run, so wiring re-chunking and re-embedding into the document-update event — rather than treating ingestion as a one-time job — is what keeps retrieval results current as new filings land. Chunk boundaries matter too: sizing chunks to preserve a full procedural step avoids returning a fragment that references a step the retriever never surfaced. Embedding a hundred-page manual as a single vector dilutes the semantic signal so badly that a query about one narrow procedure competes with the meaning of the entire document, which tanks retrieval precision. Assuming the foundation model's context window will absorb procedural changes after ingestion misunderstands the architecture: the model only sees what retrieval hands it at query time, and a document embedded once stays frozen in the vector store until something re-embeds it. Chunking purely on a fixed character count ignores document structure, so procedures get sliced mid-sentence and chunks lose the coherence a retriever needs to return a usable answer. Scope caveat: re-embedding everything on every minor edit can get expensive at scale, so many pipelines diff documents and only re-chunk sections that actually changed. Operational check: after publishing a new ordinance, query the assistant on that specific procedure and confirm the retrieved chunk contains the updated text.