SLM Content
Generation Pipeline

For scheduled pipeline types (not interactive chat), the data requirements are fully predictable. Pre-fetching in parallel has two major advantages: total wall time equals the slowest single call (not sum of all calls), and the LLM receives a complete context block rather than making tool decisions under generation pressure. The agentic loop still fires for unexpected data needs, but the pre-fetch layer covers 90%+ of what each pipeline type needs. The PIPELINE_PREFETCH config makes it explicit and testable — a new engineer can see exactly what data flows into each pipeline type before reading any LLM code.

should_gate_for_fact_pack() inspects the pre-fetched KPI fact pack before any LLM call. Required conditions: crowd_score is present and numeric, top_10_waits has at least one entry, and operational_date matches today (Eastern Time). If any condition fails, the pipeline logs a gate reason (insufficient_kpi_data, aws_auth_failure, generation_failed) and skips generation entirely. This prevents publishing content built from stale or partial data — which would be worse than publishing nothing. The gate reason is auditable in the pipeline run log.

PostgreSQL BM25-style ranking (and the previous Cosmos query layer) scores documents by text relevance. If you query knowledge_types=["popularity_ranking"] with a generic question, the ranker returns low-priority attractions written last in the upsert cycle. Headliner rides (TRON, Rise of the Resistance, Seven Dwarfs Mine Train) that were upserted earlier score lower on recency-based metrics. By embedding headliner names directly into the query string — "TRON Rise Resistance Seven Dwarfs Mine Train Guardians Cosmic Rewind popularity ranking" — the text matching layer surfaces the right rides first regardless of upsert order. This was discovered through operational observation: bulletin content was featuring Remy's Ratatouille Adventure over Space Mountain because Remy was written later and scored higher on recency.

The Bedrock Agent runtime (RETURN_CONTROL loop) serialized tool calls: the agent emitted one tool call, waited for the response, then decided whether to call another. This meant a 3-tool bulletin build took 3 sequential 45-second HTTP calls = 135 seconds. LangChain's ChatBedrock calls bedrock-runtime:InvokeModel directly — we own the agentic loop. When Claude emits 5 tool calls in a single turn, we fire all 5 in parallel via ThreadPoolExecutor and collect results. The same bulletin build now takes ~45 seconds (cost of the slowest tool). The secondary benefit is output format control: with the Bedrock Agent, getting structured section-marked output reliably required retries. At temperature=0 with explicit format instructions in the system prompt, Claude's first response is always correctly formatted.

Restaurant wait patterns are strongly day-of-week dependent (Magic Kingdom Saturdays vs. Tuesdays have completely different dining pressure). The structured knowledge query "top 10 restaurants by wait time date={last_same_dow}" resolves {last_same_dow} to the prior week's same day-of-week (e.g., for a Thursday bulletin, it fetches last Thursday's restaurant data). This gives the LLM a meaningful historical dining baseline that reflects the same crowd pattern as today — much more accurate than a trailing 7-day average, which blends weekday and weekend patterns.