Retrieval becomes an AI systems problem when relevance, constraints and uncertain language meet execution.
A useful retrieval system must combine semantic relevance with explicit constraints while preventing uncertain language interpretation from silently removing valid candidates. ARMIE separates language interpretation, user authority and deterministic retrieval execution as distinct responsibilities.
Retrieval as a system
Query → Plan → Runtime → Result
Governed interpretation → C1 authority
The v0.5.1 language layer sits above the retrieval platform; it does not replace the platform.
Natural language can propose intent. It cannot silently authorize execution.
Ambiguous supported intent triggers clarification. The user resolves the bounded choice, confirms the canonical contract, and only then can deterministic C1 execute. Unsupported meaning stays unsupported; editing a confirmed interpretation invalidates previous authorization. Manual structured C1 and confirmed natural-language execution converge at the same RetrievalContract boundary. No model participates in final compilation.
When automation failed held-out evaluation, the architecture changed.
Rule-based semantic-role classification looked promising on small development fixtures, then failed to generalize on a prospective held-out benchmark. A stronger local model improved parts of the task but did not make false hardening safe enough. The project did not promote automation simply because an LLM was available; uncertainty became an explicit product state routed back to the user.
Runtime and validation proof
The benchmark is controlled synthetic evidence, not customer-scale or real-world expert-search quality. Current CI covers Python 3.9 and 3.11.
Constraint-aware execution
Supported C1 constraints use native Elasticsearch pre-filtering.
If fewer eligible results exist than requested, the system reports the shortfall rather than backfilling ineligible candidates.
Natural-language-derived hard constraints require clarification and confirmation where needed.
Interpretation, contract and execution lineage remain inspectable.
Dense, Sparse/Keyword, Hybrid/RRF and Graph remain explicit platform strategies.
Reranking, result processing, traces and evaluation remain separate from planning and execution.
Designed beyond one retrieval domain
Expert Discovery is the released product scenario, but the core runtime uses domain-neutral objects and contracts such as Query, RetrievalPlan, RetrievalRuntime, ResultItem, RetrievalResult, registries and evaluation. A read-only architecture review found the generic platform suitable for a bounded second-domain proof without changing the core platform.
Current maturity and limitations
A retrieval platform was built, measured, stress-tested and deliberately constrained where evidence showed automation was unsafe. v0.5.1 includes the governed natural-language workflow, deterministic RetrievalContract/C1 execution, real Elasticsearch validation, Workbench integration, browser E2E and controlled evaluation infrastructure.
It does not claim real-world expert-network quality, unrestricted natural-language understanding, arbitrary automatic hard-constraint extraction, production multi-tenant deployment, universal cross-domain semantics or shipped Companion Memory integration.