technical glossary / AOPX vocabulary

Key terms, defined precisely.

Definitions for the terms used across AOPX, provider routing, MCP, benchmarks, production outcomes and agent infrastructure. The glossary reflects the current project vocabulary and avoids claiming production capabilities that are not live.

core routing evidence lab mcp infrastructure

Precision is the beginning of wisdom.

01 · Core

AOPX and the product model.

AOPX: An evidence-based provider-selection layer for software agents. AOPX recommends a primary provider and fallback path, records reported production outcomes, and keeps benchmark evidence separate from production evidence.
SEARCH: The current production category in AOPX. SEARCH recommendations currently operate across Brave Search and Tavily Search.
Provider: An external service that can execute a task on behalf of a calling agent. In the current SEARCH implementation, providers are search APIs.
Primary provider: The provider AOPX recommends calling first for a given recommendation.
Fallback provider: The second provider in the recommended path. It is used only when the primary path requires fallback according to the active policy.
Provider path: The ordered provider sequence returned by AOPX for a recommendation, typically a primary provider and an optional fallback provider.
Recommendation: A production decision returned by AOPX describing which provider path an agent should use under the active policy.
Recommendation ID: The identifier returned with a production recommendation. A reported outcome must reference a valid prior recommendation ID.
Consultation-only: The current AOPX operating model. AOPX recommends the provider path, while the calling agent performs the provider execution externally.
Reported production outcome: A result sent back to AOPX after execution of a real production recommendation. It is reported by the caller and is not described as independently verified.
Production evidence: Evidence derived only from real production recommendations and reported production outcomes. Benchmarks, tests, shadow runs and replays are excluded.
Benchmark evidence: Evidence produced inside an AOPX LAB under a defined benchmark protocol. Benchmark evidence is not mixed into production outcome statistics.
Evidence over claims: The AOPX operating principle: publish measurable results, provenance and limitations instead of relying on unsupported marketing claims.
Vendor Memory: The private production record AOPX uses to accumulate provider performance evidence over time. Production Vendor Memory is private and is not exported as a public dataset.
Public evidence ledger: The public AOPX evidence view exposing anonymised reported production outcomes and aggregate pilot statistics without publishing unique caller identity data.
Provider alias: A public anonymous provider label such as Provider A or Provider B. Public evidence can use aliases instead of exposing the real provider mapping.
Public pilot: The current external AOPX operating phase. Billing is disabled and the focus is real usage, outcome return and evidence accumulation.
Policy: The current AOPX decision rule that determines how provider recommendations are produced for a category and mode.
Policy version: The version identifier attached to a production recommendation, such as search-consult-v0.2.
Private decision engine: The non-public internal logic that produces AOPX provider decisions. Public evidence is designed to make results inspectable without publishing the engine itself.

02 · Routing

Selection, fallback and decision behavior.

Routing: Choosing which provider path an agent should use.
Contextual routing: Provider selection that uses context about the task or request. AOPX does not use this term as a blanket claim for the current production selector unless the deployed policy actually uses request-level context.
Query-aware routing: Routing that uses the query text or request features as input to provider selection. LAB-004A explored this approach, but it is not the basis of the current production policy.
Aggregate provider statistics: Provider performance statistics aggregated across production evidence for a category and mode, such as success, quality, cost and latency.
Cold start: The phase in which there is not yet enough production evidence for stable provider comparison. AOPX can rotate providers during cold start until minimum observations are reached.
Exploration: Selecting a provider partly to gather evidence rather than always choosing the current top-ranked option.
Exploitation: Selecting the provider currently estimated to perform best under the active policy.
Epsilon: A small exploration probability used by the current exploration logic after cold start.
ECONOMY: AOPX mode designed as a cost-oriented reference path. In the current v0 SEARCH policy, ECONOMY uses a fixed provider reference.
CRITICAL: AOPX mode focused on reliability with a primary provider plus second-provider fallback. Current benchmark evidence supports fallback reliability more strongly than a claim of contextual-routing superiority.
BALANCED: An AOPX mode that is currently disabled in production v0 because the earlier signal did not confirm on holdout.
Fallback: Calling the second provider after the primary path fails according to the active policy.
Cascade: A deterministic provider order such as Brave then Tavily. A cascade can improve final success compared with a single provider when provider successes are complementary.
Fixed provider: A strategy that always calls the same provider first rather than selecting among providers.
First-call success: Whether the first provider in the path succeeds. This matters because final success can be identical across fallback orders even when cost, latency and fallback count differ.
Final success: Whether the full provider path succeeds after any allowed fallback.
Quality score: A normalized AOPX measurement representing the assessed quality of a provider result inside a benchmark or reported attempt record.
Latency: Elapsed time for a provider attempt, typically measured in milliseconds.
Reported provider spend: Provider cost reported back with a production outcome. AOPX distinguishes this from AOPX pricing or billing.
Outcome return rate: The share of recommendations for which callers later submit a reported production outcome.
Success ceiling: The maximum final success achievable from a given set of providers on a fixed paired dataset when at least one provider succeeds.
Union / oracle ceiling: The success rate achieved if the system could always choose a successful provider whenever at least one provider succeeds. It is a diagnostic upper bound, not a deployable policy.

03 · Evidence

Production evidence, hashes and integrity.

SHA-256: A cryptographic hash function used by AOPX to identify frozen benchmark artifacts and support reproducibility and integrity checks.
Hash: A deterministic cryptographic representation of data. In AOPX it is used for artifact integrity and, where needed internally, pseudonymous technical correlation.
Origin hash: A pseudonymous technical identifier that may represent an origin without publishing the raw identifying value. Unique origin hashes are not intended to be exposed in public telemetry.
Evidence ID: A stable identifier associated with an evidence run or benchmark artifact set.
Run ID: A unique identifier for a specific AOPX benchmark run, for example LAB0035-E33AC6B7B4.
Frozen artifact: A benchmark file that is not modified after publication and can be identified by its hash.
Reproducibility: The ability to trace a published benchmark result back to a frozen run, artifacts and hashes.
Provenance: Information showing where an observation, result or evidence artifact came from and how it was produced.
Production-only: AOPX terminology indicating that a statistic excludes LAB, test, shadow and replay events.
Public telemetry: Aggregate information AOPX exposes about the pilot. It should not reveal raw IP addresses, unique origin hashes, user-agent strings or identifiable caller data.
One outcome per recommendation: A production integrity rule preventing the same recommendation from being used to submit multiple outcomes.
Attempt path validation: Validation that a reported outcome follows the provider path AOPX actually recommended.
Provider poisoning: The risk that inaccurate or manipulated outcome reports distort production memory or future provider decisions.
Shadow run: An evaluation run that does not count as production evidence.
Replay: A repeated or reconstructed request used for testing or analysis. Replay data is not counted as reported production evidence.

04 · LAB

Benchmark and evaluation terminology.

LAB: A controlled AOPX benchmark environment used to evaluate provider strategies, decision rules and evidence before any production policy change.
LAB-003.5: A frozen SEARCH benchmark run covering 150 fresh missions. In CRITICAL mode, the AOPX policy reached 40/50 final successes, Tavily fixed reached 37/50, and a post-hoc Brave-to-Tavily cascade also reached 40/50.
LAB-004A: A development experiment for query-aware routing using a previously inspected dataset. It is development evidence only and is not treated as pristine prospective proof.
Prospective holdout: A fresh evaluation set not used to design or tune the policy being evaluated. It is used to test whether a previously frozen rule generalises.
Holdout: An evaluation subset kept separate from model or policy development. Its evidentiary strength depends on whether it remained truly untouched before evaluation.
Post-hoc analysis: Analysis performed after a benchmark result is known. Post-hoc findings can be useful for diagnosis but do not replace pre-registered prospective evidence.
Pre-registration: A benchmark plan, decision rule or evaluation criterion fixed before results are observed, used to reduce hindsight bias.
Mission: A benchmark task or test request used to evaluate provider behavior under a defined protocol.
Paired mission: A benchmark mission executed against multiple providers so their results can be compared on the same task.

05 · MCP & API

Agent and workflow integration surfaces.

MCP: Model Context Protocol, an open protocol that lets AI clients discover and call external tools. AOPX exposes a remote MCP server.
MCP server: The AOPX remote tool surface available at https://api.aopx.fr/mcp/.
recommend_provider: The AOPX MCP tool that returns a provider recommendation for the current supported category and mode.
report_outcome: The AOPX MCP tool used to submit the real result of a prior production recommendation.
public_stats: The AOPX MCP tool that returns aggregate production-only public pilot statistics.
public_outcomes: The AOPX MCP tool that returns recent anonymised reported production outcomes.
MCP Registry: The public Model Context Protocol registry where AOPX is listed under fr.aopx/aopx.
Glama: A third-party MCP discovery and metadata service where the AOPX connector can be listed.
n8n: A workflow automation platform. AOPX has a beta community node package named n8n-nodes-aopx.
OpenAPI: The machine-readable API description exposed by the AOPX service and used by developer tooling.
REST API: The HTTP API surface for health, provider recommendations, outcome reporting and public production telemetry.

06 · Infrastructure

Current providers, pilot state and wider agent stack.

Authless: A service state where no authentication credential is required. The AOPX MCP pilot is currently authless.
Rate limit: A request-volume control used to reduce abuse and protect service availability.
Serper: A search provider under evaluation for future AOPX support. It should not be described as an active production provider until it is actually enabled.
Brave Search: One of the current production SEARCH providers supported by AOPX.
Tavily Search: One of the current production SEARCH providers supported by AOPX.
x402: An emerging machine-to-machine payment pattern over HTTP. It is relevant to the wider agent economy but is not part of the current AOPX public pilot billing flow.
Machine-native procurement: The broader AOPX direction in which software agents can evaluate and choose external providers programmatically before execution or payment.
Agentic infrastructure: Infrastructure designed for software agents to discover, select and use external services through machine-readable interfaces.
Agent: A software system that can make decisions, call tools and execute multi-step tasks.