{ "schema": "kynetra.database-terminology/v1", "version": "2026.1", "status": "proposed-standard", "title": "Kynetra Database Developer Terminology", "description": "A vendor-neutral vocabulary for discussing database semantics, evidence, interoperability, and operations.", "governance": { "rfc": "KDT-000", "stability": "Identifiers are append-only; accepted definitions change only through a superseding RFC.", "claim_policy": "A proposed term describes a contract, not proof that KynetraDB implements it.", "id_lock_sha256": "ea1714fc00774ac5d0ae0e0689ce17c91d1518203eaa7c8e545a36ad6b75f171" }, "categories": [ { "slug": "transactions", "title": "Transactions and Mutation Semantics", "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": "its boundary or value is exposed in the API, trace, or conformance report and survives retry testing", "count": 15 }, { "slug": "consistency-time", "title": "Consistency, Ordering, and Time", "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": "clients can request or observe the declared ordering and freshness behavior under concurrent execution", "count": 15 }, { "slug": "log-storage", "title": "Log, Storage, and Recovery Internals", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "operators can locate the corresponding persisted marker and verify it during restart or compaction", "count": 15 }, { "slug": "index-planner", "title": "Indexes and Query Planning", "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": "an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work", "count": 15 }, { "slug": "query-semantics", "title": "Query and Result Semantics", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results", "count": 15 }, { "slug": "retrieval", "title": "Search and Retrieval", "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": "a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept", "count": 15 }, { "slug": "vector-ai", "title": "Vector, AI, and Agent Data", "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": "stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information", "count": 15 }, { "slug": "replication", "title": "Replication and Distributed Authority", "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": "fault tests can observe the declared authority, progress, and safety behavior during delay or partition", "count": 15 }, { "slug": "sharding-routing", "title": "Sharding, Routing, and Locality", "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": "routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions", "count": 15 }, { "slug": "cache-edge", "title": "Caching and Edge Data", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "cache traces expose key identity, freshness decision, source, and invalidation behavior for each response", "count": 15 }, { "slug": "schema-evolution", "title": "Schema and Data Evolution", "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": "migration tests can identify the active shape, compatibility phase, progress, and reversible boundary", "count": 15 }, { "slug": "api-sdk", "title": "API, Protocol, and SDK Contracts", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome", "count": 15 }, { "slug": "security-identity", "title": "Security, Identity, and Authorization", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "authorization tests and audit records identify the principal, boundary, decision, key state, and exception path", "count": 15 }, { "slug": "privacy-compliance", "title": "Privacy, Residency, and Compliance", "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": "a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence", "count": 15 }, { "slug": "observability-sre", "title": "Observability and Reliability Engineering", "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": "operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision", "count": 15 }, { "slug": "backup-recovery", "title": "Backup, Restore, and Disaster Recovery", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives", "count": 15 }, { "slug": "performance-cost", "title": "Performance, Capacity, and Cost", "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": "a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost", "count": 15 }, { "slug": "interoperability", "title": "Portability and Interoperability", "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": "a conformance run moves data or behavior across two implementations and reports losses and dependencies", "count": 15 }, { "slug": "operations-control", "title": "Operations and Control Planes", "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": "an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change", "count": 15 }, { "slug": "governance-standards", "title": "Standards and Engineering Governance", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "the public registry or capability manifest identifies status, version, evidence, and compatibility impact", "count": 15 } ], "terms": [ { "id": "KDT-001", "name": "COMMIT HORIZON", "category": "transactions", "definition": "The highest transaction position acknowledged as committed under the declared durability policy.", "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": "COMMIT HORIZON is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-002", "name": "DURABILITY POINT", "category": "transactions", "definition": "The exact event after which an acknowledged mutation survives the promised failure model.", "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": "DURABILITY POINT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-003", "name": "VISIBILITY POINT", "category": "transactions", "definition": "The event after which a committed mutation may be observed by eligible readers.", "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": "VISIBILITY POINT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-004", "name": "TRANSACTION ENVELOPE", "category": "transactions", "definition": "The complete set of reads, writes, preconditions, identity, and deadlines in one atomic request.", "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": "TRANSACTION ENVELOPE is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-005", "name": "MUTATION SET", "category": "transactions", "definition": "The ordered collection of record changes proposed for one transaction envelope.", "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": "MUTATION SET is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-006", "name": "READ SNAPSHOT", "category": "transactions", "definition": "An immutable database view identified by a stable version or logical time.", "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": "READ SNAPSHOT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-007", "name": "WRITE INTENT", "category": "transactions", "definition": "A provisional claim that a transaction plans to modify a named conflict domain.", "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": "WRITE INTENT is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-008", "name": "CONFLICT DOMAIN", "category": "transactions", "definition": "The smallest key, range, index, or constraint scope that can force transaction serialization.", "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": "CONFLICT DOMAIN is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-009", "name": "ISOLATION FLOOR", "category": "transactions", "definition": "The weakest isolation behavior an operation is permitted to receive.", "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": "ISOLATION FLOOR is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-010", "name": "ISOLATION CEILING", "category": "transactions", "definition": "The strongest isolation behavior an implementation can guarantee for an operation.", "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": "ISOLATION CEILING is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-011", "name": "RETRY TOKEN", "category": "transactions", "definition": "A stable caller-supplied identity that makes a repeated mutation detectably idempotent.", "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": "RETRY TOKEN is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-012", "name": "COMMIT WITNESS", "category": "transactions", "definition": "Durable evidence that identifies the decision, participants, and commit outcome.", "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": "COMMIT WITNESS is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-013", "name": "ABORT CAUSE", "category": "transactions", "definition": "A machine-readable reason explaining why a transaction did not commit.", "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": "ABORT CAUSE is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-014", "name": "SAVEPOINT BOUNDARY", "category": "transactions", "definition": "A named position inside a transaction to which provisional work may be rolled back.", "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": "SAVEPOINT BOUNDARY is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-015", "name": "ATOMIC SCOPE", "category": "transactions", "definition": "The explicitly declared records and side effects that succeed or fail together.", "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": "ATOMIC SCOPE is adopted when its boundary or value is exposed in the API, trace, or conformance report and survives retry testing.", "status": "proposed" }, { "id": "KDT-016", "name": "CONSISTENCY CONTRACT", "category": "consistency-time", "definition": "The declared visibility and ordering guarantees for a read or write class.", "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": "CONSISTENCY CONTRACT is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-017", "name": "SESSION FENCE", "category": "consistency-time", "definition": "A token preventing a session from observing state older than its prior acknowledged work.", "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": "SESSION FENCE is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-018", "name": "READ HORIZON", "category": "consistency-time", "definition": "The newest committed position a read is guaranteed to include.", "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": "READ HORIZON is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-019", "name": "CAUSAL TOKEN", "category": "consistency-time", "definition": "Portable metadata encoding the causal dependencies a later operation must observe.", "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": "CAUSAL TOKEN is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-020", "name": "MONOTONIC CURSOR", "category": "consistency-time", "definition": "A progress marker that never moves backward within its declared ordering domain.", "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": "MONOTONIC CURSOR is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-021", "name": "STALENESS BUDGET", "category": "consistency-time", "definition": "The maximum permitted distance between served state and the current commit horizon.", "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": "STALENESS BUDGET is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-022", "name": "CLOCK UNCERTAINTY", "category": "consistency-time", "definition": "The bounded interval within which the database believes physical time may lie.", "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": "CLOCK UNCERTAINTY is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-023", "name": "VERSION STAMP", "category": "consistency-time", "definition": "An immutable identifier for one logical version of a record or snapshot.", "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": "VERSION STAMP is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-024", "name": "ORDERING DOMAIN", "category": "consistency-time", "definition": "The keys or operations over which one total order is guaranteed.", "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": "ORDERING DOMAIN is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-025", "name": "FRESHNESS PROOF", "category": "consistency-time", "definition": "Evidence that a response satisfies its requested read horizon or staleness budget.", "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": "FRESHNESS PROOF is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-026", "name": "CONVERGENCE WINDOW", "category": "consistency-time", "definition": "The bounded time allowed for replicas or indexes to reach equivalent state.", "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": "CONVERGENCE WINDOW is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-027", "name": "LINEARIZATION POINT", "category": "consistency-time", "definition": "The single logical instant at which a concurrent operation takes effect.", "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": "LINEARIZATION POINT is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-028", "name": "TEMPORAL LEASE", "category": "consistency-time", "definition": "A time-bounded authority to serve or mutate state under a named epoch.", "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": "TEMPORAL LEASE is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-029", "name": "HISTORY CUT", "category": "consistency-time", "definition": "A consistent boundary dividing retained history from safely discarded history.", "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": "HISTORY CUT is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-030", "name": "CONSISTENCY DOWNGRADE", "category": "consistency-time", "definition": "An explicit transition to weaker guarantees rather than silent semantic erosion.", "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": "CONSISTENCY DOWNGRADE is adopted when clients can request or observe the declared ordering and freshness behavior under concurrent execution.", "status": "proposed" }, { "id": "KDT-031", "name": "UNIVERSAL LOG", "category": "log-storage", "definition": "The authoritative ordered mutation history from which database personalities can be rebuilt.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "UNIVERSAL LOG is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-032", "name": "LOG FRAME", "category": "log-storage", "definition": "A checksummed storage unit containing one or more ordered mutation records.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "LOG FRAME is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-033", "name": "SEAL SEQUENCE", "category": "log-storage", "definition": "The durable monotonic position assigned when a log frame is safely sealed.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "SEAL SEQUENCE is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-034", "name": "REPLAY CURSOR", "category": "log-storage", "definition": "The last log position completely applied by a consumer or materialized view.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "REPLAY CURSOR is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-035", "name": "SEGMENT EPOCH", "category": "log-storage", "definition": "The generation identifying a coherent family of immutable storage segments.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "SEGMENT EPOCH is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-036", "name": "COMPACTION DEBT", "category": "log-storage", "definition": "The measured obsolete bytes and read work waiting to be reclaimed.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "COMPACTION DEBT is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-037", "name": "TOMBSTONE HORIZON", "category": "log-storage", "definition": "The oldest point before which deletion markers may be safely discarded.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "TOMBSTONE HORIZON is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-038", "name": "STORAGE AMPLIFICATION", "category": "log-storage", "definition": "The ratio of physical stored bytes to logical live data bytes.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "STORAGE AMPLIFICATION is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-039", "name": "WRITE AMPLIFICATION BUDGET", "category": "log-storage", "definition": "The allowed physical bytes written for each logical byte changed.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "WRITE AMPLIFICATION BUDGET is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-040", "name": "READ AMPLIFICATION BUDGET", "category": "log-storage", "definition": "The allowed storage probes or bytes read for one logical lookup.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "READ AMPLIFICATION BUDGET is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-041", "name": "CHECKPOINT ANCHOR", "category": "log-storage", "definition": "A verified log position represented completely by a restartable snapshot.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "CHECKPOINT ANCHOR is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-042", "name": "RECOVERY TAIL", "category": "log-storage", "definition": "The log interval after a checkpoint that must be replayed during recovery.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "RECOVERY TAIL is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-043", "name": "SEGMENT MANIFEST", "category": "log-storage", "definition": "The authoritative inventory, ordering, checksums, and ownership of storage segments.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "SEGMENT MANIFEST is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-044", "name": "BLOB INDIRECTION", "category": "log-storage", "definition": "A stable reference separating large value bytes from primary record metadata.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "BLOB INDIRECTION is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-045", "name": "DATA TEMPERATURE", "category": "log-storage", "definition": "A measured access class used to choose memory, local disk, or remote storage placement.", "contract": "Implementations using these terms MUST identify persisted progress, recovery dependencies, amplification costs, and reclamation safety without relying on undocumented storage-engine behavior.", "adoption": "DATA TEMPERATURE is adopted when operators can locate the corresponding persisted marker and verify it during restart or compaction.", "status": "proposed" }, { "id": "KDT-046", "name": "INDEX CONTRACT", "category": "index-planner", "definition": "The keys, predicates, ordering, freshness, and maintenance guarantees of an index.", "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": "INDEX CONTRACT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-047", "name": "INDEX WATERMARK", "category": "index-planner", "definition": "The commit horizon through which an index is complete and query-safe.", "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": "INDEX WATERMARK is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-048", "name": "INDEX DEBT", "category": "index-planner", "definition": "The queued mutation work not yet incorporated into a queryable index.", "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": "INDEX DEBT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-049", "name": "COVERING PATH", "category": "index-planner", "definition": "An access path that answers a query without fetching base records.", "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": "COVERING PATH is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-050", "name": "PREDICATE SHAPE", "category": "index-planner", "definition": "A normalized representation of filter operators independent of literal values.", "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": "PREDICATE SHAPE is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-051", "name": "PLAN FINGERPRINT", "category": "index-planner", "definition": "A stable identity for a normalized query and its selected execution shape.", "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": "PLAN FINGERPRINT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-052", "name": "SELECTIVITY SKETCH", "category": "index-planner", "definition": "A compact estimate of how much data a predicate is expected to match.", "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": "SELECTIVITY SKETCH is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-053", "name": "SCAN ESCAPE", "category": "index-planner", "definition": "A proven access path that avoids a full collection or segment scan.", "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": "SCAN ESCAPE is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-054", "name": "ACCESS PATH", "category": "index-planner", "definition": "The ordered indexes, scans, joins, and fetches used to answer a query.", "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": "ACCESS PATH is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-055", "name": "PLAN STABILITY", "category": "index-planner", "definition": "The degree to which equivalent inputs retain predictable execution behavior.", "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": "PLAN STABILITY is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-056", "name": "ADAPTIVE SWITCHPOINT", "category": "index-planner", "definition": "The measured threshold where execution changes to a different plan.", "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": "ADAPTIVE SWITCHPOINT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-057", "name": "CARDINALITY CONFIDENCE", "category": "index-planner", "definition": "The uncertainty bound attached to an estimated row or candidate count.", "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": "CARDINALITY CONFIDENCE is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-058", "name": "INDEX ADMISSION", "category": "index-planner", "definition": "The evidence-based decision to create or retain an index for real workload demand.", "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": "INDEX ADMISSION is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-059", "name": "INDEX RETIREMENT", "category": "index-planner", "definition": "The safe removal process for an index whose cost exceeds its measured value.", "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": "INDEX RETIREMENT is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-060", "name": "QUERY WORK BUDGET", "category": "index-planner", "definition": "The maximum rows, bytes, probes, or CPU units allowed for one query.", "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": "QUERY WORK BUDGET is adopted when an explain or telemetry surface reports the value and a benchmark can verify its effect on scanned work.", "status": "proposed" }, { "id": "KDT-061", "name": "RESULT CONTRACT", "category": "query-semantics", "definition": "The declared columns, types, ordering, completeness, and metadata of a query response.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "RESULT CONTRACT is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-062", "name": "DETERMINISTIC ORDER", "category": "query-semantics", "definition": "An ordering whose tie-breakers produce the same sequence for the same snapshot.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "DETERMINISTIC ORDER is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-063", "name": "STABLE PAGINATION", "category": "query-semantics", "definition": "Page traversal that neither duplicates nor omits unchanged records across requests.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "STABLE PAGINATION is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-064", "name": "CONTINUATION TOKEN", "category": "query-semantics", "definition": "Opaque state that resumes a query under the same ordering and snapshot contract.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "CONTINUATION TOKEN is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-065", "name": "NULL POLICY", "category": "query-semantics", "definition": "The declared comparison, sorting, and serialization behavior for explicit null values.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "NULL POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-066", "name": "MISSING-FIELD POLICY", "category": "query-semantics", "definition": "The declared treatment of absent fields in filtering, sorting, and projection.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "MISSING-FIELD POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-067", "name": "TYPE COERCION POLICY", "category": "query-semantics", "definition": "The explicit conversions permitted when operand or stored value types differ.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "TYPE COERCION POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-068", "name": "COLLATION PROFILE", "category": "query-semantics", "definition": "The locale, normalization, case, and byte ordering rules for text comparison.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "COLLATION PROFILE is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-069", "name": "FILTER PUSHDOWN", "category": "query-semantics", "definition": "Moving a predicate closer to storage while preserving exact result semantics.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "FILTER PUSHDOWN is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-070", "name": "PROJECTION BOUNDARY", "category": "query-semantics", "definition": "The earliest safe stage at which unrequested fields stop flowing through execution.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "PROJECTION BOUNDARY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-071", "name": "JOIN DOMAIN", "category": "query-semantics", "definition": "The keyspace and consistency boundary within which a join is executed.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "JOIN DOMAIN is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-072", "name": "FANOUT BUDGET", "category": "query-semantics", "definition": "The maximum partitions, nodes, or remote calls a query may contact.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "FANOUT BUDGET is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-073", "name": "QUERY DEADLINE", "category": "query-semantics", "definition": "The absolute completion boundary after which query work should be cancelled.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "QUERY DEADLINE is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-074", "name": "PARTIAL RESULT POLICY", "category": "query-semantics", "definition": "The declared response when only part of a distributed query completes.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "PARTIAL RESULT POLICY is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-075", "name": "EXPLAIN EVIDENCE", "category": "query-semantics", "definition": "Machine-readable proof of plan choices, estimates, actual work, and timing.", "contract": "Implementations using these terms MUST define ordering, pagination, missing values, coercion, deadlines, and partial-result behavior independently of a particular query language.", "adoption": "EXPLAIN EVIDENCE is adopted when client contract tests can distinguish compliant results from reordered, coerced, truncated, or partial results.", "status": "proposed" }, { "id": "KDT-076", "name": "RETRIEVAL PROFILE", "category": "retrieval", "definition": "A versioned bundle of lexical, vector, fusion, filtering, and ranking settings.", "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": "RETRIEVAL PROFILE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-077", "name": "RELEVANCE CONTRACT", "category": "retrieval", "definition": "The quality metrics and thresholds a retrieval release must preserve.", "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": "RELEVANCE CONTRACT is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-078", "name": "CANDIDATE BUDGET", "category": "retrieval", "definition": "The maximum documents or vectors admitted to an expensive ranking stage.", "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": "CANDIDATE BUDGET is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-079", "name": "RECALL FLOOR", "category": "retrieval", "definition": "The minimum acceptable fraction of known relevant results returned by retrieval.", "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": "RECALL FLOOR is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-080", "name": "RANKING PROVENANCE", "category": "retrieval", "definition": "The channels, scores, models, and transformations that produced a result rank.", "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": "RANKING PROVENANCE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-081", "name": "FUSION POLICY", "category": "retrieval", "definition": "The deterministic method used to combine rankings from multiple retrieval channels.", "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": "FUSION POLICY is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-082", "name": "LEXICAL CHANNEL", "category": "retrieval", "definition": "A retrieval path driven by tokens, terms, fields, and sparse relevance signals.", "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": "LEXICAL CHANNEL is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-083", "name": "SEMANTIC CHANNEL", "category": "retrieval", "definition": "A retrieval path driven by embeddings or learned semantic representations.", "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": "SEMANTIC CHANNEL is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-084", "name": "RERANK STAGE", "category": "retrieval", "definition": "A bounded later pass that reorders an already selected candidate set.", "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": "RERANK STAGE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-085", "name": "FRESHNESS-AWARE RANKING", "category": "retrieval", "definition": "Ranking that includes document or index freshness as an explicit signal.", "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": "FRESHNESS-AWARE RANKING is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-086", "name": "DIVERSITY BUDGET", "category": "retrieval", "definition": "The allowed relevance tradeoff used to reduce redundant results.", "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": "DIVERSITY BUDGET is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-087", "name": "QUERY EXPANSION BOUNDARY", "category": "retrieval", "definition": "The controlled point where additional terms or concepts enter retrieval.", "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": "QUERY EXPANSION BOUNDARY is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-088", "name": "GOLDEN QUERY SET", "category": "retrieval", "definition": "A versioned collection of queries, judgments, and expected retrieval behavior.", "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": "GOLDEN QUERY SET is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-089", "name": "RELEVANCE DRIFT", "category": "retrieval", "definition": "Measured change in retrieval quality after data, model, or index evolution.", "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": "RELEVANCE DRIFT is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-090", "name": "RETRIEVAL TRACE", "category": "retrieval", "definition": "A per-query record of channels, candidates, filters, scores, and final ranks.", "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": "RETRIEVAL TRACE is adopted when a versioned retrieval evaluation reports latency, candidate work, and relevance quality for the named concept.", "status": "proposed" }, { "id": "KDT-091", "name": "EMBEDDING CONTRACT", "category": "vector-ai", "definition": "The model, tokenizer, dimensions, normalization, distance, and version for a vector field.", "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": "EMBEDDING CONTRACT is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-092", "name": "MODEL FINGERPRINT", "category": "vector-ai", "definition": "A stable digest identifying model weights, configuration, and preprocessing behavior.", "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": "MODEL FINGERPRINT is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-093", "name": "VECTOR DIMENSION LOCK", "category": "vector-ai", "definition": "A schema rule preventing incompatible vector lengths from sharing one index.", "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": "VECTOR DIMENSION LOCK is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-094", "name": "DISTANCE PROFILE", "category": "vector-ai", "definition": "The named similarity metric and normalization assumptions used during vector search.", "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": "DISTANCE PROFILE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-095", "name": "QUANTIZATION BUDGET", "category": "vector-ai", "definition": "The maximum relevance loss and memory cost allowed for compressed vectors.", "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": "QUANTIZATION BUDGET is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-096", "name": "ANN RECALL GATE", "category": "vector-ai", "definition": "The minimum approximate-neighbor recall required against exact search.", "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": "ANN RECALL GATE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-097", "name": "VECTOR FRESHNESS", "category": "vector-ai", "definition": "The delay between source mutation and searchable embedding availability.", "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": "VECTOR FRESHNESS is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-098", "name": "EMBEDDING BACKFILL", "category": "vector-ai", "definition": "A resumable process that creates vectors for existing source records.", "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": "EMBEDDING BACKFILL is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-099", "name": "DUAL-MODEL WINDOW", "category": "vector-ai", "definition": "A migration interval where old and new embeddings coexist and are distinguishable.", "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": "DUAL-MODEL WINDOW is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-100", "name": "SEMANTIC TOMBSTONE", "category": "vector-ai", "definition": "A deletion marker that removes derived vectors and semantic caches with source data.", "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": "SEMANTIC TOMBSTONE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-101", "name": "VECTOR PROVENANCE", "category": "vector-ai", "definition": "The source fields, model, time, and transformation that produced a stored vector.", "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": "VECTOR PROVENANCE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-102", "name": "AGENT MEMORY SCOPE", "category": "vector-ai", "definition": "The tenant, principal, purpose, and retention boundary for agent-written memory.", "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": "AGENT MEMORY SCOPE is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-103", "name": "CONTEXT BUDGET", "category": "vector-ai", "definition": "The maximum retrieved tokens, records, or evidence bytes passed to inference.", "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": "CONTEXT BUDGET is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-104", "name": "GROUNDING CITATION", "category": "vector-ai", "definition": "A stable reference linking generated output to the database evidence used.", "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": "GROUNDING CITATION is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-105", "name": "INFERENCE-DATA BOUNDARY", "category": "vector-ai", "definition": "The policy boundary separating durable database state from model execution.", "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": "INFERENCE-DATA BOUNDARY is adopted when stored metadata and evaluation output expose the model, quality, provenance, and lifecycle information.", "status": "proposed" }, { "id": "KDT-106", "name": "REPLICA CONTRACT", "category": "replication", "definition": "The ordering, durability, freshness, and read guarantees offered by a replica class.", "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": "REPLICA CONTRACT is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-107", "name": "APPLY WATERMARK", "category": "replication", "definition": "The commit horizon completely incorporated into a replica's queryable state.", "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": "APPLY WATERMARK is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-108", "name": "QUORUM SHAPE", "category": "replication", "definition": "The voter set and acknowledgement rule required for a distributed decision.", "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": "QUORUM SHAPE is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-109", "name": "FAILURE DOMAIN", "category": "replication", "definition": "Infrastructure expected to fail independently from other declared domains.", "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": "FAILURE DOMAIN is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-110", "name": "PLACEMENT INTENT", "category": "replication", "definition": "The desired distribution of replicas across regions, zones, and hardware boundaries.", "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": "PLACEMENT INTENT is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-111", "name": "LEADERSHIP EPOCH", "category": "replication", "definition": "A monotonic generation identifying one period of valid write authority.", "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": "LEADERSHIP EPOCH is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-112", "name": "FENCING TOKEN", "category": "replication", "definition": "A monotonic proof that rejects operations from superseded authority holders.", "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": "FENCING TOKEN is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-113", "name": "READ REPLICA CLASS", "category": "replication", "definition": "A named bundle of locality, lag, consistency, and workload guarantees.", "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": "READ REPLICA CLASS is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-114", "name": "REPLICA ADMISSION", "category": "replication", "definition": "The validation required before a new replica may serve production reads.", "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": "REPLICA ADMISSION is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-115", "name": "CATCH-UP WINDOW", "category": "replication", "definition": "The bounded time and log distance allowed for replica synchronization.", "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": "CATCH-UP WINDOW is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-116", "name": "ANTI-ENTROPY PASS", "category": "replication", "definition": "A background comparison and repair cycle for divergent replicated state.", "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": "ANTI-ENTROPY PASS is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-117", "name": "REPLICATION HORIZON", "category": "replication", "definition": "The oldest commit still needed by any replica, subscriber, or recovery process.", "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": "REPLICATION HORIZON is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-118", "name": "SHARD LEASE", "category": "replication", "definition": "A time-bounded and epoch-bound authority to serve one shard role.", "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": "SHARD LEASE is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-119", "name": "REBALANCE BUDGET", "category": "replication", "definition": "The allowed network, storage, and latency impact of moving replicated data.", "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": "REBALANCE BUDGET is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-120", "name": "TOPOLOGY PROOF", "category": "replication", "definition": "Evidence that live placement satisfies declared quorum and failure-domain rules.", "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": "TOPOLOGY PROOF is adopted when fault tests can observe the declared authority, progress, and safety behavior during delay or partition.", "status": "proposed" }, { "id": "KDT-121", "name": "PARTITION CONTRACT", "category": "sharding-routing", "definition": "The key mapping, ownership, ordering, and movement rules for partitioned data.", "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": "PARTITION CONTRACT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-122", "name": "SHARD KEY FITNESS", "category": "sharding-routing", "definition": "A measured score for distribution, locality, query targeting, and growth behavior.", "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": "SHARD KEY FITNESS is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-123", "name": "HOT-KEY BUDGET", "category": "sharding-routing", "definition": "The maximum load one key may place on a shard before mitigation.", "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": "HOT-KEY BUDGET is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-124", "name": "ROUTING EPOCH", "category": "sharding-routing", "definition": "A monotonic version for the ownership map used to route operations.", "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": "ROUTING EPOCH is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-125", "name": "OWNERSHIP MAP", "category": "sharding-routing", "definition": "The authoritative mapping from key ranges or hashes to serving shard groups.", "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": "OWNERSHIP MAP is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-126", "name": "SCATTER WIDTH", "category": "sharding-routing", "definition": "The number of shards contacted by one logical operation.", "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": "SCATTER WIDTH is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-127", "name": "COLOCATION HINT", "category": "sharding-routing", "definition": "A non-binding request to place related data within one transaction or query domain.", "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": "COLOCATION HINT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-128", "name": "MIGRATION FENCE", "category": "sharding-routing", "definition": "The epoch and progress barrier preventing unsafe access during data movement.", "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": "MIGRATION FENCE is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-129", "name": "SPLIT POINT", "category": "sharding-routing", "definition": "The key or hash boundary where one shard becomes multiple owned ranges.", "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": "SPLIT POINT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-130", "name": "MERGE POINT", "category": "sharding-routing", "definition": "The validated boundary where adjacent shard ranges become one ownership unit.", "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": "MERGE POINT is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-131", "name": "TENANT CELL", "category": "sharding-routing", "definition": "A bounded placement and failure unit containing one tenant's assigned shards.", "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": "TENANT CELL is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-132", "name": "LOCALITY POLICY", "category": "sharding-routing", "definition": "The allowed regions and proximity preferences for storage and query execution.", "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": "LOCALITY POLICY is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-133", "name": "CROSS-SHARD ENVELOPE", "category": "sharding-routing", "definition": "The participants, coordinator, deadline, and recovery state for distributed work.", "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": "CROSS-SHARD ENVELOPE is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-134", "name": "COORDINATOR BUDGET", "category": "sharding-routing", "definition": "The maximum participants and time allowed for coordination overhead.", "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": "COORDINATOR BUDGET is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-135", "name": "DATA GRAVITY", "category": "sharding-routing", "definition": "The measured pressure to execute compute near the dominant data location.", "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": "DATA GRAVITY is adopted when routing traces and movement tests expose ownership epochs, contacted shards, and locality decisions.", "status": "proposed" }, { "id": "KDT-136", "name": "CACHE CONTRACT", "category": "cache-edge", "definition": "The identity, freshness, invalidation, isolation, and failure rules for cached data.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "CACHE CONTRACT is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-137", "name": "FRESHNESS KEY", "category": "cache-edge", "definition": "The version input that determines whether a cached value remains safe to serve.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "FRESHNESS KEY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-138", "name": "PURGE SPAN", "category": "cache-edge", "definition": "The elapsed time from mutation to removal of the final unsafe cached copy.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "PURGE SPAN is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-139", "name": "NEGATIVE CACHE", "category": "cache-edge", "definition": "A bounded cached representation of an absent key or empty result.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "NEGATIVE CACHE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-140", "name": "ADMISSION POLICY", "category": "cache-edge", "definition": "The rule deciding whether a response is valuable and safe enough to cache.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "ADMISSION POLICY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-141", "name": "EVICTION PROOF", "category": "cache-edge", "definition": "Telemetry showing why a cached object left memory or edge storage.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "EVICTION PROOF is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-142", "name": "HOTSET RESIDENCY", "category": "cache-edge", "definition": "The fraction of high-value working data retained in the intended cache tier.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "HOTSET RESIDENCY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-143", "name": "CACHE STAMPEDE FENCE", "category": "cache-edge", "definition": "Coordination that limits duplicate origin work when a popular item expires.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "CACHE STAMPEDE FENCE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-144", "name": "READ-THROUGH BOUNDARY", "category": "cache-edge", "definition": "The point where a cache miss becomes an authoritative database read.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "READ-THROUGH BOUNDARY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-145", "name": "WRITE-THROUGH BOUNDARY", "category": "cache-edge", "definition": "The point where a mutation and its cache update share one success contract.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "WRITE-THROUGH BOUNDARY is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-146", "name": "EDGE READ TOKEN", "category": "cache-edge", "definition": "Portable metadata proving the freshness horizon of an edge-served response.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "EDGE READ TOKEN is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-147", "name": "ORIGIN SHIELD", "category": "cache-edge", "definition": "A shared intermediate cache that protects the authoritative origin from fanout.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "ORIGIN SHIELD is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-148", "name": "CACHE VARIANT", "category": "cache-edge", "definition": "One representation selected by tenant, authorization, locale, schema, or protocol.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "CACHE VARIANT is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-149", "name": "BYPASS CAUSE", "category": "cache-edge", "definition": "A machine-readable reason a request skipped an otherwise eligible cache.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "BYPASS CAUSE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-150", "name": "CACHE COST ENVELOPE", "category": "cache-edge", "definition": "The memory, egress, invalidation, and origin-savings budget for a cache tier.", "contract": "Implementations using these terms MUST declare cache identity, freshness, invalidation, admission, bypass, and origin behavior so caching never silently changes database semantics.", "adoption": "CACHE COST ENVELOPE is adopted when cache traces expose key identity, freshness decision, source, and invalidation behavior for each response.", "status": "proposed" }, { "id": "KDT-151", "name": "SCHEMA CONTRACT", "category": "schema-evolution", "definition": "The named fields, types, constraints, defaults, and compatibility rules for data.", "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": "SCHEMA CONTRACT is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-152", "name": "SHAPE VERSION", "category": "schema-evolution", "definition": "A stable identifier for one externally meaningful schema representation.", "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": "SHAPE VERSION is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-153", "name": "COMPATIBILITY WINDOW", "category": "schema-evolution", "definition": "The period during which multiple schema or protocol shapes remain supported.", "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": "COMPATIBILITY WINDOW is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-154", "name": "EVOLUTION STEP", "category": "schema-evolution", "definition": "One independently deployable and reversible change in a schema migration.", "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": "EVOLUTION STEP is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-155", "name": "DEFAULT MATERIALIZATION", "category": "schema-evolution", "definition": "The decision to store a default physically rather than derive it at read time.", "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": "DEFAULT MATERIALIZATION is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-156", "name": "BACKFILL BUDGET", "category": "schema-evolution", "definition": "The maximum resource and latency impact allowed for historical data rewriting.", "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": "BACKFILL BUDGET is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-157", "name": "DUAL-READ WINDOW", "category": "schema-evolution", "definition": "A migration phase where readers understand both old and new representations.", "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": "DUAL-READ WINDOW is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-158", "name": "DUAL-WRITE WINDOW", "category": "schema-evolution", "definition": "A migration phase where mutations maintain both old and new representations.", "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": "DUAL-WRITE WINDOW is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-159", "name": "FIELD LIFECYCLE", "category": "schema-evolution", "definition": "The proposed, optional, required, deprecated, and removed states of a field.", "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": "FIELD LIFECYCLE is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-160", "name": "CONSTRAINT PHASE", "category": "schema-evolution", "definition": "The observe, warn, enforce, or validate state of a data constraint.", "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": "CONSTRAINT PHASE is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-161", "name": "VALIDATION HORIZON", "category": "schema-evolution", "definition": "The data boundary through which a new constraint has been checked.", "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": "VALIDATION HORIZON is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-162", "name": "UNKNOWN-FIELD POLICY", "category": "schema-evolution", "definition": "The preserve, ignore, index, or reject behavior for undeclared fields.", "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": "UNKNOWN-FIELD POLICY is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-163", "name": "CANONICAL ENCODING", "category": "schema-evolution", "definition": "The one deterministic byte or JSON representation used for equality and hashing.", "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": "CANONICAL ENCODING is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-164", "name": "MIGRATION PROOF", "category": "schema-evolution", "definition": "Evidence that transformed data satisfies source, target, count, and invariant checks.", "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": "MIGRATION PROOF is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-165", "name": "ROLLBACK SHAPE", "category": "schema-evolution", "definition": "The retained representation and procedure required to reverse a migration safely.", "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": "ROLLBACK SHAPE is adopted when migration tests can identify the active shape, compatibility phase, progress, and reversible boundary.", "status": "proposed" }, { "id": "KDT-166", "name": "API CONTRACT", "category": "api-sdk", "definition": "The versioned requests, responses, errors, authentication, and behavioral guarantees of an API.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "API CONTRACT is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-167", "name": "CAPABILITY DISCOVERY", "category": "api-sdk", "definition": "A machine-readable method for clients to learn supported database features.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "CAPABILITY DISCOVERY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-168", "name": "IDEMPOTENCY SCOPE", "category": "api-sdk", "definition": "The endpoint, tenant, time window, and payload identity covered by an idempotency key.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "IDEMPOTENCY SCOPE is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-169", "name": "ERROR TAXONOMY", "category": "api-sdk", "definition": "A stable classification of failures by retryability, responsibility, and semantics.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "ERROR TAXONOMY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-170", "name": "RETRY CLASS", "category": "api-sdk", "definition": "The declared conditions and backoff rules under which an operation may be repeated.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "RETRY CLASS is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-171", "name": "PAGINATION CONTRACT", "category": "api-sdk", "definition": "The ordering, snapshot, token lifetime, and mutation behavior of paged results.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "PAGINATION CONTRACT is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-172", "name": "BATCH ENVELOPE", "category": "api-sdk", "definition": "The limits, ordering, atomicity, and per-item outcomes of a batch request.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "BATCH ENVELOPE is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-173", "name": "REQUEST BUDGET", "category": "api-sdk", "definition": "The maximum bytes, operations, complexity, and time accepted for one request.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "REQUEST BUDGET is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-174", "name": "RESPONSE BUDGET", "category": "api-sdk", "definition": "The maximum rows, bytes, metadata, and generation time for one response.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "RESPONSE BUDGET is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-175", "name": "COMPATIBILITY HEADER", "category": "api-sdk", "definition": "Wire metadata declaring requested and selected contract versions.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "COMPATIBILITY HEADER is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-176", "name": "FEATURE NEGOTIATION", "category": "api-sdk", "definition": "The deterministic exchange selecting mutually supported optional behavior.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "FEATURE NEGOTIATION is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-177", "name": "CLIENT WATERMARK", "category": "api-sdk", "definition": "The newest server contract version a client proves it understands.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "CLIENT WATERMARK is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-178", "name": "SDK PARITY", "category": "api-sdk", "definition": "Equivalent supported behavior and error semantics across official language clients.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "SDK PARITY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-179", "name": "WIRE STABILITY", "category": "api-sdk", "definition": "The guarantee that compatible clients can parse and interpret future responses.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "WIRE STABILITY is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-180", "name": "DEPRECATION CLOCK", "category": "api-sdk", "definition": "The published interval between deprecation notice and contract removal.", "contract": "Implementations using these terms MUST publish capability, compatibility, error, retry, pagination, and deprecation behavior consistently across supported protocols and SDKs.", "adoption": "DEPRECATION CLOCK is adopted when cross-SDK contract tests observe the same wire behavior, error class, and compatibility outcome.", "status": "proposed" }, { "id": "KDT-181", "name": "TRUST BOUNDARY", "category": "security-identity", "definition": "A boundary across which data or authority requires explicit validation.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "TRUST BOUNDARY is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-182", "name": "PRINCIPAL SCOPE", "category": "security-identity", "definition": "The tenant, project, resources, and actions assigned to one authenticated identity.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "PRINCIPAL SCOPE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-183", "name": "TENANT FENCE", "category": "security-identity", "definition": "Enforcement preventing one tenant's identity, data, or compute from crossing into another.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "TENANT FENCE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-184", "name": "POLICY DECISION POINT", "category": "security-identity", "definition": "The component that evaluates identity, resource, action, context, and policy.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "POLICY DECISION POINT is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-185", "name": "POLICY ENFORCEMENT POINT", "category": "security-identity", "definition": "The component that blocks or permits an operation using a policy decision.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "POLICY ENFORCEMENT POINT is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-186", "name": "LEAST-PRIVILEGE SHAPE", "category": "security-identity", "definition": "The smallest resource and action set required for a workload to function.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "LEAST-PRIVILEGE SHAPE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-187", "name": "SECRET LIFETIME", "category": "security-identity", "definition": "The maximum interval during which one credential value remains valid.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "SECRET LIFETIME is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-188", "name": "KEY ROTATION WINDOW", "category": "security-identity", "definition": "The bounded overlap where old and new cryptographic keys are accepted.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "KEY ROTATION WINDOW is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-189", "name": "ENCRYPTION DOMAIN", "category": "security-identity", "definition": "The data set protected by one key hierarchy and access policy.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "ENCRYPTION DOMAIN is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-190", "name": "AUDIT WITNESS", "category": "security-identity", "definition": "Tamper-evident evidence identifying who performed or approved a protected action.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "AUDIT WITNESS is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-191", "name": "BREAK-GLASS LEASE", "category": "security-identity", "definition": "Time-limited emergency authority requiring reason, approval, and enhanced audit.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "BREAK-GLASS LEASE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-192", "name": "DATA ACCESS PURPOSE", "category": "security-identity", "definition": "The declared business or operational reason authorizing a protected read.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "DATA ACCESS PURPOSE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-193", "name": "ROW AUTHORITY", "category": "security-identity", "definition": "The policy proof granting a principal access to an individual record.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "ROW AUTHORITY is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-194", "name": "CAPABILITY TOKEN", "category": "security-identity", "definition": "A bounded bearer proof granting specific actions on specific resources.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "CAPABILITY TOKEN is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-195", "name": "SECURITY DOWNGRADE", "category": "security-identity", "definition": "An explicit and auditable transition to weaker protection, never a silent fallback.", "contract": "Implementations using these terms MUST make principal, tenant, policy, key, encryption, and emergency authority boundaries explicit and auditable for every protected operation.", "adoption": "SECURITY DOWNGRADE is adopted when authorization tests and audit records identify the principal, boundary, decision, key state, and exception path.", "status": "proposed" }, { "id": "KDT-196", "name": "DATA PURPOSE", "category": "privacy-compliance", "definition": "The declared and allowed reason for collecting or processing a data class.", "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": "DATA PURPOSE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-197", "name": "CONSENT RECEIPT", "category": "privacy-compliance", "definition": "Versioned evidence of the principal, purpose, notice, choice, and consent time.", "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": "CONSENT RECEIPT is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-198", "name": "RETENTION CLOCK", "category": "privacy-compliance", "definition": "The policy-derived deadline controlling when governed data must be reviewed or erased.", "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": "RETENTION CLOCK is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-199", "name": "ERASURE PROOF", "category": "privacy-compliance", "definition": "Evidence that primary, derived, indexed, cached, and backup data followed deletion policy.", "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": "ERASURE PROOF is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-200", "name": "CORRECTION TRAIL", "category": "privacy-compliance", "definition": "An auditable history of requested and applied corrections to personal data.", "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": "CORRECTION TRAIL is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-201", "name": "DATA PRINCIPAL LINK", "category": "privacy-compliance", "definition": "A protected association between governed records and the person they concern.", "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": "DATA PRINCIPAL LINK is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-202", "name": "PROCESSING BOUNDARY", "category": "privacy-compliance", "definition": "The services, regions, and purposes within which governed data may be processed.", "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": "PROCESSING BOUNDARY is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-203", "name": "RESIDENCY CONTRACT", "category": "privacy-compliance", "definition": "The allowed storage, processing, replication, and backup locations for data.", "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": "RESIDENCY CONTRACT is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-204", "name": "EXPORT PACKAGE", "category": "privacy-compliance", "definition": "A portable, authenticated, and explainable bundle of a principal's governed data.", "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": "EXPORT PACKAGE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-205", "name": "LEGAL HOLD FENCE", "category": "privacy-compliance", "definition": "A scoped policy suspending normal deletion while preserving access controls and audit.", "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": "LEGAL HOLD FENCE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-206", "name": "MINIMIZATION BUDGET", "category": "privacy-compliance", "definition": "The maximum fields, precision, and retention justified by a declared purpose.", "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": "MINIMIZATION BUDGET is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-207", "name": "SENSITIVE FIELD CLASS", "category": "privacy-compliance", "definition": "A policy label selecting stronger access, logging, masking, and retention controls.", "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": "SENSITIVE FIELD CLASS is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-208", "name": "ANONYMIZATION PROFILE", "category": "privacy-compliance", "definition": "The transformations and risk threshold used to remove principal identifiability.", "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": "ANONYMIZATION PROFILE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-209", "name": "REIDENTIFICATION RISK", "category": "privacy-compliance", "definition": "The measured likelihood that transformed data can be linked back to a person.", "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": "REIDENTIFICATION RISK is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-210", "name": "COMPLIANCE EVIDENCE", "category": "privacy-compliance", "definition": "Versioned proof connecting a requirement to policy, control, execution, and result.", "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": "COMPLIANCE EVIDENCE is adopted when a compliance export links the governed data to purpose, policy, lifecycle action, and verifiable evidence.", "status": "proposed" }, { "id": "KDT-211", "name": "SIGNAL CONTRACT", "category": "observability-sre", "definition": "The name, unit, dimensions, sampling, retention, and privacy rules of telemetry.", "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 CONTRACT is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-212", "name": "TRACE SPINE", "category": "observability-sre", "definition": "The shared correlation path connecting gateway, query, storage, replication, and sink work.", "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": "TRACE SPINE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-213", "name": "QUERY TRACE", "category": "observability-sre", "definition": "A bounded record of planning, execution stages, waits, work units, and result outcome.", "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": "QUERY TRACE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-214", "name": "STORAGE TRACE", "category": "observability-sre", "definition": "A bounded record of cache, segment, log, object, and filesystem operations.", "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": "STORAGE TRACE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-215", "name": "CORRELATION TOKEN", "category": "observability-sre", "definition": "A safe identifier linking related logs, metrics, traces, and audit events.", "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": "CORRELATION TOKEN is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-216", "name": "TAIL LENS", "category": "observability-sre", "definition": "A view focused on p95, p99, timeout, and worst-case behavior rather than averages.", "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": "TAIL LENS is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-217", "name": "ERROR BUDGET", "category": "observability-sre", "definition": "The allowed unreliability remaining before an SLO requires delivery tradeoffs.", "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": "ERROR BUDGET is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-218", "name": "BURN WINDOW", "category": "observability-sre", "definition": "A time interval over which error-budget consumption is measured and alerted.", "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": "BURN WINDOW is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-219", "name": "SLO GATE", "category": "observability-sre", "definition": "A release or operation decision driven by measured service-level objectives.", "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": "SLO GATE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-220", "name": "SLOW-PATH SAMPLE", "category": "observability-sre", "definition": "A retained high-detail trace selected because latency crossed a declared threshold.", "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": "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.", "status": "proposed" }, { "id": "KDT-221", "name": "SATURATION SIGNAL", "category": "observability-sre", "definition": "A measure showing a finite resource approaching throughput or queue capacity.", "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": "SATURATION SIGNAL is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-222", "name": "QUEUE AGE", "category": "observability-sre", "definition": "The elapsed time of the oldest unfinished item in an asynchronous stage.", "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": "QUEUE AGE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-223", "name": "LAG LENS", "category": "observability-sre", "definition": "A view correlating replication, index, cache, connector, and subscriber freshness.", "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": "LAG LENS is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-224", "name": "INCIDENT MARKER", "category": "observability-sre", "definition": "A timestamped annotation connecting telemetry changes to an operational event.", "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": "INCIDENT MARKER is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-225", "name": "EVIDENCE BUNDLE", "category": "observability-sre", "definition": "The minimal logs, traces, metrics, config, and timeline needed to review an incident.", "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": "EVIDENCE BUNDLE is adopted when operators can correlate the signal to a request or subsystem and use it in an SLO or incident decision.", "status": "proposed" }, { "id": "KDT-226", "name": "RECOVERY CONTRACT", "category": "backup-recovery", "definition": "The declared recovery point, recovery time, scope, dependencies, and validation process.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "RECOVERY CONTRACT is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-227", "name": "RECOVERY POINT", "category": "backup-recovery", "definition": "The latest committed position guaranteed present after a successful recovery.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "RECOVERY POINT is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-228", "name": "RECOVERY TIME", "category": "backup-recovery", "definition": "The elapsed time from declared failure to validated service restoration.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "RECOVERY TIME is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-229", "name": "RESTORE TARGET", "category": "backup-recovery", "definition": "The isolated cluster, timestamp, log position, and data scope selected for restore.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "RESTORE TARGET is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-230", "name": "BACKUP CHAIN", "category": "backup-recovery", "definition": "The ordered snapshots and log intervals required to reconstruct a recovery point.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "BACKUP CHAIN is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-231", "name": "SNAPSHOT SEAL", "category": "backup-recovery", "definition": "A checksum and position proving a snapshot is complete and immutable.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "SNAPSHOT SEAL is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-232", "name": "LOG CONTINUITY", "category": "backup-recovery", "definition": "Evidence that required log positions contain no unrecoverable gap.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "LOG CONTINUITY is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-233", "name": "RESTORE DRILL", "category": "backup-recovery", "definition": "A scheduled recovery execution that validates data, timing, access, and applications.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "RESTORE DRILL is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-234", "name": "RECOVERY PROOF", "category": "backup-recovery", "definition": "The checksums, counts, invariants, and timing showing a restore met its contract.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "RECOVERY PROOF is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-235", "name": "REGION ESCAPE", "category": "backup-recovery", "definition": "The documented path to restore service outside a failed or inaccessible region.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "REGION ESCAPE is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-236", "name": "IMMUTABLE COPY", "category": "backup-recovery", "definition": "A backup copy protected from mutation and deletion for a declared interval.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "IMMUTABLE COPY is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-237", "name": "CORRUPTION WINDOW", "category": "backup-recovery", "definition": "The bounded history interval that may contain undetected invalid data.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "CORRUPTION WINDOW is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-238", "name": "REPAIR BOUNDARY", "category": "backup-recovery", "definition": "The smallest data and history scope selected for verified repair.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "REPAIR BOUNDARY is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-239", "name": "FAILOVER FENCE", "category": "backup-recovery", "definition": "The authority barrier preventing the failed primary from resuming unsafe writes.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "FAILOVER FENCE is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-240", "name": "RETURN-TO-PRIMARY PLAN", "category": "backup-recovery", "definition": "The validated sequence for moving authority back after disaster operation.", "contract": "Implementations using these terms MUST prove backup completeness, log continuity, restore isolation, recovery objectives, and failover fencing through recurring restore drills.", "adoption": "RETURN-TO-PRIMARY PLAN is adopted when a restore drill produces checksummed evidence for completeness, timing, isolation, and declared objectives.", "status": "proposed" }, { "id": "KDT-241", "name": "WORK UNIT", "category": "performance-cost", "definition": "One precisely defined useful database outcome used to normalize performance and cost.", "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": "WORK UNIT is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-242", "name": "LATENCY ENVELOPE", "category": "performance-cost", "definition": "The allowed p50, p95, p99, and timeout behavior for a workload.", "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": "LATENCY ENVELOPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-243", "name": "THROUGHPUT ENVELOPE", "category": "performance-cost", "definition": "The sustainable work rate under declared latency and correctness constraints.", "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": "THROUGHPUT ENVELOPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-244", "name": "CONCURRENCY SHAPE", "category": "performance-cost", "definition": "The clients, connections, in-flight work, key skew, and arrival pattern of load.", "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": "CONCURRENCY SHAPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-245", "name": "RESOURCE ENVELOPE", "category": "performance-cost", "definition": "The CPU, memory, storage, IOPS, network, and power limits of a workload.", "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": "RESOURCE ENVELOPE is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-246", "name": "COST PER USEFUL OPERATION", "category": "performance-cost", "definition": "Total infrastructure cost divided by successfully validated work units.", "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": "COST PER USEFUL OPERATION is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-247", "name": "AMPLIFICATION LEDGER", "category": "performance-cost", "definition": "A combined account of logical work versus physical reads, writes, storage, and network.", "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": "AMPLIFICATION LEDGER is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-248", "name": "ALLOCATION BUDGET", "category": "performance-cost", "definition": "The maximum heap allocations and allocated bytes allowed per work unit.", "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": "ALLOCATION BUDGET is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-249", "name": "COPY BUDGET", "category": "performance-cost", "definition": "The maximum memory or serialization copies allowed through a data path.", "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": "COPY BUDGET is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-250", "name": "LOCK HOLD BUDGET", "category": "performance-cost", "definition": "The maximum duration shared progress may be blocked by one critical section.", "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": "LOCK HOLD BUDGET is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-251", "name": "TAIL TAX", "category": "performance-cost", "definition": "The resource or coordination overhead paid specifically to control worst-case latency.", "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": "TAIL TAX is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-252", "name": "COLD-START CLOCK", "category": "performance-cost", "definition": "The time from process start to validated readiness for the declared workload.", "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": "COLD-START CLOCK is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-253", "name": "BENCHMARK CONTRACT", "category": "performance-cost", "definition": "The fixed dataset, operations, durability, concurrency, correctness, and reporting rules.", "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": "BENCHMARK CONTRACT is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-254", "name": "BASELINE PAIR", "category": "performance-cost", "definition": "Two runs verified compatible enough for a meaningful performance delta.", "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": "BASELINE PAIR is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-255", "name": "PERFORMANCE CLAIM BOUNDARY", "category": "performance-cost", "definition": "The exact workloads and evidence beyond which a speed claim does not apply.", "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": "PERFORMANCE CLAIM BOUNDARY is adopted when a reproducible benchmark or production profile reports the named work unit, tails, resources, and cost.", "status": "proposed" }, { "id": "KDT-256", "name": "PORTABILITY CONTRACT", "category": "interoperability", "definition": "The supported runtime, storage, network, identity, and operational dependencies across providers.", "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": "PORTABILITY CONTRACT is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-257", "name": "PROVIDER PROFILE", "category": "interoperability", "definition": "A versioned description of one cloud's regions, services, limits, and deployment capabilities.", "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": "PROVIDER PROFILE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-258", "name": "RUNTIME PROFILE", "category": "interoperability", "definition": "A deployable topology with explicit compute, storage, replication, backup, and SLO behavior.", "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": "RUNTIME PROFILE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-259", "name": "STORAGE ADAPTER CONTRACT", "category": "interoperability", "definition": "The ordering, atomicity, durability, and error behavior required from a storage backend.", "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": "STORAGE ADAPTER CONTRACT is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-260", "name": "PROTOCOL PERSONALITY", "category": "interoperability", "definition": "A compatibility surface translating a familiar protocol into native database semantics.", "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": "PROTOCOL PERSONALITY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-261", "name": "WIRE-COMPATIBLE SURFACE", "category": "interoperability", "definition": "An endpoint preserving declared request, response, and error behavior of another protocol.", "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": "WIRE-COMPATIBLE SURFACE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-262", "name": "IMPORT FIDELITY", "category": "interoperability", "definition": "The measured preservation of source values, types, order, identity, and constraints.", "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": "IMPORT FIDELITY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-263", "name": "EXPORT FIDELITY", "category": "interoperability", "definition": "The measured completeness and reconstructability of data leaving the database.", "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": "EXPORT FIDELITY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-264", "name": "CONNECTOR CHECKPOINT", "category": "interoperability", "definition": "A durable source and destination position for resumable data movement.", "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": "CONNECTOR CHECKPOINT is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-265", "name": "SINK DELIVERY CLASS", "category": "interoperability", "definition": "The ordering, duplication, retry, and acknowledgement guarantees of an outbound sink.", "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": "SINK DELIVERY CLASS is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-266", "name": "SOURCE REPLAY CLASS", "category": "interoperability", "definition": "The history, ordering, and resume behavior available from an inbound source.", "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": "SOURCE REPLAY CLASS is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-267", "name": "SOVEREIGNTY PROFILE", "category": "interoperability", "definition": "A deployable bundle of residency, operator, key, network, and support constraints.", "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": "SOVEREIGNTY PROFILE is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-268", "name": "ESCAPE HATCH", "category": "interoperability", "definition": "A documented and tested path to export data, keys, configuration, and operational control.", "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": "ESCAPE HATCH is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-269", "name": "VENDOR BOUNDARY", "category": "interoperability", "definition": "The exact feature or responsibility delegated to provider-specific infrastructure.", "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": "VENDOR BOUNDARY is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-270", "name": "INTEROP PROOF", "category": "interoperability", "definition": "Versioned evidence that two systems exchange data and behavior within declared loss bounds.", "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": "INTEROP PROOF is adopted when a conformance run moves data or behavior across two implementations and reports losses and dependencies.", "status": "proposed" }, { "id": "KDT-271", "name": "DESIRED STATE", "category": "operations-control", "definition": "The versioned configuration the control plane is responsible for realizing.", "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": "DESIRED STATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-272", "name": "OBSERVED STATE", "category": "operations-control", "definition": "The measured resource and service condition reported by the managed data plane.", "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": "OBSERVED STATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-273", "name": "RECONCILE LOOP", "category": "operations-control", "definition": "An idempotent process that drives observed state toward desired state.", "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": "RECONCILE LOOP is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-274", "name": "DRIFT MARKER", "category": "operations-control", "definition": "A machine-readable difference between declared and observed configuration or capacity.", "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": "DRIFT MARKER is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-275", "name": "OPERATION LEASE", "category": "operations-control", "definition": "Exclusive time-bounded authority to execute one dangerous lifecycle operation.", "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": "OPERATION LEASE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-276", "name": "APPROVAL GATE", "category": "operations-control", "definition": "A policy-controlled checkpoint requiring named authorization before execution continues.", "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": "APPROVAL GATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-277", "name": "CHANGE WINDOW", "category": "operations-control", "definition": "The allowed time, scope, and risk conditions for an operational change.", "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": "CHANGE WINDOW is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-278", "name": "ROLLOUT RING", "category": "operations-control", "definition": "An ordered fleet subset used to limit exposure during progressive delivery.", "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": "ROLLOUT RING is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-279", "name": "HEALTH GATE", "category": "operations-control", "definition": "The measured conditions required before an operation advances to the next stage.", "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": "HEALTH GATE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-280", "name": "AUTO-HEAL BUDGET", "category": "operations-control", "definition": "The maximum concurrent repair work and customer impact allowed for automation.", "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": "AUTO-HEAL BUDGET is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-281", "name": "CAPACITY INTENT", "category": "operations-control", "definition": "The workload, headroom, locality, and cost targets driving resource allocation.", "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": "CAPACITY INTENT is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-282", "name": "SCALE DECISION", "category": "operations-control", "definition": "An auditable action linking capacity evidence to a topology or resource change.", "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": "SCALE DECISION is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-283", "name": "FLEET SLICE", "category": "operations-control", "definition": "A selectable group of deployments sharing provider, region, version, tenant, or risk.", "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": "FLEET SLICE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-284", "name": "CONTROL-DATA SEPARATION", "category": "operations-control", "definition": "The authority and failure boundary between fleet management and customer data processing.", "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": "CONTROL-DATA SEPARATION is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-285", "name": "OPERATOR EVIDENCE", "category": "operations-control", "definition": "The timeline, inputs, approvals, outputs, and rollback information for an operation.", "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": "OPERATOR EVIDENCE is adopted when an operator can inspect the state transition, authority, approval, health evidence, and resulting fleet change.", "status": "proposed" }, { "id": "KDT-286", "name": "TERM REGISTRY", "category": "governance-standards", "definition": "An append-only versioned catalog assigning stable identifiers to defined engineering language.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "TERM REGISTRY is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-287", "name": "NORMATIVE CONTRACT", "category": "governance-standards", "definition": "A requirement stated with testable MUST, SHOULD, or MAY behavior.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "NORMATIVE CONTRACT is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-288", "name": "CONFORMANCE LEVEL", "category": "governance-standards", "definition": "A named set of mandatory contracts an implementation proves together.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "CONFORMANCE LEVEL is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-289", "name": "CAPABILITY MANIFEST", "category": "governance-standards", "definition": "A machine-readable declaration of supported contracts, versions, limits, and evidence.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "CAPABILITY MANIFEST is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-290", "name": "FEATURE STATUS", "category": "governance-standards", "definition": "The proposed, experimental, preview, stable, deprecated, or removed state of behavior.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "FEATURE STATUS is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-291", "name": "MATURITY STAGE", "category": "governance-standards", "definition": "The evidence level reached from concept through production and multi-provider proof.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "MATURITY STAGE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-292", "name": "EXPERIMENTAL FENCE", "category": "governance-standards", "definition": "A boundary preventing unproven behavior from silently becoming a stable dependency.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "EXPERIMENTAL FENCE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-293", "name": "STANDARD PROFILE", "category": "governance-standards", "definition": "A named interoperable selection of contracts and parameter ranges.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "STANDARD PROFILE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-294", "name": "COMPATIBILITY MATRIX", "category": "governance-standards", "definition": "The tested behavior across client, server, protocol, provider, and version combinations.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "COMPATIBILITY MATRIX is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-295", "name": "DEPRECATION RECORD", "category": "governance-standards", "definition": "The reason, replacement, notice date, migration path, and removal date for a contract.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "DEPRECATION RECORD is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-296", "name": "DECISION LEDGER", "category": "governance-standards", "definition": "An append-only record of accepted, rejected, superseded, and reversed engineering decisions.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "DECISION LEDGER is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-297", "name": "IMPLEMENTATION NOTE", "category": "governance-standards", "definition": "Non-normative guidance explaining one valid way to satisfy a contract.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "IMPLEMENTATION NOTE is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-298", "name": "INTEROPERABILITY TEST", "category": "governance-standards", "definition": "A vendor-neutral test proving two independent implementations exchange valid behavior.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "INTEROPERABILITY TEST is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-299", "name": "ADOPTION SIGNAL", "category": "governance-standards", "definition": "Observable evidence that an external tool, client, or operator uses a term or contract.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "ADOPTION SIGNAL is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" }, { "id": "KDT-300", "name": "PROOF BEFORE CLAIM", "category": "governance-standards", "definition": "The rule that architecture, scale, security, or speed language requires reproducible evidence.", "contract": "Implementations using these terms MUST distinguish proposal from implementation, publish conformance evidence, preserve stable identifiers, and deprecate behavior through recorded decisions.", "adoption": "PROOF BEFORE CLAIM is adopted when the public registry or capability manifest identifies status, version, evidence, and compatibility impact.", "status": "proposed" } ] }