Skip to content

Capability protocols with provider plugins as the model-agnosticity seam

Each Stage depends on a narrow Capability protocol (Parser, EntityExtractor, RelationExtractor, PIIDetector, Embedder, EntityLinker, …) typed against the framework's data contracts; concrete models plug in as Providers registered via Python entry points. In-process models (e.g., GLiNER via transformers), remote inference endpoints (vLLM, Triton, OpenAI-compatible), and cloud AI services (Azure Document Intelligence, AWS Textract/Comprehend) are all just Providers of the same Capability — the framework never names a model. Core ships exactly one permissively-licensed reference Provider per Capability so the demo runs end to end. Rejected: HTTP-only service contracts (forces N containers for a laptop demo, loses type safety — the superpod shape), LiteLLM-style registry strings (OCR/NER/RE/linking signatures are too heterogeneous for one router surface), and config-swappable checkpoints on a fixed vLLM stack (model-swappable, not model-agnostic).