---
id: standard.language.q-kdbplus
version: 1.2.0
status: stable
---
# q/kdb+ Standard

## Apply by impact

Apply only rule groups activated by the current task or change-impact record. Do not invent
evidence for untouched surfaces; when a required gate asks about one, record why it is not
applicable.

## Rules
### Design and boundaries
- Prefer vector operations, explicit namespaces, pure query functions, and clear separation of calculation, orchestration, storage, and IPC.
- Keep process roles and ownership explicit; avoid hidden dependencies through global namespace mutation.
### Types and data
- State table shape, keys, column q types, attributes, units, ordering, null/infinity behaviour, temporal assumptions, and symbol-domain expectations.
- Validate schemas and normalize temporal zones/precision at ingestion boundaries.
### Errors and resources
- Use consistent error atoms/messages and translate boundary failures without losing context. Define retry and partial-write behaviour.
- Own handles, callbacks, timers, subscriptions, files, and process shutdown explicitly.
### Concurrency and state
- Document process topology, IPC contracts, async/sync calls, serialization, update ordering, replay/idempotency, and shared state ownership.
- Avoid long blocking work on critical tickerplant/RDB/HDB paths; isolate expensive analytics.
### Testing
- Use deterministic table fixtures covering empty, singleton, null, infinity, keyed/unkeyed, sorted/parted, temporal, duplicate, and schema-change cases.
- Test IPC and PyKX seams with isolated processes when behaviour depends on process state.
### Performance
- Measure scans, joins, grouping, sorts, allocations, serialization, symbol growth, and IPC using representative row counts and cardinalities.
- Prefer keyed lookups, attributes, partition pruning, and vector expressions only when semantics and measurement justify them.
### Security
- Treat IPC, `.Q` utilities, file paths, dynamic evaluation, callbacks, and remote commands as trust boundaries. Restrict capabilities and never log credentials.
### Public API documentation
- Add structured adjacent comments or generated-reference metadata to changed public namespaces, functions, tables, and service entry points.
- Document purpose, arguments, return shape/q types, keys/columns, units, null and infinity semantics, ordering, temporal assumptions, errors, side effects, IPC, update frequency, and examples.
- Do not use comments that merely repeat a name. Private expressions need comments when data-shape assumptions, algorithms, or failure behaviour are non-obvious.
### Tooling and delivery
- Pin supported q/kdb+ and PyKX versions, startup scripts, environment variables, process topology, and deployment layout.
- Validate load order, namespace cleanliness, package contents, process startup/shutdown, and backward-compatible IPC/schema changes.
## Review triggers
Review missing public q documentation, undocumented schemas/null semantics, implicit globals,
repeated full-table scans, nested functional expressions, schema-dependent magic, symbol growth,
blocking IPC, unsafe dynamic evaluation, copied large data, and changes tested only on tiny fixtures.
## Required response
Update structured comments and generated references, name intermediate expressions, isolate
namespaces and processes, validate schemas, add representative fixtures, inspect query cost, and
test null, empty, keyed, temporal, IPC, and PyKX boundary cases.
## Exceptions
A compact q expression may remain when it is idiomatic, measured, named, and covered by
representative tests. Generated, vendored, compatibility-only, or externally owned schemas may
use narrowly configured exclusions.
## Evidence
Record q test commands, fixture sizes/cardinalities, timing/memory measurements, process-isolation,
IPC, restart/replay, and PyKX boundary checks. Record repository documentation validation,
generated q reference checks, and executable example results.