--- title: "KYE™ Federated Directory Query™ — one query, eleven indices, tenant-masked" description: "KYE™ Federated Directory Query™ is the fan-out query that hits all eleven Directory indices in one round-trip and merges results under a deterministic ranking rule with per-tenant masking." url: https://kyeprotocol.com/federated-directory-query/ lang: en source: "KYE Protocol" --- > KYE™ Federated Directory Query™ is the fan-out query that hits all eleven Directory indices in one round-trip and merges results under a deterministic ranking rule with per-tenant masking. KYE™ Federated Directory Query™ # One query. Eleven indices. Tenant-masked. KYE™ Federated Directory Query™ is the canonical fan-out query for the Directory rail. Ask one question and get one answer: which entries, across which of the eleven indices, match what you are looking for under your own permission. You get one round-trip. Masking is applied for you at the edge. Results are merged under a fixed ranking rule. Any index your token cannot reach comes back as denied, never as a bare error. 1 · What it is ## The Directory's cross-index fan-out. The Directory rail maintains eleven logical FTS5 indices — one per artefact class: entity, engines, rails, surfaces, profiles, schemas, vocabulary, registries, templates, evidence-headers, audit. A normal Directory query targets one index by name. A federated query targets _all_ eleven in one round-trip, applies the caller's tenant-token mask per-index, and returns a single merged result envelope keyed by index name. The endpoint is `POST /v1/directory/search` with `indices: ["*"]` in the request body. Every other shape is the same as a single-index query. The deterministic ranking rule is locked in the index descriptors under `internal`; fan-out does not change ranking, it merges per-index hit arrays into one response. Federated query is one rail of the wider [KYE Protocol™](https://kyeprotocol.com/) platform. 2 · What it solves ## Find anything without knowing which index it lives in. When you investigate an incident, you rarely know upfront which index holds the answer. You want every reference to a counterparty, across every artefact class, in one place. You want to see what the platform actually surfaces for your purpose — without guessing which index to ask first. Without a federated query, you have to issue eleven separate requests, stitch the results together yourself, and re-build masking and ranking by hand. The federated query collapses all of that into one signed, audited, masked round-trip. Your tenant boundary is enforced for you on the server, and the audit event records the full index set, the indices you were denied, and how many results were filtered out. 3 · How it works ## One request. Eleven indices. One audit event. 1. **Tenant token check** — The Directory Engine validates the caller's Ed25519-signed scoped tenant token. The token carries the set of indices the caller is permitted to read. Indices outside that set are added to `denied_indices`; the request is never rejected with 403 on this axis. 2. **Per-index fan-out** — The KYE™ Native Search Engine™ (lexical + semantic substrates inside the tenant boundary) issues one query against each admitted index in parallel. Per-index ranking rules from the locked index descriptors apply unchanged. 3. **Mask + filter** — Per-row classification-floor and risk-tier-max filters are applied. Filtered rows are counted (not returned) into `filtered_out.by_classification_floor` and `filtered_out.by_risk_tier_max`. 4. **Merge** — Results are returned as `hits[]` arrays keyed by index name, plus a top-level `denied_indices` array. Cross-index joins follow the `links` field on each entry — the Directory is denormalised by design; no relational join happens server-side. 5. **Audit emission** — A single directory-audit event in the Directory Engine's declared evidence-event family is emitted under the tenant scope, carrying the query string, the admitted indices, the denied indices, the filtered-out counts, the result size per index, and the caller's purpose binding. This is self-governance: every privileged read across the Directory leaves a hash-chained event behind. 4 · The 11 indices (locked) ## Every queryable artefact lives in exactly one of these. No index may be added without a naming amendment and an index-descriptor entry under `internal`. The split between free and paid tiers is locked: nine public indices, two tenant-scoped indices. - `kye_entity` — every entity record (org, person, agent, partner, connector) · Public · Free - `kye_engines` — all ten core engines + named sub-engines · Public · Free - `kye_rails` — all seven rails · Public · Free - `kye_surfaces` — all eight surfaces (admin marked tenant-only) · Public · Free - `kye_profiles` — the public profiles + registered extensions · Public · Free - `kye_schemas` — every schema across the namespaces · Public · Free - `kye_vocabulary` — controlled dictionaries (actions, lifecycle, purposes, …) · Public · Free - `kye_registries` — Partner / Connector / Widget / Certification / Operating Model registries · Public · Free - `kye_templates` — Operating Model / Behaviour / Decision-rule / Widget / Report / [Conformance Pack](https://kyeprotocol.com/compliance/) templates · Public · Free - `kye_evidence` — [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) / Decision Map™ / Replay Proof / Context Seal / Call Ledger headers (bodies stay in the source rail) · **Tenant-scoped · Paid** - `kye_audit` — every privileged action across the platform · **Tenant-scoped · Paid** 5 · Pricing tier ## Free across nine public indices. Paid across all eleven. A federated query whose `indices: ["*"]` resolves to a token-admitted set of the nine public indices is free and anonymous-safe. A federated query whose admitted set includes either `kye_evidence` or `kye_audit` is paid — the tenant token must be minted under an invoice-paid, non-suspended subscription, and the audit emission carries the billing surface binding. The split is enforced at the tenant-token mint step: tokens with `kye_evidence` or `kye_audit` in their `indices` claim only mint under an active paid subscription. The federated endpoint itself does not enforce billing — it enforces the token; the token enforces the subscription. See the [pricing model](https://kyeprotocol.com/pricing/) for canonical SKU bindings. 6 · Related canonical pages ## Where this fits. - [**KYE™ Directory** ™](https://kyeprotocol.com/directory/) — the public search surface that hosts this query as one of its six lenses. - [**Self-Governance**](https://kyeprotocol.com/self-governance/) — the binding that emits the audit event for every federated query. - [**Discoverability Profile**](https://kyeprotocol.com/discoverability/) — the broader profile that includes federated query as the cross-tenant scope mode. ## See it in your tenant. Federated query unlocks once your tenant token admits more than one index. Start in shadow mode and add indices as your audit readiness grows. [Apply for a pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [Purpose Permission](https://kyeprotocol.com/glossary/).