System Performance
Latency percentiles, cache rates, recovery metrics, and individual trace inspection.
What this page does
The System Performance page (labeled "Observability" in some navigation contexts) provides deep operational visibility into Planara's query processing pipeline. It shows how fast responses are delivered, how effectively the cache is working, and detailed per-query traces.
KPI Grid
Six performance metrics computed from recent traces:
| Metric | Description | Warning threshold |
|---|---|---|
| P50 Latency | Median response time. Half of all queries complete faster than this. | -- |
| P95 Latency | 95th percentile. 95% of queries complete faster than this. | Over 15s (yellow) |
| P99 Latency | 99th percentile. Only 1% of queries take longer. | Over 30s (red) |
| Cache Hit Rate | Percentage of queries served from cached results. | -- |
| Recovery Rate | Percentage of queries that triggered semantic recovery. | -- |
| Error Rate | Percentage of traces that include an error node. | Over 5% (red) |
Query Volume Chart
A 14-day bar chart identical to the one on the Overview Dashboard, showing daily query counts and recovery usage. The recovery portion is shown as a darker overlay on each bar.
Filters
Below the chart, several filter controls let you drill into specific query subsets:
- Search -- free text search across query text and query hash
- Skill filter -- dropdown to filter by active skill (e.g., "winterization", "specs", "troubleshooting")
- Cache filter -- toggle between All, Hit, and Miss
- Recovery filter -- toggle between All, Yes, and No
- Sort -- toggle between Date (newest first) and Latency (highest first)
- Count indicator -- shows "X of Y traces" after filtering
Trace table
Each row represents a single query processed by Planara:
| Column | Description |
|---|---|
| Timestamp | When the query was processed |
| Query | The original query text (or hash if text is not stored) |
| Skill | Which skill was activated for this query |
| Latency | Total end-to-end time. Color-coded: normal (under 15s), yellow (15-30s), red (over 30s). Note that current production p50 for procedural and diagnostic queries sits in the yellow/red bands — see Performance for the measured profile and why. |
| Cache | "hit" (green) or "miss" (gray) |
| Recovery | "yes" (blue) if answer recovery was triggered, "no" (gray) otherwise |
| User | Email of the user who submitted the query |
| Nodes | Number of pipeline stages executed for this query |
| Trace | Arrow link to the full trace for deep inspection |
Understanding the trace pipeline
Each Planara query passes through a subset of the pipeline stages below, depending on intent, cache state, and conversation context. All executed stages are visible in the trace view:
- Intent classification -- determine intent type, role, and skill
- Query rewriting -- reformulate follow-ups into standalone queries
- Context gate -- check if the answer exists in conversation history
- Ontology expansion -- bridge vocabulary gaps using domain ontology
- Cache check -- response cache and retrieval cache lookup
- Retrieval -- hybrid keyword + semantic search across the vector index
- Confidence evaluation -- assess retrieval quality, trigger query-expansion recovery if needed
- Skill routing -- classify into skill bucket and apply skill-specific instructions
- Orchestrator -- coordinate generation strategy and context streams
- CKL enrichment -- if trigger terms match, compliance sources are retrieved
- Reranking -- neural relevance re-ranking reorders retrieved sections by relevance
- Generation -- the AI model produces the structured JSON response
- Self-evaluation -- check generation output for factual consistency
- Proactive suggestions -- generate follow-up questions and procedure candidates
- Validation -- safety checks, grounding verification, and schema compliance
- Response assembly -- final response formatting and delivery
Trace inspection
The "View Traces" button in the page header opens the full tracing view. Each trace row also has a direct link to its specific trace. In the trace view you can see:
- Per-step latency breakdown
- Processing volume and cost per query
- Retrieved chunk content and scores
- The full input and generated output text
- Error details for failed queries
Ingestion monitoring
Document ingestion progress is tracked separately from query performance. The Upload page shows real-time progress for active ingestion jobs, including:
- Stage progress — which pipeline stage is currently running (parsing, chunking, entity extraction, linking, indexing, QA gates)
- Page progress — pages processed out of total pages, with percentage
- QA gate results — which of the 7 automated quality checks passed or failed, with failure reasons
- Timing — elapsed time for in-progress jobs, total processing time for completed jobs
Ingestion runs are also traced with per-stage timing. This helps identify which pipeline stages are bottlenecks for specific document types.
Quality gate reporting
The 7 QA gates that run during ingestion produce structured reports:
| Gate | Success indicator |
|---|---|
| Chunk completeness | All chunks have required metadata |
| Safety coverage | Safety warnings from source preserved in chunks |
| Spec validation | Numeric values match source (within tolerance) |
| Link integrity | All cross-references resolve |
| Duplicate detection | No duplicate chunk IDs |
| Index quality | Indexed representations valid and within expected ranges |
| Content coverage | Chunk page coverage matches source |
Gate results are stored with the ingestion job record. Failed gates surface immediately on the Upload page. Historical gate pass rates are available in aggregate for trend analysis — a declining pass rate may indicate source document quality issues.