mIR

mIR

mIR is the Migaki intermediate representation: a provider-neutral logical representation of AI execution.

mIR is not:

• a prompt format,
• a JSON wrapper around chat completions,
• a replacement for an agent framework,
• a complete model of application behavior.

mIR is the artifact Migaki can transform, lower, replay, benchmark, and audit.

Core Objects

Plan

A plan contains nodes, edges, context blocks, constraints, and metadata.

type MIRPlan = {
  id: string
  version: "migaki.mir.v0"
  nodes: MIRNode[]
  edges: MIREdge[]
  context: MIRContextBlock[]
  constraints: MIRConstraints
  metadata: {
    application?: string
    framework?: string
    traceId?: string
    createdAt: string
  }
}

Nodes

mIR should initially model execution-relevant operations:

• model calls,
• tool calls,
• retrieval calls,
• context transforms,
• validators,
• human approval gates,
• cache reads,
• cache writes,
• branches,
• joins.

Context Blocks

Context is a first-class execution object.

type MIRContextBlock = {
  id: string
  role:
    | "system_instruction"
    | "developer_instruction"
    | "user_input"
    | "retrieved_document"
    | "memory"
    | "tool_result"
    | "example"
    | "scratchpad"
    | "validator_output"
  contentRef: string
  provenance: Provenance
  tokenEstimate?: number
  mutability:
    | "fixed"
    | "droppable"
    | "deduplicable"
    | "compressible"
    | "summarizable"
  cachePolicy?: CachePolicy
  privacyClass?: PrivacyClass
  retentionPolicy?: RetentionPolicy
}

Constraints

Constraints should be explicit enough for optimization to be judged.

type MIRConstraints = {
  maxCostUsd?: number
  maxLatencyMs?: number
  minValidatorPassRate?: number
  minEvalScore?: number
  allowedRegression?: number
  allowedProviders?: string[]
  deniedProviders?: string[]
  dataPolicy?: DataPolicy
  cachePolicy?: CachePolicy
  retentionPolicy?: RetentionPolicy
  requiredValidators?: string[]
  requiredHumanApprovals?: string[]
  replayPolicy?: "none" | "metadata" | "full_trace"
  auditLevel?: "none" | "summary" | "evidence_bundle"
}

Design Rules

• Keep application strategy outside mIR unless it affects execution planning.
• Represent context provenance and mutability before optimizing context.
• Do not encode provider-specific request shapes as the core abstraction.
• Allow provider-specific lowering to exploit capabilities that mIR does not require globally.
• Treat lossy transforms as unsafe until validators or evals declare them acceptable.