Intelligence in motion.
Control by design.

Identity and data policy constrain eligible models and destinations before routing. A model request can end at a response without an action. Workload placement and agent actions require separate action authorization before configured tools execute. Available usage evidence returns for attribution. When no eligible route exists, the request stops.

1. Identity. Establish the caller, access rights and requested scope, including the identity of an agent or workload.
2. Policy. Apply the configured identity, data, model and destination policies before routing or proposing an action.
3. Eligible options. The configured registry and deployment requirements identify policy-permitted models and destinations.
4. Routing. Use available capacity and operating constraints to choose among the eligible options.
5. Inference. Send the permitted model request to the selected destination and return its response. This grants no tool-execution authority.
6. Placement plan. Produce a workload placement plan for an eligible destination. The plan is not a deployment.
7. Proposed action. An identified agent proposes an action within the policy context. Model access does not authorize this action.
8. Authorization. Check the specific action authority and configured approval requirements. Denial stops before execution.
9. Configured tools. A configured executor performs the authorized placement or agent action against its permitted target and returns the result.
10. Usage evidence. Attribute available token, GPU and cost evidence from the integrated model, infrastructure or tool sources.
11. No eligible route. If no option satisfies the policy and deployment requirements, no inference, execution or cross-boundary fallback follows.

gFabric can work with an enterprise’s existing models and agents. iFabric, nLLM and iCore are integrations, not prerequisites. The model and agent registry informs eligible options; capacity and operating signals help choose among policy-permitted destinations. Factory, cloud, regional grid and edge are alternatives, not sequential hops. Routing chooses a permitted inference destination or produces a placement plan; a placement plan alone moves no data or workload. Agent identity and scope must be established before any proposed action is authorized. Denied or unsupported actions stop before tool execution. Usage attribution reflects the available integrated sources; it is neither a complete billing guarantee nor a claim of savings. Model compatibility, connector support and data policy govern context sharing. Physical-world actions remain subject to device and operational controls. The boundary view illustrates a stopped request, not a native exception queue. Timing is illustrative; each loop restarts the explanation.

Views

Model request. Identity and policy constrain eligible models and destinations. Routing selects a permitted model endpoint, inference returns a response, and available usage is attributed. The regional grid is the illustrative inference destination. No action or tool execution is part of this view.

Workload placement. Workload identity and requirements constrain the permitted destinations. Routing considers available operating signals and produces a placement plan. Separate authorization precedes configured execution; usage evidence follows. The selected regional grid is an illustrative destination.

Agent action. Agent identity and policy establish scope. The proposed action requires a separate authorization check before a configured tool executes and returns a result. Available usage evidence is attributed. This is the permitted-action path; a denied action never reaches the tool.

Policy boundary. The identity and policy checks leave no eligible model or destination. The request stops without inference, tool execution or a fallback across the policy boundary. This view does not imply a native operator-review queue.