Documentation / QueryTek Tapestry glossary / Routing Engine
A routing engine decides where a request or record goes next, and under what conditions, by evaluating policy rather than following a hardcoded connection. Destinations become configuration instead of code, which is what allows a new participant to be added without rebuilding the path.
Point-to-point integration answers "where does this go" in the code that sends it. That works until there are several possible destinations, the choice depends on organizational context, or the rule changes for one customer and not another. At that point the routing decision is scattered across every sender and nobody can state the current policy.
A routing engine centralizes that decision. It takes a request together with its context — who is acting, which organization, what kind of work — and resolves a destination and the constraints that apply to it.
Rules are data. Adding a partner or changing an escalation path is a configuration change against declared rules, not a code deployment on every calling system.
Decisions are contextual. The same request can route differently for two organizations because the engine evaluates the context travelling with it, rather than inferring intent from the endpoint that was called.
Decisions are observable. Because one component decided, "why did this go there" has an answer. Distributed routing logic cannot produce that answer without reconstructing the state of several systems.
A routing engine is not a load balancer. A load balancer picks among interchangeable replicas to spread traffic; a routing engine picks among meaningfully different destinations because the policy says so. Conflating the two leads to treating a governance decision as an infrastructure detail.
Routing is where governance either exists or does not. If the rule that says "this organization's records never reach that partner" lives in one policy-evaluating component, it can be inspected and tested. If it lives in conditionals spread across senders, it can only be audited by reading all of them and hoping none was missed.
The operational payoff is the cost of change. Onboarding a partner should not require touching every system that might hand work to it.
QueryTek Tapestry routes movement between systems through a governed layer, so adding a partner is a registration rather than a new integration and the policy governing the movement lives in one place. Rule syntax, evaluation internals, and partner-specific routing configuration are handled through onboarding and are not published.
