← ClaudeAtlas

orchestrate-rule-engine-architectlisted

Design a deterministic routing engine that is auditable and injection-immune. Use when choosing between rules and an LLM classifier, and when ordering rule tiers. Includes how to prove no rule is dead or shadowed.
NITISH-R-G/hackerrank-orchestrate-skills · ★ 3 · AI & Automation · score 71
Install: claude install-skill NITISH-R-G/hackerrank-orchestrate-skills
# Orchestrate: Rule Engine Architect **Evidence tier: first-hand build (August 2026).** Grounded in a completed Orchestrate submission that was audited to destruction — 48 logged defects, 9 measured-and-rejected optimisations, 17 certification scripts. Every number below was measured on that system. Nothing here claims access to HackerRank's internal scoring. ## When a rule engine beats an LLM classifier Three conditions, all measurable before you commit: 1. **The targets are templated.** In the real build, 30 labeled rows contained only **24 distinct reason strings**, several repeating verbatim. Ground-truth reasons state *which rule fired*. A rule engine reproduces that exactly; a generative model approximates it. 2. **The dataset attacks LLM routers.** One labeled row was a prompt-injection attack whose correct label was `mute/scam`. A rule engine is **structurally immune** — message text never enters a decision-making prompt. 3. **The safety-critical signals are structured data**, not prose: verification flags, opt-out state, sender role, dismissal history. The model layer earns its place only where structured data genuinely cannot reach — reading a poster, hearing a voice note. ## Tier ordering is a policy statement ``` SAFETY ▶ RELATIONSHIP / URGENCY ▶ ENGAGEMENT ▶ DEFAULT ``` Safety sits above engagement because the spec says risk is muted *"regardless of the user's usual engagement."* Ordering encodes that sentence. Write the reason in