Managing Applications¶

In Geodesia G-1 Studio, an Application is the unit you manage: one upstream LLM with GLAD-Hummingbird in the middle, owning its own policy (6-axis thresholds + enforcement), threshold profile, RAG knowledge base, cost center, and governance record. You select the active Application from the topbar App switcher, and every other surface — Dashboard, Oversight, FRIA, Reports, Knowledge Base, Cost — scopes to it.

Studio is a backward-compatible evolution of the single-upstream gateway: an existing deployment surfaces as a single Application named default, with zero behaviour change.

Lifecycle states¶

Every Application is in exactly one of three states, stored in the status column:

State transitions go through set_status, which only accepts active, paused, or killed. Pausing and resuming are the same operation with a different target state.

Configuration model¶

Each Application stores a validated AppConfig JSON document (config_json), versioned by config_version (incremented on every config update). The document has four sections — binding, policy, cost, governance — plus two top-level fields. Missing axes are always back-filled with the defaults, so the 6-axis contract always holds downstream.

binding — the upstream LLM¶

Allowed upstream_type values: openai, ollama, vllm, sglang, trtllm, bedrock, vertex, azure-openai, internal.

The logprobs setting governs the closed-book fabrication axis: require forces a logprob-capable path, off disables it, and auto (default) uses logprobs when the upstream offers them. See Detection Axes for why halluc_closedbook depends on per-token log-probabilities.

policy — detection thresholds and enforcement¶

The policy is scored across the six GLAD-Hummingbird axes. Each axis has its own threshold (probability space, 0.0–1.0) and its own enforcement mode.

Default thresholds (DEFAULT_THRESHOLDS — serving-calibrated for gemma4-e2b at FPR ≈ 0.07, plus the rag_jailbreak firewall):

Default enforcement (DEFAULT_ENFORCEMENT):

The two optional_detectors are off by default: causal_xai adds causal token attribution (see Causal XAI), and self_consistency draws multiple samples to reduce closed-book fabrication false positives.

cost — rates and budget (FinOps)¶

All rate fields must be ≥ 0; alert_pct is rejected if not ascending; on_budget_exceeded must be alert or block. The cost rate is snapshotted at call time so historical costs stay stable when you later change rates.

governance — compliance and oversight¶

Allowed risk_classification values (RISK_CLASSES): minimal, limited, high, unacceptable, unknown.

The human_oversight object controls when a call is auto-escalated for human review: auto_trigger enables it, and safety_threshold / halluc_threshold set the scores above which a call is routed to the oversight queue. See Human Oversight and FRIA.

API keys¶

Each Application has its own API keys. A key is the Application's runtime identity on the data plane: an invoke key sent as Authorization: Bearer g1k_live_… on a chat or RAG request now routes that request to its Application and scopes the request's policy, cost, quota, and compliance to it — even when no X-Geodesia-App header or application_id is supplied. (Previously an invoke key was control-plane-only — a read-only credential; it is now also the data-plane routing identity.) An explicit application_id / X-Geodesia-App still wins over the key. See Data-plane routing.

Operations:

• Create — generates a new key, returns the plaintext once along with key_id, app_id, key_preview, and role.
• List — returns key metadata (key_id, key_preview, role, active, created_at, last_used_at, expires_at) for an Application — never the plaintext or the hash.
• Revoke — sets active = 0. Revoked and expired keys fail verification immediately.

A request authenticates by presenting the plaintext key; verification hashes it, looks up the active, unexpired record, touches last_used_at, and resolves it to {app_id, role}. The full create/list/revoke routes are documented in the Control Plane API.

Creating an Application from the UI¶

Open Applications (ApplicationsView) and click New Application to open the creation modal. The modal performs live model discovery against the upstream you choose, so you pick a real model instead of typing one:

Discovery is served by the control-plane endpoint POST /v1/glad/apps/upstream/models, which returns the model list and its source (or an error you can act on).

In the same modal you set the cost for the Application — €/Mtok for input and output tokens — so the cost center is configured from the start.

Once created, the Application opens to its detail view, organised into tabs:

Saving any tab validates the full AppConfig, bumps config_version, and takes effect on the next request.

Read-only Overview, then edit with auto-save¶

The detail view opens on a read-only Overview tab — a safe summary of the Application's binding, policy, cost, and governance that you can't change by accident. To make changes, click Modifica, which switches to the editable settings tabs: Model, Policy, Cost & Budget, Governance, and API Keys.

There is no "Save" button. Every change in those tabs is saved automatically, debounced shortly after you stop editing — adjust a threshold slider, change the budget, edit alert_recipients, and it persists on its own. An inline status indicator shows where each edit stands: "Saving…" while the debounced write is in flight, then "Saved ✓" once it lands (and the underlying config_version bumps). Because saving is automatic, dependent UI — such as the Cost & Budget projection chart — redraws immediately against the new values.

The Model tab: discover and test¶

The editable Model tab (under Modifica) does more than hold the binding fields — it lets you bind to a real upstream model with confidence:

• Live model discovery. The Model field is an input backed by a datalist, so you can pick a discovered model or type your own. Models are discovered from the chosen upstream — Ollama (/api/tags), vLLM / OpenAI-compatible (/v1/models), or the curated Bedrock / Vertex catalogs — via POST /v1/glad/apps/upstream/models. Discovery runs automatically and debounced whenever you change the upstream type or the base URL (so a URL typed character-by-character only fires one query when you pause), and a ↻ discover button re-runs it on demand. An inline hint shows how many models were found, the source, or an actionable error if the upstream couldn't be listed.

• Test connection. A Test connection button probes the bound upstream for reachability (with a latency reading) and runs a logprob probe that reports whether the closed-book axis is available or unavailable for that model — since halluc_closedbook depends on per-token log-probabilities. A reachable upstream also refreshes the discovered-model list.

Where each setting lives: Applications vs. Settings¶

Studio splits configuration cleanly between the per-Application detail view and the platform-wide Settings page:

Free-tier limit¶

The number of Applications an Organization may create is capped by its license entitlement (max_applications). On the free tier the cap is one Application, so the New Application button is disabled once the default Application exists — you can still fully configure, key, and operate that one Application.