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.
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™ platform.
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.
One request. Eleven indices. One audit event.
- 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. - 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.
- Mask + filter — Per-row classification-floor and risk-tier-max filters are applied. Filtered rows are counted (not returned) into
filtered_out.by_classification_floorandfiltered_out.by_risk_tier_max. - Merge — Results are returned as
hits[]arrays keyed by index name, plus a top-leveldenied_indicesarray. Cross-index joins follow thelinksfield on each entry — the Directory is denormalised by design; no relational join happens server-side. - 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.
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 · Freekye_engines— all ten core engines + named sub-engines · Public · Freekye_rails— all seven rails · Public · Freekye_surfaces— all eight surfaces (admin marked tenant-only) · Public · Freekye_profiles— the public profiles + registered extensions · Public · Freekye_schemas— every schema across the namespaces · Public · Freekye_vocabulary— controlled dictionaries (actions, lifecycle, purposes, …) · Public · Freekye_registries— Partner / Connector / Widget / Certification / Operating Model registries · Public · Freekye_templates— Operating Model / Behaviour / Decision-rule / Widget / Report / Conformance Pack templates · Public · Freekye_evidence— Evidence Pack™ / Decision Map™ / Replay Proof / Context Seal / Call Ledger headers (bodies stay in the source rail) · Tenant-scoped · Paidkye_audit— every privileged action across the platform · Tenant-scoped · Paid
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 for canonical SKU bindings.
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.