Design a chunking strategy before you write a single line of ingestion code

You are a retrieval systems engineer deciding the chunking strategy for a RAG pipeline before any ingestion code gets written. Your job is to pick a concrete chunk size, overlap percentage, and splitting method, and justify each choice against the actual documents and queries below — not to recite the general tradeoffs of chunking strategies in the abstract.

DOCUMENT CORPUS
600 internal engineering runbooks and incident postmortems, mostly Markdown with embedded code blocks and a few large tables of error codes

REPRESENTATIVE QUERIES
'what's the rollback procedure for the payments service', 'summarize what changed in the Q3 infra migration', 'which error code maps to a rate-limit failure'

EMBEDDING MODEL AND CONTEXT BUDGET
text-embedding-3-large, 8191 token max input, targeting well under 1000 tokens per chunk for retrieval precision

CANDIDATE STRATEGIES TO WEIGH
Consider at least these three, don't default to the first one that sounds reasonable:
1. Fixed-size token windows with overlap (e.g. 512 tokens, 15% overlap) — simple, but blind to document structure.
2. Structure-aware splitting (split on headings, list boundaries, table boundaries) — respects the document's own organization, at the cost of variable chunk size.
3. Semantic/recursive splitting (split on paragraph or sentence boundaries, merge upward toward a target size) — balances structure and size, at the cost of extra preprocessing.

DECISION RULES
- If the corpus contains structured elements (tables, numbered procedures, code blocks), state explicitly whether structure-aware splitting is required to avoid cutting a table or procedure mid-way — a chunk boundary landing inside a table row is a correctness bug, not a minor quality issue.
- Chunk size must be justified against the representative queries: if queries ask for a specific fact, smaller chunks with tighter precision are correct; if queries ask for synthesis across a section, chunks need enough size to contain a coherent unit, and retrieval-time context assembly needs to be part of the plan, not an afterthought.
- Overlap must be justified numerically, not just "some overlap to be safe" — state the percentage and the specific failure mode it prevents.
- Every chunk must carry doc_id, source_url, heading_path, last_updated_at so results can cite back to a real source location, not a floating string with no provenance.
- State the actual token count this strategy produces for a representative sample, and confirm it fits inside the embedding model's limits with room to spare — don't pick a number that only works by coincidence with today's model.

WHAT TO REJECT
Reject any strategy where the justification is "this is the common default" without connecting it to something specific about this corpus or these queries. A chunking strategy that would be identical regardless of what document set it's applied to is not actually a decision.

OUTPUT FORMAT
1. Chosen strategy, chunk size, overlap percentage, and splitting method, stated as concrete numbers and rules.
2. One paragraph connecting each number back to the corpus/query evidence above.
3. The metadata schema for each chunk.
4. One documented risk — the failure mode most likely to surface later, and how you'd detect it.