Dashboard configuration ownership

The dashboard exposes live edits, deployment drafts and operational observations. Each setting keeps its own source of truth and activation mechanism. Read-only observations, counts, protocol versions and availability are not editable settings.

Use the table to find where a change belongs. The release scope identifies the runtime covered by qualification; a screenshot or local UI check does not qualify a gateway image.

Every row is a family-level coverage decision, not a claim to expose every nested property. The source inventory below also covers boot-bound types that the environment-file reference cannot enumerate. Direct Environment policies (context, temperature, thresholds), registry/core/quality DB settings and Python/deployment configuration are covered by the families above. A declaration does not imply live mutability. Exact keys/defaults/constraints remain on the authoritative types and runbooks.

Conditional registry edits#

Edit and resolve conflicts#

Use this workflow for PATCH /admin/registry/models/{id} and /admin/registry/providers/{id}:

1. Read the row and retain its opaque expected_revision.
2. Send typed changes with that revision. Omitted fields preserve their value; explicit null clears nullable fields. Identity, enabled and lifecycle fields cannot be cleared; unknown fields are refused.
3. For a toggle, send only enabled and the revision.
4. On 409, review the current row and explicitly save again. The UI retains the draft and does not automatically merge or retry.

Optimistic comparison, validation, registry version and audit commit in the same transaction; publication follows commit. A conflict rolls the write back. Existing POST/PUT/import replacement semantics remain available.

Upgrade boundary: every registry writer must use version-aware code, or writes must be frozen before conditional editing. JPA @Version covers PUT, import and probe; an older binary cannot advance the V66 edit_version column.

Per-row provider reads return stored non-secret headers; import/export/review redacts values with the existing digest marker and refuses that marker as input. Do not import a redacted export as a complete editable row. New API-only credential-pool scope is not a claim that one primary ref represents the entire pool.

Deployment drafts and observations#

These root-ADMIN endpoints distinguish configuration review from live actions.

Apply a reviewed Jev export#

1. Merge the exported changed keys and preserve omitted settings and the existing secret binding.
2. If task-models changes, replace the complete ordered map and remove deleted tasks. A shallow merge can retain obsolete tasks.
3. Check environment overrides, validate, restart and fetch readback.

max-calls-per-process resets with the process. It is neither a durable dollar budget nor a fleet-wide quota.

Interpret readiness observations#

• Distinct Redis endpoint settings do not prove physical separation.
• Cached age -1 means never observed. Missing holders remain unavailable; stale data does not imply health.
• Volume durability and collector delivery need their operating procedures and evidence.
• Readouts describe one instance, not cluster state or acceptance of the qualified profile.

Guided configuration lifecycle#

Get started offers first-request, shared-budget and adaptive-decision recipes within the existing console. Its dismissible journey links existing actions and never sends traffic automatically. Only account/origin-scoped recipe and dismissal preferences persist. Correlation is memory-only; organization selection clears on account change or reload. No credentials, prompts, outputs or tenant selections are saved by the guide.

The dashboard keeps these configuration stages separate.

An enabled row, successful save or recent timestamp does not prove all stages completed. When an API supplies only a value, explicit/default/inherited provenance remains unknown.

Global limits and activation#

The four pointsman.ratelimit.global-* ceilings are gateway-wide, shared across organizations; organization/application/user/key limits are additional constraints. The three RPM/TPM/spend values come from the immutable PlatformCeilingRules snapshot that the engine appends, with source: runtime-holder and mutability: boot. They show Loaded platform rules and Restart required, not Operator refresh. Later property rebinding cannot change those readouts or rebuild those rules. Current configured targets are not separately projected for these three entries; inspect deployment configuration before a restart. This readout is loaded policy, not proof of observed enforcement, available counters or production health.

The active rule amount is reported in the existing wire units: requests, tokens and exact micro-dollars (USD multiplied by 1,000,000). An absent rule is null, including when null, zero or a negative value at construction synthesized no rule; a later positive property target cannot create one. Loaded windows are described from the rules themselves: RPM/TPM roll over one minute, spending uses a calendar day anchored at 00:00 UTC. Separately labelled configured counter-window properties are not those loaded windows.

Concurrency is deliberately separate: its existing mutable property value and refreshable metadata remain, and admission reads that holder on each call. Only a positive concurrency value adds the global scope; null/non-positive adds none. The UI does not reinterpret zero for unrelated controls.

Policy path versus enforcement#

The tree's enforced_on_request_path describes policy path mode, not every rule or grant. With it off, mirrored fixed-chain rules still apply, and deeper-only rules do not automatically join that path. With it on, stored-path mode is reported, with runtime fallback where applicable. Missing/loading/stale/error mode evidence is unverified. Scope binding previews are not per-request enforcement certificates; management permissions remain separate.

Request correlation#

Requests use the numeric ledger ID for exact authorized detail. X-Request-ID is log correlation; X-Pointsman-Request-ID is the gateway UUID stored as request_id. There is no exact UUID lookup in this console API. The journey provides copyable correlation and manual ID verification, never a newest-row guess or automatic polling. Missing records can be delayed or hidden; recorded 2xx is status evidence only. Missing usage/cost stays unknown. Stream completion, settlement and quality have separate evidence requirements.

See the dashboard recipes and fixed-chain boundary. Existing deployment-only secrets/infrastructure, API-only credential pools and absent MCP management remain intentional boundaries; this guidance adds no runtime controls.

Bound source inventory#