{
  "version": 1,
  "generatedAt": "2026-09-30T18:40:55.603Z",
  "sources": [
    {
      "id": "foundry-html",
      "path": "deploy/cloudflare-foundry/dist/index.html",
      "sha256": "10684fcc103145488aae8168d8913d56b1c2ecd93fb48686e71f1065941c2d92"
    },
    {
      "id": "road-to-1b",
      "path": "ROAD_TO_1B.md",
      "sha256": "a2b00ea374b64085c9b5cf16c63f3ed38dca99f1999b296c0fa1847ea25e2447"
    },
    {
      "id": "micro-kpis",
      "path": "docs/scale/200-micro-kpis.md",
      "sha256": "57c673c5555debacfdc646b052a76a45f3fdecf1202b4e6fa67ffa5527e6803b"
    },
    {
      "id": "database-2050-conventions",
      "path": "docs/scale/database-2050-conventions.md",
      "sha256": "7559379d9254df3d8b53190a1456935f8fef53930d5d17f15921a3462632680e"
    },
    {
      "id": "database-performance-terms",
      "path": "docs/scale/database-performance-terms.md",
      "sha256": "c5db29a965d04197af76989fae50a0d2a4bcc964c5e505c2fc84ced0453d430a"
    },
    {
      "id": "retrieval-standard-profiles",
      "path": "docs/scale/retrieval-standard-profiles.md",
      "sha256": "2d57f05d469494ed4eace2d5acde9134ba2a80d35d24d1f268621c7bee05b51e"
    },
    {
      "id": "latest-benchmark-evidence",
      "path": "benchmarks/evidence/latest.json",
      "sha256": "0a0031946ace56bf65b703afd264c70db24f952d4cd3fecebc73b75bebbe01b8"
    },
    {
      "id": "benchmark-foundry-map",
      "path": "benchmarks/foundry-map.json",
      "sha256": "23eb4b88a7d927da24d38af8461a197858f4181a30cffb636ee94e2430597802"
    },
    {
      "id": "database-developer-terminology",
      "path": "docs/standards/kdt-registry.mjs",
      "sha256": "a42daa65eedc03d3b4f2603f560769f7995be16e9c962b130c1383603e8c4e4e"
    },
    {
      "id": "kyrx-source-snapshot",
      "path": "deploy/cloudflare-foundry/kyrx/snapshot.json",
      "sha256": "67323d2625af74146e5123b17a9dc8cc42e181ad70f8d26a0b4fe746155dfc92"
    },
    {
      "id": "data-access-integrations",
      "path": "integrations/data-access/catalog.mjs",
      "sha256": "cf43819b221cf1175ea3f320ac537a401e2cc3d778138c950f4517b9a44ecc05"
    },
    {
      "id": "foundry-operating-terminology",
      "path": "docs/scale/foundry-operating-terminology.md",
      "sha256": "9d0cf2331ee4e18886f6411d7cb13e0bf3635bed9fddf2346d62c1e02986852b"
    }
  ],
  "chunkCount": 963,
  "chunks": [
    {
      "id": "foundry-pillar-01-rankweave",
      "kind": "foundry-component",
      "title": "RankWeave",
      "text": "Sovereign low-rank delta into frozen weights. Grounded in LoRA. Pillar: Adaptation & PEFT. Search terms: rankweave framework lora sovereign low-rank delta into frozen weights rank: 4–64, trainable: ~0.1–1%, latency: +0ms merged",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adaptation-&-peft",
        "rankweave",
        "framework",
        "lora",
        "sovereign",
        "low-rank",
        "delta",
        "frozen",
        "weights",
        "rank",
        "64"
      ],
      "kpis": [],
      "anchor": "pillar-01"
    },
    {
      "id": "foundry-pillar-01-nibblegraft",
      "kind": "foundry-component",
      "title": "NibbleGraft",
      "text": "Trainable adapters on 4-bit frozen base. Grounded in QLoRA. Pillar: Adaptation & PEFT. Search terms: nibblegraft framework qlora trainable adapters on 4-bit frozen base bits: 4 nf-style, vram: -65% vs bf16",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adaptation-&-peft",
        "nibblegraft",
        "framework",
        "qlora",
        "trainable",
        "adapters",
        "4-bit",
        "frozen",
        "base",
        "bits",
        "nf-style"
      ],
      "kpis": [],
      "anchor": "pillar-01"
    },
    {
      "id": "foundry-pillar-01-tempergraft",
      "kind": "foundry-component",
      "title": "TemperGraft",
      "text": "Quantization-aware grafts + rotated sub-4-bit base + fused kernels. Grounded in QLoRA successor. Pillar: Adaptation & PEFT. Search terms: tempergraft architecture qlora successor quantization-aware grafts + rotated sub-4-bit base + fused kernels ~2–3× throughput, ~70–80% less vram, +8–10pp recovery",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adaptation-&-peft",
        "tempergraft",
        "architecture",
        "qlora",
        "successor",
        "quantization-aware",
        "grafts",
        "rotated",
        "sub-4",
        "bit",
        "base"
      ],
      "kpis": [],
      "anchor": "pillar-01"
    },
    {
      "id": "foundry-pillar-01-magnitudeforge",
      "kind": "foundry-component",
      "title": "MagnitudeForge",
      "text": "Decompose weight into magnitude+direction — full-FT parity. Grounded in DoRA. Pillar: Adaptation & PEFT. Search terms: magnitudeforge architecture dora decompose weight into magnitude+direction — full-ft parity decomp: mag+dir, rank: 4–32, accuracy: ~full-ft parity",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adaptation-&-peft",
        "magnitudeforge",
        "architecture",
        "dora",
        "decompose",
        "weight",
        "magnitude",
        "direction",
        "full-ft",
        "parity",
        "decomp"
      ],
      "kpis": [],
      "anchor": "pillar-01"
    },
    {
      "id": "foundry-pillar-01-prefixlattice",
      "kind": "foundry-component",
      "title": "PrefixLattice",
      "text": "Virtual tokens prepended to every attention layer. Grounded in Prefix-tuning. Pillar: Adaptation & PEFT. Search terms: prefixlattice architecture prefix-tuning virtual tokens prepended to every attention layer weights: 0 edited, params: ~0.1–3%, scope: all layers",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adaptation-&-peft",
        "prefixlattice",
        "architecture",
        "prefix-tuning",
        "virtual",
        "tokens",
        "prepended",
        "every",
        "attention",
        "layer",
        "weights"
      ],
      "kpis": [],
      "anchor": "pillar-01"
    },
    {
      "id": "foundry-pillar-01-graftfold",
      "kind": "foundry-component",
      "title": "GraftFold",
      "text": "Math of folding trained adapters back into base + weighted merge. Grounded in Adapter merging. Pillar: Adaptation & PEFT. Search terms: graftfold terminology adapter merging math of folding trained adapters back into base + weighted merge overhead: +0ms post-fold, merge: n adapters→1, conflict: sign-aware",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adaptation-&-peft",
        "graftfold",
        "terminology",
        "adapter",
        "merging",
        "math",
        "folding",
        "trained",
        "adapters",
        "back",
        "base"
      ],
      "kpis": [],
      "anchor": "pillar-01"
    },
    {
      "id": "foundry-pillar-02-nanocrush-nf4",
      "kind": "foundry-component",
      "title": "Nanocrush NF4",
      "text": "Information-theoretic 4-bit weight casting. Grounded in NF4. Pillar: Quantization & Compression. Search terms: nanocrush nf4 framework nf4 information-theoretic 4-bit weight casting bits: 4 nf-style, block: 64, levels: 16",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "quantization-&-compression",
        "nanocrush",
        "nf4",
        "framework",
        "information-theoretic",
        "4-bit",
        "weight",
        "casting",
        "bits",
        "nf-style"
      ],
      "kpis": [],
      "anchor": "pillar-02"
    },
    {
      "id": "foundry-pillar-02-densecore-recompress",
      "kind": "foundry-component",
      "title": "Densecore Recompress",
      "text": "Quantize the quantization metadata. Grounded in Double quantization (QLoRA). Pillar: Quantization & Compression. Search terms: densecore recompress terminology double quantization (qlora) quantize the quantization metadata overhead: 0.5→0.127 b/param, meta-block: 256",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "quantization-&-compression",
        "densecore",
        "recompress",
        "terminology",
        "double",
        "quantization",
        "qlora",
        "quantize",
        "metadata",
        "overhead"
      ],
      "kpis": [],
      "anchor": "pillar-02"
    },
    {
      "id": "foundry-pillar-02-errorforge-calibrate",
      "kind": "foundry-component",
      "title": "Errorforge Calibrate",
      "text": "Post-training low-bit quant with neighbor error compensation. Grounded in GPTQ. Pillar: Quantization & Compression. Search terms: errorforge calibrate framework gptq post-training low-bit quant with neighbor error compensation bits: 3–4, method: ptq, calib: ~128–512 samples",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "quantization-&-compression",
        "errorforge",
        "calibrate",
        "framework",
        "gptq",
        "post-training",
        "low-bit",
        "quant",
        "neighbor",
        "error",
        "compensation"
      ],
      "kpis": [],
      "anchor": "pillar-02"
    },
    {
      "id": "foundry-pillar-02-latticeprune-sparsefold",
      "kind": "foundry-component",
      "title": "Latticeprune Sparsefold",
      "text": "Hardware-aligned 2:4 structured sparsity, physically halves matrix. Grounded in Semi-structured 2:4 sparsity. Pillar: Quantization & Compression. Search terms: latticeprune sparsefold architecture semi-structured 2:4 sparsity hardware-aligned 2:4 structured sparsity, physically halves matrix pattern: 2:4, speedup: ~2×, index: 2 b/group",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "quantization-&-compression",
        "latticeprune",
        "sparsefold",
        "architecture",
        "semi-structured",
        "sparsity",
        "hardware-aligned",
        "structured",
        "physically",
        "halves"
      ],
      "kpis": [],
      "anchor": "pillar-02"
    },
    {
      "id": "foundry-pillar-02-cachecrush-streamline",
      "kind": "foundry-component",
      "title": "Cachecrush Streamline",
      "text": "Per-channel low-bit KV-cache quant for long context. Grounded in KV-cache quantization. Pillar: Quantization & Compression. Search terms: cachecrush streamline architecture kv-cache quantization per-channel low-bit kv-cache quant for long context kv bits: 4–8, key: per-channel, value: per-token",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "quantization-&-compression",
        "cachecrush",
        "streamline",
        "architecture",
        "kv-cache",
        "quantization",
        "per-channel",
        "low-bit",
        "quant",
        "long"
      ],
      "kpis": [],
      "anchor": "pillar-02"
    },
    {
      "id": "foundry-pillar-03-glyphsieve",
      "kind": "foundry-component",
      "title": "Glyphsieve",
      "text": "Near-duplicate culling at corpus scale via fingerprint-band collision. Grounded in MinHash + LSH dedup. Pillar: Corpus & Data Engineering. Search terms: glyphsieve framework minhash + lsh dedup near-duplicate culling at corpus scale via fingerprint-band collision jaccard: ~0.8, sig: 128–256 perms, redundancy: -40%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "corpus-&-data-engineering",
        "glyphsieve",
        "framework",
        "minhash",
        "lsh",
        "dedup",
        "near-duplicate",
        "culling",
        "corpus",
        "scale",
        "via"
      ],
      "kpis": [],
      "anchor": "pillar-03"
    },
    {
      "id": "foundry-pillar-03-corpusmith",
      "kind": "foundry-component",
      "title": "Corpusmith",
      "text": "Self-instruct synthetic data from seed human exemplars. Grounded in Self-instruct synthetic data. Pillar: Corpus & Data Engineering. Search terms: corpusmith framework self-instruct synthetic data self-instruct synthetic data from seed human exemplars seed: ~175 tasks, yield: 50k–500k pairs, dedup: rouge-l < 0.7",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "corpus-&-data-engineering",
        "corpusmith",
        "framework",
        "self-instruct",
        "synthetic",
        "data",
        "seed",
        "human"
      ],
      "kpis": [],
      "anchor": "pillar-03"
    },
    {
      "id": "foundry-pillar-03-latticescript",
      "kind": "foundry-component",
      "title": "Latticescript",
      "text": "Byte-level merge lattice that learns vocabulary from corpus. Grounded in BPE tokenizer. Pillar: Corpus & Data Engineering. Search terms: latticescript architecture bpe tokenizer byte-level merge lattice that learns vocabulary from corpus vocab: 32k–128k, base: 256 bytes, oov: 0%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "corpus-&-data-engineering",
        "latticescript",
        "architecture",
        "bpe",
        "tokenizer",
        "byte-level",
        "merge",
        "lattice",
        "that",
        "learns",
        "vocabulary"
      ],
      "kpis": [],
      "anchor": "pillar-03"
    },
    {
      "id": "foundry-pillar-03-strataweave",
      "kind": "foundry-component",
      "title": "Strataweave",
      "text": "Per-source sampling weights governing what the model sees. Grounded in Domain reweighting / DoReMi. Pillar: Corpus & Data Engineering. Search terms: strataweave terminology domain reweighting / doremi per-source sampling weights governing what the model sees domains: 5–20, temp: 0.3–1.0, upsample: ≤4×",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "corpus-&-data-engineering",
        "strataweave",
        "terminology",
        "domain",
        "reweighting",
        "doremi",
        "per-source",
        "sampling",
        "weights",
        "governing",
        "what"
      ],
      "kpis": [],
      "anchor": "pillar-03"
    },
    {
      "id": "foundry-pillar-03-curriculord",
      "kind": "foundry-component",
      "title": "Curriculord",
      "text": "Difficulty-ordered data scheduling easy→hard. Grounded in Curriculum learning. Pillar: Corpus & Data Engineering. Search terms: curriculord framework curriculum learning difficulty-ordered data scheduling easy→hard buckets: 4–10, pacing: linear/root, replay: ≥20%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "corpus-&-data-engineering",
        "curriculord",
        "framework",
        "curriculum",
        "learning",
        "difficulty-ordered",
        "data",
        "scheduling",
        "easy",
        "hard",
        "buckets"
      ],
      "kpis": [],
      "anchor": "pillar-03"
    },
    {
      "id": "foundry-pillar-04-creedforge",
      "kind": "foundry-component",
      "title": "CreedForge",
      "text": "Self-critique loops against written charter, no human raters. Grounded in Constitutional AI / RLAIF. Pillar: Alignment & Preference. Search terms: creedforge framework constitutional ai / rlaif self-critique loops against written charter, no human raters human labels: ~0, phases: 2 (sl+rl), judge: model-as-rater",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "alignment-&-preference",
        "creedforge",
        "framework",
        "constitutional",
        "ai",
        "rlaif",
        "self-critique",
        "loops",
        "against",
        "written",
        "charter"
      ],
      "kpis": [],
      "anchor": "pillar-04"
    },
    {
      "id": "foundry-pillar-04-concordance-lattice",
      "kind": "foundry-component",
      "title": "Concordance Lattice",
      "text": "Frozen scalar critic scoring human-ranked pairs. Grounded in RLHF reward modeling. Pillar: Alignment & Preference. Search terms: concordance lattice architecture rlhf reward modeling frozen scalar critic scoring human-ranked pairs head: 1 scalar, loss: bradley-terry, init: sft backbone",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "alignment-&-preference",
        "concordance",
        "lattice",
        "architecture",
        "rlhf",
        "reward",
        "modeling",
        "frozen",
        "scalar",
        "critic",
        "scoring"
      ],
      "kpis": [],
      "anchor": "pillar-04"
    },
    {
      "id": "foundry-pillar-04-preferloom",
      "kind": "foundry-component",
      "title": "PreferLoom",
      "text": "Skip the reward model — optimize policy from preference pairs. Grounded in DPO. Pillar: Alignment & Preference. Search terms: preferloom framework dpo skip the reward model — optimize policy from preference pairs reward model: none, loss: implicit-reward, beta: 0.1–0.5",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "alignment-&-preference",
        "preferloom",
        "framework",
        "dpo",
        "skip",
        "reward",
        "model",
        "optimize",
        "policy",
        "preference",
        "pairs"
      ],
      "kpis": [],
      "anchor": "pillar-04"
    },
    {
      "id": "foundry-pillar-04-verdance-margin",
      "kind": "foundry-component",
      "title": "Verdance Margin",
      "text": "Signed preference gap between winning/losing response. Grounded in DPO implicit reward margin. Pillar: Alignment & Preference. Search terms: verdance margin terminology dpo implicit reward margin signed preference gap between winning/losing response sign: >0=correct, target acc: >0.7, unit: log-odds",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "alignment-&-preference",
        "verdance",
        "margin",
        "terminology",
        "dpo",
        "implicit",
        "reward",
        "signed",
        "preference",
        "gap"
      ],
      "kpis": [],
      "anchor": "pillar-04"
    },
    {
      "id": "foundry-pillar-04-assayloom-cull",
      "kind": "foundry-component",
      "title": "Assayloom Cull",
      "text": "Sample N, keep best by reward, fine-tune on survivors. Grounded in Rejection sampling fine-tuning. Pillar: Alignment & Preference. Search terms: assayloom cull framework rejection sampling fine-tuning sample n, keep best by reward, fine-tune on survivors n: 4–64, keep: top-1/top-k, loss: cross-entropy",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "alignment-&-preference",
        "assayloom",
        "cull",
        "framework",
        "rejection",
        "sampling",
        "fine-tuning",
        "sample",
        "keep",
        "best",
        "reward"
      ],
      "kpis": [],
      "anchor": "pillar-04"
    },
    {
      "id": "foundry-pillar-05-distilflux",
      "kind": "foundry-component",
      "title": "Distilflux",
      "text": "Teacher's full belief via soft-label flux. Grounded in Response distillation / KD. Pillar: Distillation & Merging. Search terms: distilflux framework response distillation / kd teacher's full belief via soft-label flux temp: 2–8, params: -40 to -90%, loss: kl+ce",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "distillation-&-merging",
        "distilflux",
        "framework",
        "response",
        "distillation",
        "kd",
        "teacher",
        "x27",
        "full",
        "belief",
        "via"
      ],
      "kpis": [],
      "anchor": "pillar-05"
    },
    {
      "id": "foundry-pillar-05-tracegraft",
      "kind": "foundry-component",
      "title": "Tracegraft",
      "text": "Match teacher's hidden geometry, not just words. Grounded in Feature distillation. Pillar: Distillation & Merging. Search terms: tracegraft terminology feature distillation match teacher's hidden geometry, not just words loss: mse/cosine, targets: hidden+attn, proj: learned linear",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "distillation-&-merging",
        "tracegraft",
        "terminology",
        "feature",
        "distillation",
        "match",
        "teacher",
        "x27",
        "hidden",
        "geometry",
        "not"
      ],
      "kpis": [],
      "anchor": "pillar-05"
    },
    {
      "id": "foundry-pillar-05-mergespire",
      "kind": "foundry-component",
      "title": "Mergespire",
      "text": "Fuse many fine-tunes by reconciling task vectors. Grounded in TIES merging / task vectors. Pillar: Distillation & Merging. Search terms: mergespire architecture ties merging / task vectors fuse many fine-tunes by reconciling task vectors retrain: none, density: ~10–30%, inputs: 2–n tunes",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "distillation-&-merging",
        "mergespire",
        "architecture",
        "ties",
        "merging",
        "task",
        "vectors",
        "fuse",
        "many",
        "fine-tunes",
        "reconciling"
      ],
      "kpis": [],
      "anchor": "pillar-05"
    },
    {
      "id": "foundry-pillar-05-fluxbroth",
      "kind": "foundry-component",
      "title": "Fluxbroth",
      "text": "Average many checkpoints into one stronger model. Grounded in Model souping. Pillar: Distillation & Merging. Search terms: fluxbroth framework model souping average many checkpoints into one stronger model cost: 1× inference, inputs: 3–n runs, init: shared",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "distillation-&-merging",
        "fluxbroth",
        "framework",
        "model",
        "souping",
        "average",
        "many",
        "checkpoints",
        "one",
        "stronger"
      ],
      "kpis": [],
      "anchor": "pillar-05"
    },
    {
      "id": "foundry-pillar-05-spireforge",
      "kind": "foundry-component",
      "title": "Spireforge",
      "text": "Upcycle dense checkpoint into sparse Mixture-of-Experts. Grounded in MoE upcycling. Pillar: Distillation & Merging. Search terms: spireforge architecture moe upcycling upcycle dense checkpoint into sparse mixture-of-experts active: top-k of n, flops/token: ~flat, init: cloned ffn",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "distillation-&-merging",
        "spireforge",
        "architecture",
        "moe",
        "upcycling",
        "upcycle",
        "dense",
        "checkpoint",
        "sparse",
        "mixture-of",
        "experts"
      ],
      "kpis": [],
      "anchor": "pillar-05"
    },
    {
      "id": "foundry-pillar-06-memvault-lattice",
      "kind": "foundry-component",
      "title": "Memvault Lattice",
      "text": "Two-stage retrieval lattice grounding generation in your corpus. Grounded in RAG. Pillar: Retrieval, Memory & Long Context. Search terms: memvault lattice architecture rag two-stage retrieval lattice grounding generation in your corpus top-k: 3–20, recall@10: >0.9, refresh: index-only",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "retrieval,-memory-&-long-context",
        "memvault",
        "lattice",
        "architecture",
        "rag",
        "two-stage",
        "retrieval",
        "grounding",
        "generation",
        "your"
      ],
      "kpis": [],
      "anchor": "pillar-06"
    },
    {
      "id": "foundry-pillar-06-echograph-embeddings",
      "kind": "foundry-component",
      "title": "Echograph Embeddings",
      "text": "Dense semantic vectors: meaning not keywords drives retrieval. Grounded in Dense bi-encoder embeddings. Pillar: Retrieval, Memory & Long Context. Search terms: echograph embeddings terminology dense bi-encoder embeddings dense semantic vectors: meaning not keywords drives retrieval dim: 384–1536, metric: cosine, loss: infonce",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "retrieval,-memory-&-long-context",
        "echograph",
        "embeddings",
        "terminology",
        "dense",
        "bi-encoder",
        "semantic",
        "vectors",
        "meaning"
      ],
      "kpis": [],
      "anchor": "pillar-06"
    },
    {
      "id": "foundry-pillar-06-riftspan-rotary",
      "kind": "foundry-component",
      "title": "Riftspan Rotary",
      "text": "Stretch trained context window far past native length. Grounded in RoPE context extension. Pillar: Retrieval, Memory & Long Context. Search terms: riftspan rotary framework rope context extension stretch trained context window far past native length context: up to 8–32×, method: rope rescale, retune: <1% steps",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "retrieval,-memory-&-long-context",
        "riftspan",
        "rotary",
        "framework",
        "rope",
        "context",
        "extension",
        "stretch",
        "trained",
        "window"
      ],
      "kpis": [],
      "anchor": "pillar-06"
    },
    {
      "id": "foundry-pillar-06-vaultecho-cache",
      "kind": "foundry-component",
      "title": "Vaultecho Cache",
      "text": "Persist+stream attention state so long sessions never recompute. Grounded in StreamingLLM KV cache. Pillar: Retrieval, Memory & Long Context. Search terms: vaultecho cache architecture streamingllm kv cache persist+stream attention state so long sessions never recompute memory: o(window), sinks: 4 tokens, prefill: cached/reused",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "retrieval,-memory-&-long-context",
        "vaultecho",
        "cache",
        "architecture",
        "streamingllm",
        "kv",
        "persist",
        "stream",
        "attention",
        "state"
      ],
      "kpis": [],
      "anchor": "pillar-06"
    },
    {
      "id": "foundry-pillar-06-graftsieve-rerank",
      "kind": "foundry-component",
      "title": "Graftsieve Rerank",
      "text": "Cross-encoder second pass re-scores candidates. Grounded in Two-stage retrieval reranker. Pillar: Retrieval, Memory & Long Context. Search terms: graftsieve rerank framework two-stage retrieval reranker cross-encoder second pass re-scores candidates recall pool: 50–100, keep: top 3–5, stage: 2 (cross-enc)",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "retrieval,-memory-&-long-context",
        "graftsieve",
        "rerank",
        "framework",
        "two-stage",
        "retrieval",
        "reranker",
        "cross-encoder",
        "second",
        "pass",
        "re-scores"
      ],
      "kpis": [],
      "anchor": "pillar-06"
    },
    {
      "id": "foundry-pillar-07-speccast-relay",
      "kind": "foundry-component",
      "title": "Speccast Relay",
      "text": "Small drafter sprints ahead; sovereign model verifies in one pass. Grounded in Speculative decoding. Pillar: Inference & Serving Architecture. Search terms: speccast relay framework speculative decoding small drafter sprints ahead; sovereign model verifies in one pass speedup: 2–3×, block k: 4–8, output: lossless",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "inference-&-serving-architecture",
        "speccast",
        "relay",
        "framework",
        "speculative",
        "decoding",
        "small",
        "drafter",
        "sprints",
        "ahead",
        "sovereign"
      ],
      "kpis": [],
      "anchor": "pillar-07"
    },
    {
      "id": "foundry-pillar-07-pagewright-kv",
      "kind": "foundry-component",
      "title": "Pagewright KV",
      "text": "Virtual-memory paging for KV cache — near-zero fragmentation. Grounded in PagedAttention. Pillar: Inference & Serving Architecture. Search terms: pagewright kv architecture pagedattention virtual-memory paging for kv cache — near-zero fragmentation block: 16 tok, waste: <4%, prefix: cow-shared",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "inference-&-serving-architecture",
        "pagewright",
        "kv",
        "architecture",
        "pagedattention",
        "virtual-memory",
        "paging",
        "cache",
        "near-zero",
        "fragmentation"
      ],
      "kpis": [],
      "anchor": "pillar-07"
    },
    {
      "id": "foundry-pillar-07-flowbatch-loom",
      "kind": "foundry-component",
      "title": "Flowbatch Loom",
      "text": "Sequences join/leave batch every step; GPU never idles. Grounded in Continuous batching. Pillar: Inference & Serving Architecture. Search terms: flowbatch loom framework continuous batching sequences join/leave batch every step; gpu never idles throughput: up to 20× vs static, sched: per-iteration",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "inference-&-serving-architecture",
        "flowbatch",
        "loom",
        "framework",
        "continuous",
        "batching",
        "sequences",
        "join",
        "leave",
        "batch",
        "every"
      ],
      "kpis": [],
      "anchor": "pillar-07"
    },
    {
      "id": "foundry-pillar-07-shardloom-mesh",
      "kind": "foundry-component",
      "title": "Shardloom Mesh",
      "text": "Split layers across GPUs, stage in pipeline. Grounded in Tensor+pipeline parallelism. Pillar: Inference & Serving Architecture. Search terms: shardloom mesh architecture tensor+pipeline parallelism split layers across gpus, stage in pipeline mesh: tp×pp, tp link: nvlink, bubble: micro-batched",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "inference-&-serving-architecture",
        "shardloom",
        "mesh",
        "architecture",
        "tensor",
        "pipeline",
        "parallelism",
        "split",
        "layers",
        "across",
        "gpus"
      ],
      "kpis": [],
      "anchor": "pillar-07"
    },
    {
      "id": "foundry-pillar-07-castfuse-kernel",
      "kind": "foundry-component",
      "title": "Castfuse Kernel",
      "text": "IO-aware attention — never writes full score matrix to HBM. Grounded in FlashAttention. Pillar: Inference & Serving Architecture. Search terms: castfuse kernel terminology flashattention io-aware attention — never writes full score matrix to hbm mem: o(n), exact: yes, bottleneck: hbm io",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "inference-&-serving-architecture",
        "castfuse",
        "kernel",
        "terminology",
        "flashattention",
        "io-aware",
        "attention",
        "never",
        "writes",
        "full",
        "score"
      ],
      "kpis": [],
      "anchor": "pillar-07"
    },
    {
      "id": "foundry-pillar-08-basalt-core",
      "kind": "foundry-component",
      "title": "Basalt Core",
      "text": "Sovereign decoder backbone every Kynetra model is forged on. Grounded in Modern pre-norm decoder LLM. Pillar: Pretraining & Foundation Architecture. Search terms: basalt core architecture modern pre-norm decoder llm sovereign decoder backbone every kynetra model is forged on norm: rmsnorm (pre), ffn: swiglu, layers: 12–120+",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "pretraining-&-foundation-architecture",
        "basalt",
        "core",
        "architecture",
        "modern",
        "pre-norm",
        "decoder",
        "llm",
        "sovereign",
        "backbone"
      ],
      "kpis": [],
      "anchor": "pillar-08"
    },
    {
      "id": "foundry-pillar-08-spire-lattice",
      "kind": "foundry-component",
      "title": "Spire Lattice",
      "text": "Sparse expert routing — vast capacity, lean per-token compute. Grounded in Sparse MoE. Pillar: Pretraining & Foundation Architecture. Search terms: spire lattice architecture sparse moe sparse expert routing — vast capacity, lean per-token compute experts: 8–128, active: top-1/top-2, capacity: +10–50× params",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "pretraining-&-foundation-architecture",
        "spire",
        "lattice",
        "architecture",
        "sparse",
        "moe",
        "expert",
        "routing",
        "vast",
        "capacity"
      ],
      "kpis": [],
      "anchor": "pillar-08"
    },
    {
      "id": "foundry-pillar-08-attentryx-grip",
      "kind": "foundry-component",
      "title": "Attentryx Grip",
      "text": "Share keys, free the cache — attention that scales at inference. Grounded in GQA (Grouped Query Attention). Pillar: Pretraining & Foundation Architecture. Search terms: attentryx grip framework gqa (grouped query attention) share keys, free the cache — attention that scales at inference kv heads: 1–8, cache: -50–87%, quality: ~mha",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "pretraining-&-foundation-architecture",
        "attentryx",
        "grip",
        "framework",
        "gqa",
        "grouped",
        "query",
        "attention",
        "share",
        "keys",
        "free"
      ],
      "kpis": [],
      "anchor": "pillar-08"
    },
    {
      "id": "foundry-pillar-08-helix-anchor",
      "kind": "foundry-component",
      "title": "Helix Anchor",
      "text": "Rotary phase encoding for context extension past training length. Grounded in RoPE + long-context extension. Pillar: Pretraining & Foundation Architecture. Search terms: helix anchor terminology rope + long-context extension rotary phase encoding for context extension past training length params: 0 added, base: 10k–1m+, context: 4×–32× extend",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "pretraining-&-foundation-architecture",
        "helix",
        "anchor",
        "terminology",
        "rope",
        "long-context",
        "extension",
        "rotary",
        "phase",
        "encoding",
        "context"
      ],
      "kpis": [],
      "anchor": "pillar-08"
    },
    {
      "id": "foundry-pillar-08-forgecurve-doctrine",
      "kind": "foundry-component",
      "title": "Forgecurve Doctrine",
      "text": "Compute-optimal sizing + staged curriculum. Grounded in Chinchilla scaling laws. Pillar: Pretraining & Foundation Architecture. Search terms: forgecurve doctrine framework chinchilla scaling laws compute-optimal sizing + staged curriculum optimal: d≈20n tokens, compute: c≈6nd, stages: 2–4",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "pretraining-&-foundation-architecture",
        "forgecurve",
        "doctrine",
        "framework",
        "chinchilla",
        "scaling",
        "laws",
        "compute-optimal",
        "sizing",
        "staged",
        "curriculum"
      ],
      "kpis": [],
      "anchor": "pillar-08"
    },
    {
      "id": "foundry-pillar-09-proofgrid",
      "kind": "foundry-component",
      "title": "Proofgrid",
      "text": "Sovereign versioned eval lattice — same sealed bench for every checkpoint. Grounded in Reproducible eval harnesses. Pillar: Evaluation, Observability & Governance. Search terms: proofgrid architecture reproducible eval harnesses sovereign versioned eval lattice — same sealed bench for every checkpoint tasks: 50–400, seed: fixed/deterministic, ci: bootstrap 95%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "evaluation,-observability-&-governance",
        "proofgrid",
        "architecture",
        "reproducible",
        "eval",
        "harnesses",
        "sovereign",
        "versioned",
        "lattice",
        "same"
      ],
      "kpis": [],
      "anchor": "pillar-09"
    },
    {
      "id": "foundry-pillar-09-arbiter-lattice",
      "kind": "foundry-component",
      "title": "Arbiter Lattice",
      "text": "Ensemble LLM judge with calibrated rubrics, position-swapping. Grounded in LLM-as-judge. Pillar: Evaluation, Observability & Governance. Search terms: arbiter lattice framework llm-as-judge ensemble llm judge with calibrated rubrics, position-swapping judges: 1–5 ensemble, bias-control: order-swap, agreement: kappa-tracked",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "evaluation,-observability-&-governance",
        "arbiter",
        "lattice",
        "framework",
        "llm-as",
        "judge",
        "ensemble",
        "llm",
        "calibrated",
        "rubrics"
      ],
      "kpis": [],
      "anchor": "pillar-09"
    },
    {
      "id": "foundry-pillar-09-veracity-quotient",
      "kind": "foundry-component",
      "title": "Veracity Quotient",
      "text": "Single faithfulness score: how much is grounded in cited evidence. Grounded in Hallucination/factuality metrics. Pillar: Evaluation, Observability & Governance. Search terms: veracity quotient terminology hallucination/factuality metrics single faithfulness score: how much is grounded in cited evidence range: 0.0–1.0, checker: nli entailment, granularity: atomic-claim",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "evaluation,-observability-&-governance",
        "veracity",
        "quotient",
        "terminology",
        "hallucination",
        "factuality",
        "metrics",
        "single",
        "faithfulness",
        "score",
        "how"
      ],
      "kpis": [],
      "anchor": "pillar-09"
    },
    {
      "id": "foundry-pillar-09-lineagraph",
      "kind": "foundry-component",
      "title": "Lineagraph",
      "text": "Tamper-evident provenance DAG linking every weight to data+code. Grounded in Data+model lineage / provenance. Pillar: Evaluation, Observability & Governance. Search terms: lineagraph architecture data+model lineage / provenance tamper-evident provenance dag linking every weight to data+code addressing: sha-256, output: ml-bom, tamper: signature-chained",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "evaluation,-observability-&-governance",
        "lineagraph",
        "architecture",
        "data",
        "model",
        "lineage",
        "provenance",
        "tamper-evident",
        "dag",
        "linking"
      ],
      "kpis": [],
      "anchor": "pillar-09"
    },
    {
      "id": "foundry-pillar-09-driftwatch-sentinel",
      "kind": "foundry-component",
      "title": "Driftwatch Sentinel",
      "text": "Continuous telemetry catching input drift + quality regressions. Grounded in Production drift detection. Pillar: Evaluation, Observability & Governance. Search terms: driftwatch sentinel framework production drift detection continuous telemetry catching input drift + quality regressions drift: psi/kl/mmd, mode: streaming, gate: shadow-canary",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "evaluation,-observability-&-governance",
        "driftwatch",
        "sentinel",
        "framework",
        "production",
        "drift",
        "detection",
        "continuous",
        "telemetry",
        "catching",
        "input"
      ],
      "kpis": [],
      "anchor": "pillar-09"
    },
    {
      "id": "foundry-pillar-10-sentinel-weave",
      "kind": "foundry-component",
      "title": "Sentinel Weave",
      "text": "Layered guardrail mesh filtering I/O before reaching user. Grounded in Guardrails + content filtering. Pillar: Safety, Sovereignty & Orchestration. Search terms: sentinel weave framework guardrails + content filtering layered guardrail mesh filtering i/o before reaching user latency: <40ms/turn, categories: 12+, action: block/redact/rewrite",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "safety,-sovereignty-&-orchestration",
        "sentinel",
        "weave",
        "framework",
        "guardrails",
        "content",
        "filtering",
        "layered",
        "guardrail",
        "mesh"
      ],
      "kpis": [],
      "anchor": "pillar-10"
    },
    {
      "id": "foundry-pillar-10-wardgate",
      "kind": "foundry-component",
      "title": "Wardgate",
      "text": "Adversarial-prompt defense hardening against jailbreaks. Grounded in Jailbreak + prompt injection defense. Pillar: Safety, Sovereignty & Orchestration. Search terms: wardgate framework jailbreak + prompt injection defense adversarial-prompt defense hardening against jailbreaks asr: -90% vs base, hierarchy: 4-tier, detect: perplexity+embed",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "safety,-sovereignty-&-orchestration",
        "wardgate",
        "framework",
        "jailbreak",
        "prompt",
        "injection",
        "defense",
        "adversarial-prompt",
        "hardening",
        "against"
      ],
      "kpis": [],
      "anchor": "pillar-10"
    },
    {
      "id": "foundry-pillar-10-sovryn-vault",
      "kind": "foundry-component",
      "title": "Sovryn Vault",
      "text": "Air-gapped on-prem training — data/weights never leave perimeter. Grounded in Air-gapped sovereign training. Pillar: Safety, Sovereignty & Orchestration. Search terms: sovryn vault architecture air-gapped sovereign training air-gapped on-prem training — data/weights never leave perimeter egress: zero, keys: customer hsm, residency: pinned",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "safety,-sovereignty-&-orchestration",
        "sovryn",
        "vault",
        "architecture",
        "air-gapped",
        "sovereign",
        "training",
        "on-prem",
        "data"
      ],
      "kpis": [],
      "anchor": "pillar-10"
    },
    {
      "id": "foundry-pillar-10-shardbastion",
      "kind": "foundry-component",
      "title": "Shardbastion",
      "text": "Fully-sharded parallelism — weights/grads/optimizer across cluster. Grounded in FSDP / ZeRO sharding. Pillar: Safety, Sovereignty & Orchestration. Search terms: shardbastion architecture fsdp / zero sharding fully-sharded parallelism — weights/grads/optimizer across cluster mem/gpu: ~1/n replicas, stage: 3 (params+grads+opt), offload: cpu/nvme",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "safety,-sovereignty-&-orchestration",
        "shardbastion",
        "architecture",
        "fsdp",
        "zero",
        "sharding",
        "fully-sharded",
        "parallelism",
        "weights",
        "grads",
        "optimizer"
      ],
      "kpis": [],
      "anchor": "pillar-10"
    },
    {
      "id": "foundry-pillar-10-anchorpoint",
      "kind": "foundry-component",
      "title": "Anchorpoint",
      "text": "Durable resumable training checkpoint restoring full run state. Grounded in Checkpoint + activation checkpointing. Pillar: Safety, Sovereignty & Orchestration. Search terms: anchorpoint terminology checkpoint + activation checkpointing durable resumable training checkpoint restoring full run state resume: exactly-once, recompute: ~+30% flops, write: async/sharded",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "safety,-sovereignty-&-orchestration",
        "anchorpoint",
        "terminology",
        "checkpoint",
        "activation",
        "checkpointing",
        "durable",
        "resumable",
        "training",
        "restoring"
      ],
      "kpis": [],
      "anchor": "pillar-10"
    },
    {
      "id": "foundry-pillar-11-octforge-precision",
      "kind": "foundry-component",
      "title": "Octforge Precision",
      "text": "Run math in 8-bit and 4-bit floats the silicon speaks natively. Grounded in FP8/FP4 hardware arithmetic. Pillar: Acceleration Frontier (100×). Search terms: octforge precision framework fp8/fp4 hardware arithmetic run math in 8-bit and 4-bit floats the silicon speaks natively ~2× throughput vs bf16, ~2× memory cut, <1% quality loss",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "acceleration-frontier-(100×)",
        "octforge",
        "precision",
        "framework",
        "fp8",
        "fp4",
        "hardware",
        "arithmetic",
        "run",
        "math",
        "8-bit"
      ],
      "kpis": [],
      "anchor": "pillar-11"
    },
    {
      "id": "foundry-pillar-11-streamcore-ssm",
      "kind": "foundry-component",
      "title": "Streamcore SSM",
      "text": "Linear-time recurrence — constant memory, book-length context. Grounded in State Space Models (Mamba/SSM). Pillar: Acceleration Frontier (100×). Search terms: streamcore ssm architecture state space models (mamba/ssm) linear-time recurrence — constant memory, book-length context o(n) vs o(n²), no kv-cache growth, 4–5× long-ctx throughput",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "acceleration-frontier-(100×)",
        "streamcore",
        "ssm",
        "architecture",
        "state",
        "space",
        "models",
        "mamba",
        "linear-time",
        "recurrence"
      ],
      "kpis": [],
      "anchor": "pillar-11"
    },
    {
      "id": "foundry-pillar-11-latent-grip",
      "kind": "foundry-component",
      "title": "Latent Grip",
      "text": "Compress keys+values into tiny latent — 5–13× smaller KV cache. Grounded in MLA (Multi-head Latent Attention). Pillar: Acceleration Frontier (100×). Search terms: latent grip architecture mla (multi-head latent attention) compress keys+values into tiny latent — 5–13× smaller kv cache 2.7–4.7× smaller vs gqa, ~5–13× vs mha, ≥mha quality",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "acceleration-frontier-(100×)",
        "latent",
        "grip",
        "architecture",
        "mla",
        "multi-head",
        "attention",
        "compress",
        "keys",
        "values"
      ],
      "kpis": [],
      "anchor": "pillar-11"
    },
    {
      "id": "foundry-pillar-11-radix-echo",
      "kind": "foundry-component",
      "title": "Radix Echo",
      "text": "Compute prompt prefix once, reuse everywhere — zero re-prefill. Grounded in RadixAttention / prefix caching. Pillar: Acceleration Frontier (100×). Search terms: radix echo framework radixattention / prefix caching compute prompt prefix once, reuse everywhere — zero re-prefill up to 6.4× on shared prefix, 50–99% hit rates, o(1) lookup",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "acceleration-frontier-(100×)",
        "radix",
        "echo",
        "framework",
        "radixattention",
        "prefix",
        "caching",
        "compute",
        "prompt",
        "once"
      ],
      "kpis": [],
      "anchor": "pillar-11"
    },
    {
      "id": "foundry-pillar-11-splitstream-relay",
      "kind": "foundry-component",
      "title": "Splitstream Relay",
      "text": "Run prefill+decode on separate GPU pools — kill interference. Grounded in Prefill-decode disaggregation. Pillar: Acceleration Frontier (100×). Search terms: splitstream relay architecture prefill-decode disaggregation run prefill+decode on separate gpu pools — kill interference 1.4–2.3× ttft cut, up to 7.4× at slo, independent scaling",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "acceleration-frontier-(100×)",
        "splitstream",
        "relay",
        "architecture",
        "prefill-decode",
        "disaggregation",
        "run",
        "prefill",
        "decode",
        "separate",
        "gpu"
      ],
      "kpis": [],
      "anchor": "pillar-11"
    },
    {
      "id": "foundry-pillar-12-optimusforge",
      "kind": "foundry-component",
      "title": "OptimusForge",
      "text": "100-worker meta-orchestrator training+scoring+promoting toward 100× target. Grounded in Fleet orchestration / self-evolution. Pillar: Autonomous Self-Evolution. Search terms: optimusforge architecture fleet orchestration / self-evolution 100-worker meta-orchestrator training+scoring+promoting toward 100× target fleet: ≤100 workers, target: 100×/30d, daily rate: ~1.166×",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "autonomous-self-evolution",
        "optimusforge",
        "architecture",
        "fleet",
        "orchestration",
        "self-evolution",
        "100-worker",
        "meta-orchestrator",
        "training",
        "scoring",
        "promoting"
      ],
      "kpis": [],
      "anchor": "pillar-12"
    },
    {
      "id": "foundry-pillar-12-crucible-selfplay",
      "kind": "foundry-component",
      "title": "Crucible Selfplay",
      "text": "One model plays questioner+responder+verifier — no human labels. Grounded in Self-play / STaR. Pillar: Autonomous Self-Evolution. Search terms: crucible selfplay framework self-play / star one model plays questioner+responder+verifier — no human labels labels: zero human, roles: 3 (q/r/v), target success: 60–80%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "autonomous-self-evolution",
        "crucible",
        "selfplay",
        "framework",
        "self-play",
        "star",
        "one",
        "model",
        "plays",
        "questioner",
        "responder"
      ],
      "kpis": [],
      "anchor": "pillar-12"
    },
    {
      "id": "foundry-pillar-12-tribunal-distill",
      "kind": "foundry-component",
      "title": "Tribunal Distill",
      "text": "Panel of teachers debates student's outputs — confidence-weighted supervision. Grounded in Multi-agent debate distillation. Pillar: Autonomous Self-Evolution. Search terms: tribunal distill framework multi-agent debate distillation panel of teachers debates student's outputs — confidence-weighted supervision panel: k teachers, rounds: m per span, signal: token-level consensus",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "autonomous-self-evolution",
        "tribunal",
        "distill",
        "framework",
        "multi-agent",
        "debate",
        "distillation",
        "panel",
        "teachers",
        "debates",
        "student"
      ],
      "kpis": [],
      "anchor": "pillar-12"
    },
    {
      "id": "foundry-pillar-12-edictforge-selfedit",
      "kind": "foundry-component",
      "title": "Edictforge Selfedit",
      "text": "Model writes its own training data+hyperparams, outer RL rewards self-edits. Grounded in Self-edit / self-supervised SFT. Pillar: Autonomous Self-Evolution. Search terms: edictforge selfedit framework self-edit / self-supervised sft model writes its own training data+hyperparams, outer rl rewards self-edits labels: zero external, loop: outer rl + inner sft, signal: probe-delta reward",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "autonomous-self-evolution",
        "edictforge",
        "selfedit",
        "framework",
        "self-edit",
        "self-supervised",
        "sft",
        "model",
        "writes",
        "its",
        "own"
      ],
      "kpis": [],
      "anchor": "pillar-12"
    },
    {
      "id": "foundry-pillar-12-driftloom-online",
      "kind": "foundry-component",
      "title": "Driftloom Online",
      "text": "Model evolves during inference — accept/reject feedback drives policy updates. Grounded in Online learning from serving. Pillar: Autonomous Self-Evolution. Search terms: driftloom online architecture online learning from serving model evolves during inference — accept/reject feedback drives policy updates labels: zero, update: per-batch online, path: drafter or mem-store",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "autonomous-self-evolution",
        "driftloom",
        "online",
        "architecture",
        "learning",
        "serving",
        "model",
        "evolves",
        "during",
        "inference"
      ],
      "kpis": [],
      "anchor": "pillar-12"
    },
    {
      "id": "foundry-pillar-13-tempest-drill",
      "kind": "foundry-component",
      "title": "Tempest Drill",
      "text": "Attacker-LLM automated red-teaming before adversaries do. Grounded in GCG, PAIR, TAP, HarmBench. Pillar: Adversarial Robustness & Red-Teaming. Search terms: tempest drill framework gcg, pair, tap, harmbench attacker-llm automated red-teaming before adversaries do asr@harmbench, queries-to-jailbreak, behavior-set coverage%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adversarial-robustness-&-red-teaming",
        "tempest",
        "drill",
        "framework",
        "gcg",
        "pair",
        "tap",
        "harmbench",
        "attacker-llm",
        "automated",
        "red-teaming"
      ],
      "kpis": [],
      "anchor": "pillar-13"
    },
    {
      "id": "foundry-pillar-13-forgeward-training",
      "kind": "foundry-component",
      "title": "Forgeward Training",
      "text": "Harden from inside — adversarial perturbations at latent layer. Grounded in Latent Adversarial Training (LAT). Pillar: Adversarial Robustness & Red-Teaming. Search terms: forgeward training framework latent adversarial training (lat) harden from inside — adversarial perturbations at latent layer post-lat asr reduction%, retain/capability delta, backdoor removal rate",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adversarial-robustness-&-red-teaming",
        "forgeward",
        "training",
        "framework",
        "latent",
        "adversarial",
        "lat",
        "harden",
        "inside"
      ],
      "kpis": [],
      "anchor": "pillar-13"
    },
    {
      "id": "foundry-pillar-13-certvault-smoothing",
      "kind": "foundry-component",
      "title": "Certvault Smoothing",
      "text": "Provable safety — certify no perturbation within radius can flip refusal. Grounded in SmoothLLM / certified robustness. Pillar: Adversarial Robustness & Red-Teaming. Search terms: certvault smoothing architecture smoothllm / certified robustness provable safety — certify no perturbation within radius can flip refusal certificate radius r (tokens), certified accuracy@threat level",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adversarial-robustness-&-red-teaming",
        "certvault",
        "smoothing",
        "architecture",
        "smoothllm",
        "certified",
        "robustness",
        "provable",
        "safety",
        "certify",
        "no"
      ],
      "kpis": [],
      "anchor": "pillar-13"
    },
    {
      "id": "foundry-pillar-13-latentguard-reroute",
      "kind": "foundry-component",
      "title": "Latentguard Reroute",
      "text": "Cut the wire before harmful thought completes — circuit-level rerouting. Grounded in Representation Engineering (RepE). Pillar: Adversarial Robustness & Red-Teaming. Search terms: latentguard reroute architecture representation engineering (repe) cut the wire before harmful thought completes — circuit-level rerouting harmful-output suppression rate, benign capability retention%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adversarial-robustness-&-red-teaming",
        "latentguard",
        "reroute",
        "architecture",
        "representation",
        "engineering",
        "repe",
        "cut",
        "wire",
        "before",
        "harmful"
      ],
      "kpis": [],
      "anchor": "pillar-13"
    },
    {
      "id": "foundry-pillar-13-harmscope-grid",
      "kind": "foundry-component",
      "title": "Harmscope Grid",
      "text": "Taxonomy turning 'it refused' into a number — standardized harm grid. Grounded in HarmBench, JailbreakBench, StrongREJECT. Pillar: Adversarial Robustness & Red-Teaming. Search terms: harmscope grid terminology harmbench, jailbreakbench, strongreject taxonomy turning 'it refused' into a number — standardized harm grid asr per attack×behavior cell, strongreject weighted score",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "adversarial-robustness-&-red-teaming",
        "harmscope",
        "grid",
        "terminology",
        "harmbench",
        "jailbreakbench",
        "strongreject",
        "taxonomy",
        "turning",
        "x27",
        "refused"
      ],
      "kpis": [],
      "anchor": "pillar-13"
    },
    {
      "id": "foundry-pillar-14-venomsieve",
      "kind": "foundry-component",
      "title": "Venomsieve",
      "text": "Multi-stage filter hunting poisoned training samples. Grounded in Spectral signatures, activation clustering. Pillar: Data & Supply-Chain Integrity. Search terms: venomsieve framework spectral signatures, activation clustering multi-stage filter hunting poisoned training samples poison recall on trigger attacks, clean-data retention%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "data-&-supply-chain-integrity",
        "venomsieve",
        "framework",
        "spectral",
        "signatures",
        "activation",
        "clustering",
        "multi-stage",
        "filter",
        "hunting",
        "poisoned"
      ],
      "kpis": [],
      "anchor": "pillar-14"
    },
    {
      "id": "foundry-pillar-14-trapward-scan",
      "kind": "foundry-component",
      "title": "Trapward Scan",
      "text": "Reverse-engineers and excises hidden backdoor triggers. Grounded in Neural Cleanse, ABS. Pillar: Data & Supply-Chain Integrity. Search terms: trapward scan framework neural cleanse, abs reverse-engineers and excises hidden backdoor triggers backdoor asr post-scan, clean-accuracy drop after fine-pruning",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "data-&-supply-chain-integrity",
        "trapward",
        "scan",
        "framework",
        "neural",
        "cleanse",
        "abs",
        "reverse-engineers",
        "excises",
        "hidden",
        "backdoor"
      ],
      "kpis": [],
      "anchor": "pillar-14"
    },
    {
      "id": "foundry-pillar-14-sigil-seal",
      "kind": "foundry-component",
      "title": "Sigil Seal",
      "text": "Cryptographic identity+provenance binding every artifact to verified origin. Grounded in Sigstore/cosign + Rekor. Pillar: Data & Supply-Chain Integrity. Search terms: sigil seal architecture sigstore/cosign + rekor cryptographic identity+provenance binding every artifact to verified origin provenance chain verify time, zero unsigned artifacts",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "data-&-supply-chain-integrity",
        "sigil",
        "seal",
        "architecture",
        "sigstore",
        "cosign",
        "rekor",
        "cryptographic",
        "identity",
        "provenance",
        "binding"
      ],
      "kpis": [],
      "anchor": "pillar-14"
    },
    {
      "id": "foundry-pillar-14-attestgraph-ledger",
      "kind": "foundry-component",
      "title": "Attestgraph Ledger",
      "text": "Content-addressed queryable graph of verifiable dataset provenance. Grounded in Croissant, OpenLineage. Pillar: Data & Supply-Chain Integrity. Search terms: attestgraph ledger architecture croissant, openlineage content-addressed queryable graph of verifiable dataset provenance full provenance trace query time, tdbom generation time",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "data-&-supply-chain-integrity",
        "attestgraph",
        "ledger",
        "architecture",
        "croissant",
        "openlineage",
        "content-addressed",
        "queryable",
        "graph",
        "verifiable",
        "dataset"
      ],
      "kpis": [],
      "anchor": "pillar-14"
    },
    {
      "id": "foundry-pillar-14-pickleguard-sweep",
      "kind": "foundry-component",
      "title": "Pickleguard Sweep",
      "text": "Mandatory artifact malware scan blocking unsafe serialization formats. Grounded in PickleScan CVE. Pillar: Data & Supply-Chain Integrity. Search terms: pickleguard sweep terminology picklescan cve mandatory artifact malware scan blocking unsafe serialization formats zero malicious opcodes to storage, 100% safetensors enforcement",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "data-&-supply-chain-integrity",
        "pickleguard",
        "sweep",
        "terminology",
        "picklescan",
        "cve",
        "mandatory",
        "artifact",
        "malware",
        "scan",
        "blocking"
      ],
      "kpis": [],
      "anchor": "pillar-14"
    },
    {
      "id": "foundry-pillar-15-hazeguard-dp",
      "kind": "foundry-component",
      "title": "Hazeguard DP",
      "text": "Provable per-sample privacy — gradient clipping+calibrated noise. Grounded in DP-SGD / differential privacy. Pillar: Privacy & Confidential Compute. Search terms: hazeguard dp framework dp-sgd / differential privacy provable per-sample privacy — gradient clipping+calibrated noise (ε, δ) certificate, per-sample overhead vs sgd",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "privacy-&-confidential-compute",
        "hazeguard",
        "dp",
        "framework",
        "dp-sgd",
        "differential",
        "privacy",
        "provable",
        "per-sample",
        "gradient"
      ],
      "kpis": [],
      "anchor": "pillar-15"
    },
    {
      "id": "foundry-pillar-15-cryptcore-enclave",
      "kind": "foundry-component",
      "title": "Cryptcore Enclave",
      "text": "Sovereign training+inference inside hardware-attested GPU enclaves. Grounded in NVIDIA H100/H200 Confidential Computing. Pillar: Privacy & Confidential Compute. Search terms: cryptcore enclave architecture nvidia h100/h200 confidential computing sovereign training+inference inside hardware-attested gpu enclaves per-session aes-256 vram key, ~95–99% native throughput",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "privacy-&-confidential-compute",
        "cryptcore",
        "enclave",
        "architecture",
        "nvidia",
        "h100",
        "h200",
        "confidential",
        "computing",
        "sovereign",
        "training"
      ],
      "kpis": [],
      "anchor": "pillar-15"
    },
    {
      "id": "foundry-pillar-15-swarmfed-loom",
      "kind": "foundry-component",
      "title": "Swarmfed Loom",
      "text": "Distributed private training across sovereign silos. Grounded in Federated Learning / FedAvg, secure aggregation. Pillar: Privacy & Confidential Compute. Search terms: swarmfed loom framework federated learning / fedavg, secure aggregation distributed private training across sovereign silos secure-aggregation overhead, cross-silo convergence rounds",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "privacy-&-confidential-compute",
        "swarmfed",
        "loom",
        "framework",
        "federated",
        "learning",
        "fedavg",
        "secure",
        "aggregation",
        "distributed",
        "private"
      ],
      "kpis": [],
      "anchor": "pillar-15"
    },
    {
      "id": "foundry-pillar-15-lethe-unlearn",
      "kind": "foundry-component",
      "title": "Lethe Unlearn",
      "text": "Surgically excise training-data influence — GDPR-compliant forgetting. Grounded in SISA, gradient unlearning. Pillar: Privacy & Confidential Compute. Search terms: lethe unlearn framework sisa, gradient unlearning surgically excise training-data influence — gdpr-compliant forgetting unlearning runtime, forget-set mia accuracy threshold",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "privacy-&-confidential-compute",
        "lethe",
        "unlearn",
        "framework",
        "sisa",
        "gradient",
        "unlearning",
        "surgically",
        "excise",
        "training-data",
        "influence"
      ],
      "kpis": [],
      "anchor": "pillar-15"
    },
    {
      "id": "foundry-pillar-15-cipherquery",
      "kind": "foundry-component",
      "title": "Cipherquery",
      "text": "Query sovereign model over fully encrypted inputs. Grounded in FHE (CKKS), MPC. Pillar: Privacy & Confidential Compute. Search terms: cipherquery architecture fhe (ckks), mpc query sovereign model over fully encrypted inputs ckks mantissa precision, per-token latency (fhe+mpc)",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "privacy-&-confidential-compute",
        "cipherquery",
        "architecture",
        "fhe",
        "ckks",
        "mpc",
        "query",
        "sovereign",
        "model",
        "fully",
        "encrypted"
      ],
      "kpis": [],
      "anchor": "pillar-15"
    },
    {
      "id": "foundry-pillar-16-glyphmark-watermark",
      "kind": "foundry-component",
      "title": "Glyphmark Watermark",
      "text": "Invisible statistical provenance in every token stream. Grounded in Green-token watermarking (Kirchenbauer). Pillar: Model IP & Weight Protection. Search terms: glyphmark watermark framework green-token watermarking (kirchenbauer) invisible statistical provenance in every token stream z-score at fixed length, detection accuracy post-paraphrase",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "model-ip-&-weight-protection",
        "glyphmark",
        "watermark",
        "framework",
        "green-token",
        "watermarking",
        "kirchenbauer",
        "invisible",
        "statistical",
        "provenance",
        "every"
      ],
      "kpis": [],
      "anchor": "pillar-16"
    },
    {
      "id": "foundry-pillar-16-siphonward",
      "kind": "foundry-component",
      "title": "Siphonward",
      "text": "Turn every API query into dead end for extraction attackers. Grounded in Model extraction defense. Pillar: Model IP & Weight Protection. Search terms: siphonward framework model extraction defense turn every api query into dead end for extraction attackers surrogate-accuracy degradation, watermark inheritance rate",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "model-ip-&-weight-protection",
        "siphonward",
        "framework",
        "model",
        "extraction",
        "defense",
        "turn",
        "every",
        "api",
        "query",
        "dead"
      ],
      "kpis": [],
      "anchor": "pillar-16"
    },
    {
      "id": "foundry-pillar-16-vaultseal-weights",
      "kind": "foundry-component",
      "title": "Vaultseal Weights",
      "text": "Weights exist only inside silicon boundary — encrypted, TEE-only decrypt. Grounded in TEE-sealed weights. Pillar: Model IP & Weight Protection. Search terms: vaultseal weights architecture tee-sealed weights weights exist only inside silicon boundary — encrypted, tee-only decrypt zero plaintext weight exposure outside silicon, ≥95% throughput",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "model-ip-&-weight-protection",
        "vaultseal",
        "weights",
        "architecture",
        "tee-sealed",
        "exist",
        "only",
        "inside",
        "silicon"
      ],
      "kpis": [],
      "anchor": "pillar-16"
    },
    {
      "id": "foundry-pillar-16-fingergraph-id",
      "kind": "foundry-component",
      "title": "Fingergraph ID",
      "text": "Unforgeable identity woven into weights — survives fine-tuning. Grounded in Representation fingerprinting. Pillar: Model IP & Weight Protection. Search terms: fingergraph id terminology representation fingerprinting unforgeable identity woven into weights — survives fine-tuning intrinsic collision rate, ownership-key survival after fine-tune",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "model-ip-&-weight-protection",
        "fingergraph",
        "id",
        "terminology",
        "representation",
        "fingerprinting",
        "unforgeable",
        "identity",
        "woven",
        "weights",
        "survives"
      ],
      "kpis": [],
      "anchor": "pillar-16"
    },
    {
      "id": "foundry-pillar-16-tamperwire",
      "kind": "foundry-component",
      "title": "Tamperwire",
      "text": "Tripwire through model's weights — any corruption breaks circuit. Grounded in Hardware tamper detection. Pillar: Model IP & Weight Protection. Search terms: tamperwire architecture hardware tamper detection tripwire through model's weights — any corruption breaks circuit tamper-detection probability, load-time full-verify latency",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "model-ip-&-weight-protection",
        "tamperwire",
        "architecture",
        "hardware",
        "tamper",
        "detection",
        "tripwire",
        "through",
        "model",
        "x27",
        "weights"
      ],
      "kpis": [],
      "anchor": "pillar-16"
    },
    {
      "id": "foundry-pillar-17-aegis-policy-mesh",
      "kind": "foundry-component",
      "title": "Aegis Policy Mesh",
      "text": "Programmable I/O policy orchestration wrapping every inference. Grounded in NeMo Guardrails, OPA/Rego. Pillar: Runtime & Agent Security. Search terms: aegis policy mesh framework nemo guardrails, opa/rego programmable i/o policy orchestration wrapping every inference rail p99 latency, policy hot-reload propagation, i/o path coverage%",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "runtime-&-agent-security",
        "aegis",
        "policy",
        "mesh",
        "framework",
        "nemo",
        "guardrails",
        "opa",
        "rego",
        "programmable"
      ],
      "kpis": [],
      "anchor": "pillar-17"
    },
    {
      "id": "foundry-pillar-17-sandward-runtime",
      "kind": "foundry-component",
      "title": "Sandward Runtime",
      "text": "Least-privilege sandbox confining every agent tool call. Grounded in Firecracker microVMs, gVisor, V8 isolates. Pillar: Runtime & Agent Security. Search terms: sandward runtime architecture firecracker microvms, gvisor, v8 isolates least-privilege sandbox confining every agent tool call warm-pool spin-up p99, zero cross-session secret leakage",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "runtime-&-agent-security",
        "sandward",
        "runtime",
        "architecture",
        "firecracker",
        "microvms",
        "gvisor",
        "v8",
        "isolates",
        "least-privilege",
        "sandbox"
      ],
      "kpis": [],
      "anchor": "pillar-17"
    },
    {
      "id": "foundry-pillar-17-injectward",
      "kind": "foundry-component",
      "title": "Injectward",
      "text": "Defense blocking indirect prompt injection in agents+RAG. Grounded in CaMeL (Google DeepMind), Microsoft spotlighting. Pillar: Runtime & Agent Security. Search terms: injectward framework camel (google deepmind), microsoft spotlighting defense blocking indirect prompt injection in agents+rag ipi success rate (dual-llm), contaminated-chain block rate",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "runtime-&-agent-security",
        "injectward",
        "framework",
        "camel",
        "google",
        "deepmind",
        "microsoft",
        "spotlighting",
        "defense",
        "blocking",
        "indirect"
      ],
      "kpis": [],
      "anchor": "pillar-17"
    },
    {
      "id": "foundry-pillar-17-sentryln-forensics",
      "kind": "foundry-component",
      "title": "Sentryln Forensics",
      "text": "Tamper-evident audit making every inference+action replayable. Grounded in HMAC audit chains. Pillar: Runtime & Agent Security. Search terms: sentryln forensics architecture hmac audit chains tamper-evident audit making every inference+action replayable forensic replay fidelity, chain-of-custody integrity",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "foundry",
        "component",
        "runtime-&-agent-security",
        "sentryln",
        "forensics",
        "architecture",
        "hmac",
        "audit",
        "chains",
        "tamper-evident",
        "making",
        "every"
      ],
      "kpis": [],
      "anchor": "pillar-17"
    },
    {
      "id": "term-write-append",
      "kind": "kynetradb-term",
      "title": "APPEND",
      "text": "Write a new record to the tail of the log — the atomic unit of durability.. maps to INSERT. Category: Write. Search terms: append write a new record to the tail of the log — the atomic unit of durability. insert write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "append",
        "new",
        "record",
        "tail",
        "log",
        "atomic",
        "unit",
        "durability",
        "insert"
      ],
      "kpis": []
    },
    {
      "id": "term-write-put",
      "kind": "kynetradb-term",
      "title": "PUT",
      "text": "Create or replace an entity by id.. maps to UPSERT. Category: Write. Search terms: put create or replace an entity by id. upsert write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "put",
        "create",
        "replace",
        "entity",
        "id",
        "upsert"
      ],
      "kpis": []
    },
    {
      "id": "term-write-patch",
      "kind": "kynetradb-term",
      "title": "PATCH",
      "text": "Merge fields into an existing entity without rewriting the whole record.. maps to UPDATE. Category: Write. Search terms: patch merge fields into an existing entity without rewriting the whole record. update write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "patch",
        "merge",
        "fields",
        "existing",
        "entity",
        "without",
        "rewriting",
        "whole",
        "record",
        "update"
      ],
      "kpis": []
    },
    {
      "id": "term-write-drop",
      "kind": "kynetradb-term",
      "title": "DROP",
      "text": "Retire an entity by writing a tombstone — the log records the deletion, never erases it.. maps to DELETE. Category: Write. Search terms: drop retire an entity by writing a tombstone — the log records the deletion, never erases it. delete write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "drop",
        "retire",
        "entity",
        "writing",
        "tombstone",
        "log",
        "records",
        "deletion",
        "never",
        "erases"
      ],
      "kpis": []
    },
    {
      "id": "term-write-seal",
      "kind": "kynetradb-term",
      "title": "SEAL",
      "text": "Force pending writes to durable storage.. maps to COMMIT / fsync. Category: Write. Search terms: seal force pending writes to durable storage. commit / fsync write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "seal",
        "force",
        "pending",
        "writes",
        "durable",
        "storage",
        "commit",
        "fsync"
      ],
      "kpis": []
    },
    {
      "id": "term-write-batch",
      "kind": "kynetradb-term",
      "title": "BATCH",
      "text": "Group writes so they apply atomically or not at all.. maps to TRANSACTION. Category: Write. Search terms: batch group writes so they apply atomically or not at all. transaction write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "batch",
        "group",
        "writes",
        "so",
        "they",
        "apply",
        "atomically",
        "not",
        "all",
        "transaction"
      ],
      "kpis": []
    },
    {
      "id": "term-write-embed",
      "kind": "kynetradb-term",
      "title": "EMBED",
      "text": "Attach a vector embedding to an entity at write time.. maps to vector column write. Category: Write. Search terms: embed attach a vector embedding to an entity at write time. vector column write write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "embed",
        "attach",
        "vector",
        "embedding",
        "entity",
        "time",
        "column"
      ],
      "kpis": []
    },
    {
      "id": "term-write-tag",
      "kind": "kynetradb-term",
      "title": "TAG",
      "text": "Label a record with a kind for routing and isolation.. maps to set type / label. Category: Write. Search terms: tag label a record with a kind for routing and isolation. set type / label write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "tag",
        "label",
        "record",
        "kind",
        "routing",
        "isolation",
        "set",
        "type"
      ],
      "kpis": []
    },
    {
      "id": "term-write-stamp",
      "kind": "kynetradb-term",
      "title": "STAMP",
      "text": "The monotonic sequence and timestamp the log assigns each record.. maps to LSN + ts. Category: Write. Search terms: stamp the monotonic sequence and timestamp the log assigns each record. lsn + ts concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "concept",
        "live",
        "stamp",
        "monotonic",
        "sequence",
        "timestamp",
        "log",
        "assigns",
        "each",
        "record",
        "lsn",
        "ts"
      ],
      "kpis": []
    },
    {
      "id": "term-write-mint",
      "kind": "kynetradb-term",
      "title": "MINT",
      "text": "Issue a new unique id for an entity.. maps to generate primary key. Category: Write. Search terms: mint issue a new unique id for an entity. generate primary key write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "write",
        "live",
        "mint",
        "issue",
        "new",
        "unique",
        "id",
        "entity",
        "generate",
        "primary",
        "key"
      ],
      "kpis": []
    },
    {
      "id": "term-read-fetch",
      "kind": "kynetradb-term",
      "title": "FETCH",
      "text": "Read a single entity by id.. maps to SELECT by PK. Category: Read. Search terms: fetch read a single entity by id. select by pk read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "fetch",
        "single",
        "entity",
        "id",
        "select",
        "pk"
      ],
      "kpis": []
    },
    {
      "id": "term-read-scan",
      "kind": "kynetradb-term",
      "title": "SCAN",
      "text": "Read a range or page of entities in log order.. maps to SELECT … LIMIT/OFFSET. Category: Read. Search terms: scan read a range or page of entities in log order. select … limit/offset read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "scan",
        "range",
        "page",
        "entities",
        "log",
        "order",
        "select",
        "limit",
        "offset"
      ],
      "kpis": []
    },
    {
      "id": "term-read-filter",
      "kind": "kynetradb-term",
      "title": "FILTER",
      "text": "Return entities matching a predicate.. maps to WHERE. Category: Read. Search terms: filter return entities matching a predicate. where read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "filter",
        "return",
        "entities",
        "matching",
        "predicate",
        "where"
      ],
      "kpis": []
    },
    {
      "id": "term-read-count",
      "kind": "kynetradb-term",
      "title": "COUNT",
      "text": "Number of entities matching a query.. maps to COUNT(*). Category: Read. Search terms: count number of entities matching a query. count(*) read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "count",
        "number",
        "entities",
        "matching",
        "query"
      ],
      "kpis": []
    },
    {
      "id": "term-read-project",
      "kind": "kynetradb-term",
      "title": "PROJECT",
      "text": "Return only a chosen subset of fields.. maps to SELECT columns. Category: Read. Search terms: project return only a chosen subset of fields. select columns read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "project",
        "return",
        "only",
        "chosen",
        "subset",
        "fields",
        "select",
        "columns"
      ],
      "kpis": []
    },
    {
      "id": "term-read-expand",
      "kind": "kynetradb-term",
      "title": "EXPAND",
      "text": "Resolve related entities inline in one read.. maps to JOIN / embed. Category: Read. Search terms: expand resolve related entities inline in one read. join / embed read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "expand",
        "resolve",
        "related",
        "entities",
        "inline",
        "one",
        "join",
        "embed"
      ],
      "kpis": []
    },
    {
      "id": "term-read-tail",
      "kind": "kynetradb-term",
      "title": "TAIL",
      "text": "Follow the log forward from an offset — the streaming read primitive.. maps to CDC / change feed. Category: Read. Search terms: tail follow the log forward from an offset — the streaming read primitive. cdc / change feed read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "tail",
        "follow",
        "log",
        "forward",
        "offset",
        "streaming",
        "primitive",
        "cdc",
        "change"
      ],
      "kpis": []
    },
    {
      "id": "term-read-replay",
      "kind": "kynetradb-term",
      "title": "REPLAY",
      "text": "Rebuild in-memory state by re-reading the log from the start.. maps to WAL replay. Category: Read. Search terms: replay rebuild in-memory state by re-reading the log from the start. wal replay concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "concept",
        "live",
        "replay",
        "rebuild",
        "in-memory",
        "state",
        "re-reading",
        "log",
        "start",
        "wal"
      ],
      "kpis": []
    },
    {
      "id": "term-read-snapshot",
      "kind": "kynetradb-term",
      "title": "SNAPSHOT",
      "text": "A consistent point-in-time view of the state.. maps to snapshot read. Category: Read. Search terms: snapshot a consistent point-in-time view of the state. snapshot read read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "live",
        "snapshot",
        "consistent",
        "point-in",
        "time",
        "view",
        "state"
      ],
      "kpis": []
    },
    {
      "id": "term-read-peek",
      "kind": "kynetradb-term",
      "title": "PEEK",
      "text": "Read without advancing a cursor or causing side effects.. maps to non-consuming read. Category: Read. Search terms: peek read without advancing a cursor or causing side effects. non-consuming read read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "read",
        "concept",
        "peek",
        "without",
        "advancing",
        "cursor",
        "causing",
        "side",
        "effects",
        "non-consuming"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-search",
      "kind": "kynetradb-term",
      "title": "SEARCH",
      "text": "Full-text BM25 query over indexed text.. maps to full-text search. Category: Search & Rank. Search terms: search full-text bm25 query over indexed text. full-text search read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "read",
        "live",
        "search",
        "full-text",
        "bm25",
        "query",
        "indexed",
        "text"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-near",
      "kind": "kynetradb-term",
      "title": "NEAR",
      "text": "Vector nearest-neighbour search by cosine similarity.. maps to ANN / vector search. Category: Search & Rank. Search terms: near vector nearest-neighbour search by cosine similarity. ann / vector search read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "read",
        "live",
        "near",
        "vector",
        "nearest-neighbour",
        "search",
        "cosine",
        "similarity",
        "ann"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-fuse",
      "kind": "kynetradb-term",
      "title": "FUSE",
      "text": "Combine text and vector results with reciprocal rank fusion.. maps to hybrid search. Category: Search & Rank. Search terms: fuse combine text and vector results with reciprocal rank fusion. hybrid search read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "read",
        "live",
        "fuse",
        "combine",
        "text",
        "vector",
        "results",
        "reciprocal",
        "rank",
        "fusion",
        "hybrid",
        "search"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-rank",
      "kind": "kynetradb-term",
      "title": "RANK",
      "text": "The relevance ordering applied to results.. maps to ORDER BY score. Category: Search & Rank. Search terms: rank the relevance ordering applied to results. order by score read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "read",
        "live",
        "rank",
        "relevance",
        "ordering",
        "applied",
        "results",
        "order",
        "score"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-score",
      "kind": "kynetradb-term",
      "title": "SCORE",
      "text": "The numeric relevance of a single hit.. maps to rank score. Category: Search & Rank. Search terms: score the numeric relevance of a single hit. rank score concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "concept",
        "live",
        "score",
        "numeric",
        "relevance",
        "single",
        "hit",
        "rank"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-recall",
      "kind": "kynetradb-term",
      "title": "RECALL",
      "text": "Fraction of true neighbours an approximate search returns.. maps to recall@k. Category: Search & Rank. Search terms: recall fraction of true neighbours an approximate search returns. recall@k concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "concept",
        "recall",
        "fraction",
        "true",
        "neighbours",
        "approximate",
        "search",
        "returns"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-fold",
      "kind": "kynetradb-term",
      "title": "FOLD",
      "text": "Case and accent normalization applied before indexing.. maps to text normalization. Category: Search & Rank. Search terms: fold case and accent normalization applied before indexing. text normalization concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "concept",
        "live",
        "fold",
        "case",
        "accent",
        "normalization",
        "applied",
        "before",
        "indexing",
        "text"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-token",
      "kind": "kynetradb-term",
      "title": "TOKEN",
      "text": "The unit of indexed text.. maps to term. Category: Search & Rank. Search terms: token the unit of indexed text. term concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "concept",
        "live",
        "token",
        "unit",
        "indexed",
        "text"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-topk",
      "kind": "kynetradb-term",
      "title": "TOPK",
      "text": "The number of results a query asks for.. maps to k / LIMIT. Category: Search & Rank. Search terms: topk the number of results a query asks for. k / limit read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "read",
        "live",
        "topk",
        "number",
        "results",
        "query",
        "asks",
        "limit"
      ],
      "kpis": []
    },
    {
      "id": "term-search-rank-index",
      "kind": "kynetradb-term",
      "title": "INDEX",
      "text": "The derived structure that makes a query shape fast (BM25, HNSW).. maps to index. Category: Search & Rank. Search terms: index the derived structure that makes a query shape fast (bm25, hnsw). index concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "search-&-rank",
        "concept",
        "live",
        "index",
        "derived",
        "structure",
        "that",
        "makes",
        "query",
        "shape",
        "fast",
        "bm25",
        "hnsw"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-warm",
      "kind": "kynetradb-term",
      "title": "WARM",
      "text": "Preload a query result into the edge cache before it is asked for.. maps to cache warm. Category: Cache. Search terms: warm preload a query result into the edge cache before it is asked for. cache warm concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "concept",
        "live",
        "warm",
        "preload",
        "query",
        "result",
        "edge",
        "before",
        "asked"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-pin",
      "kind": "kynetradb-term",
      "title": "PIN",
      "text": "Keep an entry resident, exempt from eviction.. maps to pin. Category: Cache. Search terms: pin keep an entry resident, exempt from eviction. pin concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "concept",
        "pin",
        "keep",
        "entry",
        "resident",
        "exempt",
        "eviction"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-evict",
      "kind": "kynetradb-term",
      "title": "EVICT",
      "text": "Remove an entry to reclaim space.. maps to evict. Category: Cache. Search terms: evict remove an entry to reclaim space. evict concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "concept",
        "evict",
        "remove",
        "entry",
        "reclaim",
        "space"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-purge",
      "kind": "kynetradb-term",
      "title": "PURGE",
      "text": "Invalidate cached entries by tag — fired automatically on mutation.. maps to invalidate. Category: Cache. Search terms: purge invalidate cached entries by tag — fired automatically on mutation. invalidate both",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "both",
        "live",
        "purge",
        "invalidate",
        "cached",
        "entries",
        "tag",
        "fired",
        "automatically",
        "mutation"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-stale",
      "kind": "kynetradb-term",
      "title": "STALE",
      "text": "An entry past its freshness window.. maps to stale. Category: Cache. Search terms: stale an entry past its freshness window. stale concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "concept",
        "live",
        "stale",
        "entry",
        "past",
        "its",
        "freshness",
        "window"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-fresh",
      "kind": "kynetradb-term",
      "title": "FRESH",
      "text": "An entry still within its TTL.. maps to fresh. Category: Cache. Search terms: fresh an entry still within its ttl. fresh concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "concept",
        "live",
        "fresh",
        "entry",
        "still",
        "within",
        "its",
        "ttl"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-hit",
      "kind": "kynetradb-term",
      "title": "HIT",
      "text": "A request served from cache.. maps to cache hit. Category: Cache. Search terms: hit a request served from cache. cache hit read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "read",
        "live",
        "hit",
        "request",
        "served"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-miss",
      "kind": "kynetradb-term",
      "title": "MISS",
      "text": "A request that fell through to origin.. maps to cache miss. Category: Cache. Search terms: miss a request that fell through to origin. cache miss read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "read",
        "live",
        "miss",
        "request",
        "that",
        "fell",
        "through",
        "origin"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-ttl",
      "kind": "kynetradb-term",
      "title": "TTL",
      "text": "How long an entry stays fresh before revalidation.. maps to ttl. Category: Cache. Search terms: ttl how long an entry stays fresh before revalidation. ttl concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "concept",
        "live",
        "ttl",
        "how",
        "long",
        "entry",
        "stays",
        "fresh",
        "before",
        "revalidation"
      ],
      "kpis": []
    },
    {
      "id": "term-cache-revalidate",
      "kind": "kynetradb-term",
      "title": "REVALIDATE",
      "text": "Refresh a stale entry in the background while still serving it.. maps to stale-while-revalidate. Category: Cache. Search terms: revalidate refresh a stale entry in the background while still serving it. stale-while-revalidate concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "cache",
        "concept",
        "live",
        "revalidate",
        "refresh",
        "stale",
        "entry",
        "background",
        "while",
        "still",
        "serving",
        "stale-while"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-fan-out",
      "kind": "kynetradb-term",
      "title": "FAN-OUT",
      "text": "One primary log read by many replicas.. maps to replication. Category: Replicate & Cluster. Search terms: fan-out one primary log read by many replicas. replication concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "concept",
        "live",
        "fan-out",
        "one",
        "primary",
        "log",
        "read",
        "many",
        "replicas",
        "replication"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-primary",
      "kind": "kynetradb-term",
      "title": "PRIMARY",
      "text": "The single node that assigns sequence and accepts writes.. maps to leader. Category: Replicate & Cluster. Search terms: primary the single node that assigns sequence and accepts writes. leader concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "concept",
        "live",
        "primary",
        "single",
        "node",
        "that",
        "assigns",
        "sequence",
        "accepts",
        "writes",
        "leader"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-replica",
      "kind": "kynetradb-term",
      "title": "REPLICA",
      "text": "A read-only node tailing the primary log.. maps to read replica. Category: Replicate & Cluster. Search terms: replica a read-only node tailing the primary log. read replica concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "concept",
        "live",
        "replica",
        "read-only",
        "node",
        "tailing",
        "primary",
        "log",
        "read"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-lag",
      "kind": "kynetradb-term",
      "title": "LAG",
      "text": "How many records a replica trails the primary by.. maps to replication lag. Category: Replicate & Cluster. Search terms: lag how many records a replica trails the primary by. replication lag concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "concept",
        "live",
        "lag",
        "how",
        "many",
        "records",
        "replica",
        "trails",
        "primary",
        "replication"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-promote",
      "kind": "kynetradb-term",
      "title": "PROMOTE",
      "text": "Turn a replica into the primary.. maps to failover promote. Category: Replicate & Cluster. Search terms: promote turn a replica into the primary. failover promote concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "concept",
        "promote",
        "turn",
        "replica",
        "primary",
        "failover"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-proxy",
      "kind": "kynetradb-term",
      "title": "PROXY",
      "text": "A replica forwarding a write to the primary.. maps to write forwarding. Category: Replicate & Cluster. Search terms: proxy a replica forwarding a write to the primary. write forwarding write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "write",
        "live",
        "proxy",
        "replica",
        "forwarding",
        "primary"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-topology",
      "kind": "kynetradb-term",
      "title": "TOPOLOGY",
      "text": "The live map of primary and replicas.. maps to cluster topology. Category: Replicate & Cluster. Search terms: topology the live map of primary and replicas. cluster topology read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "read",
        "live",
        "topology",
        "map",
        "primary",
        "replicas",
        "cluster"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-heartbeat",
      "kind": "kynetradb-term",
      "title": "HEARTBEAT",
      "text": "The periodic liveness signal between nodes.. maps to heartbeat. Category: Replicate & Cluster. Search terms: heartbeat the periodic liveness signal between nodes. heartbeat concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "concept",
        "live",
        "heartbeat",
        "periodic",
        "liveness",
        "signal",
        "between",
        "nodes"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-drift",
      "kind": "kynetradb-term",
      "title": "DRIFT",
      "text": "Divergence between a replica state and the primary.. maps to divergence. Category: Replicate & Cluster. Search terms: drift divergence between a replica state and the primary. divergence concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "concept",
        "drift",
        "divergence",
        "between",
        "replica",
        "state",
        "primary"
      ],
      "kpis": []
    },
    {
      "id": "term-replicate-cluster-region",
      "kind": "kynetradb-term",
      "title": "REGION",
      "text": "The geographic pool a read is routed to at the edge.. maps to regional routing. Category: Replicate & Cluster. Search terms: region the geographic pool a read is routed to at the edge. regional routing read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "replicate-&-cluster",
        "read",
        "live",
        "region",
        "geographic",
        "pool",
        "routed",
        "edge",
        "regional",
        "routing"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-log",
      "kind": "kynetradb-term",
      "title": "LOG",
      "text": "The append-only sequence that is the one source of truth.. maps to WAL. Category: Log & Storage. Search terms: log the append-only sequence that is the one source of truth. wal concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "live",
        "log",
        "append-only",
        "sequence",
        "that",
        "one",
        "source",
        "truth",
        "wal"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-seq",
      "kind": "kynetradb-term",
      "title": "SEQ",
      "text": "The monotonic position of a record in the log.. maps to LSN / offset. Category: Log & Storage. Search terms: seq the monotonic position of a record in the log. lsn / offset concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "live",
        "seq",
        "monotonic",
        "position",
        "record",
        "log",
        "lsn",
        "offset"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-offset",
      "kind": "kynetradb-term",
      "title": "OFFSET",
      "text": "A cursor position within the log.. maps to offset. Category: Log & Storage. Search terms: offset a cursor position within the log. offset concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "live",
        "offset",
        "cursor",
        "position",
        "within",
        "log"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-segment",
      "kind": "kynetradb-term",
      "title": "SEGMENT",
      "text": "A contiguous chunk of the log on disk.. maps to WAL segment. Category: Log & Storage. Search terms: segment a contiguous chunk of the log on disk. wal segment concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "segment",
        "contiguous",
        "chunk",
        "log",
        "disk",
        "wal"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-checkpoint",
      "kind": "kynetradb-term",
      "title": "CHECKPOINT",
      "text": "A periodic durable snapshot that bounds replay time.. maps to checkpoint. Category: Log & Storage. Search terms: checkpoint a periodic durable snapshot that bounds replay time. checkpoint concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "live",
        "checkpoint",
        "periodic",
        "durable",
        "snapshot",
        "that",
        "bounds",
        "replay",
        "time"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-compact",
      "kind": "kynetradb-term",
      "title": "COMPACT",
      "text": "Reclaim space by dropping superseded records.. maps to compaction. Category: Log & Storage. Search terms: compact reclaim space by dropping superseded records. compaction concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "compact",
        "reclaim",
        "space",
        "dropping",
        "superseded",
        "records",
        "compaction"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-tombstone",
      "kind": "kynetradb-term",
      "title": "TOMBSTONE",
      "text": "The log marker for a deleted entity.. maps to tombstone. Category: Log & Storage. Search terms: tombstone the log marker for a deleted entity. tombstone concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "live",
        "tombstone",
        "log",
        "marker",
        "deleted",
        "entity"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-truncate",
      "kind": "kynetradb-term",
      "title": "TRUNCATE",
      "text": "Cut the log back to a sequence.. maps to truncate. Category: Log & Storage. Search terms: truncate cut the log back to a sequence. truncate write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "write",
        "live",
        "truncate",
        "cut",
        "log",
        "back",
        "sequence"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-backend",
      "kind": "kynetradb-term",
      "title": "BACKEND",
      "text": "Where the log physically lives — file, Postgres, or D1.. maps to storage engine. Category: Log & Storage. Search terms: backend where the log physically lives — file, postgres, or d1. storage engine concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "live",
        "backend",
        "where",
        "log",
        "physically",
        "lives",
        "file",
        "postgres",
        "d1",
        "storage",
        "engine"
      ],
      "kpis": []
    },
    {
      "id": "term-log-storage-durable",
      "kind": "kynetradb-term",
      "title": "DURABLE",
      "text": "Written past the point of loss on crash.. maps to fsynced. Category: Log & Storage. Search terms: durable written past the point of loss on crash. fsynced concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "log-&-storage",
        "concept",
        "live",
        "durable",
        "written",
        "past",
        "point",
        "loss",
        "crash",
        "fsynced"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-kind",
      "kind": "kynetradb-term",
      "title": "KIND",
      "text": "The type that partitions entities and enforces isolation.. maps to table / type. Category: Shape & Schema. Search terms: kind the type that partitions entities and enforces isolation. table / type concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "kind",
        "type",
        "that",
        "partitions",
        "entities",
        "enforces",
        "isolation",
        "table"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-entity",
      "kind": "kynetradb-term",
      "title": "ENTITY",
      "text": "One record: id, attrs, and an optional embedding.. maps to row / document. Category: Shape & Schema. Search terms: entity one record: id, attrs, and an optional embedding. row / document concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "entity",
        "one",
        "record",
        "id",
        "attrs",
        "optional",
        "embedding",
        "row",
        "document"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-attrs",
      "kind": "kynetradb-term",
      "title": "ATTRS",
      "text": "The JSON payload of an entity.. maps to columns / fields. Category: Shape & Schema. Search terms: attrs the json payload of an entity. columns / fields concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "attrs",
        "json",
        "payload",
        "entity",
        "columns",
        "fields"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-field",
      "kind": "kynetradb-term",
      "title": "FIELD",
      "text": "A typed attribute within a collection schema.. maps to column. Category: Shape & Schema. Search terms: field a typed attribute within a collection schema. column concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "field",
        "typed",
        "attribute",
        "within",
        "collection",
        "schema",
        "column"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-collection",
      "kind": "kynetradb-term",
      "title": "COLLECTION",
      "text": "A named, schema-bound set of entities.. maps to table. Category: Shape & Schema. Search terms: collection a named, schema-bound set of entities. table concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "collection",
        "named",
        "schema-bound",
        "set",
        "entities",
        "table"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-shape",
      "kind": "kynetradb-term",
      "title": "SHAPE",
      "text": "A collection schema — fields, types, and rules.. maps to schema. Category: Shape & Schema. Search terms: shape a collection schema — fields, types, and rules. schema concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "shape",
        "collection",
        "schema",
        "fields",
        "types",
        "rules"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-rule",
      "kind": "kynetradb-term",
      "title": "RULE",
      "text": "An access predicate on a collection.. maps to RLS policy. Category: Shape & Schema. Search terms: rule an access predicate on a collection. rls policy concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "rule",
        "access",
        "predicate",
        "collection",
        "rls",
        "policy"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-relation",
      "kind": "kynetradb-term",
      "title": "RELATION",
      "text": "A link from one entity to another.. maps to foreign key. Category: Shape & Schema. Search terms: relation a link from one entity to another. foreign key concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "relation",
        "link",
        "one",
        "entity",
        "another",
        "foreign",
        "key"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-geo",
      "kind": "kynetradb-term",
      "title": "GEO",
      "text": "A latitude/longitude point field.. maps to geo point. Category: Shape & Schema. Search terms: geo a latitude/longitude point field. geo point concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "concept",
        "live",
        "geo",
        "latitude",
        "longitude",
        "point",
        "field"
      ],
      "kpis": []
    },
    {
      "id": "term-shape-schema-migrate",
      "kind": "kynetradb-term",
      "title": "MIGRATE",
      "text": "Evolve a collection shape over time.. maps to migration. Category: Shape & Schema. Search terms: migrate evolve a collection shape over time. migration write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "shape-&-schema",
        "write",
        "live",
        "migrate",
        "evolve",
        "collection",
        "shape",
        "time",
        "migration"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-token",
      "kind": "kynetradb-term",
      "title": "TOKEN",
      "text": "A bearer credential that authorizes a caller.. maps to API key. Category: Identity & Access. Search terms: token a bearer credential that authorizes a caller. api key concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "concept",
        "live",
        "token",
        "bearer",
        "credential",
        "that",
        "authorizes",
        "caller",
        "api",
        "key"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-grant",
      "kind": "kynetradb-term",
      "title": "GRANT",
      "text": "Give a role a capability.. maps to GRANT. Category: Identity & Access. Search terms: grant give a role a capability. grant write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "write",
        "live",
        "grant",
        "give",
        "role",
        "capability"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-scope",
      "kind": "kynetradb-term",
      "title": "SCOPE",
      "text": "The boundary a token or role may act within.. maps to scope. Category: Identity & Access. Search terms: scope the boundary a token or role may act within. scope concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "concept",
        "live",
        "scope",
        "boundary",
        "token",
        "role",
        "may",
        "act",
        "within"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-role",
      "kind": "kynetradb-term",
      "title": "ROLE",
      "text": "A named permission set — User, Admin, SuperAdmin.. maps to role. Category: Identity & Access. Search terms: role a named permission set — user, admin, superadmin. role concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "concept",
        "live",
        "role",
        "named",
        "permission",
        "set",
        "user",
        "admin",
        "superadmin"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-claim",
      "kind": "kynetradb-term",
      "title": "CLAIM",
      "text": "An assertion inside a JWT — sub, role, exp.. maps to JWT claim. Category: Identity & Access. Search terms: claim an assertion inside a jwt — sub, role, exp. jwt claim concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "concept",
        "live",
        "claim",
        "assertion",
        "inside",
        "jwt",
        "sub",
        "role",
        "exp"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-rotate",
      "kind": "kynetradb-term",
      "title": "ROTATE",
      "text": "Replace a key while briefly accepting the old one.. maps to key rotation. Category: Identity & Access. Search terms: rotate replace a key while briefly accepting the old one. key rotation both",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "both",
        "live",
        "rotate",
        "replace",
        "key",
        "while",
        "briefly",
        "accepting",
        "old",
        "one",
        "rotation"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-revoke",
      "kind": "kynetradb-term",
      "title": "REVOKE",
      "text": "Invalidate a token or grant.. maps to revoke. Category: Identity & Access. Search terms: revoke invalidate a token or grant. revoke write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "write",
        "live",
        "revoke",
        "invalidate",
        "token",
        "grant"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-anon",
      "kind": "kynetradb-term",
      "title": "ANON",
      "text": "An unauthenticated identity with restricted rights.. maps to anonymous. Category: Identity & Access. Search terms: anon an unauthenticated identity with restricted rights. anonymous concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "concept",
        "live",
        "anon",
        "unauthenticated",
        "identity",
        "restricted",
        "rights",
        "anonymous"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-uid",
      "kind": "kynetradb-term",
      "title": "UID",
      "text": "The authenticated subject id rules evaluate against.. maps to auth.uid(). Category: Identity & Access. Search terms: uid the authenticated subject id rules evaluate against. auth.uid() concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "concept",
        "live",
        "uid",
        "authenticated",
        "subject",
        "id",
        "rules",
        "evaluate",
        "against",
        "auth"
      ],
      "kpis": []
    },
    {
      "id": "term-identity-access-gate",
      "kind": "kynetradb-term",
      "title": "GATE",
      "text": "The auth check a request must pass before it runs.. maps to auth middleware. Category: Identity & Access. Search terms: gate the auth check a request must pass before it runs. auth middleware concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "identity-&-access",
        "concept",
        "live",
        "gate",
        "auth",
        "check",
        "request",
        "must",
        "pass",
        "before",
        "runs",
        "middleware"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-probe",
      "kind": "kynetradb-term",
      "title": "PROBE",
      "text": "A health check that proves a node can actually serve.. maps to health probe. Category: Operations & Health. Search terms: probe a health check that proves a node can actually serve. health probe read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "read",
        "live",
        "probe",
        "health",
        "check",
        "that",
        "proves",
        "node",
        "can",
        "actually",
        "serve"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-breaker",
      "kind": "kynetradb-term",
      "title": "BREAKER",
      "text": "A circuit breaker that fails fast on a downed dependency.. maps to circuit breaker. Category: Operations & Health. Search terms: breaker a circuit breaker that fails fast on a downed dependency. circuit breaker concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "concept",
        "live",
        "breaker",
        "circuit",
        "that",
        "fails",
        "fast",
        "downed",
        "dependency"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-audit",
      "kind": "kynetradb-term",
      "title": "AUDIT",
      "text": "The tamper-evident hash-chained record of every admin mutation.. maps to audit log. Category: Operations & Health. Search terms: audit the tamper-evident hash-chained record of every admin mutation. audit log read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "read",
        "live",
        "audit",
        "tamper-evident",
        "hash-chained",
        "record",
        "every",
        "admin",
        "mutation",
        "log"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-chain",
      "kind": "kynetradb-term",
      "title": "CHAIN",
      "text": "The hash links that make the audit tamper-evident.. maps to hash chain. Category: Operations & Health. Search terms: chain the hash links that make the audit tamper-evident. hash chain concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "concept",
        "live",
        "chain",
        "hash",
        "links",
        "that",
        "make",
        "audit",
        "tamper-evident"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-percentile",
      "kind": "kynetradb-term",
      "title": "PERCENTILE",
      "text": "p50 / p95 / p99 request latency.. maps to latency percentile. Category: Operations & Health. Search terms: percentile p50 / p95 / p99 request latency. latency percentile read",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "read",
        "live",
        "percentile",
        "p50",
        "p95",
        "p99",
        "request",
        "latency"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-ring",
      "kind": "kynetradb-term",
      "title": "RING",
      "text": "The bounded buffer of recent latency samples.. maps to ring buffer. Category: Operations & Health. Search terms: ring the bounded buffer of recent latency samples. ring buffer concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "concept",
        "live",
        "ring",
        "bounded",
        "buffer",
        "recent",
        "latency",
        "samples"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-throttle",
      "kind": "kynetradb-term",
      "title": "THROTTLE",
      "text": "Rate-limit a caller at the edge.. maps to rate limit. Category: Operations & Health. Search terms: throttle rate-limit a caller at the edge. rate limit concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "concept",
        "live",
        "throttle",
        "rate-limit",
        "caller",
        "edge",
        "rate",
        "limit"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-waf",
      "kind": "kynetradb-term",
      "title": "WAF",
      "text": "The edge guard filtering IPs, user-agents, and headers.. maps to WAF. Category: Operations & Health. Search terms: waf the edge guard filtering ips, user-agents, and headers. waf concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "concept",
        "live",
        "waf",
        "edge",
        "guard",
        "filtering",
        "ips",
        "user-agents",
        "headers"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-ready",
      "kind": "kynetradb-term",
      "title": "READY",
      "text": "The state where a node can accept traffic.. maps to readiness. Category: Operations & Health. Search terms: ready the state where a node can accept traffic. readiness concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "concept",
        "live",
        "ready",
        "state",
        "where",
        "node",
        "can",
        "accept",
        "traffic",
        "readiness"
      ],
      "kpis": []
    },
    {
      "id": "term-operations-health-degraded",
      "kind": "kynetradb-term",
      "title": "DEGRADED",
      "text": "Serving, but with a failing check.. maps to degraded. Category: Operations & Health. Search terms: degraded serving, but with a failing check. degraded concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "operations-&-health",
        "concept",
        "live",
        "degraded",
        "serving",
        "but",
        "failing",
        "check"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-bridge",
      "kind": "kynetradb-term",
      "title": "BRIDGE",
      "text": "A serverless worker that speaks the API over a Cloudflare store.. maps to edge adapter. Category: Connect & Edge. Search terms: bridge a serverless worker that speaks the api over a cloudflare store. edge adapter concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "concept",
        "live",
        "bridge",
        "serverless",
        "worker",
        "that",
        "speaks",
        "api",
        "cloudflare",
        "store",
        "edge",
        "adapter"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-edge",
      "kind": "kynetradb-term",
      "title": "EDGE",
      "text": "The Cloudflare POP layer in front of the origin.. maps to edge / CDN. Category: Connect & Edge. Search terms: edge the cloudflare pop layer in front of the origin. edge / cdn concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "concept",
        "live",
        "edge",
        "cloudflare",
        "pop",
        "layer",
        "front",
        "origin",
        "cdn"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-sdk",
      "kind": "kynetradb-term",
      "title": "SDK",
      "text": "The typed client — @kynetra/client.. maps to client library. Category: Connect & Edge. Search terms: sdk the typed client — @kynetra/client. client library both",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "both",
        "live",
        "sdk",
        "typed",
        "client",
        "kynetra",
        "library"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-mcp",
      "kind": "kynetradb-term",
      "title": "MCP",
      "text": "The JSON-RPC tool surface agents connect through.. maps to MCP server. Category: Connect & Edge. Search terms: mcp the json-rpc tool surface agents connect through. mcp server both",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "both",
        "live",
        "mcp",
        "json-rpc",
        "tool",
        "surface",
        "agents",
        "connect",
        "through",
        "server"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-wire",
      "kind": "kynetradb-term",
      "title": "WIRE",
      "text": "The CLI remote protocol to a node.. maps to remote CLI. Category: Connect & Edge. Search terms: wire the cli remote protocol to a node. remote cli both",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "both",
        "live",
        "wire",
        "cli",
        "remote",
        "protocol",
        "node"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-hook",
      "kind": "kynetradb-term",
      "title": "HOOK",
      "text": "An outbound webhook fired when a mutation lands.. maps to webhook. Category: Connect & Edge. Search terms: hook an outbound webhook fired when a mutation lands. webhook concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "concept",
        "live",
        "hook",
        "outbound",
        "webhook",
        "fired",
        "when",
        "mutation",
        "lands"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-sign",
      "kind": "kynetradb-term",
      "title": "SIGN",
      "text": "HMAC-sign a webhook payload so the receiver can verify it.. maps to payload signing. Category: Connect & Edge. Search terms: sign hmac-sign a webhook payload so the receiver can verify it. payload signing concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "concept",
        "live",
        "sign",
        "hmac-sign",
        "webhook",
        "payload",
        "so",
        "receiver",
        "can",
        "verify",
        "signing"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-origin",
      "kind": "kynetradb-term",
      "title": "ORIGIN",
      "text": "The node the edge forwards a request to.. maps to origin server. Category: Connect & Edge. Search terms: origin the node the edge forwards a request to. origin server concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "concept",
        "live",
        "origin",
        "node",
        "edge",
        "forwards",
        "request",
        "server"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-route",
      "kind": "kynetradb-term",
      "title": "ROUTE",
      "text": "The rule mapping a hostname or path to a worker.. maps to route. Category: Connect & Edge. Search terms: route the rule mapping a hostname or path to a worker. route concept",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "concept",
        "live",
        "route",
        "rule",
        "mapping",
        "hostname",
        "path",
        "worker"
      ],
      "kpis": []
    },
    {
      "id": "term-connect-edge-sink",
      "kind": "kynetradb-term",
      "title": "SINK",
      "text": "An outbound destination the log streams to.. maps to CDC sink. Category: Connect & Edge. Search terms: sink an outbound destination the log streams to. cdc sink write",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "connect-&-edge",
        "write",
        "live",
        "sink",
        "outbound",
        "destination",
        "log",
        "streams",
        "cdc"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-signal",
      "kind": "kynetradb-term",
      "title": "SIGNAL",
      "text": "A measured value from route telemetry, a benchmark, a deploy smoke test, or a production probe.. maps to KPI evidence source. Category: Micro-KPI Scale Terms. Search terms: signal measured telemetry value emitted by route benchmark deploy smoke or production probe microkpi metric",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "signal",
        "measured",
        "telemetry",
        "value",
        "emitted",
        "route",
        "benchmark",
        "deploy",
        "smoke",
        "production"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-baseline",
      "kind": "kynetradb-term",
      "title": "BASELINE",
      "text": "The first trusted current value for a KPI, recorded before declaring a target met.. maps to KPI state: baseline. Category: Micro-KPI Scale Terms. Search terms: baseline first trusted current measurement microkpi baseline state road to 1b",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "baseline",
        "first",
        "trusted",
        "current",
        "measurement",
        "microkpi",
        "state",
        "road",
        "1b"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-target",
      "kind": "kynetradb-term",
      "title": "TARGET",
      "text": "The measurable value KynetraDB is trying to reach for a KPI family.. maps to KPI state: target. Category: Micro-KPI Scale Terms. Search terms: target desired measurable value microkpi threshold kdb target",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "target",
        "desired",
        "measurable",
        "value",
        "microkpi",
        "threshold",
        "kdb"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-gate",
      "kind": "kynetradb-term",
      "title": "GATE",
      "text": "A KPI condition that must pass before a release, provider, or roadmap phase is called done.. maps to release gate. Category: Micro-KPI Scale Terms. Search terms: gate release certification condition microkpi must pass before phase ships",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "governance",
        "live",
        "gate",
        "release",
        "certification",
        "condition",
        "microkpi",
        "must",
        "pass",
        "before",
        "phase",
        "ships"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-regression",
      "kind": "kynetradb-term",
      "title": "REGRESSION",
      "text": "A KPI value moving the wrong way against its baseline or release gate.. maps to CI/release block. Category: Micro-KPI Scale Terms. Search terms: regression target got worse build release block kpi trend",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "governance",
        "live",
        "regression",
        "target",
        "got",
        "worse",
        "build",
        "release",
        "block",
        "kpi",
        "trend"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-budget",
      "kind": "kynetradb-term",
      "title": "BUDGET",
      "text": "A numeric limit for latency, error rate, memory, storage overhead, or cost.. maps to latency/error/cost target. Category: Micro-KPI Scale Terms. Search terms: budget numeric limit latency error cost memory microkpi budget p95 p99",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "budget",
        "numeric",
        "limit",
        "latency",
        "error",
        "cost",
        "memory",
        "microkpi",
        "p95"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-burn",
      "kind": "kynetradb-term",
      "title": "BURN",
      "text": "The rate at which a service consumes its SLO or error budget.. maps to KDB-161..170. Category: Micro-KPI Scale Terms. Search terms: burn slo burn rate error budget observability incident kdb-161 kdb-170",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "burn",
        "slo",
        "rate",
        "error",
        "budget",
        "observability",
        "incident",
        "kdb-161",
        "kdb-170"
      ],
      "kpis": [
        "KDB-161",
        "KDB-162",
        "KDB-163",
        "KDB-164",
        "KDB-165",
        "KDB-166",
        "KDB-167",
        "KDB-168",
        "KDB-169",
        "KDB-170"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-tail",
      "kind": "kynetradb-term",
      "title": "TAIL",
      "text": "The p95, p99, and max behavior that decides whether a system feels reliable under load.. maps to route SLO p99. Category: Micro-KPI Scale Terms. Search terms: tail latency p95 p99 max not mean route slo microkpi",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "tail",
        "latency",
        "p95",
        "p99",
        "max",
        "not",
        "mean",
        "route",
        "slo",
        "microkpi"
      ],
      "kpis": []
    },
    {
      "id": "term-micro-kpi-scale-terms-seal-p99",
      "kind": "kynetradb-term",
      "title": "SEAL P99",
      "text": "The p99 durable append time for the Universal Log with fsync enabled.. maps to KDB-001..002. Category: Micro-KPI Scale Terms. Search terms: seal p99 durable wal append fsync latency universal log kdb-001 kdb-002",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "seal",
        "p99",
        "durable",
        "wal",
        "append",
        "fsync",
        "latency",
        "universal",
        "log",
        "kdb-001"
      ],
      "kpis": [
        "KDB-001",
        "KDB-002"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-replay-rate",
      "kind": "kynetradb-term",
      "title": "REPLAY RATE",
      "text": "Records per second applied during boot, restore, or replica catch-up.. maps to KDB-021..030. Category: Micro-KPI Scale Terms. Search terms: replay rate boot records per second checkpoint tail kdb-021 kdb-030",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "replay",
        "rate",
        "boot",
        "records",
        "per",
        "second",
        "checkpoint",
        "tail",
        "kdb-021",
        "kdb-030"
      ],
      "kpis": [
        "KDB-021",
        "KDB-022",
        "KDB-023",
        "KDB-024",
        "KDB-025",
        "KDB-026",
        "KDB-027",
        "KDB-028",
        "KDB-029",
        "KDB-030"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-index-coverage",
      "kind": "kynetradb-term",
      "title": "INDEX COVERAGE",
      "text": "The share of real queries served by scalar, BM25, vector, or hybrid indexes instead of scans.. maps to KDB-041..060. Category: Micro-KPI Scale Terms. Search terms: index coverage json bm25 hnsw query planner indexed query kdb-041 kdb-060",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "index",
        "coverage",
        "json",
        "bm25",
        "hnsw",
        "query",
        "planner",
        "indexed",
        "kdb-041"
      ],
      "kpis": [
        "KDB-041",
        "KDB-042",
        "KDB-043",
        "KDB-044",
        "KDB-045",
        "KDB-046",
        "KDB-047",
        "KDB-048",
        "KDB-049",
        "KDB-050",
        "KDB-051",
        "KDB-052",
        "KDB-053",
        "KDB-054",
        "KDB-055",
        "KDB-056",
        "KDB-057",
        "KDB-058",
        "KDB-059",
        "KDB-060"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-recall",
      "kind": "kynetradb-term",
      "title": "RECALL",
      "text": "The retrieval quality check: whether search and vector results still find the right answers at scale.. maps to KDB-063, KDB-069. Category: Micro-KPI Scale Terms. Search terms: recall vector hnsw hybrid relevance ndcg recall at ten kdb-063 kdb-069",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "recall",
        "vector",
        "hnsw",
        "hybrid",
        "relevance",
        "ndcg",
        "ten",
        "kdb-063",
        "kdb-069"
      ],
      "kpis": [
        "KDB-063",
        "KDB-069"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-lag",
      "kind": "kynetradb-term",
      "title": "LAG",
      "text": "The distance between primary commit progress and what a replica or edge can safely serve.. maps to KDB-131..132. Category: Micro-KPI Scale Terms. Search terms: lag replica log apply distance primary read stale regional read kdb-131 kdb-132",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "lag",
        "replica",
        "log",
        "apply",
        "distance",
        "primary",
        "read",
        "stale",
        "regional"
      ],
      "kpis": [
        "KDB-131",
        "KDB-132"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-purge-span",
      "kind": "kynetradb-term",
      "title": "PURGE SPAN",
      "text": "The time between a mutation and the last unsafe cached response being invalidated.. maps to KDB-136. Category: Micro-KPI Scale Terms. Search terms: purge span cache invalidation edge read cache propagation cloudflare kdb-136",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "metric",
        "live",
        "purge",
        "span",
        "cache",
        "invalidation",
        "edge",
        "read",
        "propagation",
        "cloudflare",
        "kdb-136"
      ],
      "kpis": [
        "KDB-136"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-rpo",
      "kind": "kynetradb-term",
      "title": "RPO",
      "text": "The maximum committed data the system is allowed to lose during disaster recovery.. maps to KDB-150. Category: Micro-KPI Scale Terms. Search terms: rpo recovery point objective data loss backup restore kdb-150",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "resilience",
        "live",
        "rpo",
        "recovery",
        "point",
        "objective",
        "data",
        "loss",
        "backup",
        "restore",
        "kdb-150"
      ],
      "kpis": [
        "KDB-150"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-rto",
      "kind": "kynetradb-term",
      "title": "RTO",
      "text": "The time allowed to restore service after failover, restore-to-new, or regional loss.. maps to KDB-137..138, KDB-144. Category: Micro-KPI Scale Terms. Search terms: rto recovery time objective restore failover recovery kdb-137 kdb-138 kdb-144",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "resilience",
        "live",
        "rto",
        "recovery",
        "time",
        "objective",
        "restore",
        "failover",
        "kdb-137",
        "kdb-138",
        "kdb-144"
      ],
      "kpis": [
        "KDB-137",
        "KDB-138",
        "KDB-144"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-cost-envelope",
      "kind": "kynetradb-term",
      "title": "COST ENVELOPE",
      "text": "The allowed cost range for a workload before KynetraDB loses its stack-compression advantage.. maps to KDB-181..190. Category: Micro-KPI Scale Terms. Search terms: cost envelope workload cost per million reads writes storage cache savings kdb-181 kdb-190",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "business",
        "live",
        "cost",
        "envelope",
        "workload",
        "per",
        "million",
        "reads",
        "writes",
        "storage",
        "cache"
      ],
      "kpis": [
        "KDB-181",
        "KDB-182",
        "KDB-183",
        "KDB-184",
        "KDB-185",
        "KDB-186",
        "KDB-187",
        "KDB-188",
        "KDB-189",
        "KDB-190"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-activation-clock",
      "kind": "kynetradb-term",
      "title": "ACTIVATION CLOCK",
      "text": "The measured time from first contact to first useful database action.. maps to KDB-191..193. Category: Micro-KPI Scale Terms. Search terms: activation clock install first write first search deploy wizard developer experience kdb-191 kdb-193",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "business",
        "live",
        "activation",
        "clock",
        "install",
        "first",
        "write",
        "search",
        "deploy",
        "wizard",
        "developer"
      ],
      "kpis": [
        "KDB-191",
        "KDB-192",
        "KDB-193"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-proof-point",
      "kind": "kynetradb-term",
      "title": "PROOF POINT",
      "text": "A validated customer story showing which services KynetraDB removed from a real stack.. maps to KDB-199. Category: Micro-KPI Scale Terms. Search terms: proof point case study replaced postgres redis elastic pinecone stack compression kdb-199",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "business",
        "concept",
        "proof",
        "point",
        "case",
        "study",
        "replaced",
        "postgres",
        "redis",
        "elastic",
        "pinecone",
        "stack"
      ],
      "kpis": [
        "KDB-199"
      ]
    },
    {
      "id": "term-micro-kpi-scale-terms-moat-delta",
      "kind": "kynetradb-term",
      "title": "MOAT DELTA",
      "text": "The measured advantage over a multi-vendor stack: fewer services, lower cost, faster activation, or higher retention.. maps to KDB-181, KDB-199..200. Category: Micro-KPI Scale Terms. Search terms: moat delta measurable advantage cost retention replacement migration kdb-181 kdb-199 kdb-200",
      "source": "deploy/cloudflare-foundry/dist/index.html",
      "tags": [
        "kynetradb",
        "term",
        "micro-kpi-scale-terms",
        "business",
        "concept",
        "moat",
        "delta",
        "measurable",
        "advantage",
        "cost",
        "retention",
        "replacement",
        "migration",
        "kdb-181",
        "kdb-199"
      ],
      "kpis": [
        "KDB-181",
        "KDB-199",
        "KDB-200"
      ]
    },
    {
      "id": "database-convention-db50-001",
      "kind": "database-convention",
      "title": "DB50-001 TRANSACTION ENVELOPE",
      "text": "Every accepted write MUST be a versioned transaction envelope containing identity, tenant, shard, schema version, mutations, and integrity data; a bare `Put` or `Delete` is not a distributed transaction. Proof: Decode compatibility and atomic replay tests. Family: Mutation and Commit. Gate: KQ-002.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "mutation-and-commit",
        "kq-002",
        "transaction",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-002",
      "kind": "database-convention",
      "title": "DB50-002 ATOMIC MUTATION SET",
      "text": "All mutations in one transaction MUST become visible and durable together or not at all. Proof: Crash injection at every commit boundary. Family: Mutation and Commit. Gate: KQ-002.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "mutation-and-commit",
        "kq-002",
        "atomic",
        "mutation",
        "set"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-003",
      "kind": "database-convention",
      "title": "DB50-003 IDEMPOTENT RETRY",
      "text": "Retrying a request with the same idempotency key MUST return the original outcome without duplicating effects. Proof: Delay, disconnect, duplicate, and replay histories. Family: Mutation and Commit. Gate: KQ-002.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "mutation-and-commit",
        "kq-002",
        "idempotent",
        "retry"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-004",
      "kind": "database-convention",
      "title": "DB50-004 CONDITIONAL WRITE",
      "text": "Every mutable record SHOULD support compare-and-set against an observed version or predicate. Proof: Concurrent lost-update and write-skew tests. Family: Mutation and Commit. Gate: KQ-003.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "mutation-and-commit",
        "kq-003",
        "conditional",
        "write"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-005",
      "kind": "database-convention",
      "title": "DB50-005 COMMIT RECEIPT",
      "text": "A successful write MUST return an immutable transaction ID, commit coordinate, durability level, and session token. Proof: Receipt validation after failover and restore. Family: Mutation and Commit. Gate: KQ-007.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "mutation-and-commit",
        "kq-007",
        "commit",
        "receipt"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-006",
      "kind": "database-convention",
      "title": "DB50-006 STRONG DEFAULT",
      "text": "The default transaction mode MUST be strict serializable; weaker modes require explicit selection. Proof: Linearizability and serializability histories. Family: Isolation and Time. Gate: KQ-003.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "isolation-and-time",
        "kq-003",
        "strong",
        "default"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-007",
      "kind": "database-convention",
      "title": "DB50-007 SNAPSHOT READ",
      "text": "Every read transaction MUST observe one stable committed snapshot. Proof: Concurrent reader and writer anomaly suite. Family: Isolation and Time. Gate: KQ-004.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "isolation-and-time",
        "kq-004",
        "snapshot",
        "read"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-008",
      "kind": "database-convention",
      "title": "DB50-008 MONOTONIC SESSION",
      "text": "A session read MUST NOT return state older than a commit already observed by that session. Proof: Cross-replica session-token tests. Family: Isolation and Time. Gate: KQ-020.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "isolation-and-time",
        "kq-020",
        "monotonic",
        "session"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-009",
      "kind": "database-convention",
      "title": "DB50-009 EXPLICIT STALENESS",
      "text": "Eventual and bounded-staleness reads MUST declare their maximum tolerated lag in time or commit positions. Proof: Stale-read budget enforcement tests. Family: Isolation and Time. Gate: KQ-020.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "isolation-and-time",
        "kq-020",
        "explicit",
        "staleness"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-010",
      "kind": "database-convention",
      "title": "DB50-010 LOGICAL TIME",
      "text": "Ordering MUST use logical or hybrid-logical commit time; wall-clock time alone MUST NOT decide causality. Proof: Clock skew, rollback, and leap tests. Family: Isolation and Time. Gate: KQ-004.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "isolation-and-time",
        "kq-004",
        "logical",
        "time"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-011",
      "kind": "database-convention",
      "title": "DB50-011 INTEGRITY FRAME",
      "text": "Every durable frame MUST be checksummed or authenticated and linked to an expected sequence. Proof: Byte-flip, truncation, reorder, and wrong-key corpus. Family: Durability and Recovery. Gate: KQ-001.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "durability-and-recovery",
        "kq-001",
        "integrity",
        "frame"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-012",
      "kind": "database-convention",
      "title": "DB50-012 ACKNOWLEDGED MEANS QUORUM",
      "text": "In an HA profile, success MUST mean a voting quorum durably accepted the transaction. Proof: Replica-loss and network-partition histories. Family: Durability and Recovery. Gate: KQ-017.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "durability-and-recovery",
        "kq-017",
        "acknowledged",
        "means",
        "quorum"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-013",
      "kind": "database-convention",
      "title": "DB50-013 BOUNDED RECOVERY",
      "text": "Recovery work MUST be bounded by a snapshot plus retained tail, not total database history. Proof: Recovery tests at 10M and 1B commits. Family: Durability and Recovery. Gate: KQ-014.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "durability-and-recovery",
        "kq-014",
        "bounded",
        "recovery"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-014",
      "kind": "database-convention",
      "title": "DB50-014 POINT-IN-TIME RESTORE",
      "text": "A database MUST restore to a named commit coordinate or timestamp with a declared RPO. Proof: Automated restore-to-new drill. Family: Durability and Recovery. Gate: KQ-007.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "durability-and-recovery",
        "kq-007",
        "point-in",
        "time",
        "restore"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-015",
      "kind": "database-convention",
      "title": "DB50-015 RESTORE PROVES BACKUP",
      "text": "A backup MUST NOT be called successful until an independent restore verifies manifests, checksums, sampled records, and index watermarks. Proof: Scheduled cross-region restore drill. Family: Durability and Recovery. Gate: KQ-056.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "durability-and-recovery",
        "kq-056",
        "restore",
        "proves",
        "backup"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-016",
      "kind": "database-convention",
      "title": "DB50-016 ONE ORDER PER SHARD",
      "text": "Each shard MUST have one consensus order for conflicting writes at any instant. Proof: Split-brain and leadership-fencing tests. Family: Distribution and Placement. Gate: KQ-018.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "distribution-and-placement",
        "kq-018",
        "one",
        "order",
        "per",
        "shard"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-017",
      "kind": "database-convention",
      "title": "DB50-017 CONSENSUS MEMBERSHIP",
      "text": "Replica membership changes MUST be committed by the shard consensus protocol. Proof: Joint-membership add, remove, and replace tests. Family: Distribution and Placement. Gate: KQ-017.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "distribution-and-placement",
        "kq-017",
        "consensus",
        "membership"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-018",
      "kind": "database-convention",
      "title": "DB50-018 EPOCH ROUTING",
      "text": "Every partition map MUST carry an epoch; stale routers MUST redirect or refresh without misrouting writes. Proof: Split and move tests with old clients. Family: Distribution and Placement. Gate: KQ-021.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "distribution-and-placement",
        "kq-021",
        "epoch",
        "routing"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-019",
      "kind": "database-convention",
      "title": "DB50-019 ONLINE MOVEMENT",
      "text": "Split, merge, and move operations MUST preserve availability, ordering, and session monotonicity. Proof: Foreground workload during rebalance. Family: Distribution and Placement. Gate: KQ-022.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "distribution-and-placement",
        "kq-022",
        "online",
        "movement"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-020",
      "kind": "database-convention",
      "title": "DB50-020 CELL BOUNDARY",
      "text": "Capacity and failure domains MUST be bounded into cells so one incident cannot exhaust an entire fleet. Proof: Cross-cell quota and fault-isolation drill. Family: Distribution and Placement. Gate: KQ-024.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "distribution-and-placement",
        "kq-024",
        "cell",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-021",
      "kind": "database-convention",
      "title": "DB50-021 INDEX WATERMARK",
      "text": "Every secondary index MUST expose the commit position through which it is complete. Proof: Mutation, restart, and catch-up histories. Family: Index and Query Consistency. Gate: KQ-029.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "index-and-query-consistency",
        "kq-029",
        "index",
        "watermark"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-022",
      "kind": "database-convention",
      "title": "DB50-022 CONSTRAINT SYNCHRONY",
      "text": "Indexes enforcing uniqueness, authorization, or integrity MUST commit synchronously with the transaction. Proof: Differential constraint and crash tests. Family: Index and Query Consistency. Gate: KQ-027.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "index-and-query-consistency",
        "kq-027",
        "constraint",
        "synchrony"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-023",
      "kind": "database-convention",
      "title": "DB50-023 SEARCH CONSISTENCY",
      "text": "Search and vector queries MUST offer explicit consistent, session, and eventual modes. Proof: Query tests against controlled index lag. Family: Index and Query Consistency. Gate: KQ-029.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "index-and-query-consistency",
        "kq-029",
        "search",
        "consistency"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-024",
      "kind": "database-convention",
      "title": "DB50-024 EXPLAIN THE WORK",
      "text": "Every query plan MUST expose route, shards, indexes, fan-out, consistency, estimates, and observed cost. Proof: Stable `EXPLAIN` contract tests. Family: Index and Query Consistency. Gate: KQ-027.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "index-and-query-consistency",
        "kq-027",
        "explain",
        "work"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-025",
      "kind": "database-convention",
      "title": "DB50-025 BOUNDED FAN-OUT",
      "text": "A request MUST declare or inherit a shard fan-out budget; unbounded scatter-gather MUST be rejected. Proof: Hotspot and adversarial query tests. Family: Index and Query Consistency. Gate: KQ-021.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "index-and-query-consistency",
        "kq-021",
        "bounded",
        "fan-out"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-026",
      "kind": "database-convention",
      "title": "DB50-026 ONE COMMIT STREAM",
      "text": "Documents, text postings, vectors, realtime, and change data MUST derive from the same committed transaction stream. Proof: Cross-personality digest and replay tests. Family: Search, Vector, and AI Data. Gate: KQ-005.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "search,-vector,-and-ai-data",
        "kq-005",
        "one",
        "commit",
        "stream"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-027",
      "kind": "database-convention",
      "title": "DB50-027 VECTOR SCHEMA",
      "text": "Every vector field MUST declare dimension, metric, numeric encoding, model identity, and compatibility policy. Proof: Invalid-dimension and model-change tests. Family: Search, Vector, and AI Data. Gate: KQ-030.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "search,-vector,-and-ai-data",
        "kq-030",
        "vector",
        "schema"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-028",
      "kind": "database-convention",
      "title": "DB50-028 QUALITY IS A GATE",
      "text": "Recall, NDCG, freshness, latency, and resource cost MUST gate search and vector releases together. Proof: Versioned golden-corpus benchmark. Family: Search, Vector, and AI Data. Gate: KQ-028.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "search,-vector,-and-ai-data",
        "kq-028",
        "quality",
        "gate"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-029",
      "kind": "database-convention",
      "title": "DB50-029 INCREMENTAL INDEX LIFE",
      "text": "Search and vector indexes MUST support insert, update, delete, snapshot, merge, rebuild, and rollback without hidden stale state. Proof: Continuous mutation and recovery test. Family: Search, Vector, and AI Data. Gate: KQ-030.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "search,-vector,-and-ai-data",
        "kq-030",
        "incremental",
        "index",
        "life"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-030",
      "kind": "database-convention",
      "title": "DB50-030 GENERATED-DATA PROVENANCE",
      "text": "Embeddings, summaries, and model-generated fields MUST retain model, input digest, policy, and generation lineage. Proof: Provenance round-trip and regeneration tests. Family: Search, Vector, and AI Data. Gate: KQ-040.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "search,-vector,-and-ai-data",
        "kq-040",
        "generated-data",
        "provenance"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-031",
      "kind": "database-convention",
      "title": "DB50-031 TENANT IN EVERY ADDRESS",
      "text": "Tenant identity MUST be part of every key, cursor, cache key, file path, event, snapshot, and backup object. Proof: Cross-tenant adversarial matrix. Family: Security and Tenancy. Gate: KQ-041.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "security-and-tenancy",
        "kq-041",
        "tenant",
        "every",
        "address"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-032",
      "kind": "database-convention",
      "title": "DB50-032 DENY BY DEFAULT",
      "text": "Missing identity, policy, scope, or routing context MUST deny access rather than fall back to a global namespace. Proof: Missing-context and confused-deputy tests. Family: Security and Tenancy. Gate: KQ-043.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "security-and-tenancy",
        "kq-043",
        "deny",
        "default"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-033",
      "kind": "database-convention",
      "title": "DB50-033 CAPABILITY CREDENTIAL",
      "text": "Credentials MUST grant the minimum named capabilities, resources, regions, and duration required. Proof: Privilege-escalation and expiry tests. Family: Security and Tenancy. Gate: KQ-042.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "security-and-tenancy",
        "kq-042",
        "capability",
        "credential"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-034",
      "kind": "database-convention",
      "title": "DB50-034 ROTATION WITHOUT OUTAGE",
      "text": "Data, node, API, and backup keys MUST rotate without downtime or permanent dual-key acceptance. Proof: Live rotation, restart, and restore drill. Family: Security and Tenancy. Gate: KQ-044.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "security-and-tenancy",
        "kq-044",
        "rotation",
        "without",
        "outage"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-035",
      "kind": "database-convention",
      "title": "DB50-035 TAMPER-EVIDENT AUDIT",
      "text": "Administrative and policy-changing actions MUST enter a verifiable append-only audit chain. Proof: Gap, reorder, deletion, and export verification. Family: Security and Tenancy. Gate: KQ-047.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "security-and-tenancy",
        "kq-047",
        "tamper-evident",
        "audit"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-036",
      "kind": "database-convention",
      "title": "DB50-036 VERSION EVERY BOUNDARY",
      "text": "Records, protocols, cursors, snapshots, plugins, and backups MUST carry explicit format versions. Proof: N-1, N, and N+1 compatibility matrix. Family: Interoperability and Evolution. Gate: KQ-040.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "interoperability-and-evolution",
        "kq-040",
        "version",
        "every",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-037",
      "kind": "database-convention",
      "title": "DB50-037 ADD BEFORE BREAK",
      "text": "Public interfaces SHOULD evolve additively; removals require telemetry, deprecation, migration, and a defined sunset. Proof: Multi-release contract tests. Family: Interoperability and Evolution. Gate: KQ-033.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "interoperability-and-evolution",
        "kq-033",
        "add",
        "before",
        "break"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-038",
      "kind": "database-convention",
      "title": "DB50-038 PORTABLE CHANGE STREAM",
      "text": "Change events MUST use a documented, resumable, ordered envelope independent of one cloud transport. Proof: Disconnect, resume, duplicate, and retention tests. Family: Interoperability and Evolution. Gate: KQ-036.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "interoperability-and-evolution",
        "kq-036",
        "portable",
        "change",
        "stream"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-039",
      "kind": "database-convention",
      "title": "DB50-039 LOSSLESS ROUND TRIP",
      "text": "Import and export MUST preserve identity, value, schema, ordering metadata, and checksums or report every loss. Proof: Export, import, and digest comparison. Family: Interoperability and Evolution. Gate: KQ-037.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "interoperability-and-evolution",
        "kq-037",
        "lossless",
        "round",
        "trip"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-040",
      "kind": "database-convention",
      "title": "DB50-040 PROVIDER-NEUTRAL KERNEL",
      "text": "Cloud credentials, billing, regions, and service quirks MUST NOT enter the storage or transaction kernel. Proof: Dependency-boundary and provider conformance checks. Family: Interoperability and Evolution. Gate: KQ-059.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "interoperability-and-evolution",
        "kq-059",
        "provider-neutral",
        "kernel"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-041",
      "kind": "database-convention",
      "title": "DB50-041 TAILS BEFORE AVERAGES",
      "text": "SLOs MUST include p95 and p99 latency, error rate, saturation, and staleness; averages alone are insufficient. Proof: Metric contract and burn-rate simulation. Family: Operations and Economics. Gate: KQ-052.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "operations-and-economics",
        "kq-052",
        "tails",
        "before",
        "averages"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-042",
      "kind": "database-convention",
      "title": "DB50-042 BACKPRESSURE BEFORE COLLAPSE",
      "text": "Overload MUST queue, throttle, shed, or degrade by policy while memory and recovery remain bounded. Proof: Load-to-saturation and recovery test. Family: Operations and Economics. Gate: KQ-016.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "operations-and-economics",
        "kq-016",
        "backpressure",
        "before",
        "collapse"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-043",
      "kind": "database-convention",
      "title": "DB50-043 COST IS A QUERY RESULT",
      "text": "Every workload SHOULD expose CPU, memory, storage, replication, egress, and monetary cost per useful operation. Proof: Reproducible cost benchmark. Family: Operations and Economics. Gate: KQ-061.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "operations-and-economics",
        "kq-061",
        "cost",
        "query",
        "result"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-044",
      "kind": "database-convention",
      "title": "DB50-044 ONLINE REVERSIBLE UPGRADE",
      "text": "Rolling upgrades MUST preserve service and data compatibility and MUST support a tested rollback point. Proof: Mixed-version upgrade and rollback matrix. Family: Operations and Economics. Gate: KQ-053.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "operations-and-economics",
        "kq-053",
        "online",
        "reversible",
        "upgrade"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-045",
      "kind": "database-convention",
      "title": "DB50-045 PROFILE REQUIRES CERTIFICATION",
      "text": "A deployment profile MUST pass the same lifecycle test on every advertised provider before being called supported. Proof: Create, write, read, failover, backup, restore, destroy artifact. Family: Operations and Economics. Gate: KQ-059.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "operations-and-economics",
        "kq-059",
        "profile",
        "requires",
        "certification"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-046",
      "kind": "database-convention",
      "title": "DB50-046 MACHINE-READABLE CLAIM",
      "text": "Every capability claim MUST have a machine-readable status, owner, evidence link, and expiry date. Proof: Automated claim inventory. Family: Governance, Agents, and Exit. Gate: KQ-064.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "governance,-agents,-and-exit",
        "kq-064",
        "machine-readable",
        "claim"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-047",
      "kind": "database-convention",
      "title": "DB50-047 EVIDENCE BEFORE MARKETING",
      "text": "Performance, scale, security, and availability claims MUST be reproducible by the released artifact. Proof: Release claim-to-artifact check. Family: Governance, Agents, and Exit. Gate: KQ-064.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "governance,-agents,-and-exit",
        "kq-064",
        "evidence",
        "before",
        "marketing"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-048",
      "kind": "database-convention",
      "title": "DB50-048 AGENT AUTHORITY IS EXPLICIT",
      "text": "Destructive, expensive, or cross-tenant agent actions MUST require scoped authority, approval policy, and audit. Proof: Agent escalation and replay tests. Family: Governance, Agents, and Exit. Gate: KQ-043.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "governance,-agents,-and-exit",
        "kq-043",
        "agent",
        "authority",
        "explicit"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-049",
      "kind": "database-convention",
      "title": "DB50-049 DETERMINISTIC FORENSICS",
      "text": "An operator MUST be able to reconstruct why a transaction, policy, query plan, or agent action occurred. Proof: Incident replay from immutable evidence. Family: Governance, Agents, and Exit. Gate: KQ-051.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "governance,-agents,-and-exit",
        "kq-051",
        "deterministic",
        "forensics"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-convention-db50-050",
      "kind": "database-convention",
      "title": "DB50-050 EXIT IS A FEATURE",
      "text": "Users MUST be able to export data, schema, change history, and backup manifests in documented formats without provider permission. Proof: Clean-room migration and restore test. Family: Governance, Agents, and Exit. Gate: KQ-037.",
      "source": "docs/scale/database-2050-conventions.md",
      "tags": [
        "database-2050",
        "convention",
        "governance,-agents,-and-exit",
        "kq-037",
        "exit",
        "feature"
      ],
      "kpis": [],
      "anchor": "database-2050-conventions"
    },
    {
      "id": "database-performance-kpf-001",
      "kind": "database-performance-term",
      "title": "KPF-001 HOTSET RESIDENCY",
      "text": "Keep the access-weighted working set in a bounded memory tier instead of treating every cached byte equally. Speed gate: Warm read p99 MUST be at most 20% of the uncached baseline with a cache hit ratio of at least 99%. Family: Data Path and Memory. KPI links: KDB-014, KDB-183, KDB-188.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "data-path-and-memory",
        "hotset",
        "residency"
      ],
      "kpis": [
        "KDB-014",
        "KDB-183",
        "KDB-188"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-002",
      "kind": "database-performance-term",
      "title": "KPF-002 SCAN-RESISTANT ADMISSION",
      "text": "Admit an item only when its expected reuse is greater than the item it would evict, protecting hot data from one-pass scans. Speed gate: A full-dataset scan MUST reduce the pre-scan hotset hit ratio by no more than 1 percentage point. Family: Data Path and Memory. KPI links: KDB-014, KDB-135, KDB-188.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "data-path-and-memory",
        "scan-resistant",
        "admission"
      ],
      "kpis": [
        "KDB-014",
        "KDB-135",
        "KDB-188"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-003",
      "kind": "database-performance-term",
      "title": "KPF-003 BLOOM-GATED MISS",
      "text": "Use a probabilistic membership gate to reject absent keys before opening an index or data block. Speed gate: Negative lookups MUST average no more than 0.05 data-block reads with a false-positive rate at or below 1%. Family: Data Path and Memory. KPI links: KDB-014, KDB-031.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "data-path-and-memory",
        "bloom-gated",
        "miss"
      ],
      "kpis": [
        "KDB-014",
        "KDB-031"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-004",
      "kind": "database-performance-term",
      "title": "KPF-004 PREFIX-COMPACT KEYSPACE",
      "text": "Encode shared tenant, collection, and key prefixes once per block while preserving ordered comparison. Speed gate: Stored and read key bytes MUST be at most 25% of the flat-key baseline with identical ordering results. Family: Data Path and Memory. KPI links: KDB-024, KDB-044, KDB-185.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "data-path-and-memory",
        "prefix-compact",
        "keyspace"
      ],
      "kpis": [
        "KDB-024",
        "KDB-044",
        "KDB-185"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-005",
      "kind": "database-performance-term",
      "title": "KPF-005 ZERO-COPY FRAME PATH",
      "text": "Carry record payloads through validated buffer views and transfer ownership instead of repeatedly allocating and copying. Speed gate: Ingress through durable-frame encoding MUST perform no more than one full-payload copy and MUST meet the 1 MB write p99 gate. Family: Data Path and Memory. KPI links: KDB-007, KDB-019, KDB-053.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "data-path-and-memory",
        "zero-copy",
        "frame",
        "path"
      ],
      "kpis": [
        "KDB-007",
        "KDB-019",
        "KDB-053"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-006",
      "kind": "database-performance-term",
      "title": "KPF-006 DEADLINE GROUP COMMIT",
      "text": "Coalesce independent commits into one durability operation without exceeding each caller's declared latency deadline. Speed gate: Sustained throughput MUST be at least 10x the one-transaction-per-fsync baseline while durable append p99 remains within its gate. Family: Commit and Concurrency. KPI links: KDB-002, KDB-003, KDB-012.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "commit-and-concurrency",
        "deadline",
        "group",
        "commit"
      ],
      "kpis": [
        "KDB-002",
        "KDB-003",
        "KDB-012"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-007",
      "kind": "database-performance-term",
      "title": "KPF-007 CONFLICT-LANE SHARDING",
      "text": "Route disjoint write conflict domains to independent lock and log lanes while retaining one order inside each domain. Speed gate: Four disjoint lanes MUST deliver at least 3.2x single-lane throughput without worsening write p99 by more than 20%. Family: Commit and Concurrency. KPI links: KDB-003, KDB-012, KDB-018.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "commit-and-concurrency",
        "conflict-lane",
        "sharding"
      ],
      "kpis": [
        "KDB-003",
        "KDB-012",
        "KDB-018"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-008",
      "kind": "database-performance-term",
      "title": "KPF-008 OVERLAPPED COMMIT PIPELINE",
      "text": "Overlap validation, encoding, replication, durability, and index preparation while preserving atomic visibility. Speed gate: The overlapped path MUST deliver at least 2.5x the serial-stage baseline with identical crash and visibility results. Family: Commit and Concurrency. KPI links: KDB-003, KDB-005, KDB-012, KDB-017.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "commit-and-concurrency",
        "overlapped",
        "commit",
        "pipeline"
      ],
      "kpis": [
        "KDB-003",
        "KDB-005",
        "KDB-012",
        "KDB-017"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-009",
      "kind": "database-performance-term",
      "title": "KPF-009 RETRY RECEIPT MEMO",
      "text": "Return the immutable prior receipt for a repeated idempotency key without executing the mutation again. Speed gate: A duplicate retry MUST consume at most 10% of the original request CPU and MUST produce no additional log record. Family: Commit and Concurrency. KPI links: KDB-011, KDB-012, KDB-017.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "commit-and-concurrency",
        "retry",
        "receipt",
        "memo"
      ],
      "kpis": [
        "KDB-011",
        "KDB-012",
        "KDB-017"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-010",
      "kind": "database-performance-term",
      "title": "KPF-010 SNAPSHOT COALESCING",
      "text": "Let compatible reads share an immutable snapshot handle, validation result, and coordinated readahead window. Speed gate: At least 80% of compatible concurrent reads MUST reuse snapshot setup and reduce setup CPU per read by at least 80%. Family: Commit and Concurrency. KPI links: KDB-013, KDB-014, KDB-024.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "commit-and-concurrency",
        "snapshot",
        "coalescing"
      ],
      "kpis": [
        "KDB-013",
        "KDB-014",
        "KDB-024"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-011",
      "kind": "database-performance-term",
      "title": "KPF-011 PLAN SHAPE CACHE",
      "text": "Cache a normalized query plan by query shape, schema epoch, index epoch, consistency mode, and tenant policy epoch. Speed gate: Eligible workloads MUST reach at least 95% plan-cache hits with planning below 5% of total query latency. Family: Query and Index Execution. KPI links: KDB-035, KDB-045, KDB-046.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "query-and-index-execution",
        "plan",
        "shape",
        "cache"
      ],
      "kpis": [
        "KDB-035",
        "KDB-045",
        "KDB-046"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-012",
      "kind": "database-performance-term",
      "title": "KPF-012 PROVEN PARTITION PRUNING",
      "text": "Produce an auditable proof that excluded shards cannot contain a matching row before dispatch. Speed gate: Selective benchmarks MUST scan only required shards and perform at least 10x less shard work than full fan-out. Family: Query and Index Execution. KPI links: KDB-035, KDB-101, KDB-134.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "query-and-index-execution",
        "proven",
        "partition",
        "pruning"
      ],
      "kpis": [
        "KDB-035",
        "KDB-101",
        "KDB-134"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-013",
      "kind": "database-performance-term",
      "title": "KPF-013 INCREMENTAL VIEW PATH",
      "text": "Maintain expensive projections and aggregates from the commit stream instead of recomputing them on every read. Speed gate: Materialized reads MUST run in at most 10% of full-recompute p95 while staying inside the declared freshness budget. Family: Query and Index Execution. KPI links: KDB-017, KDB-055, KDB-072.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "query-and-index-execution",
        "incremental",
        "view",
        "path"
      ],
      "kpis": [
        "KDB-017",
        "KDB-055",
        "KDB-072"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-014",
      "kind": "database-performance-term",
      "title": "KPF-014 DELTA INDEX MERGE",
      "text": "Apply mutations to small ordered deltas and merge them incrementally without blocking reads or rebuilding the full index. Speed gate: Incremental maintenance MUST preserve the index update p99 gate and keep merge write amplification at or below 1.4x. Family: Query and Index Execution. KPI links: KDB-008, KDB-042, KDB-043, KDB-055.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "query-and-index-execution",
        "delta",
        "index",
        "merge"
      ],
      "kpis": [
        "KDB-008",
        "KDB-042",
        "KDB-043",
        "KDB-055"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-015",
      "kind": "database-performance-term",
      "title": "KPF-015 WORKLOAD-SHAPED COMPACTION",
      "text": "Schedule compaction by hotness, tombstone density, overlap debt, and foreground latency budget. Speed gate: During steady compaction, foreground p99 MUST stay within 1.2x the no-compaction baseline and write amplification at or below 1.4x. Family: Query and Index Execution. KPI links: KDB-006, KDB-008, KDB-012.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "query-and-index-execution",
        "workload-shaped",
        "compaction"
      ],
      "kpis": [
        "KDB-006",
        "KDB-008",
        "KDB-012"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-016",
      "kind": "database-performance-term",
      "title": "KPF-016 BLOCK MAX WAND EXIT",
      "text": "Use Block Max WAND score bounds to skip posting blocks that cannot enter the current top-k result set. Speed gate: Sparse BM25 workloads MUST reduce scored candidates by at least 80% while preserving exact top-k results. Family: Search, Vector, and Distributed Tails. KPI links: KDB-051, KDB-052, KDB-056.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "search,-vector,-and-distributed-tails",
        "block",
        "max",
        "wand",
        "exit"
      ],
      "kpis": [
        "KDB-051",
        "KDB-052",
        "KDB-056"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-017",
      "kind": "database-performance-term",
      "title": "KPF-017 QUANTIZED RETRIEVAL CASCADE",
      "text": "Retrieve candidates from compressed vectors, then rerank the short list with full-precision vectors. Speed gate: First-stage vector memory MUST be at most 35% of raw vectors while recall remains at least 0.95 and p99 stays within 8 ms. Family: Search, Vector, and Distributed Tails. KPI links: KDB-062, KDB-063, KDB-067.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "search,-vector,-and-distributed-tails",
        "quantized",
        "retrieval",
        "cascade"
      ],
      "kpis": [
        "KDB-062",
        "KDB-063",
        "KDB-067"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-018",
      "kind": "database-performance-term",
      "title": "KPF-018 CONFIDENCE STOP RULE",
      "text": "Stop retrieval when a proven score bound shows that more work cannot materially change the accepted result. Speed gate: The engine MUST inspect at most 25% of baseline candidates with NDCG@10 loss no greater than 0.01. Family: Search, Vector, and Distributed Tails. KPI links: KDB-056, KDB-060, KDB-063, KDB-069.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "search,-vector,-and-distributed-tails",
        "confidence",
        "stop",
        "rule"
      ],
      "kpis": [
        "KDB-056",
        "KDB-060",
        "KDB-063",
        "KDB-069"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-019",
      "kind": "database-performance-term",
      "title": "KPF-019 TAIL-HEDGED LOCAL READ",
      "text": "After a percentile-derived delay, issue one cancellable duplicate read to another eligible replica. Speed gate: Read p99 MUST be at most 50% of the unhedged baseline with no more than 5% extra requests and no consistency downgrade. Family: Search, Vector, and Distributed Tails. KPI links: KDB-014, KDB-133, KDB-134.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "search,-vector,-and-distributed-tails",
        "tail-hedged",
        "local",
        "read"
      ],
      "kpis": [
        "KDB-014",
        "KDB-133",
        "KDB-134"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "database-performance-kpf-020",
      "kind": "database-performance-term",
      "title": "KPF-020 SATURATION GOVERNOR",
      "text": "Adapt concurrency, admission, and queue budgets before CPU, memory, or I/O saturation creates a latency collapse. Speed gate: The engine MUST sustain at least 85% of peak useful throughput with bounded p99 queues and zero out-of-memory failures. Family: Search, Vector, and Distributed Tails. KPI links: KDB-020, KDB-184.",
      "source": "docs/scale/database-performance-terms.md",
      "tags": [
        "database-performance",
        "10x",
        "search,-vector,-and-distributed-tails",
        "saturation",
        "governor"
      ],
      "kpis": [
        "KDB-020",
        "KDB-184"
      ],
      "anchor": "database-performance-terms"
    },
    {
      "id": "retrieval-standard-krs-001",
      "kind": "retrieval-standard",
      "title": "KRS-001 BM25F FIELD PROFILE",
      "text": "Declare analyzer, per-field weights and length normalization, `k1`, missing-field behavior, score formula, and deterministic tie break. Required proof: Field perturbation tests plus NDCG@10 and latency against BM25 on the same structured corpus. KPI links: KDB-051, KDB-052, KDB-054, KDB-059, KDB-060. Primary reference: R1.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r1",
        "bm25f",
        "field",
        "profile"
      ],
      "kpis": [
        "KDB-051",
        "KDB-052",
        "KDB-054",
        "KDB-059",
        "KDB-060"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-002",
      "kind": "retrieval-standard",
      "title": "KRS-002 DIRICHLET QUERY LIKELIHOOD",
      "text": "Declare analyzer, collection language model, smoothing `mu`, out-of-vocabulary handling, log-score formula, document length, and tie break. Required proof: Parameter sweep with frozen qrels, score fixtures, NDCG@10, and latency on the same corpus. KPI links: KDB-051, KDB-052, KDB-054, KDB-059, KDB-060. Primary reference: R2.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r2",
        "dirichlet",
        "query",
        "likelihood"
      ],
      "kpis": [
        "KDB-051",
        "KDB-052",
        "KDB-054",
        "KDB-059",
        "KDB-060"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-003",
      "kind": "retrieval-standard",
      "title": "KRS-003 SPLADE SPARSE PROFILE",
      "text": "Declare model and tokenizer digests, pooling, sparsity regularizer, expansion threshold, posting quantization, vocabulary, and maximum active terms. Required proof: NDCG@10, postings expansion, p99, index size, and mutation-freshness results versus BM25. KPI links: KDB-051, KDB-052, KDB-053, KDB-055, KDB-060. Primary reference: R3.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r3",
        "splade",
        "sparse",
        "profile"
      ],
      "kpis": [
        "KDB-051",
        "KDB-052",
        "KDB-053",
        "KDB-055",
        "KDB-060"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-004",
      "kind": "retrieval-standard",
      "title": "KRS-004 HNSW GRAPH PROFILE",
      "text": "Declare metric, vector dimension and encoding, `M`, `efConstruction`, `efSearch`, seed policy, insertion, deletion, filtering, snapshot, and tie semantics. Required proof: Recall@10 versus brute force with p99, build rate, memory overhead, snapshot load, and update visibility. KPI links: KDB-061, KDB-062, KDB-063, KDB-064, KDB-065, KDB-066, KDB-067. Primary reference: R4.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r4",
        "hnsw",
        "graph",
        "profile"
      ],
      "kpis": [
        "KDB-061",
        "KDB-062",
        "KDB-063",
        "KDB-064",
        "KDB-065",
        "KDB-066",
        "KDB-067"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-005",
      "kind": "retrieval-standard",
      "title": "KRS-005 DISKANN SSD PROFILE",
      "text": "Declare metric, dimension, graph degree, build and search list sizes, beam width, compressed-vector bytes, cache budget, SSD model, and deletion policy. Required proof: Recall, p99, QPS, memory, bytes read per query, build time, restart, and delete-rebuild evidence at declared scale. KPI links: KDB-061, KDB-062, KDB-063, KDB-064, KDB-065, KDB-067. Primary reference: R5.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r5",
        "diskann",
        "ssd",
        "profile"
      ],
      "kpis": [
        "KDB-061",
        "KDB-062",
        "KDB-063",
        "KDB-064",
        "KDB-065",
        "KDB-067"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-006",
      "kind": "retrieval-standard",
      "title": "KRS-006 IVF-PQ COMPRESSED PROFILE",
      "text": "Declare metric, coarse centroids, probes, subquantizers, bits per code, training-set digest, residual mode, rerank depth, and empty-list behavior. Required proof: Recall-latency-memory frontier versus exact search, including build reproducibility and update visibility. KPI links: KDB-061, KDB-062, KDB-063, KDB-064, KDB-066, KDB-067. Primary reference: R6.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r6",
        "ivf-pq",
        "compressed",
        "profile"
      ],
      "kpis": [
        "KDB-061",
        "KDB-062",
        "KDB-063",
        "KDB-064",
        "KDB-066",
        "KDB-067"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-007",
      "kind": "retrieval-standard",
      "title": "KRS-007 COLBERT LATE INTERACTION",
      "text": "Declare model and tokenizer digests, token dimension, query and document limits, MaxSim formula, compression, candidate depth, and truncation behavior. Required proof: NDCG@10, p99, FLOPs or CPU time, index bytes, and deterministic fixtures versus the declared first-stage retriever. KPI links: KDB-060, KDB-062, KDB-067, KDB-068, KDB-069. Primary reference: R7.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r7",
        "colbert",
        "late",
        "interaction"
      ],
      "kpis": [
        "KDB-060",
        "KDB-062",
        "KDB-067",
        "KDB-068",
        "KDB-069"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-008",
      "kind": "retrieval-standard",
      "title": "KRS-008 RECIPROCAL RANK FUSION",
      "text": "Declare ordered input rankers, per-ranker depth, rank constant, optional weights, duplicate handling, missing-list behavior, and tie break. Required proof: Exact score fixtures, permutation and missing-list tests, NDCG@10, and measured fusion overhead. KPI links: KDB-059, KDB-060, KDB-068, KDB-069. Primary reference: R8.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r8",
        "reciprocal",
        "rank",
        "fusion"
      ],
      "kpis": [
        "KDB-059",
        "KDB-060",
        "KDB-068",
        "KDB-069"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-009",
      "kind": "retrieval-standard",
      "title": "KRS-009 LAMBDAMART RERANKER",
      "text": "Declare feature schema and normalization, training and validation digests, judgment provenance, objective, tree parameters, random seed, missing-feature behavior, and model digest. Required proof: Leakage-safe NDCG uplift, p99, feature-cost budget, deterministic scoring fixtures, and drift report. KPI links: KDB-059, KDB-060, KDB-068, KDB-069. Primary reference: R9.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r9",
        "lambdamart",
        "reranker"
      ],
      "kpis": [
        "KDB-059",
        "KDB-060",
        "KDB-068",
        "KDB-069"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "retrieval-standard-krs-010",
      "kind": "retrieval-standard",
      "title": "KRS-010 MAXIMAL MARGINAL RELEVANCE",
      "text": "Declare relevance score, pairwise similarity, normalization, diversity weight, candidate depth, duplicate policy, selection order, and tie break. Required proof: NDCG plus a declared diversity metric across the diversity-weight frontier, with deterministic selection fixtures and p99. KPI links: KDB-059, KDB-060, KDB-068, KDB-069. Primary reference: R10.",
      "source": "docs/scale/retrieval-standard-profiles.md",
      "tags": [
        "retrieval-standard",
        "conformance",
        "r10",
        "maximal",
        "marginal",
        "relevance"
      ],
      "kpis": [
        "KDB-059",
        "KDB-060",
        "KDB-068",
        "KDB-069"
      ],
      "anchor": "retrieval-standard-profiles"
    },
    {
      "id": "micro-kpi-kdb-001",
      "kind": "micro-kpi",
      "title": "KDB-001 Durable WAL append latency p50 with fsync on",
      "text": "Durable WAL append latency p50 with fsync on. Target: <= 0.8 ms. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "durable",
        "wal",
        "append",
        "latency",
        "p50",
        "fsync"
      ],
      "kpis": [
        "KDB-001"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-002",
      "kind": "micro-kpi",
      "title": "KDB-002 Durable WAL append latency p99 with fsync on",
      "text": "Durable WAL append latency p99 with fsync on. Target: <= 1.5 ms. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "durable",
        "wal",
        "append",
        "latency",
        "p99",
        "fsync"
      ],
      "kpis": [
        "KDB-002"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-003",
      "kind": "micro-kpi",
      "title": "KDB-003 Batched WAL append throughput on NVMe",
      "text": "Batched WAL append throughput on NVMe. Target: >= 50k records/sec. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "batched",
        "wal",
        "append",
        "throughput",
        "nvme"
      ],
      "kpis": [
        "KDB-003"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-004",
      "kind": "micro-kpi",
      "title": "KDB-004 Torn-record recovery correctness",
      "text": "Torn-record recovery correctness. Target: 100% valid prefix recovery. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "torn-record",
        "recovery",
        "correctness"
      ],
      "kpis": [
        "KDB-004"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-005",
      "kind": "micro-kpi",
      "title": "KDB-005 Crash recovery data loss with fsync on",
      "text": "Crash recovery data loss with fsync on. Target: 0 committed records lost. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "crash",
        "recovery",
        "data",
        "loss",
        "fsync"
      ],
      "kpis": [
        "KDB-005"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-006",
      "kind": "micro-kpi",
      "title": "KDB-006 WAL segment rotation pause p99",
      "text": "WAL segment rotation pause p99. Target: <= 10 ms. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "wal",
        "segment",
        "rotation",
        "pause",
        "p99"
      ],
      "kpis": [
        "KDB-006"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-007",
      "kind": "micro-kpi",
      "title": "KDB-007 WAL checksum validation throughput",
      "text": "WAL checksum validation throughput. Target: >= 1 GB/sec. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "wal",
        "checksum",
        "validation",
        "throughput"
      ],
      "kpis": [
        "KDB-007"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-008",
      "kind": "micro-kpi",
      "title": "KDB-008 Log compaction write amplification",
      "text": "Log compaction write amplification. Target: <= 1.4x live data. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "log",
        "compaction",
        "write",
        "amplification"
      ],
      "kpis": [
        "KDB-008"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-009",
      "kind": "micro-kpi",
      "title": "KDB-009 Snapshot creation stall p99",
      "text": "Snapshot creation stall p99. Target: <= 50 ms. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "snapshot",
        "creation",
        "stall",
        "p99"
      ],
      "kpis": [
        "KDB-009"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-010",
      "kind": "micro-kpi",
      "title": "KDB-010 Restore from snapshot plus WAL tail at 100M records",
      "text": "Restore from snapshot plus WAL tail at 100M records. Target: <= 120 sec. Family: 001-010: Universal Log and Durability.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "001-010:-universal-log-and-durability",
        "restore",
        "snapshot",
        "plus",
        "wal",
        "tail",
        "100m",
        "records"
      ],
      "kpis": [
        "KDB-010"
      ],
      "anchor": "001-010-universal-log-and-durability"
    },
    {
      "id": "micro-kpi-kdb-011",
      "kind": "micro-kpi",
      "title": "KDB-011 Single entity put p50",
      "text": "Single entity put p50. Target: <= 1.2 ms. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "single",
        "entity",
        "put",
        "p50"
      ],
      "kpis": [
        "KDB-011"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-012",
      "kind": "micro-kpi",
      "title": "KDB-012 Single entity put p99",
      "text": "Single entity put p99. Target: <= 6 ms. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "single",
        "entity",
        "put",
        "p99"
      ],
      "kpis": [
        "KDB-012"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-013",
      "kind": "micro-kpi",
      "title": "KDB-013 Single entity get by id p50",
      "text": "Single entity get by id p50. Target: <= 200 us. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "single",
        "entity",
        "get",
        "id",
        "p50"
      ],
      "kpis": [
        "KDB-013"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-014",
      "kind": "micro-kpi",
      "title": "KDB-014 Single entity get by id p99",
      "text": "Single entity get by id p99. Target: <= 1 ms. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "single",
        "entity",
        "get",
        "id",
        "p99"
      ],
      "kpis": [
        "KDB-014"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-015",
      "kind": "micro-kpi",
      "title": "KDB-015 Bulk import sustained throughput",
      "text": "Bulk import sustained throughput. Target: >= 100k records/sec. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "bulk",
        "import",
        "sustained",
        "throughput"
      ],
      "kpis": [
        "KDB-015"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-016",
      "kind": "micro-kpi",
      "title": "KDB-016 Delete tombstone application p99",
      "text": "Delete tombstone application p99. Target: <= 2 ms. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "delete",
        "tombstone",
        "application",
        "p99"
      ],
      "kpis": [
        "KDB-016"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-017",
      "kind": "micro-kpi",
      "title": "KDB-017 Read-after-write visibility",
      "text": "Read-after-write visibility. Target: <= 5 ms. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "read-after",
        "write",
        "visibility"
      ],
      "kpis": [
        "KDB-017"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-018",
      "kind": "micro-kpi",
      "title": "KDB-018 Engine lock hold p99 during writes",
      "text": "Engine lock hold p99 during writes. Target: <= 500 us. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "engine",
        "lock",
        "hold",
        "p99",
        "during",
        "writes"
      ],
      "kpis": [
        "KDB-018"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-019",
      "kind": "micro-kpi",
      "title": "KDB-019 Large JSON record write p99 at 1 MB payload",
      "text": "Large JSON record write p99 at 1 MB payload. Target: <= 25 ms. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "large",
        "json",
        "record",
        "write",
        "p99",
        "mb",
        "payload"
      ],
      "kpis": [
        "KDB-019"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-020",
      "kind": "micro-kpi",
      "title": "KDB-020 Backpressure activation accuracy under overload",
      "text": "Backpressure activation accuracy under overload. Target: >= 99% before OOM risk. Family: 011-020: Engine Write and Read Path.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "011-020:-engine-write-and-read-path",
        "backpressure",
        "activation",
        "accuracy",
        "under",
        "overload"
      ],
      "kpis": [
        "KDB-020"
      ],
      "anchor": "011-020-engine-write-and-read-path"
    },
    {
      "id": "micro-kpi-kdb-021",
      "kind": "micro-kpi",
      "title": "KDB-021 Parallel log replay throughput",
      "text": "Parallel log replay throughput. Target: >= 2M records/sec. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "parallel",
        "log",
        "replay",
        "throughput"
      ],
      "kpis": [
        "KDB-021"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-022",
      "kind": "micro-kpi",
      "title": "KDB-022 Cold boot with checkpoint at 10M records",
      "text": "Cold boot with checkpoint at 10M records. Target: <= 5 sec. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "cold",
        "boot",
        "checkpoint",
        "10m",
        "records"
      ],
      "kpis": [
        "KDB-022"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-023",
      "kind": "micro-kpi",
      "title": "KDB-023 Cold boot with checkpoint at 100M records",
      "text": "Cold boot with checkpoint at 100M records. Target: <= 30 sec. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "cold",
        "boot",
        "checkpoint",
        "100m",
        "records"
      ],
      "kpis": [
        "KDB-023"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-024",
      "kind": "micro-kpi",
      "title": "KDB-024 Memory overhead per small document excluding payload",
      "text": "Memory overhead per small document excluding payload. Target: <= 256 bytes. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "memory",
        "overhead",
        "per",
        "small",
        "document",
        "excluding",
        "payload"
      ],
      "kpis": [
        "KDB-024"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-025",
      "kind": "micro-kpi",
      "title": "KDB-025 Index rebuild progress reporting interval",
      "text": "Index rebuild progress reporting interval. Target: <= 1 sec. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "index",
        "rebuild",
        "progress",
        "reporting",
        "interval"
      ],
      "kpis": [
        "KDB-025"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-026",
      "kind": "micro-kpi",
      "title": "KDB-026 Checkpoint corruption detection",
      "text": "Checkpoint corruption detection. Target: 100% fail-closed. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "checkpoint",
        "corruption",
        "detection"
      ],
      "kpis": [
        "KDB-026"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-027",
      "kind": "micro-kpi",
      "title": "KDB-027 Checkpoint fallback to full replay",
      "text": "Checkpoint fallback to full replay. Target: 100% automatic. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "checkpoint",
        "fallback",
        "full",
        "replay"
      ],
      "kpis": [
        "KDB-027"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-028",
      "kind": "micro-kpi",
      "title": "KDB-028 Boot memory overshoot above steady state",
      "text": "Boot memory overshoot above steady state. Target: <= 20%. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "boot",
        "memory",
        "overshoot",
        "above",
        "steady",
        "state"
      ],
      "kpis": [
        "KDB-028"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-029",
      "kind": "micro-kpi",
      "title": "KDB-029 Startup config validation failures",
      "text": "Startup config validation failures. Target: 100% actionable error messages. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "startup",
        "config",
        "validation",
        "failures"
      ],
      "kpis": [
        "KDB-029"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-030",
      "kind": "micro-kpi",
      "title": "KDB-030 Time to ready probe after warm restart",
      "text": "Time to ready probe after warm restart. Target: <= 3 sec. Family: 021-030: Boot, Replay, and Memory.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "021-030:-boot,-replay,-and-memory",
        "time",
        "ready",
        "probe",
        "after",
        "warm",
        "restart"
      ],
      "kpis": [
        "KDB-030"
      ],
      "anchor": "021-030-boot-replay-and-memory"
    },
    {
      "id": "micro-kpi-kdb-031",
      "kind": "micro-kpi",
      "title": "KDB-031 Equality filter p95 on indexed JSON path at 10M docs",
      "text": "Equality filter p95 on indexed JSON path at 10M docs. Target: <= 8 ms. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "equality",
        "filter",
        "p95",
        "indexed",
        "json",
        "path",
        "10m",
        "docs"
      ],
      "kpis": [
        "KDB-031"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-032",
      "kind": "micro-kpi",
      "title": "KDB-032 Range filter p95 on indexed numeric path at 10M docs",
      "text": "Range filter p95 on indexed numeric path at 10M docs. Target: <= 12 ms. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "range",
        "filter",
        "p95",
        "indexed",
        "numeric",
        "path",
        "10m",
        "docs"
      ],
      "kpis": [
        "KDB-032"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-033",
      "kind": "micro-kpi",
      "title": "KDB-033 Boolean filter p95 on indexed path at 10M docs",
      "text": "Boolean filter p95 on indexed path at 10M docs. Target: <= 8 ms. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "boolean",
        "filter",
        "p95",
        "indexed",
        "path",
        "10m",
        "docs"
      ],
      "kpis": [
        "KDB-033"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-034",
      "kind": "micro-kpi",
      "title": "KDB-034 Nested JSON path extraction p99",
      "text": "Nested JSON path extraction p99. Target: <= 500 us. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "nested",
        "json",
        "path",
        "extraction",
        "p99"
      ],
      "kpis": [
        "KDB-034"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-035",
      "kind": "micro-kpi",
      "title": "KDB-035 Filter planner index selection accuracy",
      "text": "Filter planner index selection accuracy. Target: >= 98%. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "filter",
        "planner",
        "index",
        "selection",
        "accuracy"
      ],
      "kpis": [
        "KDB-035"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-036",
      "kind": "micro-kpi",
      "title": "KDB-036 Full scan warning coverage for expensive filters",
      "text": "Full scan warning coverage for expensive filters. Target: 100%. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "full",
        "scan",
        "warning",
        "coverage",
        "expensive",
        "filters"
      ],
      "kpis": [
        "KDB-036"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-037",
      "kind": "micro-kpi",
      "title": "KDB-037 Filter pagination stability under concurrent writes",
      "text": "Filter pagination stability under concurrent writes. Target: 100% deterministic cursor order. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "filter",
        "pagination",
        "stability",
        "under",
        "concurrent",
        "writes"
      ],
      "kpis": [
        "KDB-037"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-038",
      "kind": "micro-kpi",
      "title": "KDB-038 Compound filter p95 with 3 predicates at 10M docs",
      "text": "Compound filter p95 with 3 predicates at 10M docs. Target: <= 25 ms. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "compound",
        "filter",
        "p95",
        "predicates",
        "10m",
        "docs"
      ],
      "kpis": [
        "KDB-038"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-039",
      "kind": "micro-kpi",
      "title": "KDB-039 Projection payload reduction accuracy",
      "text": "Projection payload reduction accuracy. Target: 100% requested fields only. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "projection",
        "payload",
        "reduction",
        "accuracy"
      ],
      "kpis": [
        "KDB-039"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-040",
      "kind": "micro-kpi",
      "title": "KDB-040 Schema validation p99 for 12 field types",
      "text": "Schema validation p99 for 12 field types. Target: <= 2 ms. Family: 031-040: JSON Documents and Filters.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "031-040:-json-documents-and-filters",
        "schema",
        "validation",
        "p99",
        "12",
        "field",
        "types"
      ],
      "kpis": [
        "KDB-040"
      ],
      "anchor": "031-040-json-documents-and-filters"
    },
    {
      "id": "micro-kpi-kdb-041",
      "kind": "micro-kpi",
      "title": "KDB-041 Automatic JSON path index suggestion latency",
      "text": "Automatic JSON path index suggestion latency. Target: <= 1 sec after query window. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "automatic",
        "json",
        "path",
        "index",
        "suggestion",
        "latency"
      ],
      "kpis": [
        "KDB-041"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-042",
      "kind": "micro-kpi",
      "title": "KDB-042 Index build throughput",
      "text": "Index build throughput. Target: >= 250k records/sec. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "index",
        "build",
        "throughput"
      ],
      "kpis": [
        "KDB-042"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-043",
      "kind": "micro-kpi",
      "title": "KDB-043 Online index build write availability",
      "text": "Online index build write availability. Target: 100% writes accepted. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "online",
        "index",
        "build",
        "write",
        "availability"
      ],
      "kpis": [
        "KDB-043"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-044",
      "kind": "micro-kpi",
      "title": "KDB-044 Index storage overhead per scalar field",
      "text": "Index storage overhead per scalar field. Target: <= 35% of field payload. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "index",
        "storage",
        "overhead",
        "per",
        "scalar",
        "field"
      ],
      "kpis": [
        "KDB-044"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-045",
      "kind": "micro-kpi",
      "title": "KDB-045 Query plan explain coverage",
      "text": "Query plan explain coverage. Target: 100% public query endpoints. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "query",
        "plan",
        "explain",
        "coverage"
      ],
      "kpis": [
        "KDB-045"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-046",
      "kind": "micro-kpi",
      "title": "KDB-046 Query planner regression test coverage",
      "text": "Query planner regression test coverage. Target: >= 95% of supported operators. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "query",
        "planner",
        "regression",
        "test",
        "coverage"
      ],
      "kpis": [
        "KDB-046"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-047",
      "kind": "micro-kpi",
      "title": "KDB-047 Stale index detection after crash",
      "text": "Stale index detection after crash. Target: 100% automatic rebuild or reject. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "stale",
        "index",
        "detection",
        "after",
        "crash"
      ],
      "kpis": [
        "KDB-047"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-048",
      "kind": "micro-kpi",
      "title": "KDB-048 Index rebuild resume from checkpoint",
      "text": "Index rebuild resume from checkpoint. Target: >= 95% progress retained. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "index",
        "rebuild",
        "resume",
        "checkpoint"
      ],
      "kpis": [
        "KDB-048"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-049",
      "kind": "micro-kpi",
      "title": "KDB-049 Admin index create to usable p95 for 1M docs",
      "text": "Admin index create to usable p95 for 1M docs. Target: <= 15 sec. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "admin",
        "index",
        "create",
        "usable",
        "p95",
        "1m",
        "docs"
      ],
      "kpis": [
        "KDB-049"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-050",
      "kind": "micro-kpi",
      "title": "KDB-050 Index drop cleanup completion p95",
      "text": "Index drop cleanup completion p95. Target: <= 10 sec. Family: 041-050: Secondary Indexes and Query Planning.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "041-050:-secondary-indexes-and-query-planning",
        "index",
        "drop",
        "cleanup",
        "completion",
        "p95"
      ],
      "kpis": [
        "KDB-050"
      ],
      "anchor": "041-050-secondary-indexes-and-query-planning"
    },
    {
      "id": "micro-kpi-kdb-051",
      "kind": "micro-kpi",
      "title": "KDB-051 BM25 top-10 p95 at 1M docs",
      "text": "BM25 top-10 p95 at 1M docs. Target: <= 5 ms. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "bm25",
        "top-10",
        "p95",
        "1m",
        "docs"
      ],
      "kpis": [
        "KDB-051"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-052",
      "kind": "micro-kpi",
      "title": "KDB-052 BM25 top-10 p99 at 5M docs",
      "text": "BM25 top-10 p99 at 5M docs. Target: <= 15 ms. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "bm25",
        "top-10",
        "p99",
        "5m",
        "docs"
      ],
      "kpis": [
        "KDB-052"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-053",
      "kind": "micro-kpi",
      "title": "KDB-053 Tokenization throughput",
      "text": "Tokenization throughput. Target: >= 50 MB/sec. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "tokenization",
        "throughput"
      ],
      "kpis": [
        "KDB-053"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-054",
      "kind": "micro-kpi",
      "title": "KDB-054 Accent and case folding correctness",
      "text": "Accent and case folding correctness. Target: >= 99.9% golden set pass. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "accent",
        "case",
        "folding",
        "correctness"
      ],
      "kpis": [
        "KDB-054"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-055",
      "kind": "micro-kpi",
      "title": "KDB-055 Search index incremental update p99",
      "text": "Search index incremental update p99. Target: <= 10 ms. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "search",
        "index",
        "incremental",
        "update",
        "p99"
      ],
      "kpis": [
        "KDB-055"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-056",
      "kind": "micro-kpi",
      "title": "KDB-056 Block-Max WAND candidate reduction",
      "text": "Block-Max WAND candidate reduction. Target: >= 80% on sparse queries. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "block-max",
        "wand",
        "candidate",
        "reduction"
      ],
      "kpis": [
        "KDB-056"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-057",
      "kind": "micro-kpi",
      "title": "KDB-057 Phrase search p95 at 1M docs",
      "text": "Phrase search p95 at 1M docs. Target: <= 20 ms. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "phrase",
        "search",
        "p95",
        "1m",
        "docs"
      ],
      "kpis": [
        "KDB-057"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-058",
      "kind": "micro-kpi",
      "title": "KDB-058 Synonym expansion overhead p95",
      "text": "Synonym expansion overhead p95. Target: <= 5 ms. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "synonym",
        "expansion",
        "overhead",
        "p95"
      ],
      "kpis": [
        "KDB-058"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-059",
      "kind": "micro-kpi",
      "title": "KDB-059 Search explain includes term scores",
      "text": "Search explain includes term scores. Target: 100% when requested. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "search",
        "explain",
        "includes",
        "term",
        "scores"
      ],
      "kpis": [
        "KDB-059"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-060",
      "kind": "micro-kpi",
      "title": "KDB-060 Search relevance NDCG@10 on benchmark set",
      "text": "Search relevance NDCG@10 on benchmark set. Target: >= 0.85. Family: 051-060: BM25 Search.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "051-060:-bm25-search",
        "search",
        "relevance",
        "ndcg",
        "10",
        "benchmark",
        "set"
      ],
      "kpis": [
        "KDB-060"
      ],
      "anchor": "051-060-bm25-search"
    },
    {
      "id": "micro-kpi-kdb-061",
      "kind": "micro-kpi",
      "title": "KDB-061 Brute-force cosine p95 at 100k 384-d vectors",
      "text": "Brute-force cosine p95 at 100k 384-d vectors. Target: <= 30 ms. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "brute-force",
        "cosine",
        "p95",
        "100k",
        "384-d",
        "vectors"
      ],
      "kpis": [
        "KDB-061"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-062",
      "kind": "micro-kpi",
      "title": "KDB-062 HNSW top-10 p99 at 1M 768-d vectors",
      "text": "HNSW top-10 p99 at 1M 768-d vectors. Target: <= 8 ms. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "hnsw",
        "top-10",
        "p99",
        "1m",
        "768-d",
        "vectors"
      ],
      "kpis": [
        "KDB-062"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-063",
      "kind": "micro-kpi",
      "title": "KDB-063 HNSW recall@10 versus brute force",
      "text": "HNSW recall@10 versus brute force. Target: >= 0.95. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "hnsw",
        "recall",
        "10",
        "versus",
        "brute",
        "force"
      ],
      "kpis": [
        "KDB-063"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-064",
      "kind": "micro-kpi",
      "title": "KDB-064 HNSW build throughput for 768-d vectors",
      "text": "HNSW build throughput for 768-d vectors. Target: >= 20k vectors/min. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "hnsw",
        "build",
        "throughput",
        "768-d",
        "vectors"
      ],
      "kpis": [
        "KDB-064"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-065",
      "kind": "micro-kpi",
      "title": "KDB-065 HNSW persisted snapshot load at 1M vectors",
      "text": "HNSW persisted snapshot load at 1M vectors. Target: <= 20 sec. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "hnsw",
        "persisted",
        "snapshot",
        "load",
        "1m",
        "vectors"
      ],
      "kpis": [
        "KDB-065"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-066",
      "kind": "micro-kpi",
      "title": "KDB-066 Vector insert visibility in ANN index p95",
      "text": "Vector insert visibility in ANN index p95. Target: <= 2 sec. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "vector",
        "insert",
        "visibility",
        "ann",
        "index",
        "p95"
      ],
      "kpis": [
        "KDB-066"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-067",
      "kind": "micro-kpi",
      "title": "KDB-067 Vector memory overhead over raw embeddings",
      "text": "Vector memory overhead over raw embeddings. Target: <= 1.8x. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "vector",
        "memory",
        "overhead",
        "raw",
        "embeddings"
      ],
      "kpis": [
        "KDB-067"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-068",
      "kind": "micro-kpi",
      "title": "KDB-068 Hybrid RRF fusion overhead p95",
      "text": "Hybrid RRF fusion overhead p95. Target: <= 1 ms. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "hybrid",
        "rrf",
        "fusion",
        "overhead",
        "p95"
      ],
      "kpis": [
        "KDB-068"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-069",
      "kind": "micro-kpi",
      "title": "KDB-069 Hybrid retrieval NDCG@10 on benchmark set",
      "text": "Hybrid retrieval NDCG@10 on benchmark set. Target: >= 0.88. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "hybrid",
        "retrieval",
        "ndcg",
        "10",
        "benchmark",
        "set"
      ],
      "kpis": [
        "KDB-069"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-070",
      "kind": "micro-kpi",
      "title": "KDB-070 pgvector offload query p95 via Postgres backend",
      "text": "pgvector offload query p95 via Postgres backend. Target: <= 25 ms. Family: 061-070: Vector, HNSW, and Hybrid Retrieval.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "061-070:-vector,-hnsw,-and-hybrid-retrieval",
        "pgvector",
        "offload",
        "query",
        "p95",
        "via",
        "postgres",
        "backend"
      ],
      "kpis": [
        "KDB-070"
      ],
      "anchor": "061-070-vector-hnsw-and-hybrid-retrieval"
    },
    {
      "id": "micro-kpi-kdb-071",
      "kind": "micro-kpi",
      "title": "KDB-071 Change feed cursor read p95",
      "text": "Change feed cursor read p95. Target: <= 10 ms. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "change",
        "feed",
        "cursor",
        "read",
        "p95"
      ],
      "kpis": [
        "KDB-071"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-072",
      "kind": "micro-kpi",
      "title": "KDB-072 SSE publish latency p95 after commit",
      "text": "SSE publish latency p95 after commit. Target: <= 50 ms. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "sse",
        "publish",
        "latency",
        "p95",
        "after",
        "commit"
      ],
      "kpis": [
        "KDB-072"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-073",
      "kind": "micro-kpi",
      "title": "KDB-073 SSE fanout at 10k subscribers",
      "text": "SSE fanout at 10k subscribers. Target: >= 99.9% delivery within 1 sec. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "sse",
        "fanout",
        "10k",
        "subscribers"
      ],
      "kpis": [
        "KDB-073"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-074",
      "kind": "micro-kpi",
      "title": "KDB-074 Reconnect with last event id correctness",
      "text": "Reconnect with last event id correctness. Target: 100% no gaps. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "reconnect",
        "last",
        "event",
        "id",
        "correctness"
      ],
      "kpis": [
        "KDB-074"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-075",
      "kind": "micro-kpi",
      "title": "KDB-075 Change feed retention window configurability",
      "text": "Change feed retention window configurability. Target: 100% per project. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "change",
        "feed",
        "retention",
        "window",
        "configurability"
      ],
      "kpis": [
        "KDB-075"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-076",
      "kind": "micro-kpi",
      "title": "KDB-076 Subscription filter evaluation p99",
      "text": "Subscription filter evaluation p99. Target: <= 2 ms. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "subscription",
        "filter",
        "evaluation",
        "p99"
      ],
      "kpis": [
        "KDB-076"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-077",
      "kind": "micro-kpi",
      "title": "KDB-077 Realtime memory per idle subscriber",
      "text": "Realtime memory per idle subscriber. Target: <= 16 KB. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "realtime",
        "memory",
        "per",
        "idle",
        "subscriber"
      ],
      "kpis": [
        "KDB-077"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-078",
      "kind": "micro-kpi",
      "title": "KDB-078 Backpressure disconnect safety",
      "text": "Backpressure disconnect safety. Target: 100% audit logged. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "backpressure",
        "disconnect",
        "safety"
      ],
      "kpis": [
        "KDB-078"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-079",
      "kind": "micro-kpi",
      "title": "KDB-079 Event ordering per entity",
      "text": "Event ordering per entity. Target: 100% commit order. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "event",
        "ordering",
        "per",
        "entity"
      ],
      "kpis": [
        "KDB-079"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-080",
      "kind": "micro-kpi",
      "title": "KDB-080 Change feed lag dashboard refresh interval",
      "text": "Change feed lag dashboard refresh interval. Target: <= 5 sec. Family: 071-080: Realtime and Change Feed.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "071-080:-realtime-and-change-feed",
        "change",
        "feed",
        "lag",
        "dashboard",
        "refresh",
        "interval"
      ],
      "kpis": [
        "KDB-080"
      ],
      "anchor": "071-080-realtime-and-change-feed"
    },
    {
      "id": "micro-kpi-kdb-081",
      "kind": "micro-kpi",
      "title": "KDB-081 Password sign-in p95 with bcrypt",
      "text": "Password sign-in p95 with bcrypt. Target: <= 250 ms. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "password",
        "sign-in",
        "p95",
        "bcrypt"
      ],
      "kpis": [
        "KDB-081"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-082",
      "kind": "micro-kpi",
      "title": "KDB-082 JWT validation p99",
      "text": "JWT validation p99. Target: <= 500 us. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "jwt",
        "validation",
        "p99"
      ],
      "kpis": [
        "KDB-082"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-083",
      "kind": "micro-kpi",
      "title": "KDB-083 Scoped API key validation p99",
      "text": "Scoped API key validation p99. Target: <= 500 us. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "scoped",
        "api",
        "key",
        "validation",
        "p99"
      ],
      "kpis": [
        "KDB-083"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-084",
      "kind": "micro-kpi",
      "title": "KDB-084 Role rule evaluation p99",
      "text": "Role rule evaluation p99. Target: <= 2 ms. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "role",
        "rule",
        "evaluation",
        "p99"
      ],
      "kpis": [
        "KDB-084"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-085",
      "kind": "micro-kpi",
      "title": "KDB-085 Tenant isolation test coverage",
      "text": "Tenant isolation test coverage. Target: 100% critical paths. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "tenant",
        "isolation",
        "test",
        "coverage"
      ],
      "kpis": [
        "KDB-085"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-086",
      "kind": "micro-kpi",
      "title": "KDB-086 First admin bootstrap path correctness",
      "text": "First admin bootstrap path correctness. Target: 100% one-time promotion. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "first",
        "admin",
        "bootstrap",
        "path",
        "correctness"
      ],
      "kpis": [
        "KDB-086"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-087",
      "kind": "micro-kpi",
      "title": "KDB-087 Token revocation propagation p95",
      "text": "Token revocation propagation p95. Target: <= 5 sec. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "token",
        "revocation",
        "propagation",
        "p95"
      ],
      "kpis": [
        "KDB-087"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-088",
      "kind": "micro-kpi",
      "title": "KDB-088 MFA enrollment success rate",
      "text": "MFA enrollment success rate. Target: >= 99% in supported clients. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "mfa",
        "enrollment",
        "success",
        "rate"
      ],
      "kpis": [
        "KDB-088"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-089",
      "kind": "micro-kpi",
      "title": "KDB-089 Auth audit event coverage",
      "text": "Auth audit event coverage. Target: 100% privileged actions. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "auth",
        "audit",
        "event",
        "coverage"
      ],
      "kpis": [
        "KDB-089"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-090",
      "kind": "micro-kpi",
      "title": "KDB-090 Session anomaly detection latency",
      "text": "Session anomaly detection latency. Target: <= 60 sec. Family: 081-090: Auth, RBAC, and Tenancy.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "081-090:-auth,-rbac,-and-tenancy",
        "session",
        "anomaly",
        "detection",
        "latency"
      ],
      "kpis": [
        "KDB-090"
      ],
      "anchor": "081-090-auth-rbac-and-tenancy"
    },
    {
      "id": "micro-kpi-kdb-091",
      "kind": "micro-kpi",
      "title": "KDB-091 Small file upload p95 under 1 MB",
      "text": "Small file upload p95 under 1 MB. Target: <= 150 ms plus network. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "small",
        "file",
        "upload",
        "p95",
        "under",
        "mb"
      ],
      "kpis": [
        "KDB-091"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-092",
      "kind": "micro-kpi",
      "title": "KDB-092 Large multipart upload success at 5 GB",
      "text": "Large multipart upload success at 5 GB. Target: >= 99.9%. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "large",
        "multipart",
        "upload",
        "success",
        "gb"
      ],
      "kpis": [
        "KDB-092"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-093",
      "kind": "micro-kpi",
      "title": "KDB-093 File metadata write consistency",
      "text": "File metadata write consistency. Target: 100% commit or rollback. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "file",
        "metadata",
        "write",
        "consistency"
      ],
      "kpis": [
        "KDB-093"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-094",
      "kind": "micro-kpi",
      "title": "KDB-094 Signed URL generation p99",
      "text": "Signed URL generation p99. Target: <= 5 ms. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "signed",
        "url",
        "generation",
        "p99"
      ],
      "kpis": [
        "KDB-094"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-095",
      "kind": "micro-kpi",
      "title": "KDB-095 Object store retry success after transient 5xx",
      "text": "Object store retry success after transient 5xx. Target: >= 99%. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "object",
        "store",
        "retry",
        "success",
        "after",
        "transient",
        "5xx"
      ],
      "kpis": [
        "KDB-095"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-096",
      "kind": "micro-kpi",
      "title": "KDB-096 Orphaned object cleanup detection",
      "text": "Orphaned object cleanup detection. Target: <= 24 hours. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "orphaned",
        "object",
        "cleanup",
        "detection"
      ],
      "kpis": [
        "KDB-096"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-097",
      "kind": "micro-kpi",
      "title": "KDB-097 File permission rule evaluation p99",
      "text": "File permission rule evaluation p99. Target: <= 2 ms. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "file",
        "permission",
        "rule",
        "evaluation",
        "p99"
      ],
      "kpis": [
        "KDB-097"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-098",
      "kind": "micro-kpi",
      "title": "KDB-098 Cross-region object replication lag p95",
      "text": "Cross-region object replication lag p95. Target: <= 15 min. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "cross-region",
        "object",
        "replication",
        "lag",
        "p95"
      ],
      "kpis": [
        "KDB-098"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-099",
      "kind": "micro-kpi",
      "title": "KDB-099 Storage quota enforcement accuracy",
      "text": "Storage quota enforcement accuracy. Target: 100% before write accepted. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "storage",
        "quota",
        "enforcement",
        "accuracy"
      ],
      "kpis": [
        "KDB-099"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-100",
      "kind": "micro-kpi",
      "title": "KDB-100 Malware scan hook coverage for configured buckets",
      "text": "Malware scan hook coverage for configured buckets. Target: 100%. Family: 091-100: Files and Object Storage.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "091-100:-files-and-object-storage",
        "malware",
        "scan",
        "hook",
        "coverage",
        "configured",
        "buckets"
      ],
      "kpis": [
        "KDB-100"
      ],
      "anchor": "091-100-files-and-object-storage"
    },
    {
      "id": "micro-kpi-kdb-101",
      "kind": "micro-kpi",
      "title": "KDB-101 REST API p95 latency for simple select",
      "text": "REST API p95 latency for simple select. Target: <= 20 ms. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "rest",
        "api",
        "p95",
        "latency",
        "simple",
        "select"
      ],
      "kpis": [
        "KDB-101"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-102",
      "kind": "micro-kpi",
      "title": "KDB-102 PostgREST-style filter compatibility tests",
      "text": "PostgREST-style filter compatibility tests. Target: >= 95% supported subset. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "postgrest-style",
        "filter",
        "compatibility",
        "tests"
      ],
      "kpis": [
        "KDB-102"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-103",
      "kind": "micro-kpi",
      "title": "KDB-103 Supabase-shaped auth compatibility tests",
      "text": "Supabase-shaped auth compatibility tests. Target: >= 90% supported subset. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "supabase-shaped",
        "auth",
        "compatibility",
        "tests"
      ],
      "kpis": [
        "KDB-103"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-104",
      "kind": "micro-kpi",
      "title": "KDB-104 Storage API compatibility tests",
      "text": "Storage API compatibility tests. Target: >= 90% supported subset. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "storage",
        "api",
        "compatibility",
        "tests"
      ],
      "kpis": [
        "KDB-104"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-105",
      "kind": "micro-kpi",
      "title": "KDB-105 Realtime API compatibility tests",
      "text": "Realtime API compatibility tests. Target: >= 85% supported subset. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "realtime",
        "api",
        "compatibility",
        "tests"
      ],
      "kpis": [
        "KDB-105"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-106",
      "kind": "micro-kpi",
      "title": "KDB-106 OpenAPI route coverage",
      "text": "OpenAPI route coverage. Target: 100% public routes. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "openapi",
        "route",
        "coverage"
      ],
      "kpis": [
        "KDB-106"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-107",
      "kind": "micro-kpi",
      "title": "KDB-107 TypeScript SDK typed route coverage",
      "text": "TypeScript SDK typed route coverage. Target: 100% stable public routes. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "typescript",
        "sdk",
        "typed",
        "route",
        "coverage"
      ],
      "kpis": [
        "KDB-107"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-108",
      "kind": "micro-kpi",
      "title": "KDB-108 API error shape consistency",
      "text": "API error shape consistency. Target: 100% route tests. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "api",
        "error",
        "shape",
        "consistency"
      ],
      "kpis": [
        "KDB-108"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-109",
      "kind": "micro-kpi",
      "title": "KDB-109 Pagination cursor compatibility",
      "text": "Pagination cursor compatibility. Target: 100% stable across mutations. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "pagination",
        "cursor",
        "compatibility"
      ],
      "kpis": [
        "KDB-109"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-110",
      "kind": "micro-kpi",
      "title": "KDB-110 Breaking API change detection in CI",
      "text": "Breaking API change detection in CI. Target: 100% contract snapshot diff. Family: 101-110: APIs, SDKs, and Compatibility.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "101-110:-apis,-sdks,-and-compatibility",
        "breaking",
        "api",
        "change",
        "detection",
        "ci"
      ],
      "kpis": [
        "KDB-110"
      ],
      "anchor": "101-110-apis-sdks-and-compatibility"
    },
    {
      "id": "micro-kpi-kdb-111",
      "kind": "micro-kpi",
      "title": "KDB-111 Admin dashboard initial load LCP",
      "text": "Admin dashboard initial load LCP. Target: <= 2.5 sec. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "admin",
        "dashboard",
        "initial",
        "load",
        "lcp"
      ],
      "kpis": [
        "KDB-111"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-112",
      "kind": "micro-kpi",
      "title": "KDB-112 Admin interaction INP",
      "text": "Admin interaction INP. Target: <= 200 ms. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "admin",
        "interaction",
        "inp"
      ],
      "kpis": [
        "KDB-112"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-113",
      "kind": "micro-kpi",
      "title": "KDB-113 Cluster list refresh p95",
      "text": "Cluster list refresh p95. Target: <= 1 sec. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "cluster",
        "list",
        "refresh",
        "p95"
      ],
      "kpis": [
        "KDB-113"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-114",
      "kind": "micro-kpi",
      "title": "KDB-114 Provider credential validation p95",
      "text": "Provider credential validation p95. Target: <= 5 sec. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "provider",
        "credential",
        "validation",
        "p95"
      ],
      "kpis": [
        "KDB-114"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-115",
      "kind": "micro-kpi",
      "title": "KDB-115 Runtime profile recommendation latency",
      "text": "Runtime profile recommendation latency. Target: <= 500 ms. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "runtime",
        "profile",
        "recommendation",
        "latency"
      ],
      "kpis": [
        "KDB-115"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-116",
      "kind": "micro-kpi",
      "title": "KDB-116 Admin mutation audit coverage",
      "text": "Admin mutation audit coverage. Target: 100%. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "admin",
        "mutation",
        "audit",
        "coverage"
      ],
      "kpis": [
        "KDB-116"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-117",
      "kind": "micro-kpi",
      "title": "KDB-117 Destructive action approval coverage",
      "text": "Destructive action approval coverage. Target: 100%. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "destructive",
        "action",
        "approval",
        "coverage"
      ],
      "kpis": [
        "KDB-117"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-118",
      "kind": "micro-kpi",
      "title": "KDB-118 Admin health panel data freshness",
      "text": "Admin health panel data freshness. Target: <= 10 sec. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "admin",
        "health",
        "panel",
        "data",
        "freshness"
      ],
      "kpis": [
        "KDB-118"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-119",
      "kind": "micro-kpi",
      "title": "KDB-119 New database wizard completion rate",
      "text": "New database wizard completion rate. Target: >= 80%. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "new",
        "database",
        "wizard",
        "completion",
        "rate"
      ],
      "kpis": [
        "KDB-119"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-120",
      "kind": "micro-kpi",
      "title": "KDB-120 Admin empty/error/loading states coverage",
      "text": "Admin empty/error/loading states coverage. Target: 100% critical panels. Family: 111-120: Super Admin and Control Plane.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "111-120:-super-admin-and-control-plane",
        "admin",
        "empty",
        "error",
        "loading",
        "states",
        "coverage"
      ],
      "kpis": [
        "KDB-120"
      ],
      "anchor": "111-120-super-admin-and-control-plane"
    },
    {
      "id": "micro-kpi-kdb-121",
      "kind": "micro-kpi",
      "title": "KDB-121 Certified provider smoke test coverage",
      "text": "Certified provider smoke test coverage. Target: 100% tier-1 providers. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "certified",
        "provider",
        "smoke",
        "test",
        "coverage"
      ],
      "kpis": [
        "KDB-121"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-122",
      "kind": "micro-kpi",
      "title": "KDB-122 Create cluster p95 on managed container providers",
      "text": "Create cluster p95 on managed container providers. Target: <= 10 min. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "create",
        "cluster",
        "p95",
        "managed",
        "container",
        "providers"
      ],
      "kpis": [
        "KDB-122"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-123",
      "kind": "micro-kpi",
      "title": "KDB-123 Destroy cluster cleanup completeness",
      "text": "Destroy cluster cleanup completeness. Target: 100% tagged resources. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "destroy",
        "cluster",
        "cleanup",
        "completeness"
      ],
      "kpis": [
        "KDB-123"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-124",
      "kind": "micro-kpi",
      "title": "KDB-124 Provider capability metadata accuracy",
      "text": "Provider capability metadata accuracy. Target: >= 99%. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "provider",
        "capability",
        "metadata",
        "accuracy"
      ],
      "kpis": [
        "KDB-124"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-125",
      "kind": "micro-kpi",
      "title": "KDB-125 Runtime profile validation failure clarity",
      "text": "Runtime profile validation failure clarity. Target: 100% actionable. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "runtime",
        "profile",
        "validation",
        "failure",
        "clarity"
      ],
      "kpis": [
        "KDB-125"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-126",
      "kind": "micro-kpi",
      "title": "KDB-126 Container image boot success across targets",
      "text": "Container image boot success across targets. Target: 100% certified targets. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "container",
        "image",
        "boot",
        "success",
        "across",
        "targets"
      ],
      "kpis": [
        "KDB-126"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-127",
      "kind": "micro-kpi",
      "title": "KDB-127 Health check success after deploy",
      "text": "Health check success after deploy. Target: >= 99.5%. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "health",
        "check",
        "success",
        "after",
        "deploy"
      ],
      "kpis": [
        "KDB-127"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-128",
      "kind": "micro-kpi",
      "title": "KDB-128 Rollback to previous image p95",
      "text": "Rollback to previous image p95. Target: <= 5 min. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "rollback",
        "previous",
        "image",
        "p95"
      ],
      "kpis": [
        "KDB-128"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-129",
      "kind": "micro-kpi",
      "title": "KDB-129 Per-provider cost estimate accuracy",
      "text": "Per-provider cost estimate accuracy. Target: within 15%. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "per-provider",
        "cost",
        "estimate",
        "accuracy"
      ],
      "kpis": [
        "KDB-129"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-130",
      "kind": "micro-kpi",
      "title": "KDB-130 Region availability catalog freshness",
      "text": "Region availability catalog freshness. Target: <= 24 hours. Family: 121-130: Cloud Deployment Fabric.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "121-130:-cloud-deployment-fabric",
        "region",
        "availability",
        "catalog",
        "freshness"
      ],
      "kpis": [
        "KDB-130"
      ],
      "anchor": "121-130-cloud-deployment-fabric"
    },
    {
      "id": "micro-kpi-kdb-131",
      "kind": "micro-kpi",
      "title": "KDB-131 Replica log apply lag p95",
      "text": "Replica log apply lag p95. Target: <= 2 sec. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "replica",
        "log",
        "apply",
        "lag",
        "p95"
      ],
      "kpis": [
        "KDB-131"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-132",
      "kind": "micro-kpi",
      "title": "KDB-132 Replica log apply lag p99",
      "text": "Replica log apply lag p99. Target: <= 10 sec. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "replica",
        "log",
        "apply",
        "lag",
        "p99"
      ],
      "kpis": [
        "KDB-132"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-133",
      "kind": "micro-kpi",
      "title": "KDB-133 Read router stale-read avoidance",
      "text": "Read router stale-read avoidance. Target: 100% for primary-only paths. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "read",
        "router",
        "stale-read",
        "avoidance"
      ],
      "kpis": [
        "KDB-133"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-134",
      "kind": "micro-kpi",
      "title": "KDB-134 Regional read selection p95 overhead",
      "text": "Regional read selection p95 overhead. Target: <= 2 ms. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "regional",
        "read",
        "selection",
        "p95",
        "overhead"
      ],
      "kpis": [
        "KDB-134"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-135",
      "kind": "micro-kpi",
      "title": "KDB-135 Edge cache hit ratio for safe read endpoints",
      "text": "Edge cache hit ratio for safe read endpoints. Target: >= 70% after warmup. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "edge",
        "cache",
        "hit",
        "ratio",
        "safe",
        "read",
        "endpoints"
      ],
      "kpis": [
        "KDB-135"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-136",
      "kind": "micro-kpi",
      "title": "KDB-136 Cache purge propagation p95",
      "text": "Cache purge propagation p95. Target: <= 5 sec. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "cache",
        "purge",
        "propagation",
        "p95"
      ],
      "kpis": [
        "KDB-136"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-137",
      "kind": "micro-kpi",
      "title": "KDB-137 Failover detection p95",
      "text": "Failover detection p95. Target: <= 2 sec. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "failover",
        "detection",
        "p95"
      ],
      "kpis": [
        "KDB-137"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-138",
      "kind": "micro-kpi",
      "title": "KDB-138 Failover route switch p95",
      "text": "Failover route switch p95. Target: <= 10 sec. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "failover",
        "route",
        "switch",
        "p95"
      ],
      "kpis": [
        "KDB-138"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-139",
      "kind": "micro-kpi",
      "title": "KDB-139 Read replica bootstrap from snapshot",
      "text": "Read replica bootstrap from snapshot. Target: <= 15 min at 100 GB. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "read",
        "replica",
        "bootstrap",
        "snapshot"
      ],
      "kpis": [
        "KDB-139"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-140",
      "kind": "micro-kpi",
      "title": "KDB-140 Cross-region health probe coverage",
      "text": "Cross-region health probe coverage. Target: 100% active regions. Family: 131-140: Replication, Regional Reads, and Edge.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "131-140:-replication,-regional-reads,-and-edge",
        "cross-region",
        "health",
        "probe",
        "coverage"
      ],
      "kpis": [
        "KDB-140"
      ],
      "anchor": "131-140-replication-regional-reads-and-edge"
    },
    {
      "id": "micro-kpi-kdb-141",
      "kind": "micro-kpi",
      "title": "KDB-141 Backup schedule execution reliability",
      "text": "Backup schedule execution reliability. Target: >= 99.9%. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "backup",
        "schedule",
        "execution",
        "reliability"
      ],
      "kpis": [
        "KDB-141"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-142",
      "kind": "micro-kpi",
      "title": "KDB-142 Full backup throughput to object storage",
      "text": "Full backup throughput to object storage. Target: >= 100 MB/sec. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "full",
        "backup",
        "throughput",
        "object",
        "storage"
      ],
      "kpis": [
        "KDB-142"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-143",
      "kind": "micro-kpi",
      "title": "KDB-143 Incremental backup lag p95",
      "text": "Incremental backup lag p95. Target: <= 5 min. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "incremental",
        "backup",
        "lag",
        "p95"
      ],
      "kpis": [
        "KDB-143"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-144",
      "kind": "micro-kpi",
      "title": "KDB-144 Restore-to-new p95 for 100 GB dataset",
      "text": "Restore-to-new p95 for 100 GB dataset. Target: <= 30 min. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "restore-to",
        "new",
        "p95",
        "100",
        "gb",
        "dataset"
      ],
      "kpis": [
        "KDB-144"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-145",
      "kind": "micro-kpi",
      "title": "KDB-145 Point-in-time recovery granularity",
      "text": "Point-in-time recovery granularity. Target: <= 1 min. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "point-in",
        "time",
        "recovery",
        "granularity"
      ],
      "kpis": [
        "KDB-145"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-146",
      "kind": "micro-kpi",
      "title": "KDB-146 Backup integrity verification coverage",
      "text": "Backup integrity verification coverage. Target: 100% completed backups. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "backup",
        "integrity",
        "verification",
        "coverage"
      ],
      "kpis": [
        "KDB-146"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-147",
      "kind": "micro-kpi",
      "title": "KDB-147 Cross-region backup copy lag p95",
      "text": "Cross-region backup copy lag p95. Target: <= 30 min. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "cross-region",
        "backup",
        "copy",
        "lag",
        "p95"
      ],
      "kpis": [
        "KDB-147"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-148",
      "kind": "micro-kpi",
      "title": "KDB-148 Backup retention policy enforcement",
      "text": "Backup retention policy enforcement. Target: 100%. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "backup",
        "retention",
        "policy",
        "enforcement"
      ],
      "kpis": [
        "KDB-148"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-149",
      "kind": "micro-kpi",
      "title": "KDB-149 Restore drill frequency",
      "text": "Restore drill frequency. Target: >= 1 per month per production profile. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "restore",
        "drill",
        "frequency"
      ],
      "kpis": [
        "KDB-149"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-150",
      "kind": "micro-kpi",
      "title": "KDB-150 RPO for production profile",
      "text": "RPO for production profile. Target: <= 5 min. Family: 141-150: Backup, Restore, and Disaster Recovery.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "141-150:-backup,-restore,-and-disaster-recovery",
        "rpo",
        "production",
        "profile"
      ],
      "kpis": [
        "KDB-150"
      ],
      "anchor": "141-150-backup-restore-and-disaster-recovery"
    },
    {
      "id": "micro-kpi-kdb-151",
      "kind": "micro-kpi",
      "title": "KDB-151 Secret encryption at rest coverage",
      "text": "Secret encryption at rest coverage. Target: 100% provider credentials. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "secret",
        "encryption",
        "rest",
        "coverage"
      ],
      "kpis": [
        "KDB-151"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-152",
      "kind": "micro-kpi",
      "title": "KDB-152 Secret rotation completion p95",
      "text": "Secret rotation completion p95. Target: <= 15 min. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "secret",
        "rotation",
        "completion",
        "p95"
      ],
      "kpis": [
        "KDB-152"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-153",
      "kind": "micro-kpi",
      "title": "KDB-153 WAF block decision p99 at edge",
      "text": "WAF block decision p99 at edge. Target: <= 1 ms. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "waf",
        "block",
        "decision",
        "p99",
        "edge"
      ],
      "kpis": [
        "KDB-153"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-154",
      "kind": "micro-kpi",
      "title": "KDB-154 Rate limit decision p99 at edge",
      "text": "Rate limit decision p99 at edge. Target: <= 1 ms. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "rate",
        "limit",
        "decision",
        "p99",
        "edge"
      ],
      "kpis": [
        "KDB-154"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-155",
      "kind": "micro-kpi",
      "title": "KDB-155 Audit log tamper-evidence verification",
      "text": "Audit log tamper-evidence verification. Target: 100% chain validated. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "audit",
        "log",
        "tamper-evidence",
        "verification"
      ],
      "kpis": [
        "KDB-155"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-156",
      "kind": "micro-kpi",
      "title": "KDB-156 Vulnerability patch SLA for critical CVEs",
      "text": "Vulnerability patch SLA for critical CVEs. Target: <= 48 hours. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "vulnerability",
        "patch",
        "sla",
        "critical",
        "cves"
      ],
      "kpis": [
        "KDB-156"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-157",
      "kind": "micro-kpi",
      "title": "KDB-157 Dependency license scan coverage",
      "text": "Dependency license scan coverage. Target: 100% release builds. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "dependency",
        "license",
        "scan",
        "coverage"
      ],
      "kpis": [
        "KDB-157"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-158",
      "kind": "micro-kpi",
      "title": "KDB-158 PII erasure request completion p95",
      "text": "PII erasure request completion p95. Target: <= 24 hours. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "pii",
        "erasure",
        "request",
        "completion",
        "p95"
      ],
      "kpis": [
        "KDB-158"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-159",
      "kind": "micro-kpi",
      "title": "KDB-159 Data export request completion p95",
      "text": "Data export request completion p95. Target: <= 24 hours. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "data",
        "export",
        "request",
        "completion",
        "p95"
      ],
      "kpis": [
        "KDB-159"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-160",
      "kind": "micro-kpi",
      "title": "KDB-160 Break-glass access audit coverage",
      "text": "Break-glass access audit coverage. Target: 100%. Family: 151-160: Security, Compliance, and Secrets.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "151-160:-security,-compliance,-and-secrets",
        "break-glass",
        "access",
        "audit",
        "coverage"
      ],
      "kpis": [
        "KDB-160"
      ],
      "anchor": "151-160-security-compliance-and-secrets"
    },
    {
      "id": "micro-kpi-kdb-161",
      "kind": "micro-kpi",
      "title": "KDB-161 RED metrics coverage for public API routes",
      "text": "RED metrics coverage for public API routes. Target: 100%. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "red",
        "metrics",
        "coverage",
        "public",
        "api",
        "routes"
      ],
      "kpis": [
        "KDB-161"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-162",
      "kind": "micro-kpi",
      "title": "KDB-162 USE metrics coverage for engine resources",
      "text": "USE metrics coverage for engine resources. Target: 100%. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "use",
        "metrics",
        "coverage",
        "engine",
        "resources"
      ],
      "kpis": [
        "KDB-162"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-163",
      "kind": "micro-kpi",
      "title": "KDB-163 Trace correlation across edge, admin, and origin",
      "text": "Trace correlation across edge, admin, and origin. Target: >= 95% sampled requests. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "trace",
        "correlation",
        "across",
        "edge",
        "admin",
        "origin"
      ],
      "kpis": [
        "KDB-163"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-164",
      "kind": "micro-kpi",
      "title": "KDB-164 Slow query log capture threshold accuracy",
      "text": "Slow query log capture threshold accuracy. Target: 100% over threshold. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "slow",
        "query",
        "log",
        "capture",
        "threshold",
        "accuracy"
      ],
      "kpis": [
        "KDB-164"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-165",
      "kind": "micro-kpi",
      "title": "KDB-165 Alert noise ratio",
      "text": "Alert noise ratio. Target: <= 10% non-actionable alerts. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "alert",
        "noise",
        "ratio"
      ],
      "kpis": [
        "KDB-165"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-166",
      "kind": "micro-kpi",
      "title": "KDB-166 Incident detection p95 after SLO burn",
      "text": "Incident detection p95 after SLO burn. Target: <= 2 min. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "incident",
        "detection",
        "p95",
        "after",
        "slo",
        "burn"
      ],
      "kpis": [
        "KDB-166"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-167",
      "kind": "micro-kpi",
      "title": "KDB-167 Incident page creation p95",
      "text": "Incident page creation p95. Target: <= 5 min. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "incident",
        "page",
        "creation",
        "p95"
      ],
      "kpis": [
        "KDB-167"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-168",
      "kind": "micro-kpi",
      "title": "KDB-168 Customer-facing status update p95",
      "text": "Customer-facing status update p95. Target: <= 15 min. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "customer-facing",
        "status",
        "update",
        "p95"
      ],
      "kpis": [
        "KDB-168"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-169",
      "kind": "micro-kpi",
      "title": "KDB-169 Post-incident action item closure",
      "text": "Post-incident action item closure. Target: >= 90% within 14 days. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "post-incident",
        "action",
        "item",
        "closure"
      ],
      "kpis": [
        "KDB-169"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-170",
      "kind": "micro-kpi",
      "title": "KDB-170 Metrics cardinality budget breaches",
      "text": "Metrics cardinality budget breaches. Target: 0 per release. Family: 161-170: Observability, SLOs, and Incidents.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "161-170:-observability,-slos,-and-incidents",
        "metrics",
        "cardinality",
        "budget",
        "breaches"
      ],
      "kpis": [
        "KDB-170"
      ],
      "anchor": "161-170-observability-slos-and-incidents"
    },
    {
      "id": "micro-kpi-kdb-171",
      "kind": "micro-kpi",
      "title": "KDB-171 Postgres migration row copy throughput",
      "text": "Postgres migration row copy throughput. Target: >= 50k rows/sec. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "postgres",
        "migration",
        "row",
        "copy",
        "throughput"
      ],
      "kpis": [
        "KDB-171"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-172",
      "kind": "micro-kpi",
      "title": "KDB-172 Postgres FK rewrite correctness",
      "text": "Postgres FK rewrite correctness. Target: 100% golden schemas. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "postgres",
        "fk",
        "rewrite",
        "correctness"
      ],
      "kpis": [
        "KDB-172"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-173",
      "kind": "micro-kpi",
      "title": "KDB-173 Supabase migration path success",
      "text": "Supabase migration path success. Target: >= 95% supported schemas. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "supabase",
        "migration",
        "path",
        "success"
      ],
      "kpis": [
        "KDB-173"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-174",
      "kind": "micro-kpi",
      "title": "KDB-174 Mongo document import success",
      "text": "Mongo document import success. Target: >= 95% supported collections. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "mongo",
        "document",
        "import",
        "success"
      ],
      "kpis": [
        "KDB-174"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-175",
      "kind": "micro-kpi",
      "title": "KDB-175 Firebase import success",
      "text": "Firebase import success. Target: >= 90% supported projects. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "firebase",
        "import",
        "success"
      ],
      "kpis": [
        "KDB-175"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-176",
      "kind": "micro-kpi",
      "title": "KDB-176 Algolia search index import coverage",
      "text": "Algolia search index import coverage. Target: >= 90% common settings. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "algolia",
        "search",
        "index",
        "import",
        "coverage"
      ],
      "kpis": [
        "KDB-176"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-177",
      "kind": "micro-kpi",
      "title": "KDB-177 Pinecone/Qdrant vector import recall parity",
      "text": "Pinecone/Qdrant vector import recall parity. Target: >= 0.98. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "pinecone",
        "qdrant",
        "vector",
        "import",
        "recall",
        "parity"
      ],
      "kpis": [
        "KDB-177"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-178",
      "kind": "micro-kpi",
      "title": "KDB-178 Outbound sink delivery success",
      "text": "Outbound sink delivery success. Target: >= 99.9% after retries. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "outbound",
        "sink",
        "delivery",
        "success"
      ],
      "kpis": [
        "KDB-178"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-179",
      "kind": "micro-kpi",
      "title": "KDB-179 Mailgrid email send endpoint success",
      "text": "Mailgrid email send endpoint success. Target: >= 99.5% provider-healthy requests. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "mailgrid",
        "email",
        "send",
        "endpoint",
        "success"
      ],
      "kpis": [
        "KDB-179"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-180",
      "kind": "micro-kpi",
      "title": "KDB-180 Razorpay order/capture/signature test coverage",
      "text": "Razorpay order/capture/signature test coverage. Target: 100% critical flows. Family: 171-180: Migrations, Connectors, and Integrations.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "171-180:-migrations,-connectors,-and-integrations",
        "razorpay",
        "order",
        "capture",
        "signature",
        "test",
        "coverage"
      ],
      "kpis": [
        "KDB-180"
      ],
      "anchor": "171-180-migrations-connectors-and-integrations"
    },
    {
      "id": "micro-kpi-kdb-181",
      "kind": "micro-kpi",
      "title": "KDB-181 Cost per 1M document reads on edge-read profile",
      "text": "Cost per 1M document reads on edge-read profile. Target: <= 25% of equivalent multi-vendor stack. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "cost",
        "per",
        "1m",
        "document",
        "reads",
        "edge-read",
        "profile"
      ],
      "kpis": [
        "KDB-181"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-182",
      "kind": "micro-kpi",
      "title": "KDB-182 Cost per 1M writes on prod-single profile",
      "text": "Cost per 1M writes on prod-single profile. Target: <= 50% of managed BaaS baseline. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "cost",
        "per",
        "1m",
        "writes",
        "prod-single",
        "profile"
      ],
      "kpis": [
        "KDB-182"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-183",
      "kind": "micro-kpi",
      "title": "KDB-183 Memory per 1M small documents excluding payload",
      "text": "Memory per 1M small documents excluding payload. Target: <= 512 MB. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "memory",
        "per",
        "1m",
        "small",
        "documents",
        "excluding",
        "payload"
      ],
      "kpis": [
        "KDB-183"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-184",
      "kind": "micro-kpi",
      "title": "KDB-184 CPU saturation before throughput collapse",
      "text": "CPU saturation before throughput collapse. Target: >= 85% safe utilization. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "cpu",
        "saturation",
        "before",
        "throughput",
        "collapse"
      ],
      "kpis": [
        "KDB-184"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-185",
      "kind": "micro-kpi",
      "title": "KDB-185 Storage overhead over raw JSON plus embeddings",
      "text": "Storage overhead over raw JSON plus embeddings. Target: <= 2.0x. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "storage",
        "overhead",
        "raw",
        "json",
        "plus",
        "embeddings"
      ],
      "kpis": [
        "KDB-185"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-186",
      "kind": "micro-kpi",
      "title": "KDB-186 Object storage backup cost forecast accuracy",
      "text": "Object storage backup cost forecast accuracy. Target: within 10%. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "object",
        "storage",
        "backup",
        "cost",
        "forecast",
        "accuracy"
      ],
      "kpis": [
        "KDB-186"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-187",
      "kind": "micro-kpi",
      "title": "KDB-187 Idle control-plane cost per project",
      "text": "Idle control-plane cost per project. Target: <= $1/month target. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "idle",
        "control-plane",
        "cost",
        "per",
        "project"
      ],
      "kpis": [
        "KDB-187"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-188",
      "kind": "micro-kpi",
      "title": "KDB-188 Cache egress savings on read-heavy workloads",
      "text": "Cache egress savings on read-heavy workloads. Target: >= 60%. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "cache",
        "egress",
        "savings",
        "read-heavy",
        "workloads"
      ],
      "kpis": [
        "KDB-188"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-189",
      "kind": "micro-kpi",
      "title": "KDB-189 Autoscale decision time",
      "text": "Autoscale decision time. Target: <= 60 sec. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "autoscale",
        "decision",
        "time"
      ],
      "kpis": [
        "KDB-189"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-190",
      "kind": "micro-kpi",
      "title": "KDB-190 Capacity forecast error at 30 days",
      "text": "Capacity forecast error at 30 days. Target: <= 20%. Family: 181-190: Cost, Efficiency, and Capacity.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "181-190:-cost,-efficiency,-and-capacity",
        "capacity",
        "forecast",
        "error",
        "30",
        "days"
      ],
      "kpis": [
        "KDB-190"
      ],
      "anchor": "181-190-cost-efficiency-and-capacity"
    },
    {
      "id": "micro-kpi-kdb-191",
      "kind": "micro-kpi",
      "title": "KDB-191 Time from install to first write",
      "text": "Time from install to first write. Target: <= 5 min. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "time",
        "install",
        "first",
        "write"
      ],
      "kpis": [
        "KDB-191"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-192",
      "kind": "micro-kpi",
      "title": "KDB-192 Time from deploy wizard start to live database",
      "text": "Time from deploy wizard start to live database. Target: <= 10 min certified providers. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "time",
        "deploy",
        "wizard",
        "start",
        "live",
        "database"
      ],
      "kpis": [
        "KDB-192"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-193",
      "kind": "micro-kpi",
      "title": "KDB-193 Time from live database to first search query",
      "text": "Time from live database to first search query. Target: <= 3 min. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "time",
        "live",
        "database",
        "first",
        "search",
        "query"
      ],
      "kpis": [
        "KDB-193"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-194",
      "kind": "micro-kpi",
      "title": "KDB-194 Docs task success rate for top 20 workflows",
      "text": "Docs task success rate for top 20 workflows. Target: >= 90%. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "docs",
        "task",
        "success",
        "rate",
        "top",
        "20",
        "workflows"
      ],
      "kpis": [
        "KDB-194"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-195",
      "kind": "micro-kpi",
      "title": "KDB-195 New user activation rate",
      "text": "New user activation rate. Target: >= 35% create collection plus API key. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "new",
        "user",
        "activation",
        "rate"
      ],
      "kpis": [
        "KDB-195"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-196",
      "kind": "micro-kpi",
      "title": "KDB-196 Migration trial completion rate",
      "text": "Migration trial completion rate. Target: >= 25% of started imports. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "migration",
        "trial",
        "completion",
        "rate"
      ],
      "kpis": [
        "KDB-196"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-197",
      "kind": "micro-kpi",
      "title": "KDB-197 Support tickets per 100 active projects",
      "text": "Support tickets per 100 active projects. Target: <= 5/month. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "support",
        "tickets",
        "per",
        "100",
        "active",
        "projects"
      ],
      "kpis": [
        "KDB-197"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-198",
      "kind": "micro-kpi",
      "title": "KDB-198 Enterprise security review pass rate",
      "text": "Enterprise security review pass rate. Target: >= 80% without custom work. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "enterprise",
        "security",
        "review",
        "pass",
        "rate"
      ],
      "kpis": [
        "KDB-198"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-199",
      "kind": "micro-kpi",
      "title": "KDB-199 Multi-service replacement proof points",
      "text": "Multi-service replacement proof points. Target: >= 10 public case studies. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "multi-service",
        "replacement",
        "proof",
        "points"
      ],
      "kpis": [
        "KDB-199"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "micro-kpi-kdb-200",
      "kind": "micro-kpi",
      "title": "KDB-200 Net revenue retention target for managed offering",
      "text": "Net revenue retention target for managed offering. Target: >= 120%. Family: 191-200: Product Moat, DX, and Business Health.",
      "source": "docs/scale/200-micro-kpis.md",
      "tags": [
        "micro-kpi",
        "191-200:-product-moat,-dx,-and-business-health",
        "net",
        "revenue",
        "retention",
        "target",
        "managed",
        "offering"
      ],
      "kpis": [
        "KDB-200"
      ],
      "anchor": "191-200-product-moat-dx-and-business-health"
    },
    {
      "id": "roadmap-01-north-star",
      "kind": "roadmap-section",
      "title": "North Star",
      "text": "Build KynetraDB into a portable backend platform: Data plane: KynetraDB engine and HTTP server. One log, many query shapes, Supabase shaped APIs, search/vector built in, native file durability by default, and optional external deployment adapters. Control plane: Super Admin. Orgs, projects, clusters, provider accounts, deploys, backups, health, audit, billing hooks, agentic operations. Deployment fabric: certified deploy profiles for AWS, GCP, Azure, Cloudflare gateway, Fly, Render, Railway, DigitalOcean, Heroku, Oracle, Linode/Akamai, Vultr, plus manifest first support for Kubernetes, Hetzner, Alibaba Cloud, Scaleway, E2E, ESDS, CtrlS, Sify, and Hostinger India. Scale model: start single writer per shard, scale reads with replicas, scale boot with checkpoints, scale vectors with HNSW/pgvector, scale writes by sharding log groups. Do not ship unsafe multi writer behavior.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "north",
        "star"
      ],
      "kpis": [],
      "anchor": "north-star"
    },
    {
      "id": "roadmap-02-current-baseline",
      "kind": "roadmap-section",
      "title": "Current Baseline",
      "text": "Grounded in the current tree, not in the marketing docs. Re verified 2026 08 16 against 056ce9f by running searches and tests, not by reading this table. Six rows previously listed capabilities as gaps that already ship — see docs/kynetradb feature audit.md for the per row evidence and docs/KYNETRADB 10X PLAN.md §0 for why that mattered. Every \"Gap\" below survived that pass. Area Current state Gap Core engine Universal Log, file and Postgres storage, in memory personalities, per kind secondary indexes ( tests/kind index.rs ), automatic delta chain compaction ( checkpoint.rs:249 ) shard routing Boot speed checkpoint snapshot exists and replays tail only checkpoint needs admin controls and observability Search BM25 in process — p99 2.305 ms @ 5M docs against an 8 ms gate ( 2026 07 12 bm25 scale.json ); fuzzy + synonym expansion + Levenshtein 1 ( search.rs:560 ) labelled corpus relevance (real NDCG); latency is not a bottleneck Vector HNSW and SPANN, persisted ( hnsw incremental and persistent ), automatic rebuild on write threshold ( maybe compact , wired at engine.rs:2394/2474/3947 ), RaBitQ + Caustic + int8/binary quantization, pgvector offload. Gate met at 1M: p99 0.514 ms at recall@10 0.999 ( 2026 07 12 vector scale.json ) vector sharding; proof above 1M; SPANN posting GC Replicas KYNETRA ROLE=replica , WAL fan out, write proxy middleware — staleness p99 17 ms , lag 0 records ( 2026 07 12 replication lag.json ) gateway level replica pool and read routing (env vars exist in the CF worker; nothing in crates/ ) Ops /healthz , /readyz , metrics, audit log, provider circuit breakers, ADR 018 lease election + term fencing reconciler, failover orchestration, SLO automation Providers 14 API provider adapters plus conservative capability/runtime profile metadata in crates/providers certification tests, consistent resize Deploy docs 19 documented targets \"certified\" smoke tests per target Native distribution versioned standalone config, init/start/status/install , Docker, s",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "current",
        "baseline"
      ],
      "kpis": [],
      "anchor": "current-baseline"
    },
    {
      "id": "roadmap-03-competitive-moat",
      "kind": "roadmap-section",
      "title": "Competitive Moat",
      "text": "KynetraDB should compete against the stack, not against one incumbent in its strongest category. Competitor What they own KynetraDB moat PostgreSQL SQL, reliability, extensions, trust app native search/vector/realtime/files/auth while still allowing Postgres as a backend or sink MongoDB document model and cloud developer UX open deploy anywhere data plane with richer app platform primitives Azure Cosmos DB managed Azure native global NoSQL Cosmos like product surface without Azure only deployment DynamoDB AWS native serverless scale richer queries, local development, search/vector, and multi cloud portability Redis low latency cache/realtime durable realtime and cache like reads from the primary database Elasticsearch BM25 and hybrid search built in app search without operating a separate search cluster Qdrant/Pinecone vector retrieval vector search plus documents, files, permissions, events, and agents Firebase/Supabase fast app backend experience familiar APIs backed by KynetraDB's own portable engine CockroachDB distributed SQL app native data services and simpler runtime profile deployment Snowflake warehouse analytics and enterprise AI search operational AI app data, not warehouse first analytics The defensible layers: 1. Open cloud portability: one binary and one admin model across local, Docker, Azure, AWS, GCP, Cloudflare gateway, Kubernetes, and VMs. 2. Unified AI app data model: JSON documents, vectors, full text, files, events, permissions, realtime, and agent state in one database surface. 3. Familiar UX with a new engine: collections, indexes, API keys, users, regions, backups, metrics, and logs feel familiar while the Universal Log stays the source of truth. 4. Local first to fleet scale: dev starts with one binary; production grows through runtime profiles; managed fleets operate through Super Admin. 5. Agent native operations: agents get scoped tools, memory collections, approval gates, retrieval policies, and audit trails as first class features. Av",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "competitive",
        "moat"
      ],
      "kpis": [],
      "anchor": "competitive-moat"
    },
    {
      "id": "roadmap-04-architecture-decision",
      "kind": "roadmap-section",
      "title": "Architecture Decision",
      "text": "The architecture is three layers. Key rule: the data plane must stay useful as a single binary. The control plane may become large, multi tenant, and cloud aware. Those concerns should not leak into the engine kernel. The distributed target is defined by [ ADR 003 ](docs/decisions/ADR 003 cell based distributed architecture.md): bounded cells containing consensus backed shard groups, an owned MVCC segment store, and transaction aware secondary indexes. The [64 architecture quality gates](docs/scale/architecture quality gates.md) are the proof contract for this roadmap.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "architecture",
        "decision"
      ],
      "kpis": [],
      "anchor": "architecture-decision"
    },
    {
      "id": "roadmap-05-runtime-profiles",
      "kind": "roadmap-section",
      "title": "Runtime Profiles",
      "text": "Every deploy target should support one or more explicit runtime profiles. Profile Use case Shape Scale ceiling dev single local/dev/demo one native process or container, file WAL laptop sized prod single small production one primary, durable volume, backups one writer, vertical scale pg ha read serious production primary + N replicas, shared Postgres log read scale, one writer ha cell regional production three voter consensus shard groups automatic regional failover edge read global reads origin + Cloudflare/Fly/read cache very high read throughput sharded ha billion record tier N consensus backed shard groups across cells horizontal reads and writes managed cloud hosted KynetraDB control plane created isolated data planes business scale The Super Admin should create profiles, not raw servers. Raw provider fields remain available for escape hatches, but the product should guide users toward profiles that are known to work.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "runtime",
        "profiles"
      ],
      "kpis": [],
      "anchor": "runtime-profiles"
    },
    {
      "id": "roadmap-06-super-admin-scope",
      "kind": "roadmap-section",
      "title": "Super Admin Scope",
      "text": "Super Admin is the product surface that can make KynetraDB feel 100x stronger than a bare database binary. Minimum modules: Module Owns Organizations orgs, projects, members, roles, invitations Provider Vault encrypted AWS/GCP/etc credentials, capability discovery Clusters create, deploy, resize, delete, connect strings, runtime profiles Fleet Health health, lag, logs, metrics, SLOs, incidents Backups snapshots, PITR, restore to new, cross region copy Data Studio project scoped visual records, KynQL typed plans, collections, indexes, and future search/vector stages Security MFA, scoped keys, audit trail, break glass access, IP allowlists Migrations import from Postgres, Supabase, PocketBase, Firebase, Mongo, Algolia, Pinecone Agents safe operational agents with approvals and audited tool calls Billing Hooks usage metering, plan limits, invoices via external billing provider Control plane data should live in a dedicated KynetraDB control cluster. Customer data planes stay isolated per project or cluster. That separation is non negotiable for enterprise trust.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "super",
        "admin",
        "scope"
      ],
      "kpis": [],
      "anchor": "super-admin-scope"
    },
    {
      "id": "roadmap-07-foundry-metrics-map",
      "kind": "roadmap-section",
      "title": "Foundry Metrics Map",
      "text": "Foundry Metrics is the operating board for the 200 micro KPI scorecard in [docs/scale/200 micro kpis.md](docs/scale/200 micro kpis.md). The admin Metrics & SLO page should not only show p50/p95/p99 rows; it should group live telemetry into KPI families, show which targets have baselines, and expose which roadmap phase owns the next improvement. Timestamped application path evidence is a separate input class. Admin V2 now reads committed kynetra.application benchmark/v1 records through an authenticated, read only endpoint and renders them below engine metrics. The 2026 07 21 Camera Demo Store record is the reference: it measures Cloudflare, public HTTPS, KynetraDB, and KV over 17,790 products, so its cold/warm latency must never be presented as an engine only baseline or competitor comparison. The metric loop is: 1. Map each signal to a KPI range. 2. Baseline the current value from live route metrics, benchmarks, or deploy certification tests. 3. Gate the relevant roadmap phase on the target. 4. Regress the build or release if a gate gets worse. Foundry family KPI range Live signal Roadmap owner Kernel I/O KDB 001..020 WAL/write latency, route p99, write throughput Phase 0, Phase 4 Boot + documents KDB 021..040 ready time, replay rate, JSON filter p95/p99 Phase 4 Indexes + BM25 KDB 041..060 index build time, /v1/search p95/p99, relevance suite Phase 4 Vector + realtime KDB 061..080 /v1/vector , /v1/hybrid , /v1/changes , SSE lag Phase 3, Phase 4 Auth + files KDB 081..100 auth p99, signed URL p99, storage success rate Phase 1, Phase 6 APIs + Foundry UX KDB 101..120 REST compatibility, admin LCP/INP, route error rate Phase 1 Deploy + replicas KDB 121..140 deploy smoke tests, replica lag, failover detection Phase 2, Phase 3 Backup + security KDB 141..160 backup success, restore drills, audit and secret rotation Phase 4, Phase 6 Observability + integrations KDB 161..180 RED/USE coverage, slow query capture, sink success Phase 0, Phase 6 Cost + moat KDB 181..200 cost per",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "foundry",
        "metrics",
        "map"
      ],
      "kpis": [],
      "anchor": "foundry-metrics-map"
    },
    {
      "id": "roadmap-08-foundry-rag-ingestion",
      "kind": "roadmap-section",
      "title": "Foundry RAG Ingestion",
      "text": "Foundry reads the same operating material humans review. The static Cloudflare Foundry site now generates deploy/cloudflare foundry/dist/foundry rag corpus.json from the public Foundry terminology page, this roadmap, and the docs/scale/200 micro kpis.md scorecard. It also ingests the tracked benchmarks/evidence/latest.json snapshot and maps every workload through benchmarks/foundry map.json . The proposed KDT standard adds 300 stable database developer terms from docs/standards/kdt registry.mjs , governed by docs/standards/KDT 000 database developer terminology.md . The page side retrieval panel uses that corpus to answer with cited chunks across terms, KPI IDs, targets, roadmap sections, benchmark evidence, and candidate experiments. The proposed Kynetra Foundry Operating ( KFO ) vocabulary adds 40 governance terms from [docs/scale/foundry operating terminology.md](docs/scale/foundry operating terminology.md). KFO keeps capability maturity, evidence scope, measurement state, proof state, and delivery state separate; it does not promote any capability by itself. Foundry RAG ingests the canonical KFO document as 40 unique foundry operating term chunks ( KFO 001..040 ) with deterministic validation for count, uniqueness, numeric order, and family parsing. The ingestion contract is intentionally small: every chunk has id , kind , title , text , source , tags , and kpis . That keeps future LLM, vector, or agent readers compatible with the current local lexical search. deploy/cloudflare foundry/dist/foundry benchmark ingest.jsonl exposes the benchmark subset to external RAG and agent pipelines. Every benchmark run refreshes both outputs after normalizing Criterion data. Baseline comparison is valid only when the declared environment, dataset, durability, and workload semantics match; correctness and retrieval quality remain independent gates. The build also publishes deploy/cloudflare foundry/dist/database developer terminology.json so the browser and external agents con",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "foundry",
        "rag",
        "ingestion"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "roadmap-09-foundry-operating-terminology",
      "kind": "roadmap-section",
      "title": "Foundry Operating Terminology",
      "text": "The public Foundry terminology surface should teach the same words used in roadmap reviews. These terms make micro KPI discussions short, testable, and portable across agents, operators, and engineers. The canonical definitions and stable KFO 001..040 identifiers live in the [Foundry Operating Terminology](docs/scale/foundry operating terminology.md), governed by [ADR 021](docs/decisions/ADR 021 foundry operating vocabulary.md). The table below remains the short metric oriented view. Term Meaning in roadmap reviews KPI tie in SIGNAL A measured value from live telemetry, benchmark, deploy smoke, or probe. Evidence source for any KPI BASELINE The first trusted current value before claiming progress. KPI state: baseline TARGET The measurable value KynetraDB is trying to hit. KPI state: target GATE A condition that must pass before a release, provider, or phase is done. KPI state: gate REGRESSION A KPI moving the wrong way against its baseline or target. CI/release block TAIL p95/p99/max behavior; means never replace tail latency with averages. Route SLO and latency KPIs SEAL P99 Durable Universal Log append p99 with fsync enabled. KDB 001..002 REPLAY RATE Records per second applied during boot, restore, or replica catch up. KDB 021..030 INDEX COVERAGE Share of real queries served by scalar, BM25, vector, or hybrid indexes. KDB 041..060 RECALL Retrieval quality for BM25/vector/hybrid against a golden set. KDB 063 , KDB 069 LAG Primary to replica or origin to edge freshness distance. KDB 131..132 PURGE SPAN Time from mutation to safe cache invalidation at the edge. KDB 136 RPO Maximum committed data allowed to be lost in disaster recovery. KDB 150 RTO Time allowed to restore service after failover or restore to new. KDB 137..138 , KDB 144 COST ENVELOPE Allowed cost range before stack compression advantage is lost. KDB 181..190 ACTIVATION CLOCK Time from first contact to first useful database action. KDB 191..193 PROOF POINT Customer evidence that KynetraDB replaced real",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "foundry",
        "operating",
        "terminology"
      ],
      "kpis": [],
      "anchor": "foundry-operating-terminology"
    },
    {
      "id": "roadmap-11-tier-1-certified-api-deploy",
      "kind": "roadmap-section",
      "title": "Tier 1: certified API deploy",
      "text": "These must have automated smoke tests and real lifecycle operations: 1. AWS App Runner first, ECS/Fargate manifest second 2. GCP Cloud Run 3. Azure Container Apps 4. Fly.io 5. Render 6. Railway 7. DigitalOcean 8. Heroku 9. Oracle Cloud 10. Linode/Akamai 11. Vultr 12. Cloudflare gateway in front of a real origin",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "tier",
        "certified",
        "api",
        "deploy"
      ],
      "kpis": [],
      "anchor": "tier-1-certified-api-deploy"
    },
    {
      "id": "roadmap-12-tier-2-storage-control-integrations",
      "kind": "roadmap-section",
      "title": "Tier 2: storage/control integrations",
      "text": "These are not necessarily KynetraDB container hosts, but they matter: Supabase and Neon as Postgres log backends Cloudflare R2, AWS S3, GCS, Azure Blob for backups/files Upstash Redis as optional cache/session backend Kubernetes Helm for EKS/GKE/AKS/self hosted clusters",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "tier",
        "storage",
        "control",
        "integrations"
      ],
      "kpis": [],
      "anchor": "tier-2-storage-control-integrations"
    },
    {
      "id": "roadmap-13-tier-3-manifest-first-sovereign-and-budget-clouds",
      "kind": "roadmap-section",
      "title": "Tier 3: manifest-first sovereign and budget clouds",
      "text": "Keep docs and setup scripts strong even when API automation is thin: Hetzner, Alibaba Cloud, Scaleway E2E Networks, ESDS, CtrlS, Sify, Hostinger India Do not pretend every provider has the same maturity. The UI should show validated , deploy , list , destroy , resize , logs , metrics , and backup capabilities per provider.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "tier",
        "manifest-first",
        "sovereign",
        "budget",
        "clouds"
      ],
      "kpis": [],
      "anchor": "tier-3-manifest-first-sovereign-and-budget-clouds"
    },
    {
      "id": "roadmap-14-priority-0-standalone-database-distribution",
      "kind": "roadmap-section",
      "title": "Priority 0 - Standalone Database Distribution",
      "text": "The native database is ahead of the proof applications in the dependency order. An app cannot prove KynetraDB if its durable state actually belongs to Postgres, D1, Supabase, Neon, or the app itself. Implemented distribution foundation: versioned kynetra.toml with native storage.backend = \"file\" ; API keys stored outside the config with restrictive file permissions; kynetra init , start , status , and staged/testable Linux install ; separate kynetra and kynetra server binaries; hardened kynetradb.service , Docker/Podman image, WHM installer, Debian/RPM, Homebrew, Scoop, Chocolatey, and Snap release templates; a release workflow for Linux x86 64/arm64, macOS Intel/Apple Silicon, and Windows x86 64 archives. Next release gates, in order: 1. Signed release archives and checksums published from clean tags. 2. Install, upgrade, rollback, and uninstall certification on each OS family. 3. Stable on disk format migration tooling and corruption diagnostics. 4. Online backup plus restore to new using only KynetraDB owned formats. 5. Transaction crash matrix certification and MVCC snapshot reads before Commerce GA. 6. Owned replication and failover before any native HA claim.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "priority",
        "standalone",
        "database",
        "distribution"
      ],
      "kpis": [],
      "anchor": "priority-0-standalone-database-distribution"
    },
    {
      "id": "roadmap-15-five-app-proof-suite",
      "kind": "roadmap-section",
      "title": "Five-App Proof Suite",
      "text": "The product suite follows the standalone distribution and storage integrity gates, then turns database claims into application workloads. These are independent clients of standalone KynetraDB, never embedded parts of the engine. The machine readable proof contract lives at product suite/capability matrix.json . App Workload Current status Engine proof Kynetra Notes offline sync vertical slice stable IDs, local mutation queue, deterministic conflict order, real entity API round trip Kynetra Pages realtime collaboration vertical slice block editor and entity persistence; co edit protocol, permissions, backlinks, and replay remain Kynetra Grid indexed relational views vertical slice editable rows, formulas, filters, and entity persistence; relations and automatic indexes remain Kynetra Research hybrid retrieval vertical slice source intake, BM25 query, citations, and provenance; chunking and evaluated hybrid RAG remain Kynetra Commerce transactional inventory vertical slice one guarded checkout commits inventory and order in one native transaction; MVCC and distributed transactions remain All five applications now have independently buildable vertical slices. Notes proves offline mutation handling. Pages, Grid, and Research persist or query through the shared typed client when configured. Commerce exercises the native conditional transaction endpoint with a durable idempotency key. None of these vertical slices promotes the remaining proof targets to benchmark evidence. Proof targets are not benchmark results. A target changes to evidence only when its workload, environment, raw output, and commit are recorded together.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "five-app",
        "proof",
        "suite"
      ],
      "kpis": [],
      "anchor": "five-app-proof-suite"
    },
    {
      "id": "roadmap-17-phase-0a-moat-surface",
      "kind": "roadmap-section",
      "title": "Phase 0A - Moat Surface",
      "text": "Goal: make the competitive wedge visible in the product, API, and docs. Deliverables: Collection model that clearly supports documents, typed fields, text indexes, vector fields, file references, event subscriptions, and permissions. Query docs for filter , search , vector search , and future hybrid search . Admin pages for indexes, API keys, users, backups, health, and deployment profiles that feel familiar to Cosmos/Mongo/Firebase/Supabase users. Competitor aware migration stories for Postgres, Mongo, Firebase, Supabase, Algolia, Pinecone/Qdrant, and Cosmos style document apps. Public docs that separate \"implemented\", \"partial\", and \"roadmap\" claims. Acceptance: A new user can understand why KynetraDB replaces a multi service AI app stack within the first five minutes. The docs do not imply KynetraDB is already more mature than Cosmos DB, MongoDB Atlas, DynamoDB, or PostgreSQL.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "0a",
        "moat",
        "surface"
      ],
      "kpis": [],
      "anchor": "phase-0a-moat-surface"
    },
    {
      "id": "roadmap-18-phase-0-truth-contracts-and-release-gates",
      "kind": "roadmap-section",
      "title": "Phase 0 - Truth, Contracts, and Release Gates",
      "text": "Goal: stop roadmap drift and make every future claim testable. Deliverables: Maintain ProviderCapability and RuntimeProfile metadata as providers mature. Keep cluster creation driven by runtime profiles instead of raw provider knobs. Add a deployment certification harness: create, health check, write, read, backup smoke, destroy. Update docs so \"implemented\", \"partial\", and \"roadmap\" are never mixed. Release gate: cargo build workspace plus provider neutral tests must pass. Acceptance: Super Admin can tell the user exactly what a provider supports. A deploy target is not called certified until the smoke test has passed.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "truth",
        "contracts",
        "release",
        "gates"
      ],
      "kpis": [],
      "anchor": "phase-0-truth-contracts-and-release-gates"
    },
    {
      "id": "roadmap-19-phase-1-super-admin-mvp",
      "kind": "roadmap-section",
      "title": "Phase 1 - Super Admin MVP",
      "text": "Goal: make KynetraDB operable as a product, not just a binary. Deliverables: Orgs, projects, members, roles, invitations. Provider Vault with encrypted credentials and credential validation. Cluster CRUD around runtime profiles, with provider certification gates. Fleet health page with /healthz , /readyz , lag, p50/p95/p99, and error rate. Chained audit log for every admin mutation. Agent approval model for destructive operations. Durable agent harness foundation from accepted [ADR 016](docs/decisions/ADR 016 durable agent harness context.md): scoped sessions, append only run events, fenced leases and checkpoints, typed memory, context budgets, and versioned action effect contracts. Acceptance: From Super Admin, create a project, register AWS or GCP, deploy a cluster, get a connection URL, write/read data, see health, and destroy it.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "super",
        "admin",
        "mvp"
      ],
      "kpis": [],
      "anchor": "phase-1-super-admin-mvp"
    },
    {
      "id": "roadmap-20-phase-2-multi-cloud-certification",
      "kind": "roadmap-section",
      "title": "Phase 2 - Multi-Cloud Certification",
      "text": "Goal: GCP, AWS, and at least 10 other targets are actually deployable. Deliverables: Certified prod single on AWS, GCP, Azure, Fly, Render, Railway, DigitalOcean, Heroku, Oracle, Linode, Vultr, and Kubernetes. Cloudflare gateway profile for cached global reads. Neon/Supabase Postgres backend profile for stateless containers. Provider docs generated from the same capability metadata used by the UI. Acceptance: Every Tier 1 target has a repeatable smoke test. Failed deploys produce actionable errors, not raw provider JSON.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "multi-cloud",
        "certification"
      ],
      "kpis": [],
      "anchor": "phase-2-multi-cloud-certification"
    },
    {
      "id": "roadmap-21-phase-3-ha-read-scale",
      "kind": "roadmap-section",
      "title": "Phase 3 - HA Read Scale",
      "text": "Goal: scale reads without breaking the single writer safety model. Deliverables: Gateway level replica pool with lag aware routing. Read/write classifier for /rest/v1 , /v1 , storage metadata reads, search, and vector reads. Replica lag budgets and automatic removal from the read pool. Primary write proxy remains explicit and observable. Edge cache invalidation hooks for safe cacheable reads. Acceptance: One primary plus N replicas can survive a replica loss with no write loss. Reads distribute across healthy replicas and avoid stale replicas.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "ha",
        "read",
        "scale"
      ],
      "kpis": [],
      "anchor": "phase-3-ha-read-scale"
    },
    {
      "id": "roadmap-22-phase-4-index-and-storage-maturity",
      "kind": "roadmap-section",
      "title": "Phase 4 - Index and Storage Maturity",
      "text": "Goal: build the transaction and persisted storage kernel required before HA. Deliverables: Checksummed WAL v3 with corruption tooling and crash fault corpus. Atomic transaction envelopes, conditional writes, and durable idempotency receipts are implemented for the serialized single process engine. The crash corpus and formal serializability history remain release gates. MVCC snapshots, immutable sorted segments, manifest, compaction, version GC, and bounded block cache. Admin visible checkpoint status, force checkpoint route, checkpoint restore tests. Transaction aware scalar, BM25, and vector indexes with consistency watermarks. Backup to S3/R2/GCS/Azure Blob and restore to new cluster. Acceptance: Recovery time is bounded by snapshot plus tail, not total historical WAL. Single shard histories pass the serializability and crash matrix. Vector search has a tested path to 10M+ vectors per shard.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "index",
        "storage",
        "maturity"
      ],
      "kpis": [],
      "anchor": "phase-4-index-and-storage-maturity"
    },
    {
      "id": "roadmap-23-phase-5-consensus-cells-and-sharded-fleet",
      "kind": "roadmap-section",
      "title": "Phase 5 - Consensus Cells and Sharded Fleet",
      "text": "Goal: add proven HA to one shard, then break the single writer wall safely. Deliverables: One three voter shard group with quorum commit, leader fencing, snapshot install, replica catch up, and automatic failover. Metadata quorum with versioned partition maps and routing epochs. Collection shard key configuration. Hash/range router for writes. Bounded scatter gather for filters, search, vector, and aggregation. Online shard split/move with dual read validation. Cell placement, quotas, admission control, and hotspot rebalancing. Acceptance: Strong operations pass linearizability checks under partitions and node loss. An acknowledged write survives automatic leader failover. Writes scale with shard count. 1B records are distributed across shard groups with bounded node memory. No cross shard transaction claim exists without a recoverable coordinator.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "consensus",
        "cells",
        "sharded",
        "fleet"
      ],
      "kpis": [],
      "anchor": "phase-5-consensus-cells-and-sharded-fleet"
    },
    {
      "id": "roadmap-24-phase-6-enterprise-and-business-scale",
      "kind": "roadmap-section",
      "title": "Phase 6 - Enterprise and Business Scale",
      "text": "Goal: make this a company scale platform. Deliverables: SOC2 ready audit/export controls. MFA, scoped keys, IP allow/deny, break glass workflows. Project RBAC certification: custom role isolation, expiry, audit, delegated administration, route coverage, and no elevation proofs. Usage metering: requests, storage, replicas, backup bytes, egress estimates. Plans and quotas enforced at the control plane and gateway. Migration concierge flows for Supabase, PocketBase, Firebase, Mongo, Algolia, Pinecone, and Postgres. Marketplace for sinks, providers, and agent actions. DPDP purpose notices, consent/withdrawal receipts, rights workflow, breach clocks, residency policy, and legal hold aware retention enforcement. Acceptance: Enterprise buyer can run a proof of concept without a maintainer in the loop. Hosted and self hosted deployments share the same data plane binary. DPDP readiness drills cover notice, withdrawal, rights, breach, retention, residency, processor deletion, and audit evidence without claiming legal certification.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h3",
        "phase",
        "enterprise",
        "business",
        "scale"
      ],
      "kpis": [],
      "anchor": "phase-6-enterprise-and-business-scale"
    },
    {
      "id": "roadmap-25-database-2050-capability-gates",
      "kind": "roadmap-section",
      "title": "Database 2050 Capability Gates",
      "text": "The 100 capability kynetra.database capabilities/v1 catalog turns long range architecture into statused release gates. Edition 2050.2 records 28 implemented, 28 partial, 34 planned, and 10 research capabilities. Promotion requires the per capability correctness, scale, security, or interoperability gate; roadmap text alone cannot change status. Immediate enterprise priorities: 1. Enforce retention with legal holds, dry run evidence, and processor deletion. 2. Enforce India residency in KynetraDeploy for compute, replicas, backups, logs, and telemetry. 3. Certify the native transaction envelope under crash faults, then add MVCC before distributed ACID claims. 4. Certify cross repository contracts for AIStudio, FX, Deploy, Pods, Prime, and QuantumOS; add the QuantumOS receiver, durable outbox, replay, and dead letter tests before claiming guaranteed event delivery. 5. Promote restore proven backups and cryptographic integrity from partial to implemented. 6. Replace the dedicated Postgres connection with a measured adaptive pooler. 7. Schedule encrypted cross region backups and prove restore to new continuously. 8. Gate auto heal on fault diagnosis, fencing, rollback, and no unsafe write evidence. 9. Promote field lineage, legal holds, classification, and portable evidence packs. 10. Certify secure startup, admission control, structured logging, and secret rotation in every deployment profile.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "database",
        "2050",
        "capability",
        "gates"
      ],
      "kpis": [],
      "anchor": "database-2050-capability-gates"
    },
    {
      "id": "roadmap-26-billion-scale-targets",
      "kind": "roadmap-section",
      "title": "Billion-Scale Targets",
      "text": "These are engineering targets, not marketing claims. Target Architecture path 1B requests/day edge cache + read replicas + route level caching 1B records shard groups + checkpoint boot + object backups 10M vectors/shard persisted HNSW or pgvector per shard 99.9% single region health checks + backups + controlled restore 99.95% HA read primary + replicas + lag aware routing 99.99% enterprise multi AZ data planes + tested failover + restore drills",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "billion-scale",
        "targets"
      ],
      "kpis": [],
      "anchor": "billion-scale-targets"
    },
    {
      "id": "roadmap-27-business-scale-plan",
      "kind": "roadmap-section",
      "title": "Business Scale Plan",
      "text": "The billion dollar path is wedge first, platform second. 1. Wedge: \"Supabase for commerce and AI apps, deployable anywhere.\" Replace a stack of Postgres + Redis + Algolia + Pinecone + admin scripts. 2. Early buyers: agencies, Shopify/WooCommerce operators, AI product teams, Indian/sovereign cloud teams, and startups that need self hosted BaaS. 3. Open core trust: keep the data plane open and portable. Sell hosted control plane, enterprise security, migrations, support, and managed fleet ops. 4. Expansion: every project starts with database/search/vector, then expands into auth, storage, realtime, agents, backups, compliance, and multi cloud. 5. Retention: migrations in are easy; operations become easier inside Super Admin; switching out means rebuilding database + search + vector + deployment automation. Revenue milestones: Stage Product motion Success signal 0 to 10 customers founder led POCs repeatable migration and deploy story 10 to 100 customers hosted control plane beta clusters created without hand holding 100 to 1,000 customers paid cloud + enterprise self host expansion from one project to many 1,000+ customers marketplace and partner clouds ecosystem creates pull",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "business",
        "scale",
        "plan"
      ],
      "kpis": [],
      "anchor": "business-scale-plan"
    },
    {
      "id": "roadmap-28-things-we-should-not-build-yet",
      "kind": "roadmap-section",
      "title": "Things We Should Not Build Yet",
      "text": "A full SQL engine. Use Postgres as a sink/backend when SQL is the requirement. Same key multi leader writes before partition ownership and conflict semantics are proven. Cross shard transactions before single shard consensus and MVCC are stable. Provider specific hacks inside the engine. A giant \"smart gateway\" claim before a replica pool, cache rules, and tests exist. Billing hooks in the control plane.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "things",
        "we",
        "should",
        "not",
        "build",
        "yet"
      ],
      "kpis": [],
      "anchor": "things-we-should-not-build-yet"
    },
    {
      "id": "roadmap-29-first-execution-order",
      "kind": "roadmap-section",
      "title": "First Execution Order",
      "text": "1. Make format, Clippy, build, test, crash, and benchmark gates release green. 2. Land WAL v3 and MVCC snapshots; harden existing transaction envelopes and idempotency receipts. 3. Persist sorted data/index segments with compaction and bounded caching. 4. Prove one consensus backed shard under network and process faults. 5. Add metadata quorum, routing epochs, split/move, and one multi shard cell. 6. Make BM25/vector indexes incremental, durable, and consistency aware. 7. Certify cell lifecycle on AWS, GCP, Azure, then additional providers. 8. Add global reads and cross shard transactions only after regional proof. This order makes correctness and bounded storage the base, then adds availability, horizontal scale, search maturity, and cloud breadth.",
      "source": "ROAD_TO_1B.md",
      "tags": [
        "roadmap",
        "h2",
        "first",
        "execution",
        "order"
      ],
      "kpis": [],
      "anchor": "first-execution-order"
    },
    {
      "id": "benchmark-evidence-vector-scale-1m-graph-build-secs",
      "kind": "benchmark-evidence",
      "title": "Graph Build Secs benchmark",
      "text": "Graph Build Secs benchmark at 1000000 vectors. Suite: vector_scale_1m; schema: kynetra.benchmark/v1. Environment: Apple M5, 32 GB RAM, macos, scope: local. Metrics: value: 641.135 seconds. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "local"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-target-vector-scale-1m-graph-build-secs",
      "kind": "benchmark-optimization-target",
      "title": "Graph Build Secs next experiments",
      "text": "Candidate experiments; measure correctness and tail latency before promotion. 1. Capture matched baseline, workload envelope, and guardrails before any multiplier claim. 2. Record hardware, OS, dataset, concurrency, durability, and raw samples. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "candidate-experiment"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-evidence-vector-scale-1m-rss-mb-after-build",
      "kind": "benchmark-evidence",
      "title": "Rss Mb After Build benchmark",
      "text": "Rss Mb After Build benchmark at 1000000 vectors. Suite: vector_scale_1m; schema: kynetra.benchmark/v1. Environment: Apple M5, 32 GB RAM, macos, scope: local. Metrics: value: 3736 MiB. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "local"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-target-vector-scale-1m-rss-mb-after-build",
      "kind": "benchmark-optimization-target",
      "title": "Rss Mb After Build next experiments",
      "text": "Candidate experiments; measure correctness and tail latency before promotion. 1. Capture matched baseline, workload envelope, and guardrails before any multiplier claim. 2. Record hardware, OS, dataset, concurrency, durability, and raw samples. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "candidate-experiment"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-evidence-vector-scale-1m-recall-at-10-vs-brute-force",
      "kind": "benchmark-evidence",
      "title": "Recall At 10 Vs Brute Force benchmark",
      "text": "Recall At 10 Vs Brute Force benchmark at 1000000 vectors. Suite: vector_scale_1m; schema: kynetra.benchmark/v1. Environment: Apple M5, 32 GB RAM, macos, scope: local. Metrics: value: 0.999 ratio, queries: 200 count. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "local"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-target-vector-scale-1m-recall-at-10-vs-brute-force",
      "kind": "benchmark-optimization-target",
      "title": "Recall At 10 Vs Brute Force next experiments",
      "text": "Candidate experiments; measure correctness and tail latency before promotion. 1. Capture matched baseline, workload envelope, and guardrails before any multiplier claim. 2. Record hardware, OS, dataset, concurrency, durability, and raw samples. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "candidate-experiment"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-evidence-vector-scale-1m-query-graph-only-ms",
      "kind": "benchmark-evidence",
      "title": "Query Graph Only Ms benchmark",
      "text": "Query Graph Only Ms benchmark at 1000000 vectors. Suite: vector_scale_1m; schema: kynetra.benchmark/v1. Environment: Apple M5, 32 GB RAM, macos, scope: local. Metrics: p50: 0.417 milliseconds, p95: 0.462 milliseconds, p99: 0.514 milliseconds, queries: 1000 count. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "local"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-target-vector-scale-1m-query-graph-only-ms",
      "kind": "benchmark-optimization-target",
      "title": "Query Graph Only Ms next experiments",
      "text": "Candidate experiments; measure correctness and tail latency before promotion. 1. Capture matched baseline, workload envelope, and guardrails before any multiplier claim. 2. Record hardware, OS, dataset, concurrency, durability, and raw samples. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "candidate-experiment"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-evidence-vector-scale-1m-insert-to-searchable-ms",
      "kind": "benchmark-evidence",
      "title": "Insert To Searchable Ms benchmark",
      "text": "Insert To Searchable Ms benchmark at 1000000 vectors. Suite: vector_scale_1m; schema: kynetra.benchmark/v1. Environment: Apple M5, 32 GB RAM, macos, scope: local. Metrics: value: 1.005 milliseconds. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "local"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-target-vector-scale-1m-insert-to-searchable-ms",
      "kind": "benchmark-optimization-target",
      "title": "Insert To Searchable Ms next experiments",
      "text": "Candidate experiments; measure correctness and tail latency before promotion. 1. Capture matched baseline, workload envelope, and guardrails before any multiplier claim. 2. Record hardware, OS, dataset, concurrency, durability, and raw samples. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "candidate-experiment"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-evidence-vector-scale-1m-query-with-10k-delta-ms",
      "kind": "benchmark-evidence",
      "title": "Query With 10k Delta Ms benchmark",
      "text": "Query With 10k Delta Ms benchmark at 1000000 vectors. Suite: vector_scale_1m; schema: kynetra.benchmark/v1. Environment: Apple M5, 32 GB RAM, macos, scope: local. Metrics: p50: 1.323 milliseconds, p99: 1.599 milliseconds. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "local"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "benchmark-target-vector-scale-1m-query-with-10k-delta-ms",
      "kind": "benchmark-optimization-target",
      "title": "Query With 10k Delta Ms next experiments",
      "text": "Candidate experiments; measure correctness and tail latency before promotion. 1. Capture matched baseline, workload envelope, and guardrails before any multiplier claim. 2. Record hardware, OS, dataset, concurrency, durability, and raw samples. Claim boundary: KPI gate: 1M vectors: query p99 < 5 ms at recall@10 >= 0.95; met: true",
      "source": "benchmarks/evidence/latest.json",
      "tags": [
        "benchmark",
        "vector_scale_1m",
        "no-multiplier-claim",
        "candidate-experiment"
      ],
      "kpis": [],
      "anchor": "foundry-rag-ingestion"
    },
    {
      "id": "database-term-kdt-001",
      "kind": "database-developer-term",
      "title": "KDT-001 COMMIT HORIZON",
      "text": "The highest transaction position acknowledged as committed under the declared durability policy. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: COMMIT HORIZON is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "commit",
        "horizon"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-002",
      "kind": "database-developer-term",
      "title": "KDT-002 DURABILITY POINT",
      "text": "The exact event after which an acknowledged mutation survives the promised failure model. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: DURABILITY POINT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "durability",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-003",
      "kind": "database-developer-term",
      "title": "KDT-003 VISIBILITY POINT",
      "text": "The event after which a committed mutation may be observed by eligible readers. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: VISIBILITY POINT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "visibility",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-004",
      "kind": "database-developer-term",
      "title": "KDT-004 TRANSACTION ENVELOPE",
      "text": "The complete set of reads, writes, preconditions, identity, and deadlines in one atomic request. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: TRANSACTION ENVELOPE is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "transaction",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-005",
      "kind": "database-developer-term",
      "title": "KDT-005 MUTATION SET",
      "text": "The ordered collection of record changes proposed for one transaction envelope. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: MUTATION SET is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "mutation",
        "set"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-006",
      "kind": "database-developer-term",
      "title": "KDT-006 READ SNAPSHOT",
      "text": "An immutable database view identified by a stable version or logical time. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: READ SNAPSHOT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "read",
        "snapshot"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-007",
      "kind": "database-developer-term",
      "title": "KDT-007 WRITE INTENT",
      "text": "A provisional claim that a transaction plans to modify a named conflict domain. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: WRITE INTENT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "write",
        "intent"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-008",
      "kind": "database-developer-term",
      "title": "KDT-008 CONFLICT DOMAIN",
      "text": "The smallest key, range, index, or constraint scope that can force transaction serialization. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: CONFLICT DOMAIN is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "conflict",
        "domain"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-009",
      "kind": "database-developer-term",
      "title": "KDT-009 ISOLATION FLOOR",
      "text": "The weakest isolation behavior an operation is permitted to receive. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: ISOLATION FLOOR is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "isolation",
        "floor"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-010",
      "kind": "database-developer-term",
      "title": "KDT-010 ISOLATION CEILING",
      "text": "The strongest isolation behavior an implementation can guarantee for an operation. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: ISOLATION CEILING is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "isolation",
        "ceiling"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-011",
      "kind": "database-developer-term",
      "title": "KDT-011 RETRY TOKEN",
      "text": "A stable caller-supplied identity that makes a repeated mutation detectably idempotent. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: RETRY TOKEN is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "retry",
        "token"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-012",
      "kind": "database-developer-term",
      "title": "KDT-012 COMMIT WITNESS",
      "text": "Durable evidence that identifies the decision, participants, and commit outcome. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: COMMIT WITNESS is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "commit",
        "witness"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-013",
      "kind": "database-developer-term",
      "title": "KDT-013 ABORT CAUSE",
      "text": "A machine-readable reason explaining why a transaction did not commit. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: ABORT CAUSE is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "abort",
        "cause"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-014",
      "kind": "database-developer-term",
      "title": "KDT-014 SAVEPOINT BOUNDARY",
      "text": "A named position inside a transaction to which provisional work may be rolled back. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: SAVEPOINT BOUNDARY is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "savepoint",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-015",
      "kind": "database-developer-term",
      "title": "KDT-015 ATOMIC SCOPE",
      "text": "The explicitly declared records and side effects that succeed or fail together. Normative contract: Implementations using these terms MUST expose transaction boundaries, acknowledgement semantics, retry behavior, and the point at which a mutation becomes durable and visible. Adoption signal: ATOMIC SCOPE is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing. Family: Transactions and Mutation Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "transactions",
        "proposed",
        "atomic",
        "scope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-016",
      "kind": "database-developer-term",
      "title": "KDT-016 CONSISTENCY CONTRACT",
      "text": "The declared visibility and ordering guarantees for a read or write class. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: CONSISTENCY CONTRACT is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "consistency",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-017",
      "kind": "database-developer-term",
      "title": "KDT-017 SESSION FENCE",
      "text": "A token preventing a session from observing state older than its prior acknowledged work. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: SESSION FENCE is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "session",
        "fence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-018",
      "kind": "database-developer-term",
      "title": "KDT-018 READ HORIZON",
      "text": "The newest committed position a read is guaranteed to include. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: READ HORIZON is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "read",
        "horizon"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-019",
      "kind": "database-developer-term",
      "title": "KDT-019 CAUSAL TOKEN",
      "text": "Portable metadata encoding the causal dependencies a later operation must observe. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: CAUSAL TOKEN is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "causal",
        "token"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-020",
      "kind": "database-developer-term",
      "title": "KDT-020 MONOTONIC CURSOR",
      "text": "A progress marker that never moves backward within its declared ordering domain. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: MONOTONIC CURSOR is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "monotonic",
        "cursor"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-021",
      "kind": "database-developer-term",
      "title": "KDT-021 STALENESS BUDGET",
      "text": "The maximum permitted distance between served state and the current commit horizon. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: STALENESS BUDGET is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "staleness",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-022",
      "kind": "database-developer-term",
      "title": "KDT-022 CLOCK UNCERTAINTY",
      "text": "The bounded interval within which the database believes physical time may lie. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: CLOCK UNCERTAINTY is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "clock",
        "uncertainty"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-023",
      "kind": "database-developer-term",
      "title": "KDT-023 VERSION STAMP",
      "text": "An immutable identifier for one logical version of a record or snapshot. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: VERSION STAMP is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "version",
        "stamp"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-024",
      "kind": "database-developer-term",
      "title": "KDT-024 ORDERING DOMAIN",
      "text": "The keys or operations over which one total order is guaranteed. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: ORDERING DOMAIN is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "ordering",
        "domain"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-025",
      "kind": "database-developer-term",
      "title": "KDT-025 FRESHNESS PROOF",
      "text": "Evidence that a response satisfies its requested read horizon or staleness budget. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: FRESHNESS PROOF is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "freshness",
        "proof"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-026",
      "kind": "database-developer-term",
      "title": "KDT-026 CONVERGENCE WINDOW",
      "text": "The bounded time allowed for replicas or indexes to reach equivalent state. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: CONVERGENCE WINDOW is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "convergence",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-027",
      "kind": "database-developer-term",
      "title": "KDT-027 LINEARIZATION POINT",
      "text": "The single logical instant at which a concurrent operation takes effect. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: LINEARIZATION POINT is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "linearization",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-028",
      "kind": "database-developer-term",
      "title": "KDT-028 TEMPORAL LEASE",
      "text": "A time-bounded authority to serve or mutate state under a named epoch. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: TEMPORAL LEASE is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "temporal",
        "lease"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-029",
      "kind": "database-developer-term",
      "title": "KDT-029 HISTORY CUT",
      "text": "A consistent boundary dividing retained history from safely discarded history. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: HISTORY CUT is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "history",
        "cut"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-030",
      "kind": "database-developer-term",
      "title": "KDT-030 CONSISTENCY DOWNGRADE",
      "text": "An explicit transition to weaker guarantees rather than silent semantic erosion. Normative contract: Implementations using these terms MUST declare ordering scope, freshness limits, clock assumptions, and any consistency downgrade in a form clients can inspect and test. Adoption signal: CONSISTENCY DOWNGRADE is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution. Family: Consistency, Ordering, and Time. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "consistency-time",
        "proposed",
        "consistency",
        "downgrade"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-031",
      "kind": "database-developer-term",
      "title": "KDT-031 UNIVERSAL LOG",
      "text": "The authoritative ordered mutation history from which database personalities can be rebuilt. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: UNIVERSAL LOG is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "universal",
        "log"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-032",
      "kind": "database-developer-term",
      "title": "KDT-032 LOG FRAME",
      "text": "A checksummed storage unit containing one or more ordered mutation records. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: LOG FRAME is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "log",
        "frame"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-033",
      "kind": "database-developer-term",
      "title": "KDT-033 SEAL SEQUENCE",
      "text": "The durable monotonic position assigned when a log frame is safely sealed. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: SEAL SEQUENCE is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "seal",
        "sequence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-034",
      "kind": "database-developer-term",
      "title": "KDT-034 REPLAY CURSOR",
      "text": "The last log position completely applied by a consumer or materialized view. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: REPLAY CURSOR is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "replay",
        "cursor"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-035",
      "kind": "database-developer-term",
      "title": "KDT-035 SEGMENT EPOCH",
      "text": "The generation identifying a coherent family of immutable storage segments. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: SEGMENT EPOCH is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "segment",
        "epoch"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-036",
      "kind": "database-developer-term",
      "title": "KDT-036 COMPACTION DEBT",
      "text": "The measured obsolete bytes and read work waiting to be reclaimed. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: COMPACTION DEBT is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "compaction",
        "debt"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-037",
      "kind": "database-developer-term",
      "title": "KDT-037 TOMBSTONE HORIZON",
      "text": "The oldest point before which deletion markers may be safely discarded. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: TOMBSTONE HORIZON is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "tombstone",
        "horizon"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-038",
      "kind": "database-developer-term",
      "title": "KDT-038 STORAGE AMPLIFICATION",
      "text": "The ratio of physical stored bytes to logical live data bytes. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: STORAGE AMPLIFICATION is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "storage",
        "amplification"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-039",
      "kind": "database-developer-term",
      "title": "KDT-039 WRITE AMPLIFICATION BUDGET",
      "text": "The allowed physical bytes written for each logical byte changed. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: WRITE AMPLIFICATION BUDGET is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "write",
        "amplification",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-040",
      "kind": "database-developer-term",
      "title": "KDT-040 READ AMPLIFICATION BUDGET",
      "text": "The allowed storage probes or bytes read for one logical lookup. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: READ AMPLIFICATION BUDGET is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "read",
        "amplification",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-041",
      "kind": "database-developer-term",
      "title": "KDT-041 CHECKPOINT ANCHOR",
      "text": "A verified log position represented completely by a restartable snapshot. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: CHECKPOINT ANCHOR is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "checkpoint",
        "anchor"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-042",
      "kind": "database-developer-term",
      "title": "KDT-042 RECOVERY TAIL",
      "text": "The log interval after a checkpoint that must be replayed during recovery. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: RECOVERY TAIL is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "recovery",
        "tail"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-043",
      "kind": "database-developer-term",
      "title": "KDT-043 SEGMENT MANIFEST",
      "text": "The authoritative inventory, ordering, checksums, and ownership of storage segments. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: SEGMENT MANIFEST is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "segment",
        "manifest"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-044",
      "kind": "database-developer-term",
      "title": "KDT-044 BLOB INDIRECTION",
      "text": "A stable reference separating large value bytes from primary record metadata. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: BLOB INDIRECTION is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "blob",
        "indirection"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-045",
      "kind": "database-developer-term",
      "title": "KDT-045 DATA TEMPERATURE",
      "text": "A measured access class used to choose memory, local disk, or remote storage placement. Normative contract: Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior. Adoption signal: DATA TEMPERATURE is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction. Family: Log, Storage, and Recovery Internals. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "log-storage",
        "proposed",
        "data",
        "temperature"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-046",
      "kind": "database-developer-term",
      "title": "KDT-046 INDEX CONTRACT",
      "text": "The keys, predicates, ordering, freshness, and maintenance guarantees of an index. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: INDEX CONTRACT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "index",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-047",
      "kind": "database-developer-term",
      "title": "KDT-047 INDEX WATERMARK",
      "text": "The commit horizon through which an index is complete and query-safe. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: INDEX WATERMARK is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "index",
        "watermark"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-048",
      "kind": "database-developer-term",
      "title": "KDT-048 INDEX DEBT",
      "text": "The queued mutation work not yet incorporated into a queryable index. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: INDEX DEBT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "index",
        "debt"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-049",
      "kind": "database-developer-term",
      "title": "KDT-049 COVERING PATH",
      "text": "An access path that answers a query without fetching base records. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: COVERING PATH is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "covering",
        "path"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-050",
      "kind": "database-developer-term",
      "title": "KDT-050 PREDICATE SHAPE",
      "text": "A normalized representation of filter operators independent of literal values. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: PREDICATE SHAPE is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "predicate",
        "shape"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-051",
      "kind": "database-developer-term",
      "title": "KDT-051 PLAN FINGERPRINT",
      "text": "A stable identity for a normalized query and its selected execution shape. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: PLAN FINGERPRINT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "plan",
        "fingerprint"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-052",
      "kind": "database-developer-term",
      "title": "KDT-052 SELECTIVITY SKETCH",
      "text": "A compact estimate of how much data a predicate is expected to match. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: SELECTIVITY SKETCH is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "selectivity",
        "sketch"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-053",
      "kind": "database-developer-term",
      "title": "KDT-053 SCAN ESCAPE",
      "text": "A proven access path that avoids a full collection or segment scan. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: SCAN ESCAPE is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "scan",
        "escape"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-054",
      "kind": "database-developer-term",
      "title": "KDT-054 ACCESS PATH",
      "text": "The ordered indexes, scans, joins, and fetches used to answer a query. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: ACCESS PATH is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "access",
        "path"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-055",
      "kind": "database-developer-term",
      "title": "KDT-055 PLAN STABILITY",
      "text": "The degree to which equivalent inputs retain predictable execution behavior. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: PLAN STABILITY is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "plan",
        "stability"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-056",
      "kind": "database-developer-term",
      "title": "KDT-056 ADAPTIVE SWITCHPOINT",
      "text": "The measured threshold where execution changes to a different plan. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: ADAPTIVE SWITCHPOINT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "adaptive",
        "switchpoint"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-057",
      "kind": "database-developer-term",
      "title": "KDT-057 CARDINALITY CONFIDENCE",
      "text": "The uncertainty bound attached to an estimated row or candidate count. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: CARDINALITY CONFIDENCE is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "cardinality",
        "confidence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-058",
      "kind": "database-developer-term",
      "title": "KDT-058 INDEX ADMISSION",
      "text": "The evidence-based decision to create or retain an index for real workload demand. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: INDEX ADMISSION is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "index",
        "admission"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-059",
      "kind": "database-developer-term",
      "title": "KDT-059 INDEX RETIREMENT",
      "text": "The safe removal process for an index whose cost exceeds its measured value. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: INDEX RETIREMENT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "index",
        "retirement"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-060",
      "kind": "database-developer-term",
      "title": "KDT-060 QUERY WORK BUDGET",
      "text": "The maximum rows, bytes, probes, or CPU units allowed for one query. Normative contract: Implementations using these terms MUST make index freshness, planner choices, cardinality uncertainty, and scanned work observable enough to reproduce a chosen access path. Adoption signal: QUERY WORK BUDGET is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work. Family: Indexes and Query Planning. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "index-planner",
        "proposed",
        "query",
        "work",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-061",
      "kind": "database-developer-term",
      "title": "KDT-061 RESULT CONTRACT",
      "text": "The declared columns, types, ordering, completeness, and metadata of a query response. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: RESULT CONTRACT is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "result",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-062",
      "kind": "database-developer-term",
      "title": "KDT-062 DETERMINISTIC ORDER",
      "text": "An ordering whose tie-breakers produce the same sequence for the same snapshot. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: DETERMINISTIC ORDER is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "deterministic",
        "order"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-063",
      "kind": "database-developer-term",
      "title": "KDT-063 STABLE PAGINATION",
      "text": "Page traversal that neither duplicates nor omits unchanged records across requests. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: STABLE PAGINATION is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "stable",
        "pagination"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-064",
      "kind": "database-developer-term",
      "title": "KDT-064 CONTINUATION TOKEN",
      "text": "Opaque state that resumes a query under the same ordering and snapshot contract. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: CONTINUATION TOKEN is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "continuation",
        "token"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-065",
      "kind": "database-developer-term",
      "title": "KDT-065 NULL POLICY",
      "text": "The declared comparison, sorting, and serialization behavior for explicit null values. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: NULL POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "null",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-066",
      "kind": "database-developer-term",
      "title": "KDT-066 MISSING-FIELD POLICY",
      "text": "The declared treatment of absent fields in filtering, sorting, and projection. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: MISSING-FIELD POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "missing-field",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-067",
      "kind": "database-developer-term",
      "title": "KDT-067 TYPE COERCION POLICY",
      "text": "The explicit conversions permitted when operand or stored value types differ. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: TYPE COERCION POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "type",
        "coercion",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-068",
      "kind": "database-developer-term",
      "title": "KDT-068 COLLATION PROFILE",
      "text": "The locale, normalization, case, and byte ordering rules for text comparison. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: COLLATION PROFILE is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "collation",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-069",
      "kind": "database-developer-term",
      "title": "KDT-069 FILTER PUSHDOWN",
      "text": "Moving a predicate closer to storage while preserving exact result semantics. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: FILTER PUSHDOWN is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "filter",
        "pushdown"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-070",
      "kind": "database-developer-term",
      "title": "KDT-070 PROJECTION BOUNDARY",
      "text": "The earliest safe stage at which unrequested fields stop flowing through execution. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: PROJECTION BOUNDARY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "projection",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-071",
      "kind": "database-developer-term",
      "title": "KDT-071 JOIN DOMAIN",
      "text": "The keyspace and consistency boundary within which a join is executed. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: JOIN DOMAIN is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "join",
        "domain"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-072",
      "kind": "database-developer-term",
      "title": "KDT-072 FANOUT BUDGET",
      "text": "The maximum partitions, nodes, or remote calls a query may contact. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: FANOUT BUDGET is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "fanout",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-073",
      "kind": "database-developer-term",
      "title": "KDT-073 QUERY DEADLINE",
      "text": "The absolute completion boundary after which query work should be cancelled. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: QUERY DEADLINE is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "query",
        "deadline"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-074",
      "kind": "database-developer-term",
      "title": "KDT-074 PARTIAL RESULT POLICY",
      "text": "The declared response when only part of a distributed query completes. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: PARTIAL RESULT POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "partial",
        "result",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-075",
      "kind": "database-developer-term",
      "title": "KDT-075 EXPLAIN EVIDENCE",
      "text": "Machine-readable proof of plan choices, estimates, actual work, and timing. Normative contract: Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language. Adoption signal: EXPLAIN EVIDENCE is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results. Family: Query and Result Semantics. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "query-semantics",
        "proposed",
        "explain",
        "evidence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-076",
      "kind": "database-developer-term",
      "title": "KDT-076 RETRIEVAL PROFILE",
      "text": "A versioned bundle of lexical, vector, fusion, filtering, and ranking settings. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: RETRIEVAL PROFILE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "retrieval",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-077",
      "kind": "database-developer-term",
      "title": "KDT-077 RELEVANCE CONTRACT",
      "text": "The quality metrics and thresholds a retrieval release must preserve. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: RELEVANCE CONTRACT is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "relevance",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-078",
      "kind": "database-developer-term",
      "title": "KDT-078 CANDIDATE BUDGET",
      "text": "The maximum documents or vectors admitted to an expensive ranking stage. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: CANDIDATE BUDGET is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "candidate",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-079",
      "kind": "database-developer-term",
      "title": "KDT-079 RECALL FLOOR",
      "text": "The minimum acceptable fraction of known relevant results returned by retrieval. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: RECALL FLOOR is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "recall",
        "floor"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-080",
      "kind": "database-developer-term",
      "title": "KDT-080 RANKING PROVENANCE",
      "text": "The channels, scores, models, and transformations that produced a result rank. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: RANKING PROVENANCE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "ranking",
        "provenance"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-081",
      "kind": "database-developer-term",
      "title": "KDT-081 FUSION POLICY",
      "text": "The deterministic method used to combine rankings from multiple retrieval channels. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: FUSION POLICY is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "fusion",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-082",
      "kind": "database-developer-term",
      "title": "KDT-082 LEXICAL CHANNEL",
      "text": "A retrieval path driven by tokens, terms, fields, and sparse relevance signals. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: LEXICAL CHANNEL is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "lexical",
        "channel"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-083",
      "kind": "database-developer-term",
      "title": "KDT-083 SEMANTIC CHANNEL",
      "text": "A retrieval path driven by embeddings or learned semantic representations. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: SEMANTIC CHANNEL is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "semantic",
        "channel"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-084",
      "kind": "database-developer-term",
      "title": "KDT-084 RERANK STAGE",
      "text": "A bounded later pass that reorders an already selected candidate set. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: RERANK STAGE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "rerank",
        "stage"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-085",
      "kind": "database-developer-term",
      "title": "KDT-085 FRESHNESS-AWARE RANKING",
      "text": "Ranking that includes document or index freshness as an explicit signal. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: FRESHNESS-AWARE RANKING is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "freshness-aware",
        "ranking"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-086",
      "kind": "database-developer-term",
      "title": "KDT-086 DIVERSITY BUDGET",
      "text": "The allowed relevance tradeoff used to reduce redundant results. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: DIVERSITY BUDGET is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "diversity",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-087",
      "kind": "database-developer-term",
      "title": "KDT-087 QUERY EXPANSION BOUNDARY",
      "text": "The controlled point where additional terms or concepts enter retrieval. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: QUERY EXPANSION BOUNDARY is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "query",
        "expansion",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-088",
      "kind": "database-developer-term",
      "title": "KDT-088 GOLDEN QUERY SET",
      "text": "A versioned collection of queries, judgments, and expected retrieval behavior. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: GOLDEN QUERY SET is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "golden",
        "query",
        "set"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-089",
      "kind": "database-developer-term",
      "title": "KDT-089 RELEVANCE DRIFT",
      "text": "Measured change in retrieval quality after data, model, or index evolution. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: RELEVANCE DRIFT is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "relevance",
        "drift"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-090",
      "kind": "database-developer-term",
      "title": "KDT-090 RETRIEVAL TRACE",
      "text": "A per-query record of channels, candidates, filters, scores, and final ranks. Normative contract: Implementations using these terms MUST version ranking behavior, measure relevance against a golden set, expose candidate work, and keep latency improvements coupled to quality gates. Adoption signal: RETRIEVAL TRACE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept. Family: Search and Retrieval. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "retrieval",
        "proposed",
        "retrieval",
        "trace"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-091",
      "kind": "database-developer-term",
      "title": "KDT-091 EMBEDDING CONTRACT",
      "text": "The model, tokenizer, dimensions, normalization, distance, and version for a vector field. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: EMBEDDING CONTRACT is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "embedding",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-092",
      "kind": "database-developer-term",
      "title": "KDT-092 MODEL FINGERPRINT",
      "text": "A stable digest identifying model weights, configuration, and preprocessing behavior. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: MODEL FINGERPRINT is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "model",
        "fingerprint"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-093",
      "kind": "database-developer-term",
      "title": "KDT-093 VECTOR DIMENSION LOCK",
      "text": "A schema rule preventing incompatible vector lengths from sharing one index. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: VECTOR DIMENSION LOCK is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "vector",
        "dimension",
        "lock"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-094",
      "kind": "database-developer-term",
      "title": "KDT-094 DISTANCE PROFILE",
      "text": "The named similarity metric and normalization assumptions used during vector search. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: DISTANCE PROFILE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "distance",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-095",
      "kind": "database-developer-term",
      "title": "KDT-095 QUANTIZATION BUDGET",
      "text": "The maximum relevance loss and memory cost allowed for compressed vectors. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: QUANTIZATION BUDGET is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "quantization",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-096",
      "kind": "database-developer-term",
      "title": "KDT-096 ANN RECALL GATE",
      "text": "The minimum approximate-neighbor recall required against exact search. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: ANN RECALL GATE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "ann",
        "recall",
        "gate"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-097",
      "kind": "database-developer-term",
      "title": "KDT-097 VECTOR FRESHNESS",
      "text": "The delay between source mutation and searchable embedding availability. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: VECTOR FRESHNESS is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "vector",
        "freshness"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-098",
      "kind": "database-developer-term",
      "title": "KDT-098 EMBEDDING BACKFILL",
      "text": "A resumable process that creates vectors for existing source records. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: EMBEDDING BACKFILL is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "embedding",
        "backfill"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-099",
      "kind": "database-developer-term",
      "title": "KDT-099 DUAL-MODEL WINDOW",
      "text": "A migration interval where old and new embeddings coexist and are distinguishable. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: DUAL-MODEL WINDOW is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "dual-model",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-100",
      "kind": "database-developer-term",
      "title": "KDT-100 SEMANTIC TOMBSTONE",
      "text": "A deletion marker that removes derived vectors and semantic caches with source data. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: SEMANTIC TOMBSTONE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "semantic",
        "tombstone"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-101",
      "kind": "database-developer-term",
      "title": "KDT-101 VECTOR PROVENANCE",
      "text": "The source fields, model, time, and transformation that produced a stored vector. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: VECTOR PROVENANCE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "vector",
        "provenance"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-102",
      "kind": "database-developer-term",
      "title": "KDT-102 AGENT MEMORY SCOPE",
      "text": "The tenant, principal, purpose, and retention boundary for agent-written memory. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: AGENT MEMORY SCOPE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "agent",
        "memory",
        "scope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-103",
      "kind": "database-developer-term",
      "title": "KDT-103 CONTEXT BUDGET",
      "text": "The maximum retrieved tokens, records, or evidence bytes passed to inference. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: CONTEXT BUDGET is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "context",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-104",
      "kind": "database-developer-term",
      "title": "KDT-104 GROUNDING CITATION",
      "text": "A stable reference linking generated output to the database evidence used. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: GROUNDING CITATION is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "grounding",
        "citation"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-105",
      "kind": "database-developer-term",
      "title": "KDT-105 INFERENCE-DATA BOUNDARY",
      "text": "The policy boundary separating durable database state from model execution. Normative contract: Implementations using these terms MUST bind vectors and AI-derived data to model identity, dimensions, quality gates, provenance, deletion behavior, and explicit context boundaries. Adoption signal: INFERENCE-DATA BOUNDARY is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information. Family: Vector, AI, and Agent Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "vector-ai",
        "proposed",
        "inference-data",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-106",
      "kind": "database-developer-term",
      "title": "KDT-106 REPLICA CONTRACT",
      "text": "The ordering, durability, freshness, and read guarantees offered by a replica class. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: REPLICA CONTRACT is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "replica",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-107",
      "kind": "database-developer-term",
      "title": "KDT-107 APPLY WATERMARK",
      "text": "The commit horizon completely incorporated into a replica's queryable state. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: APPLY WATERMARK is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "apply",
        "watermark"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-108",
      "kind": "database-developer-term",
      "title": "KDT-108 QUORUM SHAPE",
      "text": "The voter set and acknowledgement rule required for a distributed decision. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: QUORUM SHAPE is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "quorum",
        "shape"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-109",
      "kind": "database-developer-term",
      "title": "KDT-109 FAILURE DOMAIN",
      "text": "Infrastructure expected to fail independently from other declared domains. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: FAILURE DOMAIN is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "failure",
        "domain"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-110",
      "kind": "database-developer-term",
      "title": "KDT-110 PLACEMENT INTENT",
      "text": "The desired distribution of replicas across regions, zones, and hardware boundaries. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: PLACEMENT INTENT is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "placement",
        "intent"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-111",
      "kind": "database-developer-term",
      "title": "KDT-111 LEADERSHIP EPOCH",
      "text": "A monotonic generation identifying one period of valid write authority. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: LEADERSHIP EPOCH is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "leadership",
        "epoch"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-112",
      "kind": "database-developer-term",
      "title": "KDT-112 FENCING TOKEN",
      "text": "A monotonic proof that rejects operations from superseded authority holders. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: FENCING TOKEN is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "fencing",
        "token"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-113",
      "kind": "database-developer-term",
      "title": "KDT-113 READ REPLICA CLASS",
      "text": "A named bundle of locality, lag, consistency, and workload guarantees. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: READ REPLICA CLASS is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "read",
        "replica",
        "class"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-114",
      "kind": "database-developer-term",
      "title": "KDT-114 REPLICA ADMISSION",
      "text": "The validation required before a new replica may serve production reads. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: REPLICA ADMISSION is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "replica",
        "admission"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-115",
      "kind": "database-developer-term",
      "title": "KDT-115 CATCH-UP WINDOW",
      "text": "The bounded time and log distance allowed for replica synchronization. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: CATCH-UP WINDOW is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "catch-up",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-116",
      "kind": "database-developer-term",
      "title": "KDT-116 ANTI-ENTROPY PASS",
      "text": "A background comparison and repair cycle for divergent replicated state. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: ANTI-ENTROPY PASS is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "anti-entropy",
        "pass"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-117",
      "kind": "database-developer-term",
      "title": "KDT-117 REPLICATION HORIZON",
      "text": "The oldest commit still needed by any replica, subscriber, or recovery process. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: REPLICATION HORIZON is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "replication",
        "horizon"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-118",
      "kind": "database-developer-term",
      "title": "KDT-118 SHARD LEASE",
      "text": "A time-bounded and epoch-bound authority to serve one shard role. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: SHARD LEASE is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "shard",
        "lease"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-119",
      "kind": "database-developer-term",
      "title": "KDT-119 REBALANCE BUDGET",
      "text": "The allowed network, storage, and latency impact of moving replicated data. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: REBALANCE BUDGET is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "rebalance",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-120",
      "kind": "database-developer-term",
      "title": "KDT-120 TOPOLOGY PROOF",
      "text": "Evidence that live placement satisfies declared quorum and failure-domain rules. Normative contract: Implementations using these terms MUST expose replica progress, authority epochs, quorum membership, failure domains, and the fencing used to prevent stale writers or readers. Adoption signal: TOPOLOGY PROOF is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition. Family: Replication and Distributed Authority. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "replication",
        "proposed",
        "topology",
        "proof"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-121",
      "kind": "database-developer-term",
      "title": "KDT-121 PARTITION CONTRACT",
      "text": "The key mapping, ownership, ordering, and movement rules for partitioned data. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: PARTITION CONTRACT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "partition",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-122",
      "kind": "database-developer-term",
      "title": "KDT-122 SHARD KEY FITNESS",
      "text": "A measured score for distribution, locality, query targeting, and growth behavior. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: SHARD KEY FITNESS is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "shard",
        "key",
        "fitness"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-123",
      "kind": "database-developer-term",
      "title": "KDT-123 HOT-KEY BUDGET",
      "text": "The maximum load one key may place on a shard before mitigation. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: HOT-KEY BUDGET is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "hot-key",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-124",
      "kind": "database-developer-term",
      "title": "KDT-124 ROUTING EPOCH",
      "text": "A monotonic version for the ownership map used to route operations. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: ROUTING EPOCH is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "routing",
        "epoch"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-125",
      "kind": "database-developer-term",
      "title": "KDT-125 OWNERSHIP MAP",
      "text": "The authoritative mapping from key ranges or hashes to serving shard groups. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: OWNERSHIP MAP is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "ownership",
        "map"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-126",
      "kind": "database-developer-term",
      "title": "KDT-126 SCATTER WIDTH",
      "text": "The number of shards contacted by one logical operation. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: SCATTER WIDTH is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "scatter",
        "width"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-127",
      "kind": "database-developer-term",
      "title": "KDT-127 COLOCATION HINT",
      "text": "A non-binding request to place related data within one transaction or query domain. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: COLOCATION HINT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "colocation",
        "hint"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-128",
      "kind": "database-developer-term",
      "title": "KDT-128 MIGRATION FENCE",
      "text": "The epoch and progress barrier preventing unsafe access during data movement. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: MIGRATION FENCE is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "migration",
        "fence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-129",
      "kind": "database-developer-term",
      "title": "KDT-129 SPLIT POINT",
      "text": "The key or hash boundary where one shard becomes multiple owned ranges. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: SPLIT POINT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "split",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-130",
      "kind": "database-developer-term",
      "title": "KDT-130 MERGE POINT",
      "text": "The validated boundary where adjacent shard ranges become one ownership unit. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: MERGE POINT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "merge",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-131",
      "kind": "database-developer-term",
      "title": "KDT-131 TENANT CELL",
      "text": "A bounded placement and failure unit containing one tenant's assigned shards. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: TENANT CELL is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "tenant",
        "cell"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-132",
      "kind": "database-developer-term",
      "title": "KDT-132 LOCALITY POLICY",
      "text": "The allowed regions and proximity preferences for storage and query execution. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: LOCALITY POLICY is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "locality",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-133",
      "kind": "database-developer-term",
      "title": "KDT-133 CROSS-SHARD ENVELOPE",
      "text": "The participants, coordinator, deadline, and recovery state for distributed work. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: CROSS-SHARD ENVELOPE is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "cross-shard",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-134",
      "kind": "database-developer-term",
      "title": "KDT-134 COORDINATOR BUDGET",
      "text": "The maximum participants and time allowed for coordination overhead. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: COORDINATOR BUDGET is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "coordinator",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-135",
      "kind": "database-developer-term",
      "title": "KDT-135 DATA GRAVITY",
      "text": "The measured pressure to execute compute near the dominant data location. Normative contract: Implementations using these terms MUST version ownership, bound scatter, declare locality, and fence data movement so routing decisions remain explainable during topology change. Adoption signal: DATA GRAVITY is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions. Family: Sharding, Routing, and Locality. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "sharding-routing",
        "proposed",
        "data",
        "gravity"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-136",
      "kind": "database-developer-term",
      "title": "KDT-136 CACHE CONTRACT",
      "text": "The identity, freshness, invalidation, isolation, and failure rules for cached data. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: CACHE CONTRACT is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "cache",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-137",
      "kind": "database-developer-term",
      "title": "KDT-137 FRESHNESS KEY",
      "text": "The version input that determines whether a cached value remains safe to serve. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: FRESHNESS KEY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "freshness",
        "key"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-138",
      "kind": "database-developer-term",
      "title": "KDT-138 PURGE SPAN",
      "text": "The elapsed time from mutation to removal of the final unsafe cached copy. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: PURGE SPAN is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "purge",
        "span"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-139",
      "kind": "database-developer-term",
      "title": "KDT-139 NEGATIVE CACHE",
      "text": "A bounded cached representation of an absent key or empty result. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: NEGATIVE CACHE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "negative",
        "cache"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-140",
      "kind": "database-developer-term",
      "title": "KDT-140 ADMISSION POLICY",
      "text": "The rule deciding whether a response is valuable and safe enough to cache. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: ADMISSION POLICY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "admission",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-141",
      "kind": "database-developer-term",
      "title": "KDT-141 EVICTION PROOF",
      "text": "Telemetry showing why a cached object left memory or edge storage. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: EVICTION PROOF is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "eviction",
        "proof"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-142",
      "kind": "database-developer-term",
      "title": "KDT-142 HOTSET RESIDENCY",
      "text": "The fraction of high-value working data retained in the intended cache tier. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: HOTSET RESIDENCY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "hotset",
        "residency"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-143",
      "kind": "database-developer-term",
      "title": "KDT-143 CACHE STAMPEDE FENCE",
      "text": "Coordination that limits duplicate origin work when a popular item expires. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: CACHE STAMPEDE FENCE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "cache",
        "stampede",
        "fence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-144",
      "kind": "database-developer-term",
      "title": "KDT-144 READ-THROUGH BOUNDARY",
      "text": "The point where a cache miss becomes an authoritative database read. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: READ-THROUGH BOUNDARY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "read-through",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-145",
      "kind": "database-developer-term",
      "title": "KDT-145 WRITE-THROUGH BOUNDARY",
      "text": "The point where a mutation and its cache update share one success contract. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: WRITE-THROUGH BOUNDARY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "write-through",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-146",
      "kind": "database-developer-term",
      "title": "KDT-146 EDGE READ TOKEN",
      "text": "Portable metadata proving the freshness horizon of an edge-served response. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: EDGE READ TOKEN is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "edge",
        "read",
        "token"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-147",
      "kind": "database-developer-term",
      "title": "KDT-147 ORIGIN SHIELD",
      "text": "A shared intermediate cache that protects the authoritative origin from fanout. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: ORIGIN SHIELD is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "origin",
        "shield"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-148",
      "kind": "database-developer-term",
      "title": "KDT-148 CACHE VARIANT",
      "text": "One representation selected by tenant, authorization, locale, schema, or protocol. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: CACHE VARIANT is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "cache",
        "variant"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-149",
      "kind": "database-developer-term",
      "title": "KDT-149 BYPASS CAUSE",
      "text": "A machine-readable reason a request skipped an otherwise eligible cache. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: BYPASS CAUSE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "bypass",
        "cause"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-150",
      "kind": "database-developer-term",
      "title": "KDT-150 CACHE COST ENVELOPE",
      "text": "The memory, egress, invalidation, and origin-savings budget for a cache tier. Normative contract: Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics. Adoption signal: CACHE COST ENVELOPE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response. Family: Caching and Edge Data. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "cache-edge",
        "proposed",
        "cache",
        "cost",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-151",
      "kind": "database-developer-term",
      "title": "KDT-151 SCHEMA CONTRACT",
      "text": "The named fields, types, constraints, defaults, and compatibility rules for data. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: SCHEMA CONTRACT is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "schema",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-152",
      "kind": "database-developer-term",
      "title": "KDT-152 SHAPE VERSION",
      "text": "A stable identifier for one externally meaningful schema representation. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: SHAPE VERSION is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "shape",
        "version"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-153",
      "kind": "database-developer-term",
      "title": "KDT-153 COMPATIBILITY WINDOW",
      "text": "The period during which multiple schema or protocol shapes remain supported. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: COMPATIBILITY WINDOW is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "compatibility",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-154",
      "kind": "database-developer-term",
      "title": "KDT-154 EVOLUTION STEP",
      "text": "One independently deployable and reversible change in a schema migration. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: EVOLUTION STEP is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "evolution",
        "step"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-155",
      "kind": "database-developer-term",
      "title": "KDT-155 DEFAULT MATERIALIZATION",
      "text": "The decision to store a default physically rather than derive it at read time. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: DEFAULT MATERIALIZATION is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "default",
        "materialization"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-156",
      "kind": "database-developer-term",
      "title": "KDT-156 BACKFILL BUDGET",
      "text": "The maximum resource and latency impact allowed for historical data rewriting. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: BACKFILL BUDGET is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "backfill",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-157",
      "kind": "database-developer-term",
      "title": "KDT-157 DUAL-READ WINDOW",
      "text": "A migration phase where readers understand both old and new representations. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: DUAL-READ WINDOW is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "dual-read",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-158",
      "kind": "database-developer-term",
      "title": "KDT-158 DUAL-WRITE WINDOW",
      "text": "A migration phase where mutations maintain both old and new representations. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: DUAL-WRITE WINDOW is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "dual-write",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-159",
      "kind": "database-developer-term",
      "title": "KDT-159 FIELD LIFECYCLE",
      "text": "The proposed, optional, required, deprecated, and removed states of a field. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: FIELD LIFECYCLE is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "field",
        "lifecycle"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-160",
      "kind": "database-developer-term",
      "title": "KDT-160 CONSTRAINT PHASE",
      "text": "The observe, warn, enforce, or validate state of a data constraint. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: CONSTRAINT PHASE is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "constraint",
        "phase"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-161",
      "kind": "database-developer-term",
      "title": "KDT-161 VALIDATION HORIZON",
      "text": "The data boundary through which a new constraint has been checked. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: VALIDATION HORIZON is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "validation",
        "horizon"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-162",
      "kind": "database-developer-term",
      "title": "KDT-162 UNKNOWN-FIELD POLICY",
      "text": "The preserve, ignore, index, or reject behavior for undeclared fields. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: UNKNOWN-FIELD POLICY is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "unknown-field",
        "policy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-163",
      "kind": "database-developer-term",
      "title": "KDT-163 CANONICAL ENCODING",
      "text": "The one deterministic byte or JSON representation used for equality and hashing. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: CANONICAL ENCODING is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "canonical",
        "encoding"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-164",
      "kind": "database-developer-term",
      "title": "KDT-164 MIGRATION PROOF",
      "text": "Evidence that transformed data satisfies source, target, count, and invariant checks. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: MIGRATION PROOF is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "migration",
        "proof"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-165",
      "kind": "database-developer-term",
      "title": "KDT-165 ROLLBACK SHAPE",
      "text": "The retained representation and procedure required to reverse a migration safely. Normative contract: Implementations using these terms MUST version data shape, define compatibility and validation phases, bound backfills, and preserve rollback information through every schema transition. Adoption signal: ROLLBACK SHAPE is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary. Family: Schema and Data Evolution. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "schema-evolution",
        "proposed",
        "rollback",
        "shape"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-166",
      "kind": "database-developer-term",
      "title": "KDT-166 API CONTRACT",
      "text": "The versioned requests, responses, errors, authentication, and behavioral guarantees of an API. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: API CONTRACT is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "api",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-167",
      "kind": "database-developer-term",
      "title": "KDT-167 CAPABILITY DISCOVERY",
      "text": "A machine-readable method for clients to learn supported database features. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: CAPABILITY DISCOVERY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "capability",
        "discovery"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-168",
      "kind": "database-developer-term",
      "title": "KDT-168 IDEMPOTENCY SCOPE",
      "text": "The endpoint, tenant, time window, and payload identity covered by an idempotency key. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: IDEMPOTENCY SCOPE is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "idempotency",
        "scope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-169",
      "kind": "database-developer-term",
      "title": "KDT-169 ERROR TAXONOMY",
      "text": "A stable classification of failures by retryability, responsibility, and semantics. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: ERROR TAXONOMY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "error",
        "taxonomy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-170",
      "kind": "database-developer-term",
      "title": "KDT-170 RETRY CLASS",
      "text": "The declared conditions and backoff rules under which an operation may be repeated. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: RETRY CLASS is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "retry",
        "class"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-171",
      "kind": "database-developer-term",
      "title": "KDT-171 PAGINATION CONTRACT",
      "text": "The ordering, snapshot, token lifetime, and mutation behavior of paged results. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: PAGINATION CONTRACT is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "pagination",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-172",
      "kind": "database-developer-term",
      "title": "KDT-172 BATCH ENVELOPE",
      "text": "The limits, ordering, atomicity, and per-item outcomes of a batch request. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: BATCH ENVELOPE is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "batch",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-173",
      "kind": "database-developer-term",
      "title": "KDT-173 REQUEST BUDGET",
      "text": "The maximum bytes, operations, complexity, and time accepted for one request. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: REQUEST BUDGET is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "request",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-174",
      "kind": "database-developer-term",
      "title": "KDT-174 RESPONSE BUDGET",
      "text": "The maximum rows, bytes, metadata, and generation time for one response. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: RESPONSE BUDGET is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "response",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-175",
      "kind": "database-developer-term",
      "title": "KDT-175 COMPATIBILITY HEADER",
      "text": "Wire metadata declaring requested and selected contract versions. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: COMPATIBILITY HEADER is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "compatibility",
        "header"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-176",
      "kind": "database-developer-term",
      "title": "KDT-176 FEATURE NEGOTIATION",
      "text": "The deterministic exchange selecting mutually supported optional behavior. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: FEATURE NEGOTIATION is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "feature",
        "negotiation"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-177",
      "kind": "database-developer-term",
      "title": "KDT-177 CLIENT WATERMARK",
      "text": "The newest server contract version a client proves it understands. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: CLIENT WATERMARK is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "client",
        "watermark"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-178",
      "kind": "database-developer-term",
      "title": "KDT-178 SDK PARITY",
      "text": "Equivalent supported behavior and error semantics across official language clients. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: SDK PARITY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "sdk",
        "parity"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-179",
      "kind": "database-developer-term",
      "title": "KDT-179 WIRE STABILITY",
      "text": "The guarantee that compatible clients can parse and interpret future responses. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: WIRE STABILITY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "wire",
        "stability"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-180",
      "kind": "database-developer-term",
      "title": "KDT-180 DEPRECATION CLOCK",
      "text": "The published interval between deprecation notice and contract removal. Normative contract: Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs. Adoption signal: DEPRECATION CLOCK is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome. Family: API, Protocol, and SDK Contracts. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "api-sdk",
        "proposed",
        "deprecation",
        "clock"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-181",
      "kind": "database-developer-term",
      "title": "KDT-181 TRUST BOUNDARY",
      "text": "A boundary across which data or authority requires explicit validation. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: TRUST BOUNDARY is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "trust",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-182",
      "kind": "database-developer-term",
      "title": "KDT-182 PRINCIPAL SCOPE",
      "text": "The tenant, project, resources, and actions assigned to one authenticated identity. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: PRINCIPAL SCOPE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "principal",
        "scope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-183",
      "kind": "database-developer-term",
      "title": "KDT-183 TENANT FENCE",
      "text": "Enforcement preventing one tenant's identity, data, or compute from crossing into another. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: TENANT FENCE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "tenant",
        "fence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-184",
      "kind": "database-developer-term",
      "title": "KDT-184 POLICY DECISION POINT",
      "text": "The component that evaluates identity, resource, action, context, and policy. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: POLICY DECISION POINT is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "policy",
        "decision",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-185",
      "kind": "database-developer-term",
      "title": "KDT-185 POLICY ENFORCEMENT POINT",
      "text": "The component that blocks or permits an operation using a policy decision. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: POLICY ENFORCEMENT POINT is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "policy",
        "enforcement",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-186",
      "kind": "database-developer-term",
      "title": "KDT-186 LEAST-PRIVILEGE SHAPE",
      "text": "The smallest resource and action set required for a workload to function. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: LEAST-PRIVILEGE SHAPE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "least-privilege",
        "shape"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-187",
      "kind": "database-developer-term",
      "title": "KDT-187 SECRET LIFETIME",
      "text": "The maximum interval during which one credential value remains valid. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: SECRET LIFETIME is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "secret",
        "lifetime"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-188",
      "kind": "database-developer-term",
      "title": "KDT-188 KEY ROTATION WINDOW",
      "text": "The bounded overlap where old and new cryptographic keys are accepted. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: KEY ROTATION WINDOW is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "key",
        "rotation",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-189",
      "kind": "database-developer-term",
      "title": "KDT-189 ENCRYPTION DOMAIN",
      "text": "The data set protected by one key hierarchy and access policy. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: ENCRYPTION DOMAIN is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "encryption",
        "domain"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-190",
      "kind": "database-developer-term",
      "title": "KDT-190 AUDIT WITNESS",
      "text": "Tamper-evident evidence identifying who performed or approved a protected action. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: AUDIT WITNESS is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "audit",
        "witness"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-191",
      "kind": "database-developer-term",
      "title": "KDT-191 BREAK-GLASS LEASE",
      "text": "Time-limited emergency authority requiring reason, approval, and enhanced audit. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: BREAK-GLASS LEASE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "break-glass",
        "lease"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-192",
      "kind": "database-developer-term",
      "title": "KDT-192 DATA ACCESS PURPOSE",
      "text": "The declared business or operational reason authorizing a protected read. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: DATA ACCESS PURPOSE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "data",
        "access",
        "purpose"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-193",
      "kind": "database-developer-term",
      "title": "KDT-193 ROW AUTHORITY",
      "text": "The policy proof granting a principal access to an individual record. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: ROW AUTHORITY is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "row",
        "authority"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-194",
      "kind": "database-developer-term",
      "title": "KDT-194 CAPABILITY TOKEN",
      "text": "A bounded bearer proof granting specific actions on specific resources. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: CAPABILITY TOKEN is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "capability",
        "token"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-195",
      "kind": "database-developer-term",
      "title": "KDT-195 SECURITY DOWNGRADE",
      "text": "An explicit and auditable transition to weaker protection, never a silent fallback. Normative contract: Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation. Adoption signal: SECURITY DOWNGRADE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path. Family: Security, Identity, and Authorization. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "security-identity",
        "proposed",
        "security",
        "downgrade"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-196",
      "kind": "database-developer-term",
      "title": "KDT-196 DATA PURPOSE",
      "text": "The declared and allowed reason for collecting or processing a data class. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: DATA PURPOSE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "data",
        "purpose"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-197",
      "kind": "database-developer-term",
      "title": "KDT-197 CONSENT RECEIPT",
      "text": "Versioned evidence of the principal, purpose, notice, choice, and consent time. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: CONSENT RECEIPT is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "consent",
        "receipt"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-198",
      "kind": "database-developer-term",
      "title": "KDT-198 RETENTION CLOCK",
      "text": "The policy-derived deadline controlling when governed data must be reviewed or erased. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: RETENTION CLOCK is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "retention",
        "clock"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-199",
      "kind": "database-developer-term",
      "title": "KDT-199 ERASURE PROOF",
      "text": "Evidence that primary, derived, indexed, cached, and backup data followed deletion policy. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: ERASURE PROOF is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "erasure",
        "proof"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-200",
      "kind": "database-developer-term",
      "title": "KDT-200 CORRECTION TRAIL",
      "text": "An auditable history of requested and applied corrections to personal data. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: CORRECTION TRAIL is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "correction",
        "trail"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-201",
      "kind": "database-developer-term",
      "title": "KDT-201 DATA PRINCIPAL LINK",
      "text": "A protected association between governed records and the person they concern. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: DATA PRINCIPAL LINK is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "data",
        "principal",
        "link"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-202",
      "kind": "database-developer-term",
      "title": "KDT-202 PROCESSING BOUNDARY",
      "text": "The services, regions, and purposes within which governed data may be processed. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: PROCESSING BOUNDARY is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "processing",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-203",
      "kind": "database-developer-term",
      "title": "KDT-203 RESIDENCY CONTRACT",
      "text": "The allowed storage, processing, replication, and backup locations for data. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: RESIDENCY CONTRACT is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "residency",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-204",
      "kind": "database-developer-term",
      "title": "KDT-204 EXPORT PACKAGE",
      "text": "A portable, authenticated, and explainable bundle of a principal's governed data. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: EXPORT PACKAGE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "export",
        "package"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-205",
      "kind": "database-developer-term",
      "title": "KDT-205 LEGAL HOLD FENCE",
      "text": "A scoped policy suspending normal deletion while preserving access controls and audit. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: LEGAL HOLD FENCE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "legal",
        "hold",
        "fence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-206",
      "kind": "database-developer-term",
      "title": "KDT-206 MINIMIZATION BUDGET",
      "text": "The maximum fields, precision, and retention justified by a declared purpose. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: MINIMIZATION BUDGET is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "minimization",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-207",
      "kind": "database-developer-term",
      "title": "KDT-207 SENSITIVE FIELD CLASS",
      "text": "A policy label selecting stronger access, logging, masking, and retention controls. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: SENSITIVE FIELD CLASS is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "sensitive",
        "field",
        "class"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-208",
      "kind": "database-developer-term",
      "title": "KDT-208 ANONYMIZATION PROFILE",
      "text": "The transformations and risk threshold used to remove principal identifiability. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: ANONYMIZATION PROFILE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "anonymization",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-209",
      "kind": "database-developer-term",
      "title": "KDT-209 REIDENTIFICATION RISK",
      "text": "The measured likelihood that transformed data can be linked back to a person. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: REIDENTIFICATION RISK is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "reidentification",
        "risk"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-210",
      "kind": "database-developer-term",
      "title": "KDT-210 COMPLIANCE EVIDENCE",
      "text": "Versioned proof connecting a requirement to policy, control, execution, and result. Normative contract: Implementations using these terms MUST attach purpose, retention, residency, principal rights, and deletion evidence to governed data while keeping policy claims independently auditable. Adoption signal: COMPLIANCE EVIDENCE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence. Family: Privacy, Residency, and Compliance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "privacy-compliance",
        "proposed",
        "compliance",
        "evidence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-211",
      "kind": "database-developer-term",
      "title": "KDT-211 SIGNAL CONTRACT",
      "text": "The name, unit, dimensions, sampling, retention, and privacy rules of telemetry. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: SIGNAL CONTRACT is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "signal",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-212",
      "kind": "database-developer-term",
      "title": "KDT-212 TRACE SPINE",
      "text": "The shared correlation path connecting gateway, query, storage, replication, and sink work. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: TRACE SPINE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "trace",
        "spine"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-213",
      "kind": "database-developer-term",
      "title": "KDT-213 QUERY TRACE",
      "text": "A bounded record of planning, execution stages, waits, work units, and result outcome. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: QUERY TRACE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "query",
        "trace"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-214",
      "kind": "database-developer-term",
      "title": "KDT-214 STORAGE TRACE",
      "text": "A bounded record of cache, segment, log, object, and filesystem operations. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: STORAGE TRACE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "storage",
        "trace"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-215",
      "kind": "database-developer-term",
      "title": "KDT-215 CORRELATION TOKEN",
      "text": "A safe identifier linking related logs, metrics, traces, and audit events. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: CORRELATION TOKEN is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "correlation",
        "token"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-216",
      "kind": "database-developer-term",
      "title": "KDT-216 TAIL LENS",
      "text": "A view focused on p95, p99, timeout, and worst-case behavior rather than averages. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: TAIL LENS is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "tail",
        "lens"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-217",
      "kind": "database-developer-term",
      "title": "KDT-217 ERROR BUDGET",
      "text": "The allowed unreliability remaining before an SLO requires delivery tradeoffs. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: ERROR BUDGET is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "error",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-218",
      "kind": "database-developer-term",
      "title": "KDT-218 BURN WINDOW",
      "text": "A time interval over which error-budget consumption is measured and alerted. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: BURN WINDOW is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "burn",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-219",
      "kind": "database-developer-term",
      "title": "KDT-219 SLO GATE",
      "text": "A release or operation decision driven by measured service-level objectives. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: SLO GATE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "slo",
        "gate"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-220",
      "kind": "database-developer-term",
      "title": "KDT-220 SLOW-PATH SAMPLE",
      "text": "A retained high-detail trace selected because latency crossed a declared threshold. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: SLOW-PATH SAMPLE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "slow-path",
        "sample"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-221",
      "kind": "database-developer-term",
      "title": "KDT-221 SATURATION SIGNAL",
      "text": "A measure showing a finite resource approaching throughput or queue capacity. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: SATURATION SIGNAL is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "saturation",
        "signal"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-222",
      "kind": "database-developer-term",
      "title": "KDT-222 QUEUE AGE",
      "text": "The elapsed time of the oldest unfinished item in an asynchronous stage. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: QUEUE AGE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "queue",
        "age"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-223",
      "kind": "database-developer-term",
      "title": "KDT-223 LAG LENS",
      "text": "A view correlating replication, index, cache, connector, and subscriber freshness. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: LAG LENS is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "lag",
        "lens"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-224",
      "kind": "database-developer-term",
      "title": "KDT-224 INCIDENT MARKER",
      "text": "A timestamped annotation connecting telemetry changes to an operational event. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: INCIDENT MARKER is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "incident",
        "marker"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-225",
      "kind": "database-developer-term",
      "title": "KDT-225 EVIDENCE BUNDLE",
      "text": "The minimal logs, traces, metrics, config, and timeline needed to review an incident. Normative contract: Implementations using these terms MUST provide correlated signals for latency, errors, saturation, queues, lag, and incidents while controlling telemetry cost and sensitive-data exposure. Adoption signal: EVIDENCE BUNDLE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision. Family: Observability and Reliability Engineering. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "observability-sre",
        "proposed",
        "evidence",
        "bundle"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-226",
      "kind": "database-developer-term",
      "title": "KDT-226 RECOVERY CONTRACT",
      "text": "The declared recovery point, recovery time, scope, dependencies, and validation process. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: RECOVERY CONTRACT is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "recovery",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-227",
      "kind": "database-developer-term",
      "title": "KDT-227 RECOVERY POINT",
      "text": "The latest committed position guaranteed present after a successful recovery. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: RECOVERY POINT is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "recovery",
        "point"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-228",
      "kind": "database-developer-term",
      "title": "KDT-228 RECOVERY TIME",
      "text": "The elapsed time from declared failure to validated service restoration. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: RECOVERY TIME is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "recovery",
        "time"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-229",
      "kind": "database-developer-term",
      "title": "KDT-229 RESTORE TARGET",
      "text": "The isolated cluster, timestamp, log position, and data scope selected for restore. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: RESTORE TARGET is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "restore",
        "target"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-230",
      "kind": "database-developer-term",
      "title": "KDT-230 BACKUP CHAIN",
      "text": "The ordered snapshots and log intervals required to reconstruct a recovery point. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: BACKUP CHAIN is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "backup",
        "chain"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-231",
      "kind": "database-developer-term",
      "title": "KDT-231 SNAPSHOT SEAL",
      "text": "A checksum and position proving a snapshot is complete and immutable. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: SNAPSHOT SEAL is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "snapshot",
        "seal"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-232",
      "kind": "database-developer-term",
      "title": "KDT-232 LOG CONTINUITY",
      "text": "Evidence that required log positions contain no unrecoverable gap. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: LOG CONTINUITY is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "log",
        "continuity"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-233",
      "kind": "database-developer-term",
      "title": "KDT-233 RESTORE DRILL",
      "text": "A scheduled recovery execution that validates data, timing, access, and applications. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: RESTORE DRILL is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "restore",
        "drill"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-234",
      "kind": "database-developer-term",
      "title": "KDT-234 RECOVERY PROOF",
      "text": "The checksums, counts, invariants, and timing showing a restore met its contract. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: RECOVERY PROOF is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "recovery",
        "proof"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-235",
      "kind": "database-developer-term",
      "title": "KDT-235 REGION ESCAPE",
      "text": "The documented path to restore service outside a failed or inaccessible region. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: REGION ESCAPE is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "region",
        "escape"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-236",
      "kind": "database-developer-term",
      "title": "KDT-236 IMMUTABLE COPY",
      "text": "A backup copy protected from mutation and deletion for a declared interval. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: IMMUTABLE COPY is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "immutable",
        "copy"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-237",
      "kind": "database-developer-term",
      "title": "KDT-237 CORRUPTION WINDOW",
      "text": "The bounded history interval that may contain undetected invalid data. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: CORRUPTION WINDOW is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "corruption",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-238",
      "kind": "database-developer-term",
      "title": "KDT-238 REPAIR BOUNDARY",
      "text": "The smallest data and history scope selected for verified repair. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: REPAIR BOUNDARY is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "repair",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-239",
      "kind": "database-developer-term",
      "title": "KDT-239 FAILOVER FENCE",
      "text": "The authority barrier preventing the failed primary from resuming unsafe writes. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: FAILOVER FENCE is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "failover",
        "fence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-240",
      "kind": "database-developer-term",
      "title": "KDT-240 RETURN-TO-PRIMARY PLAN",
      "text": "The validated sequence for moving authority back after disaster operation. Normative contract: Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills. Adoption signal: RETURN-TO-PRIMARY PLAN is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives. Family: Backup, Restore, and Disaster Recovery. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "backup-recovery",
        "proposed",
        "return-to-primary",
        "plan"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-241",
      "kind": "database-developer-term",
      "title": "KDT-241 WORK UNIT",
      "text": "One precisely defined useful database outcome used to normalize performance and cost. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: WORK UNIT is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "work",
        "unit"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-242",
      "kind": "database-developer-term",
      "title": "KDT-242 LATENCY ENVELOPE",
      "text": "The allowed p50, p95, p99, and timeout behavior for a workload. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: LATENCY ENVELOPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "latency",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-243",
      "kind": "database-developer-term",
      "title": "KDT-243 THROUGHPUT ENVELOPE",
      "text": "The sustainable work rate under declared latency and correctness constraints. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: THROUGHPUT ENVELOPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "throughput",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-244",
      "kind": "database-developer-term",
      "title": "KDT-244 CONCURRENCY SHAPE",
      "text": "The clients, connections, in-flight work, key skew, and arrival pattern of load. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: CONCURRENCY SHAPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "concurrency",
        "shape"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-245",
      "kind": "database-developer-term",
      "title": "KDT-245 RESOURCE ENVELOPE",
      "text": "The CPU, memory, storage, IOPS, network, and power limits of a workload. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: RESOURCE ENVELOPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "resource",
        "envelope"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-246",
      "kind": "database-developer-term",
      "title": "KDT-246 COST PER USEFUL OPERATION",
      "text": "Total infrastructure cost divided by successfully validated work units. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: COST PER USEFUL OPERATION is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "cost",
        "per",
        "useful",
        "operation"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-247",
      "kind": "database-developer-term",
      "title": "KDT-247 AMPLIFICATION LEDGER",
      "text": "A combined account of logical work versus physical reads, writes, storage, and network. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: AMPLIFICATION LEDGER is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "amplification",
        "ledger"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-248",
      "kind": "database-developer-term",
      "title": "KDT-248 ALLOCATION BUDGET",
      "text": "The maximum heap allocations and allocated bytes allowed per work unit. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: ALLOCATION BUDGET is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "allocation",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-249",
      "kind": "database-developer-term",
      "title": "KDT-249 COPY BUDGET",
      "text": "The maximum memory or serialization copies allowed through a data path. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: COPY BUDGET is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "copy",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-250",
      "kind": "database-developer-term",
      "title": "KDT-250 LOCK HOLD BUDGET",
      "text": "The maximum duration shared progress may be blocked by one critical section. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: LOCK HOLD BUDGET is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "lock",
        "hold",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-251",
      "kind": "database-developer-term",
      "title": "KDT-251 TAIL TAX",
      "text": "The resource or coordination overhead paid specifically to control worst-case latency. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: TAIL TAX is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "tail",
        "tax"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-252",
      "kind": "database-developer-term",
      "title": "KDT-252 COLD-START CLOCK",
      "text": "The time from process start to validated readiness for the declared workload. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: COLD-START CLOCK is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "cold-start",
        "clock"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-253",
      "kind": "database-developer-term",
      "title": "KDT-253 BENCHMARK CONTRACT",
      "text": "The fixed dataset, operations, durability, concurrency, correctness, and reporting rules. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: BENCHMARK CONTRACT is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "benchmark",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-254",
      "kind": "database-developer-term",
      "title": "KDT-254 BASELINE PAIR",
      "text": "Two runs verified compatible enough for a meaningful performance delta. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: BASELINE PAIR is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "baseline",
        "pair"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-255",
      "kind": "database-developer-term",
      "title": "KDT-255 PERFORMANCE CLAIM BOUNDARY",
      "text": "The exact workloads and evidence beyond which a speed claim does not apply. Normative contract: Implementations using these terms MUST publish a named baseline, workload semantics, correctness gates, resource envelope, and tail distributions before making comparative performance claims. Adoption signal: PERFORMANCE CLAIM BOUNDARY is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost. Family: Performance, Capacity, and Cost. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "performance-cost",
        "proposed",
        "performance",
        "claim",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-256",
      "kind": "database-developer-term",
      "title": "KDT-256 PORTABILITY CONTRACT",
      "text": "The supported runtime, storage, network, identity, and operational dependencies across providers. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: PORTABILITY CONTRACT is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "portability",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-257",
      "kind": "database-developer-term",
      "title": "KDT-257 PROVIDER PROFILE",
      "text": "A versioned description of one cloud's regions, services, limits, and deployment capabilities. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: PROVIDER PROFILE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "provider",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-258",
      "kind": "database-developer-term",
      "title": "KDT-258 RUNTIME PROFILE",
      "text": "A deployable topology with explicit compute, storage, replication, backup, and SLO behavior. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: RUNTIME PROFILE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "runtime",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-259",
      "kind": "database-developer-term",
      "title": "KDT-259 STORAGE ADAPTER CONTRACT",
      "text": "The ordering, atomicity, durability, and error behavior required from a storage backend. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: STORAGE ADAPTER CONTRACT is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "storage",
        "adapter",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-260",
      "kind": "database-developer-term",
      "title": "KDT-260 PROTOCOL PERSONALITY",
      "text": "A compatibility surface translating a familiar protocol into native database semantics. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: PROTOCOL PERSONALITY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "protocol",
        "personality"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-261",
      "kind": "database-developer-term",
      "title": "KDT-261 WIRE-COMPATIBLE SURFACE",
      "text": "An endpoint preserving declared request, response, and error behavior of another protocol. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: WIRE-COMPATIBLE SURFACE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "wire-compatible",
        "surface"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-262",
      "kind": "database-developer-term",
      "title": "KDT-262 IMPORT FIDELITY",
      "text": "The measured preservation of source values, types, order, identity, and constraints. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: IMPORT FIDELITY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "import",
        "fidelity"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-263",
      "kind": "database-developer-term",
      "title": "KDT-263 EXPORT FIDELITY",
      "text": "The measured completeness and reconstructability of data leaving the database. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: EXPORT FIDELITY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "export",
        "fidelity"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-264",
      "kind": "database-developer-term",
      "title": "KDT-264 CONNECTOR CHECKPOINT",
      "text": "A durable source and destination position for resumable data movement. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: CONNECTOR CHECKPOINT is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "connector",
        "checkpoint"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-265",
      "kind": "database-developer-term",
      "title": "KDT-265 SINK DELIVERY CLASS",
      "text": "The ordering, duplication, retry, and acknowledgement guarantees of an outbound sink. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: SINK DELIVERY CLASS is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "sink",
        "delivery",
        "class"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-266",
      "kind": "database-developer-term",
      "title": "KDT-266 SOURCE REPLAY CLASS",
      "text": "The history, ordering, and resume behavior available from an inbound source. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: SOURCE REPLAY CLASS is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "source",
        "replay",
        "class"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-267",
      "kind": "database-developer-term",
      "title": "KDT-267 SOVEREIGNTY PROFILE",
      "text": "A deployable bundle of residency, operator, key, network, and support constraints. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: SOVEREIGNTY PROFILE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "sovereignty",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-268",
      "kind": "database-developer-term",
      "title": "KDT-268 ESCAPE HATCH",
      "text": "A documented and tested path to export data, keys, configuration, and operational control. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: ESCAPE HATCH is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "escape",
        "hatch"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-269",
      "kind": "database-developer-term",
      "title": "KDT-269 VENDOR BOUNDARY",
      "text": "The exact feature or responsibility delegated to provider-specific infrastructure. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: VENDOR BOUNDARY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "vendor",
        "boundary"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-270",
      "kind": "database-developer-term",
      "title": "KDT-270 INTEROP PROOF",
      "text": "Versioned evidence that two systems exchange data and behavior within declared loss bounds. Normative contract: Implementations using these terms MUST declare provider dependencies, protocol differences, import and export fidelity, connector progress, and a tested path away from vendor-specific infrastructure. Adoption signal: INTEROP PROOF is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies. Family: Portability and Interoperability. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "interoperability",
        "proposed",
        "interop",
        "proof"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-271",
      "kind": "database-developer-term",
      "title": "KDT-271 DESIRED STATE",
      "text": "The versioned configuration the control plane is responsible for realizing. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: DESIRED STATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "desired",
        "state"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-272",
      "kind": "database-developer-term",
      "title": "KDT-272 OBSERVED STATE",
      "text": "The measured resource and service condition reported by the managed data plane. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: OBSERVED STATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "observed",
        "state"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-273",
      "kind": "database-developer-term",
      "title": "KDT-273 RECONCILE LOOP",
      "text": "An idempotent process that drives observed state toward desired state. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: RECONCILE LOOP is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "reconcile",
        "loop"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-274",
      "kind": "database-developer-term",
      "title": "KDT-274 DRIFT MARKER",
      "text": "A machine-readable difference between declared and observed configuration or capacity. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: DRIFT MARKER is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "drift",
        "marker"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-275",
      "kind": "database-developer-term",
      "title": "KDT-275 OPERATION LEASE",
      "text": "Exclusive time-bounded authority to execute one dangerous lifecycle operation. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: OPERATION LEASE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "operation",
        "lease"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-276",
      "kind": "database-developer-term",
      "title": "KDT-276 APPROVAL GATE",
      "text": "A policy-controlled checkpoint requiring named authorization before execution continues. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: APPROVAL GATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "approval",
        "gate"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-277",
      "kind": "database-developer-term",
      "title": "KDT-277 CHANGE WINDOW",
      "text": "The allowed time, scope, and risk conditions for an operational change. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: CHANGE WINDOW is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "change",
        "window"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-278",
      "kind": "database-developer-term",
      "title": "KDT-278 ROLLOUT RING",
      "text": "An ordered fleet subset used to limit exposure during progressive delivery. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: ROLLOUT RING is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "rollout",
        "ring"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-279",
      "kind": "database-developer-term",
      "title": "KDT-279 HEALTH GATE",
      "text": "The measured conditions required before an operation advances to the next stage. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: HEALTH GATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "health",
        "gate"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-280",
      "kind": "database-developer-term",
      "title": "KDT-280 AUTO-HEAL BUDGET",
      "text": "The maximum concurrent repair work and customer impact allowed for automation. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: AUTO-HEAL BUDGET is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "auto-heal",
        "budget"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-281",
      "kind": "database-developer-term",
      "title": "KDT-281 CAPACITY INTENT",
      "text": "The workload, headroom, locality, and cost targets driving resource allocation. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: CAPACITY INTENT is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "capacity",
        "intent"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-282",
      "kind": "database-developer-term",
      "title": "KDT-282 SCALE DECISION",
      "text": "An auditable action linking capacity evidence to a topology or resource change. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: SCALE DECISION is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "scale",
        "decision"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-283",
      "kind": "database-developer-term",
      "title": "KDT-283 FLEET SLICE",
      "text": "A selectable group of deployments sharing provider, region, version, tenant, or risk. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: FLEET SLICE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "fleet",
        "slice"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-284",
      "kind": "database-developer-term",
      "title": "KDT-284 CONTROL-DATA SEPARATION",
      "text": "The authority and failure boundary between fleet management and customer data processing. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: CONTROL-DATA SEPARATION is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "control-data",
        "separation"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-285",
      "kind": "database-developer-term",
      "title": "KDT-285 OPERATOR EVIDENCE",
      "text": "The timeline, inputs, approvals, outputs, and rollback information for an operation. Normative contract: Implementations using these terms MUST separate desired from observed state, serialize dangerous operations, expose drift and approvals, and gate automated healing by explicit budgets. Adoption signal: OPERATOR EVIDENCE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change. Family: Operations and Control Planes. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "operations-control",
        "proposed",
        "operator",
        "evidence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-286",
      "kind": "database-developer-term",
      "title": "KDT-286 TERM REGISTRY",
      "text": "An append-only versioned catalog assigning stable identifiers to defined engineering language. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: TERM REGISTRY is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "term",
        "registry"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-287",
      "kind": "database-developer-term",
      "title": "KDT-287 NORMATIVE CONTRACT",
      "text": "A requirement stated with testable MUST, SHOULD, or MAY behavior. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: NORMATIVE CONTRACT is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "normative",
        "contract"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-288",
      "kind": "database-developer-term",
      "title": "KDT-288 CONFORMANCE LEVEL",
      "text": "A named set of mandatory contracts an implementation proves together. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: CONFORMANCE LEVEL is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "conformance",
        "level"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-289",
      "kind": "database-developer-term",
      "title": "KDT-289 CAPABILITY MANIFEST",
      "text": "A machine-readable declaration of supported contracts, versions, limits, and evidence. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: CAPABILITY MANIFEST is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "capability",
        "manifest"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-290",
      "kind": "database-developer-term",
      "title": "KDT-290 FEATURE STATUS",
      "text": "The proposed, experimental, preview, stable, deprecated, or removed state of behavior. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: FEATURE STATUS is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "feature",
        "status"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-291",
      "kind": "database-developer-term",
      "title": "KDT-291 MATURITY STAGE",
      "text": "The evidence level reached from concept through production and multi-provider proof. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: MATURITY STAGE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "maturity",
        "stage"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-292",
      "kind": "database-developer-term",
      "title": "KDT-292 EXPERIMENTAL FENCE",
      "text": "A boundary preventing unproven behavior from silently becoming a stable dependency. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: EXPERIMENTAL FENCE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "experimental",
        "fence"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-293",
      "kind": "database-developer-term",
      "title": "KDT-293 STANDARD PROFILE",
      "text": "A named interoperable selection of contracts and parameter ranges. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: STANDARD PROFILE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "standard",
        "profile"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-294",
      "kind": "database-developer-term",
      "title": "KDT-294 COMPATIBILITY MATRIX",
      "text": "The tested behavior across client, server, protocol, provider, and version combinations. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: COMPATIBILITY MATRIX is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "compatibility",
        "matrix"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-295",
      "kind": "database-developer-term",
      "title": "KDT-295 DEPRECATION RECORD",
      "text": "The reason, replacement, notice date, migration path, and removal date for a contract. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: DEPRECATION RECORD is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "deprecation",
        "record"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-296",
      "kind": "database-developer-term",
      "title": "KDT-296 DECISION LEDGER",
      "text": "An append-only record of accepted, rejected, superseded, and reversed engineering decisions. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: DECISION LEDGER is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "decision",
        "ledger"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-297",
      "kind": "database-developer-term",
      "title": "KDT-297 IMPLEMENTATION NOTE",
      "text": "Non-normative guidance explaining one valid way to satisfy a contract. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: IMPLEMENTATION NOTE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "implementation",
        "note"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-298",
      "kind": "database-developer-term",
      "title": "KDT-298 INTEROPERABILITY TEST",
      "text": "A vendor-neutral test proving two independent implementations exchange valid behavior. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: INTEROPERABILITY TEST is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "interoperability",
        "test"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-299",
      "kind": "database-developer-term",
      "title": "KDT-299 ADOPTION SIGNAL",
      "text": "Observable evidence that an external tool, client, or operator uses a term or contract. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: ADOPTION SIGNAL is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "adoption",
        "signal"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "database-term-kdt-300",
      "kind": "database-developer-term",
      "title": "KDT-300 PROOF BEFORE CLAIM",
      "text": "The rule that architecture, scale, security, or speed language requires reproducible evidence. Normative contract: Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions. Adoption signal: PROOF BEFORE CLAIM is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact. Family: Standards and Engineering Governance. Status: proposed.",
      "source": "docs/standards/kdt-registry.mjs",
      "tags": [
        "kdt",
        "database-developer-standard",
        "governance-standards",
        "proposed",
        "proof",
        "before",
        "claim"
      ],
      "kpis": [],
      "anchor": "database-developer-terminology"
    },
    {
      "id": "kyrx-source-dabd6528dbab1b60-1",
      "kind": "kyrx-source-file",
      "title": "bootstrap/kyrxc.kyrx",
      "text": "KYRx compiler-bootstrap. Module: kyrxc. Symbols: check, codegen, compile, lex, lower, parse. Source SHA-256: 4d6ef865f50b32cfece1deac4799a46f39b2a93e21fb4811f230d594d236d216. Source:\n// kyrxc.kyrx — KYRx compiler bootstrap sketch (T063)\n// This file describes the compiler pipeline in KYRx syntax.\n// It is the seed for self-hosted compilation.\n\npub fn lex(source: String) -> String {\n    source\n}\n\npub fn parse(tokens: String) -> String {\n    tokens\n}\n\npub fn check(ast: String) -> String {\n    ast\n}\n\npub fn lower(typed_ast: String) -> String {\n    typed_ast\n}\n\npub fn codegen(mir: String) -> String {\n    mir\n}\n\npub fn compile(source: String) -> String {\n    let tokens = lex(source);\n    let ast = parse(tokens);\n    let checked = check(ast);\n    let mir = lower(checked);\n    codegen(mir)\n}\n",
      "source": "kyrx:bootstrap/kyrxc.kyrx",
      "tags": [
        "kyrx",
        "source-file",
        "compiler-bootstrap",
        "kyrxc",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files"
    },
    {
      "id": "kyrx-source-7697e774e8234828-1",
      "kind": "kyrx-source-file",
      "title": "examples/hello/main.kyrx",
      "text": "KYRx example-source. Module: main. Symbols: main. Source SHA-256: 332c9a6627eece3a9045581c7f7f2a8369b3b783999240ebab452fbf5347c60b. Source:\nfn main() { print(\"hello, kyrx\") }\n",
      "source": "kyrx:examples/hello/main.kyrx",
      "tags": [
        "kyrx",
        "source-file",
        "example-source",
        "main",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files"
    },
    {
      "id": "kyrx-source-f08a1294c1a1a5dd-1",
      "kind": "kyrx-source-file",
      "title": "examples/hello/package.kyrx",
      "text": "KYRx package-manifest. Module: package. Symbols: none. Source SHA-256: 12976677f4d59687a6ff905dfb0df58a7971ba31b931093f89d9defc964e3758. Source:\npackage {\n  name: \"hello\"\n  version: \"0.1.0\"\n  edition: \"2026\"\n}\n",
      "source": "kyrx:examples/hello/package.kyrx",
      "tags": [
        "kyrx",
        "source-file",
        "package-manifest",
        "package",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files"
    },
    {
      "id": "kyrx-knowledge-architecture-01-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: KYRx System Architecture",
      "text": "# KYRx System Architecture\n\nThis document is the single source of truth for how KYRx fits together. When in doubt, this wins. Subordinate documents (`docs/*`) elaborate specific subsystems.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-02-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 0. Top-level dataflow",
      "text": "## 0. Top-level dataflow\n\n```\n┌───────────┐   ┌──────────┐   ┌─────────┐   ┌──────────┐   ┌──────────┐\n│  .kyrx    │→  │ kyrxc    │→  │  MIR    │→  │ Cranelift│→  │  mold    │\n│  source   │   │ (front)  │   │(typed)  │   │   or     │   │ linker   │→ exe / .so / wasm\n└───────────┘   └──────────┘   └─────────┘   │  LLVM    │   └──────────┘\n                     │              │        └──────────┘\n                     ▼              ▼\n               Diagnostics    Debug metadata (.kyrx_debug)\n                     │\n                     ▼\n                LSP / IDE\n```\n\nEvery compile unit is hashed (BLAKE3 of inputs + flags + toolchain). All artifacts live in a **content-addressed store** at `~/.kyrx/store/<hash>/`.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-03-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1. Components and responsibilities",
      "text": "## 1. Components and responsibilities",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-04-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1.1 `compiler/` — `kyrxc`",
      "text": "### 1.1 `compiler/` — `kyrxc`\nThe compiler is a library (`kyrxc_driver`) with a thin CLI. It is written in **Rust 1.82+**, edition 2021, `cargo workspace`.\n\n| crate | responsibility |\n|---|---|\n| `kyrxc_lexer` | UTF-8 source → tokens w/ spans |\n| `kyrxc_parser` | tokens → CST (lossless) → AST |\n| `kyrxc_ast` | typed AST, visitor, pretty-printer |\n| `kyrxc_resolve` | name resolution, module graph |\n| `kyrxc_types` | bidirectional type inference + row polymorphism |\n| `kyrxc_effects` | effect row inference (`{io, alloc, panic, async, unsafe}`) |\n| `kyrxc_regions` | region constraint solver |\n| `kyrxc_ownership` | move/use analysis, drop insertion |\n| `kyrxc_mir` | typed mid-level IR, SSA |\n| `kyrxc_opt` | inline / DCE / devirt / escape |\n| `kyrxc_backend_cranelift` | dev codegen |\n| `kyrxc_backend_llvm` | release codegen via `inkwell` |\n| `kyrxc_diagnostics` | 3-layer diagnostics + quickfix emitter |\n| `kyrxc_driver` | orchestration, incremental cache, CLI |\n\nEach crate owns a `tests/` directory of golden-output tests. No pass may break the invariants of an earlier pass.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-05-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1.2 `pkg/` — `kyrx` CLI",
      "text": "### 1.2 `pkg/` — `kyrx` CLI\nSingle binary. Subcommands: `new`, `build`, `run`, `test`, `fmt`, `lint`, `fix`, `doc`, `bench`, `publish`, `migrate`, `add`, `tree`, `cache`. Workspace-aware. Shares the resolver with `kyrxc`.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-06-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1.3 `lsp/` — `kyrx-lsp`",
      "text": "### 1.3 `lsp/` — `kyrx-lsp`\nLSP server built on the compiler library. Talks to VS Code / Neovim / JetBrains / Zed. Emits diagnostics, quickfixes, inlay hints (regions, effects, types), go-to-def, refactor. Sub-50ms typing latency budget.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-07-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1.4 `runtime/` — `kyrx-runtime`",
      "text": "### 1.4 `runtime/` — `kyrx-runtime`\nSmall (< 50k LOC) C + Rust runtime library linked into every KYRx binary.\n- **Scheduler**: work-stealing, structured concurrency nurseries.\n- **IO reactor**: `io_uring` (Linux), `kqueue` (macOS/BSD), `IOCP` (Windows).\n- **Timers**: hierarchical timing wheel.\n- **Channels**: MPMC, bounded.\n- **Record/replay**: deterministic debug trace.\n- **Allocator**: per-region arenas + mimalloc fallback.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-08-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1.5 `stdlib/`",
      "text": "### 1.5 `stdlib/`\nKYRx source. Layered: `core` (no_alloc) → `alloc` → `std`. Unit tests co-located.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-09-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1.6 `bridges/`",
      "text": "### 1.6 `bridges/`\nThin wrapper crates/libraries that expose KYRx as loadable code in React, Node, Rust, Python, Go, and WASM. See `bridges/README.md`.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-10-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 1.7 Public knowledge pipeline",
      "text": "### 1.7 Public knowledge pipeline\n\nThe Pages build owns the public ingest artifact at `/knowledge/kyrx.json`. It is generated deterministically from the architecture, language specification, effects, regions, performance, and bridge documents; the browser does not load it during normal page navigation.\n\n`workers/kyrx-rag/` owns retrieval. A daily Cloudflare Cron Trigger fetches the artifact, skips unchanged content by SHA-256 digest, embeds changed chunks with Workers AI, and upserts them into the dedicated `kyrx-knowledge` Vectorize index. KV owns freshness metadata, active vector IDs, and bounded request counters; stale vectors are deleted after each changed ingest. The public answer endpoint retrieves source chunks before generation and returns those sources with every answer. It never rewrites product claims or source documentation.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-11-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 2. Invariants",
      "text": "## 2. Invariants\n\n1. Every artifact is content-addressed — inputs determine output, byte for byte, across machines.\n2. Debug metadata survives all optimization passes (opts may **refine** it; may not **drop** it).\n3. Any pass that rejects a program emits a **3-layer diagnostic** (see `docs/DIAGNOSTICS.md`).\n4. The compiler library never calls `exit()`. Drivers do.\n5. Public API of any crate lives in `lib.rs` and is documented.\n6. `unsafe` in the compiler is forbidden outside `kyrxc_backend_llvm`.\n7. The runtime is allocation-aware — every async op tells the scheduler its memory class.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-12-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 3. External dependencies (locked)",
      "text": "## 3. External dependencies (locked)\n\n| need | dep | rationale |\n|---|---|---|\n| LLVM bindings | `inkwell` | mature, typed |\n| Cranelift | `cranelift-*` 0.103+ | dev codegen |\n| BLAKE3 | `blake3` | content hashing |\n| Parser base | handwritten | LSP needs error-tolerant parsing |\n| Linker | `mold` (Linux/macOS), `lld` (Windows) | speed |\n| Allocator | `mimalloc` | perf |\n| IO | `io_uring` via `io-uring` crate; `kqueue` via `kqueue`; `IOCP` via `windows` | cross-platform |\n| LSP | `tower-lsp` | standard |\n\n**No Tokio.** The runtime is our own; using Tokio would couple us to its execution model.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-13-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 4. Module ownership map (who owns what)",
      "text": "## 4. Module ownership map (who owns what)\n\n| subsystem | primary spec | code |\n|---|---|---|\n| syntax | docs/GRAMMAR.ebnf + docs/SPEC.md §1-2 | kyrxc_lexer, kyrxc_parser |\n| types | docs/TYPE_SYSTEM.md | kyrxc_types |\n| regions/ownership | docs/REGIONS.md | kyrxc_regions, kyrxc_ownership |\n| effects/async | docs/EFFECTS_ASYNC.md | kyrxc_effects, runtime/scheduler |\n| MIR | docs/MIR.md | kyrxc_mir, kyrxc_opt |\n| diagnostics | docs/DIAGNOSTICS.md | kyrxc_diagnostics |\n| debugging | docs/DEBUGGER.md | kyrxc_backend_*, runtime/record_replay |\n| cache | docs/CACHE.md | pkg/cache, kyrxc_driver |\n| bridges | bridges/README.md | bridges/* |\n| public knowledge | workers/kyrx-rag/README.md | registry/web/scripts/build-knowledge.mjs, workers/kyrx-rag |",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-14-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 5. Build graph",
      "text": "## 5. Build graph\n\n```\nkyrxc_lexer  ─┐\n              ├→ kyrxc_parser → kyrxc_ast → kyrxc_resolve → kyrxc_types\n              │                                                │\nkyrxc_diagnostics ←───────────────────────────────────────────┤\n                                                               ▼\n                                           kyrxc_effects → kyrxc_regions\n                                                               │\n                                                               ▼\n                                                         kyrxc_ownership\n                                                               │\n                                                               ▼\n                                                          kyrxc_mir → kyrxc_opt\n                                                               │\n                                                   ┌───────────┴───────────┐\n                                                   ▼                       ▼\n                                         kyrxc_backend_cranelift  kyrxc_backend_llvm\n                                                   └───────────┬───────────┘\n                                                               ▼\n                                                          kyrxc_driver\n```",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-15-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 6. Performance targets (non-negotiable)",
      "text": "## 6. Performance targets (non-negotiable)\n\n| metric | target |\n|---|---|\n| incremental rebuild (1 fn edit, 100kloc project) | **< 500 ms** |\n| clean dev build, 10kloc | **< 2 s** |\n| clean release build, 10kloc | < 15 s |\n| LSP diagnostic latency (per keystroke) | **< 50 ms** |\n| hello-world release binary | ≤ 350 KB |\n| runtime overhead vs hand-C for HTTP echo | within 5% |\n\nIf a PR regresses any of these, it blocks merge.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-16-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 6.1 Measurement architecture",
      "text": "### 6.1 Measurement architecture\n\nPerformance is a continuously verified contract, not a release-only audit. Every push and pull request runs deterministic public-site asset budgets and statistical compiler pipeline benchmarks. Deterministic budget regressions block the change; runner-dependent timing results are retained as trend evidence and become gates only when measured on controlled hardware.\n\nAny update that introduces a hot path, compiler phase, asset class, or Kynetra integration boundary must add or extend its benchmark. Changes to component ownership, dataflow, or a performance target must update this document in the same commit. Commands, budgets, and the required before/after reporting loop live in [`docs/PERFORMANCE.md`](docs/PERFORMANCE.md).",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-17-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 7. Error policy",
      "text": "## 7. Error policy\n\n- Compiler panics are bugs. Prefer `Result`.\n- User-facing errors → `Diagnostic` (3-layer).\n- Internal-consistency errors → `ICE` (internal compiler error) with crash-dump hook.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-18-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 8. Release trains",
      "text": "## 8. Release trains\n\n- `nightly` — every main commit.\n- `beta` — every 6 weeks.\n- `stable` — every 12 weeks.\n- Editions — every 18 months.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-architecture-19-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx system architecture: 9. Glossary",
      "text": "## 9. Glossary\n\n- **Region** — inferred scope for reference validity. Replaces Rust lifetimes for 90% of cases.\n- **Own** — unique-ownership modifier applied explicitly to resources.\n- **Shared** — refcount-backed multi-owner; compile-time elided where possible.\n- **Nursery** — structured concurrency scope; parent of spawned tasks.\n- **Effect row** — polymorphic record of effects a function may perform.\n- **Protocol** — interface (like a Rust trait, but without the marker-trait and typeclass-deriving jobs).\n- **Capability** — zero-runtime marker type (`Send`, `Sync`, `Unsafe`).\n- **Typeclass** — derivable numeric/structural class (`Num`, `Show`, `Eq`).\n- **Store** — content-addressed artifact cache at `~/.kyrx/store/`.",
      "source": "kyrx:ARCHITECTURE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "architecture",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs"
    },
    {
      "id": "kyrx-knowledge-spec-01-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: KYRx Language Specification (v0.1 draft)",
      "text": "# KYRx Language Specification (v0.1 draft)\n\nThis is the normative specification. Examples are informative.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-02-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 1. Lexical structure",
      "text": "## 1. Lexical structure\n\n- Source files are UTF-8, extension `.kyrx`.\n- Line terminators: `\\n` (`\\r\\n` normalized on read).\n- Comments: `//` (line), `/* ... */` (block, nestable).\n- Identifiers: `[A-Za-z_][A-Za-z0-9_]*`, Unicode XID optional behind a flag.\n- Keywords: `fn let mut if else match for while loop break continue return struct enum protocol instance capability typeclass derive module import export own shared region effect nursery spawn await true false as in unsafe_cap extern`.\n- Literals: integer (`123`, `0xff`, `0b1010`, `0o17`, underscores allowed), float (`1.0`, `1e-3`), string (`\"...\"`, `r\"...\"`, multi-line `\"\"\"...\"\"\"`), char (`'x'`), byte (`b'x'`, `b\"...\"`).\n- Operators: `+ - * / % == != < <= > >= && || ! & | ^ << >> = += -= *= /= %= := -> => ?`\n- Delimiters: `( ) [ ] { } , ; :`\n\nSee `docs/GRAMMAR.ebnf` for the formal grammar.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-03-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 2. Module & package system",
      "text": "## 2. Module & package system\n\n- One `package.kyrx` at each package root.\n- A package = DAG of modules. Module = directory or single file.\n- `import foo.bar` brings `bar` into scope.\n- `export { a, b }` in a module declares its public surface; default is private.\n- No `pub use` — re-exports use `export { x from foo.bar }`.\n\n```kyrx\n// package.kyrx\npackage {\n  name: \"@acme/http\"\n  version: \"0.1.0\"\n  edition: \"2026\"\n  deps: {\n    \"@std/net\": \"1.*\",\n    \"@ext/tls\": \"^0.4\"\n  }\n}\n```",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-04-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 3. Types",
      "text": "## 3. Types\n\n- Primitives: `i8 i16 i32 i64 i128 isize`, `u8 … usize`, `f32 f64`, `bool`, `char`, `str`, `()`, `never`.\n- Compound: tuples `(T, U)`, arrays `[T; N]`, slices `[T]`, records `{x: T, y: U}`, enums.\n- References: `&T` (region inferred), `&mut T`, `&r T` when region named.\n- Ownership modifiers: `own T`, `shared T`.\n- Functions: `fn(T, U) -> V !<E>` where `<E>` is the effect row (usually inferred).\n- Generics: `fn foo<T: Ord>(...)`. Full local inference; annotations only at boundaries.\n\nSee `docs/TYPE_SYSTEM.md` for inference rules.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-05-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 4. Regions & ownership",
      "text": "## 4. Regions & ownership\n\nSee `docs/REGIONS.md`. Summary:\n\n1. Every reference has an inferred region variable.\n2. A region constraint graph is solved per function.\n3. `own T` values are unique; moving them is an ownership transfer.\n4. `shared T` values are refcounted; refcount is elided when escape analysis proves single-owner.\n5. Drops are inserted at the end of owning scopes, predictable and deterministic.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-06-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 5. Effects",
      "text": "## 5. Effects\n\nSee `docs/EFFECTS_ASYNC.md`. Effect row `{io, alloc, panic, async, unsafe, ...user}`. Inferred by default. Annotations at exported boundaries optional but idiomatic:\n\n```kyrx\nfn read_file(p: Path) -> String !<io, alloc, panic>\n```",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-07-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 6. Protocols, capabilities, typeclasses",
      "text": "## 6. Protocols, capabilities, typeclasses\n\nThree categories with distinct purposes. See §9 of ARCHITECTURE.md glossary.\n\n```kyrx\nprotocol Iterator {\n  type Item\n  fn next(self: &mut Self) -> Option<Self.Item>\n}\n\ncapability Send   // zero-runtime marker\ncapability Sync\n\ntypeclass Num<T> {\n  fn zero() -> T\n  fn one() -> T\n  fn add(a: T, b: T) -> T\n  // ... with laws\n}\n\ninstance Iterator for Range {\n  type Item = i64\n  fn next(self) -> Option<i64> { ... }\n}\n\n// named instance (orphan rule replaced)\ninstance Show for i64 as show_hex {\n  fn show(self) = \"0x{self:x}\"\n}\n```\n\nCoherence: unnamed instances must be defined in the defining package of either the protocol or the type (local coherence). Named instances can live anywhere and require explicit selection (`@use(show_hex)`).",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-08-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 7. Pattern matching",
      "text": "## 7. Pattern matching\n\n- Exhaustiveness checked.\n- Patterns: literals, bindings, `_`, struct/tuple destructuring, `|` alternatives, `..` rest, guards `if`.\n- `match` expression; `if let`, `while let`.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-09-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 8. Concurrency & async",
      "text": "## 8. Concurrency & async\n\nSee `docs/EFFECTS_ASYNC.md`. Colorless async via effect rows. Structured concurrency via nurseries:\n\n```kyrx\nnursery |n| {\n  n.spawn || task1()\n  n.spawn || task2()\n}   // both joined; panic in one cancels siblings\n```",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-10-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 9. Memory model",
      "text": "## 9. Memory model\n\n- Sequentially consistent by default for atomics; explicit ordering via `atomic.*` module.\n- No data races: enforced by `Send`/`Sync` capability typing + ownership.\n- Out-of-bounds indexing panics (not UB).\n- Overflow: panics in debug, wraps in release for unsigned; signed overflow is a debug panic, explicit `wrapping_*` / `checked_*` for release.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-11-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 10. Unsafe & FFI",
      "text": "## 10. Unsafe & FFI\n\n- `capability Unsafe` gates raw pointer ops, FFI, transmute.\n- Per-module audit: `@allow_unsafe(\"reason\")` makes grants traceable.\n- `extern \"C\" fn foo(...) -> ...` for FFI.\n- `kyrx-bindgen` generates KYRx bindings from C headers.\n\n```kyrx\nextern \"C\" { fn read(fd: i32, buf: *mut u8, n: usize) -> isize }\n\n@allow_unsafe(\"libc read for zero-copy IO\")\nfn read_raw(fd: i32, buf: &mut [u8]) -> isize =\n  unsafe_cap { read(fd, buf.as_mut_ptr(), buf.len()) }\n```",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-12-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 11. Metaprogramming",
      "text": "## 11. Metaprogramming\n\n- **Derive**: `@derive(Show, Eq, Hash)` on types.\n- **Hygienic templates** (a-la Scala inline): `template fn assert(cond: bool) { ... }` — expanded with hygiene at call site. No procedural macros.\n- **Const eval**: functions marked `const fn` run at compile time on constant inputs.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-13-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 12. Standard library contract",
      "text": "## 12. Standard library contract\n\n- `core` — no alloc, no IO, no panic (returns `Result`).\n- `alloc` — `Vec`, `String`, `Box`, `Arc` (as `shared`).\n- `std` — IO, net, fs, sync, task.\n- Stability: `std` follows SemVer with 1.0 freeze; `core` is frozen forever once stabilized.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-14-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 13. ABI & symbol stability",
      "text": "## 13. ABI & symbol stability\n\n- Internal ABI: unstable; keyed on toolchain hash.\n- External ABI: `extern \"C\"` + `@stable_symbol(\"name\")` for shippable dylibs.\n- Monomorphization manifest written to `build/*.symmap` for release-build crash decoding.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-15-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 14. Toolchain conformance",
      "text": "## 14. Toolchain conformance\n\nA toolchain is conformant if:\n1. All tests in `compiler/tests/ui/` pass with identical stdout/stderr.\n2. Bootstrap of `kyrxc` via itself (stage-2) produces bit-identical binary.\n3. Content-addressed cache hashes match reference values.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-spec-16-1",
      "kind": "kyrx-knowledge-section",
      "title": "KYRx language specification: 15. Reserved for future (intentionally unspecified)",
      "text": "## 15. Reserved for future (intentionally unspecified)\n\n- Const generics beyond `N: usize`.\n- Higher-rank protocol bounds.\n- Linear types.\n- Dependent types.",
      "source": "kyrx:docs/SPEC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "spec",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/language"
    },
    {
      "id": "kyrx-knowledge-effects-01-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: KYRx Effects & Async",
      "text": "# KYRx Effects & Async\n\nKYRx has **no `async fn` keyword** in the user-visible calling convention. Asynchrony is an **effect** tracked in the type system.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-02-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 1. Effects",
      "text": "## 1. Effects",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-03-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 1.1 Built-in effect labels",
      "text": "### 1.1 Built-in effect labels\n\n| label | meaning |\n|---|---|\n| `io` | reads/writes external state (fs, net, stdio, clocks) |\n| `alloc` | may heap-allocate |\n| `panic` | may abort via panic |\n| `async` | may suspend (await a completion) |\n| `unsafe` | uses `capability Unsafe` |\n\nUser modules can declare additional effect labels (`effect Log;`) but builtins cover 99% of cases.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-04-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 1.2 Effect rows",
      "text": "### 1.2 Effect rows\n\nA function's type is `fn(T) -> U !<ε>` where `ε` is a row like `{io, alloc, async | ρ}` with optional row variable `ρ`.\n\n- Inferred by default.\n- Displayed in errors only when relevant.\n- Polymorphic: a function like `map` has effect row `ρ` (forwarded from its callback).\n\n```kyrx\nfn map<T, U>(xs: [T], f: fn(T) -> U !<ρ>) -> Vec<U> !<alloc, ρ>\n```",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-05-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 2. Colorless async",
      "text": "## 2. Colorless async",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-06-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 2.1 Rule",
      "text": "### 2.1 Rule\n\nA call *inherits* the effects of the callee. If the callee has `async` in its effect row, so does the caller. The caller is **not syntactically marked** — no `async fn`, no `.await`.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-07-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 2.2 Suspension points",
      "text": "### 2.2 Suspension points\n\nSuspension points are implicit at calls to `async`-effectful functions when executing inside a `nursery` scope or reactor. The compiler lowers each such call into a state-machine yield.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-08-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 2.3 Why this is safe",
      "text": "### 2.3 Why this is safe\n\n- Synchronous functions never call async ones without the effect flowing — inference catches attempts.\n- Every binary has an \"effect root\": either a reactor (`run(|| main())`) that services `async`, or a pure main that must not have `async` at the root.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-09-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 3. Structured concurrency",
      "text": "## 3. Structured concurrency",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-10-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 3.1 Nurseries",
      "text": "### 3.1 Nurseries\n\n```kyrx\nnursery |n| {\n  n.spawn || fetch(\"/a\")\n  n.spawn || fetch(\"/b\")\n}   // both joined before scope exits\n```\n\n- Tasks cannot outlive their nursery.\n- A panic in any spawned task cancels siblings and propagates.\n- Cancellation is a structured signal, not a \"dropped future\".",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-11-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 3.2 Task cancellation",
      "text": "### 3.2 Task cancellation\n\nEach task carries a `CancelToken`. Library code can cooperatively observe cancellation via `task.should_cancel()`. IO primitives check cancellation at every `io_uring`/`kqueue`/`IOCP` completion.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-12-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 3.3 Timeouts",
      "text": "### 3.3 Timeouts\n\n```kyrx\nwith_timeout(30.seconds()) || {\n  slow_operation()\n}\n```\nImplemented as a nursery with a timer child that cancels siblings.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-13-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 4. Implementation",
      "text": "## 4. Implementation",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-14-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 4.1 Lowering",
      "text": "### 4.1 Lowering\n\nThe `kyrxc_effects` pass annotates each call with its effect set. The MIR lowering:\n- Functions with `async` in their effect row are compiled to **state machines** using CPS-lite transformation.\n- State machine frames are stack-allocated when their size is known ≤ threshold, else heap-allocated via an arena owned by the nursery (no `Pin` needed because the frame lives in an arena with a stable address for its lifetime).\n- Recursion through `await` is detected; such functions fall back to **stackful fibers** (64KB guard-paged stacks, cached).",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-15-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 4.2 Runtime",
      "text": "### 4.2 Runtime\n\nSee `runtime/src/scheduler/`. Work-stealing scheduler. Each worker has a local queue + global steal. Nurseries are scopes that own a task handle set; drop = join.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-16-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 4.3 No `Pin`, no `Send` bounds",
      "text": "### 4.3 No `Pin`, no `Send` bounds\n\nFrames live in a known-stable place (arena or fiber stack). Hence no self-reference problem. Cross-task sharing uses capability typing (`Send`) at the value level, same as sync code — async does not introduce new bounds.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-17-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 5. Cancellation semantics",
      "text": "## 5. Cancellation semantics\n\n- Cancellation is **cooperative** at await points and at explicit `yield_cancel()` calls.\n- IO primitives (read/write/connect/…) observe cancellation and return `Err(Cancelled)`.\n- User code may catch `Cancelled` to perform cleanup but must not swallow it (enforced: `Cancelled` is a linear-resource-like error).",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-18-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 6. Examples",
      "text": "## 6. Examples\n\n```kyrx\nfn fetch(url: Url) -> Body {          // effect row inferred: {io, async, alloc}\n  let resp = http.get(url)            // suspends; effect propagates\n  resp.body()\n}\n\nfn main() {\n  run(|| {                            // run = effect root that services async\n    nursery |n| {\n      for u in urls { n.spawn || fetch(u) }\n    }\n  })\n}\n```",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-19-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 7. Comparison to Rust",
      "text": "## 7. Comparison to Rust\n\n| concept | Rust | KYRx |\n|---|---|---|\n| function color | `async fn` | inferred effect |\n| self-reference | `Pin<&mut Self>` | arena/fiber-backed frame |\n| thread-safety | `Send`, `Sync` bounds infect futures | unchanged; applies at value level |\n| trait dyn async | `dyn Future + Send` | `dyn Protocol` unchanged; protocol methods carry effect rows |\n| cancellation | drop future | structured signal at nursery |\n| schedulers | tokio/async-std/…fragmented | one runtime, swappable backends |",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-20-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 8. Acceptance tests",
      "text": "## 8. Acceptance tests\n\n- `tests/ui/async_effect_inferred.kyrx` — async effect flows through without keyword.\n- `tests/ui/nursery_cancel.kyrx` — sibling cancellation on panic.\n- `tests/ui/no_pin_recursion.kyrx` — recursion through await works via fiber fallback.\n- `tests/ui/cancel_swallowed.kyrx` — swallowing `Cancelled` is a diagnostic.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-effects-21-1",
      "kind": "kyrx-knowledge-section",
      "title": "Effects and async: 9. Implementation notes for Sonnet",
      "text": "## 9. Implementation notes for Sonnet\n\n- `kyrxc_effects::EffectRow { fixed: BitSet, var: Option<RowVar> }`.\n- Effect inference is a second pass after type inference; unifies row variables.\n- `kyrxc_mir` ships two function kinds: `MirFn::Sync` and `MirFn::StateMachine { states, transitions }`.\n- `runtime/scheduler/nursery.rs` owns the nursery scope's task set + cancel token.\n- Start by hard-coding `async` as the only non-builtin row effect that drives lowering; add others later.",
      "source": "kyrx:docs/EFFECTS_ASYNC.md",
      "tags": [
        "kyrx",
        "knowledge",
        "effects",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/effects"
    },
    {
      "id": "kyrx-knowledge-regions-01-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: KYRx Regions & Ownership",
      "text": "# KYRx Regions & Ownership\n\nThis document defines the non-lifetime borrowing model. It is the biggest *original move* in KYRx — it replaces Rust's lifetime system with scope-inferred regions for 90% of code.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-02-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 1. Why regions",
      "text": "## 1. Why regions\n\nRust lifetimes surface in APIs, produce cryptic `'a: 'b` constraints, and force intermediate users to think about aliasing every time they hold a reference. Regions collapse this: a reference is valid in the **scope** where it was produced, and the compiler infers the scope.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-03-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 2. Model",
      "text": "## 2. Model",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-04-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 2.1 Value tiers",
      "text": "### 2.1 Value tiers\n\n| tier | syntax | semantics |\n|---|---|---|\n| value | `T` | copy-or-move (inferred by size + `Copy` protocol) |\n| owned | `own T` | unique handle, deterministic drop |\n| shared | `shared T` | multi-owner, refcount (elided when possible) |\n| reference | `&T`, `&mut T` | scoped borrow in inferred region |",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-05-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 2.2 Region variables",
      "text": "### 2.2 Region variables\n\nEvery `&T` has an implicit region variable `ρ`. A region is:\n- a stack scope (block, expression, function),\n- a nursery scope,\n- a named region introduced by `&r T` syntax.\n\nRules:\n- Reading `&T` at position `p` generates constraint `alive(ρ, p)`.\n- Storing `&T` into a struct requires region of struct ≤ region of ref.\n- Returning `&T` from a function requires ρ ≥ function's return region (the caller's).",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-06-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 2.3 The constraint solver",
      "text": "### 2.3 The constraint solver\n\n- Per function we build a graph of region variables with outlives edges.\n- Run Tarjan SCC + transitive closure.\n- If cycles collapse to a set that is both `>= caller` and `<= local scope`, **error**: region escape.\n\nThis is essentially Polonius-style but exposed in the *error UX* as \"value `x` lives only inside this function\" — never \"lifetime `'1` does not outlive `'2`\".",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-07-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 2.4 Ownership (`own`)",
      "text": "### 2.4 Ownership (`own`)\n\n`own T` is unique. Moves are explicit: `let y = x` moves if `T` is not `Copy`. After move, `x` is flagged as *consumed*; further use is an error.\n\n`own T` is used for:\n- resources (file handles, sockets, DB connections),\n- large buffers where aliasing would be a bug,\n- anything with a custom `drop`.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-08-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 2.5 Shared (`shared T`)",
      "text": "### 2.5 Shared (`shared T`)\n\nRefcount, like Rust `Arc<T>` but:\n- **compile-time elision**: if escape analysis proves the value never leaves a single task and is not cloned, refcount is deleted and `shared T` becomes `own T`.\n- Interior mutability via `shared Cell<T>` with atomic updates. No `Mutex` ceremony for common cases.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-09-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 3. The 90% promise",
      "text": "## 3. The 90% promise\n\nOn a corpus of typical backend code, ≥ 90% of references should compile without the user writing a region name or `'a`. Explicit regions only appear when:\n- a function returns a reference whose region is tied to an argument's region (and there are multiple reference arguments),\n- a struct stores a reference,\n- two references must be constrained to the same scope.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-10-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 3.1 Elision rules (90% case)",
      "text": "### 3.1 Elision rules (90% case)\n\n1. If a function has exactly one reference parameter and returns a reference, the returned reference's region equals the input's.\n2. If a method takes `&self`, return references default to `self`'s region.\n3. Struct fields holding references default to the struct's region.\n4. All other cases require either inference to succeed within the function body, or explicit regions.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-11-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 3.2 Explicit regions syntax",
      "text": "### 3.2 Explicit regions syntax\n\nName with a short lowercase identifier immediately after `&`:\n\n```kyrx\nfn pair(a: &r str, b: &r str) -> (&r str, &r str) = (a, b)\n\nstruct View<r> {\n  data: &r [u8],\n  idx:  usize,\n}\n```\n\nNo leading tick. No `for<'a>`. Named regions are ordinary type parameters.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-12-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 4. Ownership analysis",
      "text": "## 4. Ownership analysis\n\nRuns after typeck. Produces:\n- **Move map**: for each binding, where it was moved / consumed.\n- **Drop schedule**: where drops are inserted (end of owning scope).\n- **Alias graph**: which references alias which owners.\n\nErrors:\n- *use-after-move* — attempted read of consumed value.\n- *double-move* — two ownership transfers.\n- *drop-while-borrowed* — drop would invalidate live reference.\n\nDiagnostics reference **origin spans** (the move site) not just the use site.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-13-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 5. Capability interaction",
      "text": "## 5. Capability interaction\n\n- `capability Send` — values can cross task boundaries. `shared T` is `Send` iff `T: Send`.\n- `capability Sync` — references can be shared across tasks.\n- Capabilities are inferred for structural types; declared for nominal types.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-14-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 6. Comparison to Rust",
      "text": "## 6. Comparison to Rust\n\n| concept | Rust | KYRx |\n|---|---|---|\n| lifetimes | `'a`, `'b`, `'static` | region variables, inferred; named `r` only when needed |\n| ownership | every binding | opt-in `own T` for resources |\n| shared ownership | `Rc<T>` / `Arc<T>` | `shared T` (refcount elidable) |\n| interior mutability | `Cell`, `RefCell`, `Mutex` | `shared Cell<T>` unifies the common case |\n| elision rules | 3 fixed | constraint-graph inference |",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-15-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 7. Implementation notes for Sonnet",
      "text": "## 7. Implementation notes for Sonnet\n\n- `kyrxc_regions` crate implements:\n  - `RegionVar` (u32 index),\n  - `OutlivesConstraint { longer, shorter, cause: Span }`,\n  - `ConstraintGraph`,\n  - `solve(&mut self) -> Result<RegionAssignment, Vec<RegionError>>`.\n- `kyrxc_ownership` crate implements:\n  - move/use dataflow (per-function SSA),\n  - drop insertion (pre-MIR),\n  - capability check.\n- Both emit `kyrxc_diagnostics::Diagnostic` with three layers.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-regions-16-1",
      "kind": "kyrx-knowledge-section",
      "title": "Regions and ownership: 8. Acceptance tests (non-exhaustive)",
      "text": "## 8. Acceptance tests (non-exhaustive)\n\n- `tests/ui/region_escape.kyrx` — returning local reference must fail with beginner-level message.\n- `tests/ui/own_move.kyrx` — use after move must cite move site.\n- `tests/ui/shared_cross_task.kyrx` — `shared<T>` where `T: !Send` must fail with capability reason.\n- `tests/ui/elision_single_ref.kyrx` — single `&T` input, `&T` output, no annotation, compiles.\n- `tests/ui/two_ref_inputs_annotated.kyrx` — two `&T` inputs returning one, requires `r`.",
      "source": "kyrx:docs/REGIONS.md",
      "tags": [
        "kyrx",
        "knowledge",
        "regions",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/regions"
    },
    {
      "id": "kyrx-knowledge-performance-01-1",
      "kind": "kyrx-knowledge-section",
      "title": "Performance contract: Performance Contract",
      "text": "# Performance Contract\n\nPerformance evidence is part of every KYRx update. A change is complete only when its relevant speed checks run and its architecture impact is stated.",
      "source": "kyrx:docs/PERFORMANCE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "performance",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/#performance"
    },
    {
      "id": "kyrx-knowledge-performance-02-1",
      "kind": "kyrx-knowledge-section",
      "title": "Performance contract: Measurement architecture",
      "text": "## Measurement architecture\n\nEvery push and pull request follows the same path:\n\n```text\nsource change\n  -> deterministic web asset budgets (merge gate)\n  -> statistical compiler pipeline benchmarks (trend signal)\n  -> CI logs and a 30-day Criterion report artifact\n  -> accept, optimize, or revise the architecture\n```\n\nDeterministic metrics may block a merge. Wall-clock compiler timings from shared CI runners are trend data, not hard gates, because runner variance can exceed small code-level regressions.",
      "source": "kyrx:docs/PERFORMANCE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "performance",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/#performance"
    },
    {
      "id": "kyrx-knowledge-performance-03-1",
      "kind": "kyrx-knowledge-section",
      "title": "Performance contract: Required update loop",
      "text": "## Required update loop\n\n1. Measure the relevant baseline before changing a hot path.\n2. Keep architecture ownership and dataflow explicit; update `ARCHITECTURE.md` when a boundary or performance target changes.\n3. Re-run the same measurement after the change.\n4. Report the before/after delta, or state that the change is performance-neutral and include the passing budget result.\n5. Add or extend a benchmark when a new hot path, compiler phase, asset class, or integration boundary is introduced.",
      "source": "kyrx:docs/PERFORMANCE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "performance",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/#performance"
    },
    {
      "id": "kyrx-knowledge-performance-04-1",
      "kind": "kyrx-knowledge-section",
      "title": "Performance contract: Commands",
      "text": "## Commands\n\n| Surface | Command | Purpose |\n|---|---|---|\n| Public site | `npm --prefix registry/web run benchmark` | Build, test the budget guard, and enforce gzip/asset budgets |\n| Knowledge Worker | `npm --prefix workers/kyrx-rag run benchmark` | Typecheck, test, dry-run bundle, and enforce the Worker gzip budget |\n| Compiler | `cargo bench -p kyrxc_driver --bench pipeline -- --quick` | Measure end-to-end compilation for small and multi-function modules |\n| Compiler tests | `cargo test -p kyrxc_driver` | Guard pipeline correctness before interpreting timings |",
      "source": "kyrx:docs/PERFORMANCE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "performance",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/#performance"
    },
    {
      "id": "kyrx-knowledge-performance-05-1",
      "kind": "kyrx-knowledge-section",
      "title": "Performance contract: Public-site budgets",
      "text": "## Public-site budgets\n\nBudgets live in `registry/web/performance-budgets.json` and are evaluated from the production `dist` output.\n\n| Metric | Budget |\n|---|---:|\n| Asset count | 30 |\n| Total gzip bytes | 180,000 |\n| JavaScript gzip bytes | 170,000 |\n| CSS gzip bytes | 12,000 |\n| Largest asset gzip bytes | 125,000 |\n\nRaise a budget only with measured evidence and an architecture note explaining why the added cost is worth carrying. Optimizations must preserve behavior and pass the existing correctness suite.\n\nThe generated knowledge corpus is an on-demand asset fetched by the scheduled Worker, not part of the browser's page-load dependency graph. It remains in the total static asset budget so corpus growth is still visible. The Knowledge Worker bundle has a separate 50 KiB gzip budget.",
      "source": "kyrx:docs/PERFORMANCE.md",
      "tags": [
        "kyrx",
        "knowledge",
        "performance",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/#performance"
    },
    {
      "id": "kyrx-knowledge-bridges-01-1",
      "kind": "kyrx-knowledge-section",
      "title": "Language bridges: KYRx Bridges",
      "text": "# KYRx Bridges\n\nThis directory contains interop layers that let KYRx code call, and be called by, major ecosystems. Every bridge is a library + example + test.",
      "source": "kyrx:bridges/README.md",
      "tags": [
        "kyrx",
        "knowledge",
        "bridges",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/bridges"
    },
    {
      "id": "kyrx-knowledge-bridges-02-1",
      "kind": "kyrx-knowledge-section",
      "title": "Language bridges: Matrix",
      "text": "## Matrix\n\n| ecosystem | in → KYRx | KYRx → out | transport | bidirectional state |\n|---|---|---|---|---|\n| React (browser) | yes | yes | WASM (`wasm32-unknown-unknown`) + TS bindings | ✓ |\n| Node.js | yes | yes | N-API native addon | ✓ |\n| Rust | yes | yes | C ABI; `kyrx-rust-sys` crate | ✓ |\n| Python | yes | yes | CPython C-API via `kyrx-py` | ✓ |\n| Go | yes | yes | cgo + C ABI | ✓ |\n| WASM / Wasmtime | — | yes | component model (WIT) | — |\n| Deno | yes | yes | Deno FFI (dlopen) | ✓ |\n| Swift | yes | yes | C ABI | ✓ |\n| Java/Kotlin | yes | yes | JNI | ✓ |\n| .NET | yes | yes | DllImport | ✓ |",
      "source": "kyrx:bridges/README.md",
      "tags": [
        "kyrx",
        "knowledge",
        "bridges",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/bridges"
    },
    {
      "id": "kyrx-knowledge-bridges-03-1",
      "kind": "kyrx-knowledge-section",
      "title": "Language bridges: Design principles",
      "text": "## Design principles\n\n1. **One binding generator.** `kyrx-bindgen` reads a KYRx module's declared exports and emits bindings for each target. No hand-written wrappers per language.\n2. **Stable C ABI is the lingua franca.** Every bridge ultimately uses `extern \"C\"` functions + a small `kyrx_ffi.h` header. WASM and JNI sit on top.\n3. **Ownership is handed off explicitly.** Foreign callers get either owned handles (with explicit `free` calls) or borrowed views (valid until callback returns).\n4. **No hidden async.** Bridges that expose async functions surface them as the target ecosystem's idiomatic async type (`Promise`, `Future`, `asyncio.coroutine`, etc.) — the colorless-async effect in KYRx is materialized at the boundary.\n5. **Errors map cleanly.** KYRx `Result<T, E>` → `Promise rejection`, `throw`, `raise`, `panic!`, as appropriate.\n6. **The debugger reaches across.** With `.kyrx_debug` loaded, LLDB can step from foreign code into KYRx and back; symbol maps make this legible.",
      "source": "kyrx:bridges/README.md",
      "tags": [
        "kyrx",
        "knowledge",
        "bridges",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/bridges"
    },
    {
      "id": "kyrx-knowledge-bridges-04-1",
      "kind": "kyrx-knowledge-section",
      "title": "Language bridges: Bridge files",
      "text": "## Bridge files\n\n- `REACT_BRIDGE.md`\n- `NODE_BRIDGE.md`\n- `RUST_BRIDGE.md`\n- `PYTHON_BRIDGE.md`\n- `GO_BRIDGE.md`\n- `WASM_BRIDGE.md`\n- `DENO_BRIDGE.md`\n- `SWIFT_BRIDGE.md`\n- `JVM_BRIDGE.md`\n- `DOTNET_BRIDGE.md`",
      "source": "kyrx:bridges/README.md",
      "tags": [
        "kyrx",
        "knowledge",
        "bridges",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/bridges"
    },
    {
      "id": "kyrx-knowledge-bridges-05-1",
      "kind": "kyrx-knowledge-section",
      "title": "Language bridges: Shared assets (to be built once, used by every bridge)",
      "text": "## Shared assets (to be built once, used by every bridge)\n\n1. `bridges/_shared/kyrx_ffi.h` — C header with handle types, error codes, memory management functions.\n2. `bridges/_shared/abi.md` — describes the KYRx C ABI (calling convention, layouts).\n3. `bridges/_shared/wit/` — WebAssembly Interface Types definitions for WASM/React.\n4. `kyrx-bindgen` (in `pkg/src/cmd/bindgen.rs`) — generator CLI with target flags.",
      "source": "kyrx:bridges/README.md",
      "tags": [
        "kyrx",
        "knowledge",
        "bridges",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/bridges"
    },
    {
      "id": "kyrx-knowledge-bridges-06-1",
      "kind": "kyrx-knowledge-section",
      "title": "Language bridges: Build",
      "text": "## Build\n\nEach bridge has:\n```\nbridges/<name>/\n  README.md          ← how to use\n  generator/         ← bindgen templates\n  runtime/           ← thin wrapper library\n  examples/\n  tests/\n```",
      "source": "kyrx:bridges/README.md",
      "tags": [
        "kyrx",
        "knowledge",
        "bridges",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/bridges"
    },
    {
      "id": "kyrx-knowledge-bridges-07-1",
      "kind": "kyrx-knowledge-section",
      "title": "Language bridges: Golden end-to-end test per bridge",
      "text": "## Golden end-to-end test per bridge\n\nEvery bridge ships a tiny app: *read a JSON file, parse, compute, return.* That app must pass in CI on every supported platform. See each bridge's `tests/` for the scripted harness.",
      "source": "kyrx:bridges/README.md",
      "tags": [
        "kyrx",
        "knowledge",
        "bridges",
        "kdt-163",
        "kdt-253",
        "kdt-256",
        "kdt-264",
        "kdt-265",
        "kdt-269",
        "kdt-270",
        "kdt-274",
        "kdt-289",
        "kdt-300"
      ],
      "kpis": [],
      "anchor": "kyrx-source-files",
      "url": "https://kyrx.dev/docs/bridges"
    },
    {
      "id": "data-access-prisma",
      "kind": "data-access-integration",
      "title": "Prisma for KynetraDB",
      "text": "A Prisma-shaped repository for findMany, findUnique, create, update, delete, and upsert. It is not a Prisma driver adapter and does not run Prisma query-engine plans. Status: preview. Mode: native-http-preview. Transport: KynetraDB PostgREST-compatible HTTP API; bridge schema included for direct PostgreSQL use. Transaction boundary: Each native HTTP mutation is one request. Interactive and nested Prisma transactions are unsupported. Migration ownership: Prisma may introspect the bridge table, but KynetraDB owns kynetra_entities and its helper functions. Capabilities: crud=supported, scalar_filters=supported, pagination=supported, json_attributes=supported, schema_migrations=unsupported, transactions=unsupported, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/prisma/schema.prisma. SHA-256: ede8fc77e18b57a597a4e2a7d8637f9e94f577b9241f6656c171f4faf057f65e.",
      "source": "integrations/data-access/templates/prisma/schema.prisma",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "prisma",
        "native-http-preview",
        "typescript"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-drizzle",
      "kind": "data-access-integration",
      "title": "Drizzle for KynetraDB",
      "text": "A Drizzle-shaped select builder with typed condition nodes and a bridge pgTable schema. It is not a drizzle-orm database driver. Status: preview. Mode: native-http-preview. Transport: KynetraDB PostgREST-compatible HTTP API; bridge schema included for direct PostgreSQL use. Transaction boundary: Native HTTP builder requests are independent. Drizzle PostgreSQL transactions apply only when using the bridge database directly. Migration ownership: Drizzle Kit may manage application tables, while KynetraDB retains ownership of kynetra_entities. Capabilities: crud=supported, scalar_filters=supported, pagination=supported, json_attributes=supported, schema_migrations=unsupported, transactions=unsupported, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/drizzle/schema.ts. SHA-256: 0c248226194a25623536359b0b7153890c563e3c4ca1aa670ee90e5ba96ac225.",
      "source": "integrations/data-access/templates/drizzle/schema.ts",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "drizzle",
        "native-http-preview",
        "typescript"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-sqlalchemy",
      "kind": "data-access-integration",
      "title": "SQLAlchemy for KynetraDB",
      "text": "A SQLAlchemy 2.x declarative mapping for bridge entities and JSON attributes. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/sqlalchemy/models.py. SHA-256: 065759dec5fa5f01cee407519048f913cd38763abf99f133ae48d34a280700cc.",
      "source": "integrations/data-access/templates/sqlalchemy/models.py",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "sqlalchemy",
        "postgres-bridge-starter",
        "python"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-hibernate",
      "kind": "data-access-integration",
      "title": "Hibernate / JPA for KynetraDB",
      "text": "A JPA entity mapping for the bridge table with JSON and array columns. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/hibernate/KynetraEntity.java. SHA-256: d3566c8bf651de8b3f5a112d13e328b2212e5652c93e31a896accde02d8b7ecb.",
      "source": "integrations/data-access/templates/hibernate/KynetraEntity.java",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "hibernate",
        "postgres-bridge-starter",
        "java"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-ef-core",
      "kind": "data-access-integration",
      "title": "Entity Framework Core for KynetraDB",
      "text": "An EF Core entity and model configuration for Npgsql-backed bridge deployments. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/ef-core/KynetraEntity.cs. SHA-256: 7b407161a06c39f429a07092e2b3818563d8715f0d502839a923e25482e7ade9.",
      "source": "integrations/data-access/templates/ef-core/KynetraEntity.cs",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "ef-core",
        "postgres-bridge-starter",
        "c#"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-django-orm",
      "kind": "data-access-integration",
      "title": "Django ORM for KynetraDB",
      "text": "An unmanaged Django model for reading and writing bridge entities without owning migrations. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/django/models.py. SHA-256: 0c22d93462a0ce4176dcc79fda086ad4695cf17909096f9b2eff0e20795315d5.",
      "source": "integrations/data-access/templates/django/models.py",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "django-orm",
        "postgres-bridge-starter",
        "python"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-active-record",
      "kind": "data-access-integration",
      "title": "Active Record for KynetraDB",
      "text": "A Rails model for the bridge table with ownership and validation boundaries. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/active-record/kynetra_entity.rb. SHA-256: 358f6bf369d01b99293a4db230b5e140e993e0a5375552ff5bc11519ae012bf3.",
      "source": "integrations/data-access/templates/active-record/kynetra_entity.rb",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "active-record",
        "postgres-bridge-starter",
        "ruby"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-sequelize",
      "kind": "data-access-integration",
      "title": "Sequelize for KynetraDB",
      "text": "A Sequelize model definition for JSONB attributes and float-array embeddings. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/sequelize/kynetra-entity.ts. SHA-256: bbdd61c41621dfc88060bc351fa319817bf8a61cf91c3c42f5e6fa2c47c6a3f8.",
      "source": "integrations/data-access/templates/sequelize/kynetra-entity.ts",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "sequelize",
        "postgres-bridge-starter",
        "typescript"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-typeorm",
      "kind": "data-access-integration",
      "title": "TypeORM for KynetraDB",
      "text": "A TypeORM entity mapping for the bridge-owned table. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/typeorm/kynetra-entity.ts. SHA-256: fd60741820d864499783ed42e6847c8c9c83759cb2c8bda868b0e0c78b40e971.",
      "source": "integrations/data-access/templates/typeorm/kynetra-entity.ts",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "typeorm",
        "postgres-bridge-starter",
        "typescript"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-diesel",
      "kind": "data-access-integration",
      "title": "Diesel for KynetraDB",
      "text": "A Diesel table declaration and queryable bridge entity. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/diesel/schema.rs. SHA-256: 80b9a5fccea195a6624c80b7d4bf833d9760231fc5df3e46b990c2212c740d26.",
      "source": "integrations/data-access/templates/diesel/schema.rs",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "diesel",
        "postgres-bridge-starter",
        "rust"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-gorm",
      "kind": "data-access-integration",
      "title": "GORM for KynetraDB",
      "text": "A GORM model using pgtype for JSONB and float-array bridge columns. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/gorm/entity.go. SHA-256: ad0592b52852402317cc613ed92513c0d35783f60f800d9c26eafbc53924374d.",
      "source": "integrations/data-access/templates/gorm/entity.go",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "gorm",
        "postgres-bridge-starter",
        "go"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "data-access-ecto",
      "kind": "data-access-integration",
      "title": "Ecto for KynetraDB",
      "text": "An Ecto schema for bridge entities with migration ownership disabled. Status: preview. Mode: postgres-bridge-starter. Transport: Direct PostgreSQL connection to the database used by KynetraDB Postgres Bridge. Transaction boundary: Transactions cover the bridge PostgreSQL database only; they do not create a distributed KynetraDB Universal Log transaction. Migration ownership: The application migration tool may extend its own tables but must treat kynetra_entities and Kynetra helper functions as bridge-owned. Capabilities: crud=bridge-only, scalar_filters=bridge-only, pagination=bridge-only, json_attributes=bridge-only, schema_migrations=bridge-only, transactions=bridge-only, distributed_transactions=unsupported, realtime=unsupported, bm25=raw-query, vector_search=raw-query. Template: templates/ecto/kynetra_entity.ex. SHA-256: 25b2209c171d819f7477b6731fe9878eab4b4c84bb706ee1ff636eab206efe13.",
      "source": "integrations/data-access/templates/ecto/kynetra_entity.ex",
      "tags": [
        "kynetradb",
        "orm",
        "data-access",
        "ecto",
        "postgres-bridge-starter",
        "elixir"
      ],
      "kpis": [],
      "anchor": "data-access-integrations"
    },
    {
      "id": "kfo-001",
      "kind": "foundry-operating-term",
      "title": "KFO-001 PORTFOLIO",
      "text": "The complete set of candidates being compared for investment; inclusion is not a shipping promise. Required: Version, owner, selection date. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "portfolio",
        "complete",
        "set",
        "candidates",
        "being",
        "compared",
        "investment",
        "inclusion",
        "not",
        "shipping",
        "promise",
        "version",
        "owner",
        "selection",
        "date"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-002",
      "kind": "foundry-operating-term",
      "title": "KFO-002 DOMAIN",
      "text": "A stable capability family used to partition the portfolio without implying delivery order. Required: Unique domain ID and boundary. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "domain",
        "stable",
        "capability",
        "family",
        "used",
        "partition",
        "portfolio",
        "without",
        "implying",
        "delivery",
        "order",
        "unique",
        "id",
        "boundary"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-003",
      "kind": "foundry-operating-term",
      "title": "KFO-003 CAPABILITY",
      "text": "One falsifiable user or system ability with an explicit boundary. Required: Stable ID, maturity, acceptance contract. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "capability",
        "one",
        "falsifiable",
        "user",
        "system",
        "ability",
        "explicit",
        "boundary",
        "stable",
        "id",
        "maturity",
        "acceptance",
        "contract"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-004",
      "kind": "foundry-operating-term",
      "title": "KFO-004 INITIATIVE",
      "text": "A funded outcome that may require several capabilities and repositories. Required: Objective, owner, dependencies, exit gate. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "initiative",
        "funded",
        "outcome",
        "that",
        "may",
        "require",
        "several",
        "capabilities",
        "repositories",
        "objective",
        "owner",
        "dependencies",
        "exit",
        "gate"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-005",
      "kind": "foundry-operating-term",
      "title": "KFO-005 DELIVERY SLICE",
      "text": "The smallest independently reviewable change that advances one initiative. Required: Bounded diff, tests, rollback boundary. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "delivery",
        "slice",
        "smallest",
        "independently",
        "reviewable",
        "change",
        "that",
        "advances",
        "one",
        "initiative",
        "bounded",
        "diff",
        "tests",
        "rollback",
        "boundary"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-006",
      "kind": "foundry-operating-term",
      "title": "KFO-006 DEPENDENCY",
      "text": "A capability or decision that must be true before another item can be promoted. Required: Upstream ID and blocking condition. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "dependency",
        "capability",
        "decision",
        "that",
        "must",
        "true",
        "before",
        "another",
        "item",
        "can",
        "promoted",
        "upstream",
        "id",
        "blocking",
        "condition"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-007",
      "kind": "foundry-operating-term",
      "title": "KFO-007 5X OBJECTIVE",
      "text": "A proposed fivefold improvement in one named KPI, not a blanket product claim. Required: Named KPI and matched baseline. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "5x",
        "objective",
        "proposed",
        "fivefold",
        "improvement",
        "one",
        "named",
        "kpi",
        "not",
        "blanket",
        "product",
        "claim",
        "matched",
        "baseline"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-008",
      "kind": "foundry-operating-term",
      "title": "KFO-008 GUARDRAIL",
      "text": "A correctness, quality, security, resource, or cost condition that an optimization may not weaken. Required: Executable pass/fail gate. Family: Portfolio planning.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "01-portfolio-planning",
        "guardrail",
        "correctness",
        "quality",
        "security",
        "resource",
        "cost",
        "condition",
        "that",
        "optimization",
        "may",
        "not",
        "weaken",
        "executable",
        "pass",
        "fail",
        "gate"
      ],
      "kpis": [],
      "anchor": "kfo-01-portfolio-planning"
    },
    {
      "id": "kfo-009",
      "kind": "foundry-operating-term",
      "title": "KFO-009 RESEARCH",
      "text": "Exploration that needs evidence before architectural commitment. Required: Research brief and decision experiment. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "research",
        "exploration",
        "that",
        "needs",
        "evidence",
        "before",
        "architectural",
        "commitment",
        "brief",
        "decision",
        "experiment"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-010",
      "kind": "foundry-operating-term",
      "title": "KFO-010 PLANNED",
      "text": "Accepted architecture or roadmap item without production completion. Required: Accepted decision and dependency map. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "planned",
        "accepted",
        "architecture",
        "roadmap",
        "item",
        "without",
        "production",
        "completion",
        "decision",
        "dependency",
        "map"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-011",
      "kind": "foundry-operating-term",
      "title": "KFO-011 PARTIAL",
      "text": "Useful implementation exists, but the complete production or proof contract is unmet. Required: Exact missing gates listed. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "partial",
        "useful",
        "implementation",
        "exists",
        "but",
        "complete",
        "production",
        "proof",
        "contract",
        "unmet",
        "exact",
        "missing",
        "gates",
        "listed"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-012",
      "kind": "foundry-operating-term",
      "title": "KFO-012 IMPLEMENTED",
      "text": "The supported production code path exists and executable verification covers its declared boundary. Required: Code and nonzero test links. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "implemented",
        "supported",
        "production",
        "code",
        "path",
        "exists",
        "executable",
        "verification",
        "covers",
        "its",
        "declared",
        "boundary",
        "nonzero",
        "test",
        "links"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-013",
      "kind": "foundry-operating-term",
      "title": "KFO-013 LIMITATION",
      "text": "A behavior or guarantee explicitly outside the current capability boundary. Required: User-visible, testable wording. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "limitation",
        "behavior",
        "guarantee",
        "explicitly",
        "outside",
        "current",
        "capability",
        "boundary",
        "user-visible",
        "testable",
        "wording"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-014",
      "kind": "foundry-operating-term",
      "title": "KFO-014 PREREQUISITE",
      "text": "A dependency whose absence makes implementation or promotion unsafe. Required: Blocking ID and verification method. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "prerequisite",
        "dependency",
        "whose",
        "absence",
        "makes",
        "implementation",
        "promotion",
        "unsafe",
        "blocking",
        "id",
        "verification",
        "method"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-015",
      "kind": "foundry-operating-term",
      "title": "KFO-015 DEFERRED",
      "text": "A researched candidate intentionally postponed without rejecting its architecture. Required: Reason and reconsideration trigger. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "deferred",
        "researched",
        "candidate",
        "intentionally",
        "postponed",
        "without",
        "rejecting",
        "its",
        "architecture",
        "reason",
        "reconsideration",
        "trigger"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-016",
      "kind": "foundry-operating-term",
      "title": "KFO-016 REJECTED",
      "text": "A candidate Foundry decided not to pursue under the recorded constraints. Required: Decision record and alternatives. Family: Capability maturity.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "02-capability-maturity",
        "rejected",
        "candidate",
        "foundry",
        "decided",
        "not",
        "pursue",
        "under",
        "recorded",
        "constraints",
        "decision",
        "record",
        "alternatives"
      ],
      "kpis": [],
      "anchor": "kfo-02-capability-maturity"
    },
    {
      "id": "kfo-017",
      "kind": "foundry-operating-term",
      "title": "KFO-017 UNIT EVIDENCE",
      "text": "Exercises one function, type, or module in isolation. Required: Production wiring or persistence. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "unit",
        "evidence",
        "exercises",
        "one",
        "function",
        "type",
        "module",
        "isolation",
        "production",
        "wiring",
        "persistence"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-018",
      "kind": "foundry-operating-term",
      "title": "KFO-018 COMPONENT EVIDENCE",
      "text": "Exercises cooperating modules behind a real component boundary. Required: Mounted public route or external lifecycle. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "component",
        "evidence",
        "exercises",
        "cooperating",
        "modules",
        "behind",
        "real",
        "boundary",
        "mounted",
        "public",
        "route",
        "external",
        "lifecycle"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-019",
      "kind": "foundry-operating-term",
      "title": "KFO-019 PRODUCTION-ROUTE EVIDENCE",
      "text": "Calls the mounted supported route through production middleware. Required: Restart, races, or infrastructure lifecycle. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "production-route",
        "evidence",
        "calls",
        "mounted",
        "supported",
        "route",
        "through",
        "production",
        "middleware",
        "restart",
        "races",
        "infrastructure",
        "lifecycle"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-020",
      "kind": "foundry-operating-term",
      "title": "KFO-020 RESTART EVIDENCE",
      "text": "Recreates the process or node and verifies durable state through the production startup path. Required: Concurrent or distributed fault safety. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "restart",
        "evidence",
        "recreates",
        "process",
        "node",
        "verifies",
        "durable",
        "state",
        "through",
        "production",
        "startup",
        "path",
        "concurrent",
        "distributed",
        "fault",
        "safety"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-021",
      "kind": "foundry-operating-term",
      "title": "KFO-021 CONCURRENCY EVIDENCE",
      "text": "Exercises controlled races and proves preservation or a single winner. Required: Crash recovery or partition safety. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "concurrency",
        "evidence",
        "exercises",
        "controlled",
        "races",
        "proves",
        "preservation",
        "single",
        "winner",
        "crash",
        "recovery",
        "partition",
        "safety"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-022",
      "kind": "foundry-operating-term",
      "title": "KFO-022 FAULT EVIDENCE",
      "text": "Injects deterministic process, disk, network, clock, or corruption faults. Required: Provider or live-environment certification. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "fault",
        "evidence",
        "injects",
        "deterministic",
        "process",
        "disk",
        "network",
        "clock",
        "corruption",
        "faults",
        "provider",
        "live-environment",
        "certification"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-023",
      "kind": "foundry-operating-term",
      "title": "KFO-023 PROVIDER EVIDENCE",
      "text": "Runs the declared create-to-destroy lifecycle on one named target and revision. Required: Other providers or current live health. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "provider",
        "evidence",
        "runs",
        "declared",
        "create-to",
        "destroy",
        "lifecycle",
        "one",
        "named",
        "target",
        "revision",
        "other",
        "providers",
        "current",
        "live",
        "health"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-024",
      "kind": "foundry-operating-term",
      "title": "KFO-024 LIVE EVIDENCE",
      "text": "Records a time-bounded observation from a named deployed environment. Required: Historical continuity or untested guarantees. Family: Evidence scope.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "03-evidence-scope",
        "live",
        "evidence",
        "records",
        "time-bounded",
        "observation",
        "named",
        "deployed",
        "environment",
        "historical",
        "continuity",
        "untested",
        "guarantees"
      ],
      "kpis": [],
      "anchor": "kfo-03-evidence-scope"
    },
    {
      "id": "kfo-025",
      "kind": "foundry-operating-term",
      "title": "KFO-025 SIGNAL",
      "text": "A measured value emitted by telemetry, a benchmark, a deploy smoke test, or a probe. Required: Source, time, unit, scope. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "signal",
        "measured",
        "value",
        "emitted",
        "telemetry",
        "benchmark",
        "deploy",
        "smoke",
        "test",
        "probe",
        "source",
        "time",
        "unit",
        "scope"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-026",
      "kind": "foundry-operating-term",
      "title": "KFO-026 MATCHED BASELINE",
      "text": "The trusted before-value captured with the same workload envelope as its candidate. Required: Hardware, data, durability, consistency, concurrency. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "matched",
        "baseline",
        "trusted",
        "before-value",
        "captured",
        "same",
        "workload",
        "envelope",
        "its",
        "candidate",
        "hardware",
        "data",
        "durability",
        "consistency",
        "concurrency"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-027",
      "kind": "foundry-operating-term",
      "title": "KFO-027 TARGET",
      "text": "The value the programme is trying to reach; it is not evidence that the value was reached. Required: Named KPI, workload, deadline. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "target",
        "value",
        "programme",
        "trying",
        "reach",
        "not",
        "evidence",
        "that",
        "was",
        "reached",
        "named",
        "kpi",
        "workload",
        "deadline"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-028",
      "kind": "foundry-operating-term",
      "title": "KFO-028 RELEASE GATE",
      "text": "An executable condition that must pass before a release, provider, or phase is complete. Required: Command or observable and failure policy. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "release",
        "gate",
        "executable",
        "condition",
        "that",
        "must",
        "pass",
        "before",
        "provider",
        "phase",
        "complete",
        "command",
        "observable",
        "failure",
        "policy"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-029",
      "kind": "foundry-operating-term",
      "title": "KFO-029 REGRESSION",
      "text": "A correctness failure or an unexplained movement against an accepted gate or baseline. Required: Candidate/baseline comparison. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "regression",
        "correctness",
        "failure",
        "unexplained",
        "movement",
        "against",
        "accepted",
        "gate",
        "baseline",
        "candidate",
        "comparison"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-030",
      "kind": "foundry-operating-term",
      "title": "KFO-030 TAIL",
      "text": "p95, p99, and maximum behavior reported alongside error and saturation signals. Required: Sample count and percentile method. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "tail",
        "p95",
        "p99",
        "maximum",
        "behavior",
        "reported",
        "alongside",
        "error",
        "saturation",
        "signals",
        "sample",
        "count",
        "percentile",
        "method"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-031",
      "kind": "foundry-operating-term",
      "title": "KFO-031 QUALITY FLOOR",
      "text": "The minimum acceptable correctness or relevance while optimizing speed or cost. Required: Recall, NDCG, precision, loss, or invariant. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "quality",
        "floor",
        "minimum",
        "acceptable",
        "correctness",
        "relevance",
        "while",
        "optimizing",
        "speed",
        "cost",
        "recall",
        "ndcg",
        "precision",
        "loss",
        "invariant"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-032",
      "kind": "foundry-operating-term",
      "title": "KFO-032 COST ENVELOPE",
      "text": "The resource and monetary boundary for one workload and deployment profile. Required: CPU, memory, storage, network, provider rates. Family: Measurement state.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "04-measurement-state",
        "cost",
        "envelope",
        "resource",
        "monetary",
        "boundary",
        "one",
        "workload",
        "deployment",
        "profile",
        "cpu",
        "memory",
        "storage",
        "network",
        "provider",
        "rates"
      ],
      "kpis": [],
      "anchor": "kfo-04-measurement-state"
    },
    {
      "id": "kfo-033",
      "kind": "foundry-operating-term",
      "title": "KFO-033 EVIDENCE ARTIFACT",
      "text": "An immutable or content-addressed record of one test, benchmark, fault run, or observation. Required: Revision, command, environment, raw result. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "evidence",
        "artifact",
        "immutable",
        "content-addressed",
        "record",
        "one",
        "test",
        "benchmark",
        "fault",
        "run",
        "observation",
        "revision",
        "command",
        "environment",
        "raw",
        "result"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    },
    {
      "id": "kfo-034",
      "kind": "foundry-operating-term",
      "title": "KFO-034 PROOF PACK",
      "text": "The declared set of evidence artifacts required for one capability or release gate. Required: Manifest, required scopes, validation result. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "proof",
        "pack",
        "declared",
        "set",
        "evidence",
        "artifacts",
        "required",
        "one",
        "capability",
        "release",
        "gate",
        "manifest",
        "scopes",
        "validation",
        "result"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    },
    {
      "id": "kfo-035",
      "kind": "foundry-operating-term",
      "title": "KFO-035 MULTIPLIER CLAIM",
      "text": "An `Nx` comparison for one named KPI against a matched baseline. Required: Candidate/base ratio and every guardrail result. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "multiplier",
        "claim",
        "nx",
        "comparison",
        "one",
        "named",
        "kpi",
        "against",
        "matched",
        "baseline",
        "candidate",
        "base",
        "ratio",
        "every",
        "guardrail",
        "result"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    },
    {
      "id": "kfo-036",
      "kind": "foundry-operating-term",
      "title": "KFO-036 VERIFIED",
      "text": "The capability's declared proof pack passed for an exact source revision. Required: Proof-pack digest and verifier result. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "verified",
        "capability",
        "declared",
        "proof",
        "pack",
        "passed",
        "exact",
        "source",
        "revision",
        "proof-pack",
        "digest",
        "verifier",
        "result"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    },
    {
      "id": "kfo-037",
      "kind": "foundry-operating-term",
      "title": "KFO-037 CERTIFIED",
      "text": "A named provider, profile, SDK, or compatibility target passed its complete lifecycle contract. Required: Target identity and certification artifact. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "certified",
        "named",
        "provider",
        "profile",
        "sdk",
        "compatibility",
        "target",
        "passed",
        "its",
        "complete",
        "lifecycle",
        "contract",
        "identity",
        "certification",
        "artifact"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    },
    {
      "id": "kfo-038",
      "kind": "foundry-operating-term",
      "title": "KFO-038 DEPLOYED",
      "text": "A known artifact revision was released to a named environment. Required: Artifact digest, environment, deployment record. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "deployed",
        "known",
        "artifact",
        "revision",
        "was",
        "released",
        "named",
        "environment",
        "digest",
        "deployment",
        "record"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    },
    {
      "id": "kfo-039",
      "kind": "foundry-operating-term",
      "title": "KFO-039 LIVE-OBSERVED",
      "text": "A deployed environment was checked at a recorded time through declared probes. Required: Observation time, routes, result, staleness limit. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "live-observed",
        "deployed",
        "environment",
        "was",
        "checked",
        "recorded",
        "time",
        "through",
        "declared",
        "probes",
        "observation",
        "routes",
        "result",
        "staleness",
        "limit"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    },
    {
      "id": "kfo-040",
      "kind": "foundry-operating-term",
      "title": "KFO-040 CLAIM EXPIRY",
      "text": "The time or change condition after which evidence must be refreshed before reuse. Required: Expiry time or invalidating dependency. Family: Proof and delivery.",
      "source": "docs/scale/foundry-operating-terminology.md",
      "tags": [
        "kfo",
        "05-proof-and-delivery",
        "claim",
        "expiry",
        "time",
        "change",
        "condition",
        "after",
        "which",
        "evidence",
        "must",
        "refreshed",
        "before",
        "reuse",
        "invalidating",
        "dependency"
      ],
      "kpis": [],
      "anchor": "kfo-05-proof-and-delivery"
    }
  ]
}