Relation Extraction Provider is chosen empirically; a Provider may fulfil fused Capabilities

The framework builds the Capability/Provider plumbing for Relation Extraction and stays agnostic about which concrete model wins; the choice is made empirically per corpus via the Quality Report and the gold-set harness. Three candidate Providers are anticipated: (1) an LLM-based extractor over any OpenAI-compatible endpoint (incl. local Ollama), (2) knowledgator/gliner-relex-multi-v1.0, and (3) the author's custom span-predictor encoder. Consequence for the seam: a single Provider may fulfil BOTH Entity Extraction and Relation Extraction as a fused Capability — gliner-relex and the custom encoder do joint NER+RE in one pass — so the Pipeline must allow one Provider to satisfy two adjacent Stages, not force a Provider-per-Stage. The custom encoder and gliner-relex are decoupled from superpod's vLLM pooling-plugin patches: they run via plain transformers/ONNX in-process for the CPU path or behind a Triton/OpenAI-compatible endpoint for the performance path (per ADR-0007). Rejected: hardcoding the custom encoder as THE reference (forces GPU+vLLM into first-run, contradicts ADR-0007) and shipping a co-occurrence stub (undercuts the KG quality story at Assembly).