@@ -139,6 +139,7 @@ tracing-actix-web = "0.7"
 
 # Time and Date
 chrono = "0.4"
+chrono-tz = "0.10"
 chrono-humanize = "0.2"
 humantime = "2.1.0"
 humantime-serde = "1.1"
 
@@ -36,6 +36,11 @@ Response:
 }
 ```
 
+A listed `inputSchema` never has a root-level `oneOf`, `anyOf` or `allOf`,
+because several LLM tool APIs reject tool input schemas with root combinators.
+Where the catalog schema has one, the server still enforces it when the tool is
+called, and the affected property descriptions state the constraint.
+
 The response includes an `ETag` and
 `Cache-Control: private, max-age=300, must-revalidate`. A request with a
 matching `If-None-Match` receives `304 Not Modified`.
@@ -130,3 +135,144 @@ and last-seen value, and coalesces supported aliases per row. Its `total` is the
 number of returned groups, not an unbounded count of all matching groups. The
 native Errors page additionally separates issues by message, so its grouping
 and pagination are not identical to this summary tool.
+
+## SQL tool limits
+
+`query_sql`, `explain_query` and other tools that run SQL internally parse the
+statement with DataFusion's SQL parser and accept exactly one `SELECT` or `WITH`
+query. Trailing semicolons and trailing comments are allowed, including
+comments after the final semicolon (`SELECT a FROM t; -- note`).
+The outermost projection must name at most 10 explicit columns, and `*` and
+`table.*` are rejected there. The same limit applies to each branch of a
+top-level set operation such as `UNION` and to a parenthesized outer query.
+Projections inside CTE definitions, derived tables and subqueries are not
+checked. Casts to `INT64`, `UINT64` or `FLOAT64` anywhere in the statement are
+rejected with a hint to use `BIGINT` or `DOUBLE`. The statement is wrapped with
+an outer `LIMIT 500`, except in `get_trace_activity`, whose generated SQL carries
+its own limit (see below). `sample_events`
+returns at most 10 columns, choosing common observability fields such as
+`p_timestamp`, `service.name`, `severity_text`, `body` and `trace_id` before
+other fields.
+
+## Dataset and time resolution
+
+`list_datasets`, `resolve_dataset` and `discover_datasets` omit internal
+datasets.
+
+`resolve_dataset` accepts an optional `telemetryType` (`logs`, `metrics` or
+`traces`) and `limit` (1–20, default 5). Its `status` is `resolved`,
+`ambiguous`, `not_found` or `error`.
+
+- A `selectedDataset` or `contextDataset` resolves to the visible dataset with
+  exactly that (case-sensitive) name. If none has that exact name, it resolves
+  to the one visible dataset whose name matches case-insensitively; if several
+  do, the result is `ambiguous` with those datasets as `candidates`. If no
+  visible dataset matches, the result has `status: "error"`. If the selected
+  dataset's telemetry type does not match `telemetryType`, the result is
+  `not_found`.
+- Otherwise, if exactly one dataset is visible, it resolves to that dataset, or
+  returns `not_found` if its telemetry type does not match.
+- Otherwise it scores the visible datasets that match `telemetryType` by name
+  against `query`, ignoring case: 1000 if the name equals the query, 750 if the
+  query contains the name as a whole word (`-` and `_` count as part of a name,
+  so `api` is not in `rapid` or `api-gateway`), or 500 if the name contains the
+  query, plus 25 for each query term longer than two characters that the name
+  contains, plus 15 when `telemetryType` is given. It resolves only a unique top
+  score of at least 500. In every other case it returns `ambiguous` with up to
+  `limit` scored `candidates`, or `not_found` if no visible dataset matches
+  `telemetryType`.
+
+It never falls back to an arbitrary dataset.
+
+`discover_datasets` counts events in the requested range for each visible
+dataset of the requested telemetry type that the caller can query. It returns
+active datasets ordered by event count as `{ name, eventsInRange }`, together
+with `selectedDatasets`, `activeDatasetCount`, `truncated` and up to 20
+`unavailableDatasets`. If no dataset is active and at least one could not be
+counted, the result has `status: "error"` and no datasets.
+
+`resolve_time_range` accepts any IANA `timezone` (default `UTC`), and uses it
+for `today` and `yesterday` day boundaries. It also accepts `last <duration>`,
+`past <duration>`, `now-<duration>`, `<start> to <end>` and RFC3339 start
+times. An unknown timezone is an error.
+
+`sample_events` accepts an explicit `startTime` and `endTime`, which must be
+provided together. They take precedence over `minutes`.
+
+## Log context
+
+`get_log_context` uses the same implementation as `POST /api/v1/query/context`.
+Arguments must include exactly one of `log`, `body` or `message`, holding the
+anchor row's exact value. The catalog schema enforces this with a root `oneOf`,
+so calls with none or more than one are rejected with `400`. The listed
+`inputSchema` omits that `oneOf` (see [List tools](#list-tools)) and states the
+rule in the property descriptions.
+
+Context bounds are either `contextWindow` or both `contextStartTime` and
+`contextEndTime`. Giving only one explicit bound, or a window together with an
+explicit bound, is an error. If no bounds are given, the tool uses
+`contextWindow: "5 minutes"`. A window extends that duration on each side of
+`pTimestamp`, and both ends are rounded down to the minute; if they round to the
+same minute, the end is one minute after the start. Explicit bounds are used at
+millisecond precision without rounding, and `pTimestamp` must be at or after
+the start and before the end. `pageSize` is 1–500, default 100.
+
+Returned records keep at most 10 fields per row, preferring `p_timestamp`,
+service, severity, message and trace identifiers. The response also includes
+the anchor index, scope and the executed queries.
+
+## Trace activity
+
+`get_trace_activity` returns a bucketed span and trace activity series for one
+traces dataset:
+
+```json
+{
+  "name": "get_trace_activity",
+  "arguments": {
+    "dataset": "otel-traces",
+    "startTime": "2026-10-22T00:00:00Z",
+    "endTime": "2026-10-22T01:00:00Z",
+    "groupBy": ["service.name"],
+    "filters": { "span_status_code": 2 },
+    "bucketCount": 60
+  }
+}
+```
+
+`dataset`, `startTime` and `endTime` are required. `startTime` must be before
+`endTime`; both are resolved once and applied as exact, half-open bounds (start
+inclusive, end exclusive) on the dataset's time partition, so subminute ranges
+keep their full precision. `groupBy` takes up to 5
+exact field names. Each field may appear only once, and `time`, `span_count`
+and `trace_count` are rejected because they are output column names. `filters`
+maps exact field names to JSON scalars: strings, numbers and booleans test
+equality, and `null` tests `IS NULL`. `bucketCount`
+is 1–100, default 60. It approximates the number of `DATE_BIN` buckets over the
+dataset's time partition, or `p_timestamp` if none is configured. Buckets are
+whole seconds, sized from the exact range and aligned to `startTime`. The dataset
+must have traces telemetry and contain `span_span_id` and `span_trace_id`.
+Unknown fields are rejected. `span_count` is `COUNT(DISTINCT span_span_id)` and
+`trace_count` is `COUNT(DISTINCT span_trace_id)`, so duplicate span rows are
+not double counted. Rows are ordered by bucket, oldest first. The result
+contains `query`, `bucketInterval`, `semantics`, up to 500 `rows` and
+`truncated`.
+
+`query` is the exact SQL the tool runs; it ends in `LIMIT 501` so the tool can
+detect overflow. When more than 500 rows match, the newest buckets are dropped
+and `truncated` is `true`; reduce `bucketCount`, `groupBy` or the time range to
+get the full series. `query` embeds the exact time bounds as a half-open
+predicate on the time field. The query API rounds a request's `startTime` and
+`endTime` down to the minute, so to reproduce the result, for example in a
+dashboard tile, run `query` through the query API with a time range that covers
+those bounds.
+
+## Argument schema validation
+
+`inputSchema` is enforced server-side for `type` (a single type or a list of types), `required`,
+`additionalProperties`, `enum`, `const`, `minLength`/`maxLength`,
+`minimum`/`maximum`, `minItems`/`maxItems`, `items`, `anyOf` and `oneOf`.
+`oneOf` passes only when exactly one variant matches. Combinators are checked
+in addition to sibling keywords; they do not replace them. Validation uses the
+catalog schema, including any root combinators omitted from the listed
+`inputSchema`.
@@ -49,6 +49,8 @@ Team requests share the cookie session and `credentials: 'include'`. The adminis
 | `getApiKey(id, signal?)`                 | `GET /api/prism/v1/apikeys/{encoded id}`               | Full key, retrieved only on an explicit copy action                                                                                                              |
 | `deleteApiKey(id)`                       | `DELETE /api/prism/v1/apikeys/{encoded id}`            | Checked success; backend returns `{keyId, keyName, message}`                                                                                                     |
 
+API key listing accepts `?privilege=reader|ingestor|admin|writer|editor|superadmin` (alias `priviledge`), matching direct or group-inherited role privileges by kind (an admin key does not match `reader`, and a super-admin key does not match `admin`). Each entry's `roles` lists direct roles only. Unknown or differently cased values, or a repeated parameter, return 400; unknown parameter names are ignored and leave the list unfiltered.
+
 API key expiry is optional: `ttlSeconds` must be an integer from 1800 (30 minutes) through 7776000 (90 days), inclusive; invalid values return 400. Omitted or null TTL means no expiration. Responses include `expiresAt`, a UTC timestamp or null; the frontend also accepts an omitted field from older servers for legacy records. Finite lifetimes are elapsed durations from creation, independent of time zones or daylight saving changes. The creation form defaults to 90 days and offers presets, custom minutes/hours/days, and No expiration. TTL cannot be edited after creation. Expired keys remain listed and deletable; their names remain reserved until deletion.
 
 Both `X-API-KEY` and Bearer authentication return 401 once server time reaches `expiresAt`, and key validation reports false. Temporary API-key sessions, including those created for intra-cluster requests, cannot extend the deadline or refresh as OAuth sessions. Intra-cluster requests on behalf of an expired key return 401. Requests authorized before expiry may finish on the node that authorized them. Expiration changes credential validity, not its assigned roles or an administrator's authority to create other credentials.
 
@@ -90,6 +90,9 @@ async function addField(editor: Locator, label: string, value: string) {
 test('creating every chart type through the editor saves classic-compatible keys', async ({
   page,
 }) => {
+  // Eleven editor flows and four full-page accessibility scans share this budget.
+  test.setTimeout(60_000);
+
   const server = await serve(page);
   const sql = 'SELECT time, service, requests FROM "app-logs"';
 
 
@@ -0,0 +1 @@
+__pycache__/
@@ -0,0 +1,36 @@
+# Ingestion performance and compatibility checks
+
+These scripts launch disposable local-store servers on loopback ports. They require two already-built Parseable binaries, Python 3, Linux `/proc`, and `taskset` when CPU affinity is supplied. They do not connect to an existing deployment. Each output directory must be new. Test credentials are local dummy values; telemetry and update checks are disabled.
+
+Build the baseline and candidate with the same Rust toolchain, lockfile, features, allocator, profile and real UI assets. Preserve the baseline executable before building the candidate. Run builds and other experiments before timing; avoid competing activity on the test host.
+
+```sh
+python scripts/ingest-performance/compatibility.py --baseline /abs/baseline --candidate /abs/candidate --output /abs/results/compat --cpus 2,4,6,8
+python scripts/ingest-performance/run.py --baseline /abs/baseline --candidate /abs/candidate --output /abs/results/burst --pairs 4 --cpus 2,4,6,8
+python scripts/ingest-performance/sustained.py --baseline /abs/baseline --candidate /abs/candidate --output /abs/results/sustained --pairs 2 --seconds 300 --requests-per-second 20 --cpus 2,4,6,8
+python scripts/ingest-performance/mixed.py --baseline /abs/baseline --candidate /abs/candidate --output /abs/results/mixed --pairs 2 --seconds 75 --requests-per-second 2 --queries-per-second 2 --cpus 2,4,6,8
+```
+
+Select available physical cores on your machine, or pass `--cpus ''` to omit affinity. Four Actix and four Rayon workers are used in both arms. The burst runner alternates arm order across pairs; `--smoke` runs a small functional check. Sustained and mixed runners also alternate arm order with `--pairs`; the default remains one pair. The offered load starts at wall-clock minute :05 after warmup, unless phase alignment is disabled; its actual anchored start is recorded. Their fixed offered rates do not measure maximum sustainable capacity. Use separate comparisons against the original baseline and reviewed PR binary to isolate the cost of remediation; optional `--reviewed` adds a third arm but ABC/CBA ordering does not balance the middle arm across positions.
+
+The mixed runner ingests 8,204-row, 127-field scalar requests while querying the same dataset. Its default body is 9,556,551 bytes, checked before starting servers against the 10 MiB HTTP limit. The server adds `p_timestamp`; production queries sort fields and exercise reordered schema adaptation during capture. Each concurrent query must include every request acknowledged before it starts and cannot include requests that start after it finishes; in-flight rows remain allowed. These timestamp bounds are checked after load and saved per query. Exact request/row identity is checked after load, drain and persisted-only restart. Mixed CPU includes ingestion and queries. Query latency is not isolated capture time or lock-hold time.
+
+`--diagnostics` streams bounded 100 ms thread state/wchan/schedstat/fault counters, process I/O, host pressure and swap counters. Both arms receive the same instrumentation. Collection cost, errors, truncation and the byte cap are reported; use matched on/off runs before attributing timing changes to the server. A clean run or an off-CPU sample cannot explain a historical stall. The diagnostic does not enumerate unrelated host processes or identify their I/O. Client lag, workload duration, live payload bytes and sampled staging bytes are bounded; hitting a safety bound invalidates the run rather than demonstrating a performance threshold.
+
+Every timed request must succeed. Request IDs are unique, including warmup requests. Verification checks each request's row count, distinct row IDs and bounds. Burst checks repeat after SIGKILL and restart, polling for eventual query visibility for up to 120 iterations. This tests process-crash recovery, not power-loss durability or immediate recovery readiness.
+
+The sustained runner samples server CPU/RSS and file sizes each second. After load stops, it polls the target dataset’s data-bearing staging files for up to 240 seconds, requires three consecutive empty observations, and verifies rows again. It then kills its server, preserves the old staging directory and starts with empty staging to check rows from the persisted local store. Internal `pstats` work may continue after the target dataset drains. CPU is reported separately for the ACK window and through observed drain (the latter also includes the first verification query). Sampled peak RSS includes verification queries and drain; it is not an ingestion-only peak or allocator high-water mark. Staged file size is not a total in-memory backlog measure.
+
+Burst payloads are prepared before timing and capped at 768 MiB of client payload data. The current app/wide workloads retain about 413/528 MB in the client; reported server RSS excludes the client, kernel page cache and other processes. Request identities add one string field to each row. Payloads, binary hashes, timing phase, configuration and host load are recorded. Short burst results may overlap periodic background work differently; inspect all repetitions rather than a single ratio.
+
+The compatibility corpus compares HTTP status/error responses, schemas, ingestion accounting and logical row multisets. It deliberately ignores generated `p_timestamp` and unspecified SQL result order. Every request's expected status is asserted independently, including intended rejections and raw OTLP cases; `partitiontypes` pins one named inherited 500 with its known one-row partial outcome. Successful setup/readback statuses, row counts and accounting are asserted, and the static case additionally checks schema types, IDs and decoded values. Equal errors cannot satisfy these success checks. Exact non-static content/error bodies still rely on differential comparison. Ordered flattening, exact RecordBatch/schema behavior and failure boundaries are covered separately by the Rust differential tests.
+
+Run the server-free oracle and harness tests with `python3 -B -m unittest discover -s scripts/ingest-performance -p 'test_*.py' -v`. `compatibility-baseline.json` is the real successful normalized transcript from commit `6aaee1d61c261c6b71c0dad30b6bee75ac654cab`. Replay tests reject equal 503s on ingests/readbacks and incorrect static values, schemas, or accounting; a replay pass does not replace live validation on the final binaries.
+
+To render PNG/SVG charts, install matplotlib and numpy in an isolated environment, then:
+
+```sh
+python scripts/ingest-performance/plot.py --burst /abs/results/burst --sustained /abs/results/sustained --output /abs/results/figures
+```
+
+The local-store results do not establish S3 ingestion capacity. Multipart memory and failure behavior require separate storage probes. Keep exact build provenance and limitations with any reported figures.