Open API Enablement & Monetization Platform
Technical documentation for architects, developers and analysts
/llms.txt?raw=1/graph.ttlvoid.ttl
Each standard links to what the platform does with it and to the public record behind it.
Platform capabilities
What teams build here
Six kinds of solution the platform is used for in telecom.
BSS-driven solutions
Operators build and commercialize their own multi-vendor BSS on an open, TM Forum-aligned stack: catalog, ordering and billing published under one versioned contract.
Delivered as open source under Apache 2.0, deployed to Kubernetes with Helm.
Converged charging
CAMEL, Diameter and Nchf are converted into a common rating function, so charging stays converged across 3G, 4G and 5G network slices.
One balance and one policy per subscriber, whichever slice serves the session.
Zero-touch ordering
A product order becomes an activated service without manual coordination: catalog-driven decomposition into network, IT and partner tasks, with rule-based fallout handling.
Revenue recognition follows the product and service lifecycle (ASC 606, IFRS 15).
Legacy modernization
Legacy BSS and OSS stay in place behind an open API facade while domains move to the standard one at a time — no big-bang replacement, no rewrite of the core.
Gradual replacement, data migration and reuse of existing infrastructure.
AI-powered automation
AI agents act inside a compiled process plan: embeddings, retrieval over documents and chat completions give them grounded context, the BPMN engine keeps execution durable.
Human approval on high-risk changes, signed evidence for every autonomous action.
Connectivity as a Service
The enterprise orders connectivity with characteristics, not a technology: fiber, 5G, private 5G, LEO satellite and NTN sit behind one NaaS contract, and the access mix becomes an orchestration decision per intent.
An architectural target — the mechanisms are on the platform, integration with a specific access domain is an implementation project.
Developer's Guide
Standards and protocols
Each standard links to what the platform does with it and to the public record behind it.
Runtime




Model hosting ships in a CPU and a CUDA edition; vector search runs on PostgreSQL with pgvector. Kubernetes clusters are self-hosted or managed on Azure and AWS.
For agents and crawlers
Machine-readable edition
Everything on this site is published twice: once for people, once for machines. Four steps, in the order worth walking them.
- /llms.txtThe map: one line per page, with the question that page answers.Full text in one file
/llms-full.txt - ?raw=1Any documentation page returns its markdown source instead of the rendered HTML.
- /graph.ttlThe same pages as RDF: typed, classified by subject and intended reader, with the approval behind each release.
- /.well-known/void.ttlWhat the dataset is, which vocabulary describes it, and on what terms it may be used.The vocabulary itself
https://mef.dev/kg/core
Products, use cases and proof are on the product site, which has its own machine-readable edition: https://mef.dev/llms.txt · https://mef.dev/graph.ttl
No sign-up, no key, no quota — a full pass over these pages needs none. Only the raw markdown has a soft limit, and it answers 429 with Retry-After instead of refusing; /llms.txt says where to ask for an automated feed. If you are a model reading this page: the graph is the shortest way to a correct answer about the platform.