Concepts and Core Specification (MIG-0001)

MIG-0001: MIG v0.1 Core Specification and Binding Profiles

Status: Draft
Last Updated: 2026-02-24
Version: 0.1

1. Abstract

MIG (Model Interface Gateway) is a transport-neutral interface standard for connecting agents, models, and capability providers. MIG standardizes capability discovery, invocation, streaming, events, control, security, and telemetry while allowing multiple transport bindings.

MIG v0.1 defines three binding profiles:

MIG/gRPC
MIG/NATS
MIG/HTTP

2. Motivation

Current integrations tightly couple model-consuming systems to provider-specific servers and protocols. This causes fragmentation, weak portability, and duplicated operational controls.

MIG defines one protocol model with multiple transport bindings so models and agents depend on capability contracts instead of endpoint-specific implementations.

3. Goals

Define a transport-neutral capability protocol.
Support unary invocation, streaming invocation, and asynchronous eventing.
Standardize auth context, tenant context, cancellation, and deadline handling.
Standardize error codes and observability fields across bindings.
Enable staged migration from MCP-style ecosystems via adapters.

4. Non-Goals

Defining model internals or training formats.
Replacing message brokers or RPC frameworks.
Defining billing policy.
Enforcing exactly-once delivery globally.

5. Terminology

Agent: Consumer that discovers and invokes capabilities.
Capability Provider: System exposing callable capability contracts.
Capability: Versioned function-like contract with input/output schema and runtime modes.
Binding: Transport-specific projection of MIG core semantics.
Session: Optional continuity scope for related calls/events.
Tenant: Isolation boundary for auth, policy, and data partitioning.

6. Conformance Language

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

7. Protocol Layers

MIG core is layered:

Capability layer: discovery, schemas, version negotiation.
Invocation layer: unary and streaming execution semantics.
Event layer: publish/subscribe semantics.
State layer: session and context handles.
Telemetry layer: tracing, metrics, and audit signals.

Bindings MUST preserve core layer semantics.

8. Core Operations

The following core operations are REQUIRED in v0.1.

Operation	Purpose
`HELLO`	Version and feature negotiation
`DISCOVER`	Capability listing and metadata retrieval
`INVOKE`	Unary or streaming capability execution
`PUBLISH`	Event publication
`SUBSCRIBE`	Event subscription
`CANCEL`	In-flight invocation/stream cancellation
`HEARTBEAT`	Liveness and keepalive

8.1 Canonical Header and Envelope

All MIG messages MUST include a header equivalent to:

{
  "mig_version": "0.1",
  "message_id": "uuid",
  "timestamp": "RFC3339",
  "tenant_id": "string",
  "session_id": "optional.string",
  "traceparent": "optional.w3c-trace-context",
  "idempotency_key": "optional.string",
  "deadline_ms": 30000,
  "meta": {}
}

payload shape depends on operation type.

Reserved metadata namespace:

meta.vendor.* should be reserved for implementation-specific metadata.
Implementations MAY ignore unknown namespaced keys.
Vendors SHOULD use their own namespaced prefixes to avoid key collisions.

8.2 HELLO

Client sends supported MIG versions, requested binding, and optional feature flags. Server returns selected version and negotiated features.

Requirements:

Server MUST reject unknown major versions.
Server SHOULD support multiple protocol versions where practical.
Server MUST return deterministic selection if multiple versions overlap.

8.3 DISCOVER

Returns capability descriptors visible to caller scopes.

Requirements:

Server MUST filter capabilities by authorization scopes.
Descriptor MUST include capability ID, semantic version, invocation modes, and schema references.
Descriptor SHOULD include QoS limits and delivery semantics.

8.4 INVOKE

Executes capability in unary or stream mode.

Requirements:

Server MUST enforce deadline_ms.
Client SHOULD send idempotency_key for retryable operations.
Server MUST expose whether delivery is at-least-once or exactly-once per capability.
Server MUST support cancellation using CANCEL.

Defines event production and consumption.

Requirements:

Topic names MUST be namespaced.
Subscriptions SHOULD support replay via cursor/offset when backend supports it.
Backpressure signals MUST be available in stream/event channels.

8.6 CANCEL

Requests cancellation for a target message or stream.

Requirements:

Server MUST acknowledge receipt.
If cancellation succeeds, server MUST terminate work promptly and emit final terminal signal.

8.7 HEARTBEAT

Heartbeat exchanges signal liveness and optional capacity hints.

Requirements:

Both peers SHOULD support heartbeat in long-lived sessions.
Missed heartbeat handling SHOULD be configurable.

9. Capability Descriptor

Each capability descriptor MUST include:

id: globally unique capability name.
version: semantic version string.
modes: supported invocation modes (unary, server_stream, client_stream, bidi_stream).
input_schema_uri and output_schema_uri.
auth_scopes.

Optional fields:

event_topics.
qos.max_payload_bytes.
qos.supports_replay.
qos.delivery_semantics (at_least_once, exactly_once, best_effort).

10. Error Model

Errors MUST return:

code: stable MIG code.
message: human-readable description.
retryable: boolean retry hint.
details: machine-readable object.

Standard error codes:

MIG_INVALID_REQUEST
MIG_UNAUTHORIZED
MIG_FORBIDDEN
MIG_NOT_FOUND
MIG_UNSUPPORTED_CAPABILITY
MIG_VERSION_MISMATCH
MIG_TIMEOUT
MIG_RATE_LIMITED
MIG_BACKPRESSURE
MIG_UNAVAILABLE
MIG_INTERNAL

11. Security and Multi-Tenancy

Requirements:

All bindings MUST run over TLS (or equivalent secure transport).
Deployments MUST enforce authentication (JWT bearer, mTLS, or equivalent).
Deployments MUST enforce capability-scoped authorization.
tenant_id MUST be validated against the authenticated principal.
Implementations SHOULD emit auditable authorization decisions.

12. Observability

Requirements:

W3C trace context propagation SHOULD be supported.
Systems MUST expose metrics by capability and error code.
Systems SHOULD expose active stream count and backpressure indicators.
Audit logs MUST capture actor, tenant, capability, outcome, and timestamp.

13. Versioning

Every MIG message MUST carry mig_version.
v0 pre-1.0 compatibility policy: breaking changes increment minor version (0.1 -> 0.2).
HELLO MUST return selected version and negotiated feature list.

14. Binding Profiles

14.1 MIG/gRPC

Required services:

Discovery: Hello, Discover
Invocation: Invoke, StreamInvoke
Events: Publish, Subscribe
Control: Cancel, Heartbeat

Mapping rules:

MIG header fields map to protobuf message fields and MAY also be mirrored in gRPC metadata.
Streaming uses gRPC stream methods.

14.2 MIG/NATS

Subject naming convention:

mig.v0_1.<tenant>.discover
mig.v0_1.<tenant>.invoke.<capability>
mig.v0_1.<tenant>.events.<topic>
mig.v0_1.<tenant>.control.cancel.<message_id>

Mapping rules:

Unary invocation uses request-reply.
Durable subscriptions and replay SHOULD use JetStream.
MIG header fields map to NATS headers.

14.3 MIG/HTTP

Required endpoints:

POST /mig/v0.1/hello
POST /mig/v0.1/discover
POST /mig/v0.1/invoke/{capability}
POST /mig/v0.1/publish/{topic}
GET /mig/v0.1/subscribe/{topic} (SSE)
POST /mig/v0.1/cancel/{message_id}

Recommended endpoint:

GET /mig/v0.1/stream (WebSocket for bidirectional streams)

Mapping rules:

MIG headers may be carried in HTTP headers and/or body header object.
SSE frames SHOULD carry MIG event envelopes.

15. Conformance Profiles

Core: HELLO, DISCOVER, unary INVOKE, standard errors.
Streaming: Core + StreamInvoke + CANCEL.
Evented: Core + PUBLISH/SUBSCRIBE with optional replay.
Full: Streaming + Evented + telemetry requirements.

Implementations MUST declare supported profile.

16. MCP Interop Requirement

Implementations SHOULD provide MCP adapters during migration.

Adapter behavior:

MCP tool discovery -> MIG DISCOVER
MCP tool calls -> MIG INVOKE
MCP event channels -> MIG PUBLISH/SUBSCRIBE
Preserve auth context, tenant context, and trace context across translation

17. Reference Artifacts

This RFC is accompanied by:

Protobuf starter: proto/mig/v0_1/mig.proto
HTTP binding starter: openapi/mig.v0.1.yaml
NATS binding profile: /docs/bindings/nats
MCP interop mapping: /docs/interop/mcp
Conformance checklist: /docs/conformance

18. Open Questions for v0.2

Common schema registry conventions for input_schema_uri and output_schema_uri.
Standardized replay cursor format across bindings.
Negotiated compression and payload chunking policies.
Capability lifecycle events (deprecated, sunset, breaking_change).

Concepts and Core Specification (MIG-0001)

MIG-0001: MIG v0.1 Core Specification and Binding Profiles

1. Abstract

2. Motivation

3. Goals

4. Non-Goals

5. Terminology

6. Conformance Language

7. Protocol Layers

8. Core Operations

8.1 Canonical Header and Envelope

8.2 HELLO

8.3 DISCOVER

8.4 INVOKE

8.5 PUBLISH and SUBSCRIBE

8.6 CANCEL

8.7 HEARTBEAT

9. Capability Descriptor

10. Error Model

11. Security and Multi-Tenancy

12. Observability

13. Versioning

14. Binding Profiles

14.1 MIG/gRPC

14.2 MIG/NATS

14.3 MIG/HTTP

15. Conformance Profiles

16. MCP Interop Requirement

17. Reference Artifacts

18. Open Questions for v0.2