DOCSEARCHbyAlgolia
Submit Docs

MEF.DEV Open API Enablement & Monetization Platform

website·Indexed 32 days ago

https://platform.mef.dev

An open API enablement and monetization platform for building, deploying, and managing enterprise applications. The platform features an Agent Fabric with a trusted layer, knowledge graph grounding, and BPMN mapping for process governance. It provides developer guides for creating UI packages with Angular, backend packages using C# and .NET, and AI layer plugins, alongside documentation on platform architecture and the Business Source License 1.1.

Tokens
21.9K
Snippets
42
Records
140
Agent score
49%

What's inside MEF.DEV

  1. Overview of the Agent Fabric architecture

    The Agent Fabric is a framework designed to register, discover, and connect multi-vendor AI agents within telecom networks. It replaces bespoke point-to-point integrations with shared protocols, ensuring operators maintain control over agents they did not develop. The architecture is built on three pillars:

    1. Fabric-T (Discovery & Registry): Manages the agent lifecycle, including registries for agents, skills, tools, resources, prompts, and models. It uses a knowledge graph to ground requests in typed entities and handles the discovery of agents across vendors and domains.
    2. BPMN Process Governance: Converts an operator's BPMN (Business Process Model and Notation) into a canonical process contract (Process Path Graph and Structured Prompt templates) that every agent must follow.
    3. The Trusted Layer: Provides runtime enforcement by authorizing and auditing every cross-vendor dispatch based on the design-time BPMN contract.

    Together, these pillars answer three critical operational questions: Who can act (Fabric-T), what is allowed (BPMN), and prove it (Trusted Layer).

  2. Overview of MEF.DEV Platform

    MEF.DEV is an Open API Enablement & Monetization Platform designed for building, deploying, and managing enterprise applications. It is built on open TM Forum standards (Open API, SID, eTOM) and utilizes a loosely coupled component model where every function is a separate versioned service. The platform manages the full lifecycle of API products from ideation to monetization.

  3. Understand delivery unit terminology

    The platform uses different terms for the same delivery unit depending on the context of its lifecycle:

    • Plugin: The running form of an active version, as seen in the console menu.
    • Service: The registered entity with a lifecycle, used during registration.
    • Product/Package: The published offer in the Store catalog.

    These are related by a specific progression: a Service record (registered entity) has Versions (uploaded build artifacts), which are deployed as Plugins (running instances), and are published as Store products (typically a namespace bundle).

  4. Identify MEF.DEV implementation compatibility and specifications

    The Trusted Gateway and the Agent Fabric-T Telco Runtime are independent implementations developed by the Licensor. They are compatible with the following open specifications and community resources, which remain subject to their own respective licenses:

    • A2A Protocol and its telecom profile A2A-T (TM Forum IG1453)
    • Agent Gateway Protocol (AGP)
    • OpenAN project (openan.dev)
    • a2aregistry.org registry

  5. Accelerate SDLC using MEF.DEV delivery mechanisms

    MEF.DEV accelerates the entire delivery lifecycle by formalizing requirements into executable forms and enabling independent parallel teams. Key organizational and technical gains include:

    • BPMN-based requirements elicitation and Domain-Driven Design (up to 50% gain).
    • Parallel team development and testing (up to 33% gain).
    • Operations (up to 20% gain).

    Acceleration is achieved by allowing specialized teams to deliver loosely coupled, versioned services with their own contracts. The platform assembles the final product from this declared composition, using auto-generated specifications for real-time synchronization between teams instead of manual meetings.

  7. Understand the role of the Knowledge Graph in grounding AI agents

    The knowledge graph provides a structural index over enterprise knowledge, grounding free-form intent in typed entities and relations. Unlike flat text search (which relies on phrase similarity), the knowledge graph answers structural questions such as 'how is this connected', 'where does this fact come from', and 'where is it done'. It stores the identity of things, typed relations, and pointers to document bodies, but does not store the text itself.

  8. Understand Namespace Bundles for Product Publication

    A namespace bundle allows a provider to group multiple services (such as an API, a UI, and background workers) into a single product with a shared lifecycle. This ensures that a consumer can subscribe once and receive the entire set of services.

    It is important to distinguish between two concepts:

    1. namespace: The logical name scope (Alias) that defines the address segment for APIs, the card group in Applications, and the credentials scope.
    2. NAMESPACE: A specific service type used as the unit of publication. The bundle is registered as its own entity with its own configuration tabs and is not described by the manifests of the individual plugins it contains.

  9. Manage logical grouping with Namespaces

    A namespace (defined in the 'Alias' field during registration) is a logical group of plugins for one domain. It serves four simultaneous roles:

    1. API Addressing: Acts as the address segment for all APIs in the group.
    2. UI Organization: Groups cards within Applications.
    3. Security: Defines the scope for credentials and tokens.
    4. Publication: The unit of publication for the Store (as a product).

    Note: Distinguish between the namespace (the logical name scope) and the NAMESPACE service type (the mechanism used to publish that scope as a product).

  10. Understand the Process Path Graph for agent transitions

    The Process Path Graph is a canonical, agent-neutral map of a process compiled from BPMN. It defines the allowed transitions between agents, where nodes represent activities, gateways, and events, and edges represent allowed moves. Each edge has a stable identifier (edgeId) used across design-time, dispatch, and audit trails. The graph enforces the invariant that the BPMN lane equals the agent ID, allowing the Trusted Layer to verify that any given call matches a permitted transition.

  11. Understand the Trusted Layer architecture

    The Trusted Layer is the runtime trust spine of the Agent Fabric. It ensures that every cross-vendor agent-to-agent (A2A) action is authorized at the moment it occurs and is fully reconstructable for auditing. It implements a zero-trust model where agents do not trust each other directly; instead, they trust platform-attested evidence. Authorization and context claims are issued by the platform, preventing compromised or misconfigured agents from granting themselves unauthorized rights.

  12. Implement Connectivity as a Service (NaaS) orchestration

    To provide connectivity based on characteristics (latency, cost, resilience) rather than specific technology (fiber, 5G, LEO), use the following architecture:

    • Product Layer: A single NaaS contract per TMF Open API with Store-based subscription and billing.
    • Service Layer: Decomposes service orders against the service catalog into domain tasks.
    • Agent Layer: Agents evaluate access options in parallel using the knowledge graph, authorized by the trust layer, with telemetry closing the loop for lifetime re-optimization.