Binding Rule

Binding rules define specific relationships between assets and collections. They are a subset of the relationship types possible, with MCPBindings and AgentBindings being the other possibilities. Collectively, these three types are known as binding edges.

Binding Edges

Binding edges describe how things are related right now in the graph and how broad capabilities (MCPs and agents) are narrowed down into the specific, local context of an asset or collection.

Where assets and collections describe what exists in the environment (equipment, patients, rooms, workcells, projects), binding edges capture:

• The live relationships between those objects (what's in what, what's part of what, who's related to whom).
• The focused slices of MCPs and agents that are relevant to a particular asset or collection.

Conceptually, there are three edge variants:

1. Binding Rule edge – connects assets/collections and references a reusable BindingRuleConfig that controls how context flows across that relationship.
2. MCP edge – connects an asset/collection to a broad MCP, then uses an MCPBinding to narrow that MCP down to "the bit that matters here."
3. Agent edge – connects an asset/collection to a broad agent, then uses an AgentBinding to narrow that agent down to how it behaves for this node.

The assembler walks all three kinds of edges when it assembles intelligence from context for a given role × collection.

What Binding Edges Represent

Binding edges capture the real-world structure of a customer's environment and how capabilities attach to it.

Structural edges (Binding Rule edges)

These are asset/collection → asset edges that express physical or logical relationships, for example:

• collection → asset
  • A sensor "lives in" a line.
  • A piece of equipment is in a specific room or bay.
  • A client is currently associated with a ward or clinic area.
• asset → asset
  • A camera is part of an inspection armature.
  • A pump is part of a larger skidded system.
  • A patient is marked as a parent, sibling, or dependent of another record.

These structural edges are directional (A → B is not automatically B → A) and each carries a reference to a binding rule that describes how context is allowed to flow when the assembler crosses that relationship.

Capability edges (MCP / Agent edges)

These are asset/collection → MCP and asset/collection → agent edges that attach broad definitions to specific things:

• An MCP, by itself, might be able to talk to many sensors or many records.
• An agent, by itself, might be able to orchestrate workflows across many lines, many wards, or many customers.

The edge bindings are what narrow those broad capabilities down to the focused bit that belongs to a specific asset or collection.

• MCP edges use an MCPBinding payload to say:

  "From this asset or collection, this MCP is only about these IDs / paths / modes."

• Agent edges use an AgentBinding payload to say:

  "From this asset or collection, this agent runs in this configuration, against these resources."

You can think of it as:

• Binding Rule edge – "From this context, you're allowed to look through this relationship, using that high-level policy."
• MCP edge – "Here is the local slice of a broader MCP that belongs to this node."
• Agent edge – "Here is the local slice of a broader agent that belongs to this node."

Dynamic Edges from Attach / Move

Structural binding edges (the ones that reference Binding Rules) are dynamic and track how the real world changes:

• RTLS events can trigger attach/move/detach as assets move between zones.
• Business systems (ERP, EHR, CMMS, etc.) can re-parent records, work orders, or dependents.
• Operators can manually attach or move assets in the Bifrost admin tool.

Every attach/modify/move operation:

1. Chooses which two nodes should be connected (source and target).
2. Selects a binding rule to apply to that relationship.
3. Creates or updates the Binding Rule edge to reference that rule.

Because binding rules are reusable, a single rule (for example, Asset-in-Room (Operational Sensors)) can govern many edges as assets move around. Attach/move is where that rule is applied to a specific relationship.

All attach/detach/modify/move operations are logged, so you can always reconstruct:

• When a structural edge existed.
• Which binding rule it used at that time.

Capability edges (MCP/agent edges) are typically created and maintained when you bind tools or agents to assets/collections. They are generally more stable.

Binding Rules as Relationship Models

A binding rule is a relationship model for structural edges. It defines how context is allowed to flow across any edge that references it, with emphasis on:

• Which MCPs and agents are allowed to propagate along that relationship.
• Which masks are applied to those MCPs.
• How many additional hops (depth) the assembler may take after crossing that relationship.
• Default allow/deny behavior for MCPs and Agents not explicitly listed.

So in the common pattern:

• Binding rules shape where you can go and which broad MCPs/agents are even eligible across relationships.
• MCP/agent edges shape what those MCPs/agents specifically mean at each node.

Binding Rule Config Model

Binding Rules are represented by the following configuration object:

BindingRuleConfig {
  binding_rule_id: string
  name?: string
  description?: string
  default_pass_behavior?: boolean
  depth?: number
  mcp_rules?: MCPBinding[]
  agent_rules?: AgentBinding[]
  created_at?: number
  updated_at?: number
  customer_id?: string
}

Identity & metadata

Behavior

Because structural edges reference the rule by binding_rule_id, changes to a binding rule are picked up automatically by every edge that points to it the next time an assembly occurs.

MCPBinding (Narrowing MCPs on MCP Edges)

class MCPBinding(BaseModel):
    mcp_id: str
    mask: str
    parameter_overrides: Optional[Dict[str, List[str]]] = None
    resource_scope_fragments: Optional[List[str]] = None

An MCPBinding is the payload for MCP edges (asset/collection → MCP). It is the mechanism that turns a broad MCP into the local, focused slice that belongs to a given node.

Conceptually:

The MCP is global.
The MCP edge plus its MCPBinding turn it into "the MCP for this asset/collection, with this subset of parameters and scopes."

AgentBinding (Narrowing Agents on Agent Edges)

class AgentBinding(BaseModel):
    agent_id: str
    parameter_overrides: Optional[Dict[str, Any]] = None
    resource_scope_fragments: Optional[List[str]] = None

An AgentBinding is the payload for agent edges (asset/collection → agent). It is the mechanism that turns a broad agent into the local, focused behavior that belongs to a given node.

Conceptually:

The agent is global.
The agent edge plus its AgentBinding turn it into "the agent for this asset/collection, with this configuration and scopes."

Bifrost and Relationships

The Bifrost admin tool is where teams:

• Define and manage binding rules.
• Inspect and reason about which rules are applied to which structural edges.
• View the MCP/agent capabilities attached to specific assets and collections.

In Bifrost:

• A binding rule might be defined in human terms such as:
  • Guardian → Dependent (Healthcare)
  • Asset-in-Room (Operational Sensors Only)
  • Subsystem → System (Maintenance Agent Enabled)

A binding rule detail view typically shows:

• Name and description.
• default_pass_behavior and depth.
• Any MCP/Agent templates associated with the rule (if used).
• Audit metadata (binding_rule_id, created/updated timestamps).

On an individual asset or collection, Bifrost can surface:

• Structural edges – what nodes are targets for this node's edges and which binding rules govern those relationships.
• MCP edges – which MCPs are attached locally, and how they're narrowed via mask, parameter_overrides, and resource_scope_fragments.
• Agent edges – which agents are attached locally, and how they're narrowed via configuration and scopes.

Binding Edges in Assembly

During assembly, the engine walks all three kinds of edges:

1. Starting from a role × collection, the assembler:
   • Follows structural edges (Binding Rule edges) outward, respecting depth and directionality.
   • Encounters MCP and agent edges off of those nodes.
2. At each Binding Rule edge, it:
   • Looks up the BindingRuleConfig.
   • Decides which MCPs and Agents are even eligible to propagate across that relationship.
   • Uses default_pass_behavior and depth to decide how far to continue. The lower of depth and global remaining search depth is used.
3. At each MCP edge, it:
   • Uses the MCPBinding to turn the global MCP into the local slice for that node.
   • Applies mask and parameter_overrides.
   • Adds any resource_scope_fragments to the assembled OAuth scope.
4. At each Agent edge, it:
   • Uses the AgentBinding to turn the global agent into the local slice for that node.
   • Applies configuration via parameter_overrides.
   • Adds any resource_scope_fragments for that agent.
5. Assets and Collections union what they receive; Binding Rules and edge bindings act as filters and lenses as context flows upward.

The result is a mim_assembly that precisely reflects:

• Which structural relationships were traversed.
• Which Binding Rules were applied where.
• Which MCPs and Agents are available from this point of view.
• How those MCPs and Agents were narrowed to specific IDs, configurations, and OAuth scopes by the edges that attach them.

That's how binding edges, across their three variants, turn broad, global capabilities into local, governed, explainable intelligence tied to real-world assets and collections.

Bridge API Endpoints