The model should not see an unsafe option
Asking a model to avoid a tool is not the same as making the tool unavailable. A governed system should reject capabilities that exceed the task’s permissions, data boundary, budget, or platform constraints before planning begins.
The model then plans inside a smaller, relevant set. This improves reliability and makes the reason for the final plan inspectable.
The routing pipeline is a product feature
LibreTask uses a sequence of enrichment, retrieval, ranking, restriction, planning, and confirmation. The user-facing benefit is not technical novelty. It is a plan that can explain why a local parser was allowed, why a web search required confirmation, and why an external email remained blocked.
Policy must reach the call
A capability card defines inputs and outputs, but it must also define side effects, allowed destinations, cost, and health. These properties need to travel with the call, not live in a policy document disconnected from execution.
That is how governance becomes enforceable: the allowed boundary is present at the moment the action is selected and invoked.
Control should feel calm
A good governance interface does not overwhelm the user with raw policy. It surfaces the decisions that matter: this action is allowed, this one needs confirmation, this one is blocked, and here is why.