The gateway activates only after the Cognitive Engine has an authorized inference requirement and a candidate endpoint must be matched to the required capability and privacy class.
Inference Gateway
Change models or endpoints without surrendering policy.
Registers explicit embedded, local, private, dedicated, public BYOK or mixed endpoints with capability, privacy, residency, health and cost metadata.
A normalized provider response or a safe provider failure, with explicit endpoint selection, capability, deployment class, health and usage metadata — without allowing an automatic fallback to cross the approved exposure boundary.
Why it exists
The problem this module is designed to solve.
Provider SDKs often entangle transport, model names, fallback behavior and business policy. A seemingly harmless endpoint change can alter data exposure, residency, capability, latency and cost without the application recognizing that its operating boundary moved.
02 / How it works
A bounded path from need to accountable result.
The public model below describes responsibilities and decisions, not sensitive implementation details, provider secrets or customer data.
- 01
Register explicit capabilities
Describe configured endpoints by supported tasks, deployment class, residency, health and bounded operating characteristics rather than by protocol name alone.
- 02
Match policy to capability
Select only endpoints that satisfy the requested task and the authorized privacy, egress and deployment constraints.
- 03
Execute through a normalized contract
Translate the provider-neutral request to an allowed transport while preserving media, deadline and usage semantics.
- 04
Fail without changing the boundary
Report health and normalized errors, and consider fallback only within the same authorized capability and exposure class.
03 / Customer and operator value
Prevents protocol names and automatic fallback from silently changing data exposure, provider class or operating cost.
Explicit endpoint and model allowlists
Privacy-class-preserving fallback
Normalized usage and health
No implicit discovery, download or activation
04 / Where it creates value
Concrete situations, not generic feature claims.
These are representative product situations. Every deployment still requires its own policy, data boundary and acceptance criteria.
Hybrid local and cloud inference
Route appropriate work across embedded, on-premises, private and public capacity without hiding where each request executes.
Enterprise BYOK platform
Let customers provide approved endpoints while the product retains one policy and response contract.
Model and provider migration
Change underlying execution capacity without rewriting the cognitive layer or silently changing data-handling assumptions.
05 / Role in the cognitive system
A clear responsibility creates a trustworthy boundary.
No module is allowed to become an invisible monolith. It owns a narrow contract, composes with named capabilities and refuses responsibilities that belong elsewhere.
What it owns
- Provider transport
- Capability normalization
- Health and usage
- Endpoint metadata
What it composes with
Cognitive EngineEmbedded packsEnterprise endpointsBYOK providers
What it refuses to own
Boundary before convenience.
The gateway never decides intent, retrieval policy or answer acceptance.
06 / Vision and mission
Provider freedom
The gateway keeps models as replaceable capabilities rather than hidden dependencies, directly supporting Mentaview's vision of useful and sovereign AI across changing infrastructure.
AI systems that remain useful, inspectable and sovereign across models, providers and deployment boundaries.
Build the cognitive layer that chooses the smallest sufficient path and turns evidence into accountable action.
Capture the value of advanced AI without surrendering data control, architectural freedom or intellectual honesty.
07 / Evidence and maturity
What the current label means — and what remains open.
ENGINEERING MATURITYM4Mentaview internal laboratory assessment
OBJECTIVE REVIEW
Passed with moderate confidence
Provider-neutral routing, idempotency boundaries and failover/reconciliation controls are composed and locally tested; sustained heterogeneous-provider operation is not proven.
OPEN LIMITS
- No sustained target-host run across heterogeneous live providers.
- Provider-declared idempotency and invoice-external reconciliation are not broadly qualified.
- No production service-level or customer-acceptance evidence.
What exists today
Explicit endpoint configuration, capability normalization, guarded transports, privacy-class-preserving selection, health and usage reporting are implemented for controlled-pilot profiles. A sealed 12-case idempotency qualification passed 12/12 and loopback HTTP tests passed 3/3; the hint remains opt-in and process-local. Real PostgreSQL and HTTP tests also cover normalized non-invoice usage evidence and closed-day reconciliation.
Controlled pilot
A bounded runnable surface exists and can be evaluated in a controlled engagement. Production-scale controls and operating evidence remain gated.
What must earn promotion
Exercise the disabled-by-default authenticated reconciliation control plane on the target shared host, add a connector with provider-declared idempotency, and qualify heterogeneous providers, sustained failover and invoice-external reconciliation under real service objectives.
Public truth boundary: M4− is a non-standard Mentaview engineering label for internal laboratory validation. It is not an official TRL decision and does not assert production qualification, customer acceptance, independent assurance, certification or universal performance. Inspect the complete assessment record.