Harper Reflex
Sign in with your Google account to manage Reflex.
Sign in with GoogleThis account is not an authorized admin, so admin APIs are unavailable.
What should this engine do?
This deployment answers as ONE persona. Pick the one it should be — it sets the prompt and behavior defaults — and add optional details to tailor the prompt. The profile is created as soon as your first index starts, and you can refine its prompt any time on the Prompt screen.
Add your first source
Sources feed the knowledge base through the existing ingestion backends. Pick a type, name it, and provide its configuration. Upload sources take a file after the source is created.
Add a provider
Pick the type, paste the key, name the model. That is the whole step: Reflex stores the account, registers the model, checks it can actually answer, and points this cluster's answering at it — one action (issue #308). The key is stored encrypted at rest and used only server-side at call time — it is never sent back to the browser.
Advanced
Advanced — connections, model targets, and role binding
A connection is the endpoint/account and its API key, configured once and shared by everything it serves. A model target is one model reached through that connection, probed on its own. An execution role says which target does which job.
On-node runs a local OpenAI-compatible server (Ollama, vLLM, TGI, or your own). Hosted families — Anthropic, IBM watsonx, and the hosted OpenAI presets — are off-node only.
Generation model target
Run the first index
Indexing ingests your source and stamps the knowledge base so it can be queried. Once it has started, the profile is created from the persona you selected and you can continue setup — indexing keeps running in the background, and its progress and result appear on the Sources screen.
Profile created
Ask your first question
This runs the real answer pipeline (the same one POST /answer uses) through the profile you
just created. It works once indexing has produced content — if the first index is still running in the
background, finish setup now and come back to ask later from the Playground.
No citations.
You're set up.
Tune prompts and run more queries in the Playground, or add and reindex sources on the Sources screen.
Sources
Knowledge sources feed corpora through the ingestion backends: file uploads, sitemap/web crawls, and Harper tables. Page Bank sources arrive with issue #37. Disabling a source stops ingestion and scheduling but keeps its indexed content, so it can be re-enabled at any time.
| Source | Corpus | Status | Content | Freshness | Actions |
|---|
No sources exist yet. Add one below, then upload files or run a reindex to populate its corpus.
Providers
A provider is a model this cluster can call, and the account it is called through. Adding one is a single action: pick the type, paste the key, name the model. The API key is stored encrypted at rest and used only server-side at call time — it is never returned to the browser, so editing never shows the current key (leave the key field blank to keep it unchanged; enter a new value only to rotate).
What is serving
Providers
| Account | Type | Placement | Credential | Models | Actions |
|---|
No providers yet. Add one above.
Advanced — models, roles, and editing
Model targets
One model reached through one account, for one capability, probed on its own. This is what a role binds to.
| Target | Account | Capability | Model | Probe | Actions |
|---|
No model targets exist yet. Add a provider above, or create an account here and add a target under it.
Which model serves which job
Only targets the server would actually accept are offered: a disabled, unprobed, blocked, or stale-probed target is refused by the same validator the answer runtime uses, so what this screen calls ready is exactly what will run. Leaving embedding unset is not a gap — it means the zero-config on-node CPU model.
Playground
Answer & retrieval console. Answer mode runs the profile through the same
POST /answer pipeline (active prompt version and cache policy apply, so cache hits and misses are
inspectable) and shows the full answer contract and trace. Profile retrieval searches the profile's complete
resolved scope; corpus diagnostic searches the whole cluster corpus directly for tuning.
Results
Trace
Answer
Citations
No citations.
Answer trace
Top results
No retrieval results.
Profile prompt & behavior editor
Edit this deployment's model-visible instructions and behavior settings. Saving mints a new immutable
ProfileVersion — the complete serving snapshot, including the semantic-cache gates — and switches
the active version only after the save succeeds; prior versions stay inspectable and restorable below, and
restoring one brings its whole snapshot back at once. If another admin activates a version while you are
editing, your save is rejected rather than overwriting theirs. To run a query against what you saved, use the
Playground tab.
This deployment has no profile yet. Run the Setup wizard to create it, then come back to edit its prompt.
Version history
| Version | Created | By | Evals | Actions |
|---|
Access
API keys for the public surfaces: secret keys authenticate server-to-server calls to
POST /answer, POST /retrieve, and MCP via the x-api-key header;
widget keys are origin-restricted and reserved for the embeddable widget (issue #95). A key's
raw value is shown exactly once at creation and can never be retrieved again.
Endpoints
Never embed a secret key in a web page. The snippets above use a placeholder — substitute your key server-side only.
Key created
Copy this key now. It is shown only this once and cannot be retrieved again.
| Key | Kind | Scopes | Status | Usage (7d) | Actions |
|---|
No access keys exist yet. Create a secret key for server-to-server API access, or a widget key for the embeddable widget.
Advanced tuning
Dangerous knobs, kept behind this advanced surface: which model does the embedding, chunking, retrieval cutoff/weights, semantic-cache gates, and source volatility. Changing chunking on an indexed corpus requires an explicit reindex acknowledgement before anything persists; changing the embedding model additionally clears the corpus fingerprint, so retrieval fails closed until a full reindex re-stamps it. Blank fields keep their current values; placeholders show the effective value (stored or default).
Dashboard
Usage, cache, spend, latency, and content-gap metrics from the bounded rollup aggregates (POST /admin/observability/). Everything here is pre-aggregated MetricRollup data — no raw answer runs or traces are ever
read from the browser. Spend and savings are estimates from configured model pricing.
Readiness
Whether this cluster is actually configured and serving, from GET /admin/setup-state/.
Configuration integrity, embedding, provider, indexing, content, and the active profile version are reported
separately — the provider row states the same verdict the answer runtime applies, so this view and the
runtime cannot disagree.
No usage has been recorded for this window yet. Metrics appear here after the first answers run through
POST /answer or the MCP answer tool — this is normal for a new deployment.
Top queries
| Normalized query | Count |
|---|
No queries were tracked in this window.
Content gaps
Questions that were refused because nothing retrievable answered them (normalized query + count — no prompt or trace bodies). Recurring entries are the strongest signal for which knowledge sources to add or expand.
| Normalized query | Count |
|---|
No content gaps in this window — no questions were refused for lack of retrievable content.
Per-key usage
Query volume and estimated spend by access key. Keys are shown by raw id until the Access screen (issue #92) provides display labels; admin/unkeyed traffic groups under "(no access key)".
| Access key | Queries | Est. spend |
|---|
No per-key usage was tracked in this window.
History
| Bucket (UTC) | Surface | Queries | Hit rate | Refusals | p95 | Est. spend |
|---|