One research lineage. Different experiments.

The current flagship combines candidate selectors, support constraints, strict registry validation, and a domain executor. The commercial starting point is an offline, customer-specific evaluation—not an autonomous deployment.

Read the architecture and reproducibility instructions or inspect the flagship working manuscript. These links track the public repository; the manuscript is a draft, not a claim of peer-reviewed acceptance.

The local publication snapshot generated August 13, 2026 reports 12 domains and 682 canonical cases, with zero false accepts in that suite. This is a dated offline research result, not a new October benchmark run or a customer deployment result. The evaluated feature contracts are separable; strong results on those contracts do not establish performance on messy, incomplete customer data.

The local snapshot can be newer than the public repository. Request the exact revision, case manifest, and evaluation packet before relying on a number. Do not combine its metrics with the earlier selection experiments below.

The March 2026 selection article describes finite-registry neural selection, backend-sensitive measurements, and registry drift. It remains useful background, but its test counts and MPS/CPU results are historical and are not the current workflow-evaluation scorecard.

The earlier public selection-paper repository uses the Key-Value Response Mapping name. Experimental LLM-as-CPU, GPU, and operating-system threads also use KVRM terminology. Treat each implementation and its evidence separately.

Suppose an automation proposes “restart service.” A registry entry alone says the action exists. The workflow may also require an approval, a known service identity, and a permitted maintenance window.

• Approval and required context present: evaluate the action against the declared conditions.
• Approval absent: do not treat model confidence as permission.
• Context missing or stale: refuse or escalate according to the agreed contract.

This is an illustrative checklist, not a running KVRM demonstration or measured result. A conventional rules engine can implement these simple checks too. The paid evaluation asks whether the broader architecture adds useful coverage or better failure handling for your workflow.