A technical writing platform uses Claude to generate API documentation from OpenAPI specifications. The generated docs must use the company's custom terminology (e.g., 'endpoint' must be called 'resource path,' 'response' must be called 'return payload'). The team observes that standard terminology appears in 15-20% of generated sections despite system prompt instructions. Temperature is already at 0.1. The team's options are: (A) increase few-shot examples to 20 pairs demonstrating correct terminology, (B) add a self-review step where Claude checks its own output for prohibited terms, (C) post-process with deterministic string replacement. Which approach is best for production, and what does the correct architecture look like?

The combination of few-shot conditioning (Approach A) plus deterministic post-processing (Approach C) is the architecturally optimal solution. Few-shot examples reduce terminology violations during generation, which matters for cases where the prohibited term affects surrounding word choice (e.g., 'the endpoint accepts' vs 'the resource path accepts' — changing the noun affects the verb context). Post-processing handles residual violations with 100% reliability. This avoids Approach B's weaknesses: a self-review pass is an additional API call (cost + latency), and Claude doing its own terminology review may miss violations it just confidently generated — same-model self-review has documented blind spots for errors the model produced. Option C alone (post-processing only) is technically 100% reliable for exact matches but doesn't improve generation quality — and simple string replacement can create semantic errors ('the endpoint parameters' → 'the resource path parameters' may be grammatically awkward in some contexts, while few-shot conditioning produces naturally fluent correct terminology). Option A alone leaves the 1-5% residual violation rate that can still fail compliance checks.