Skip to main content
Opticon is Starfort’s monitoring app. It records a trace for every Guard evaluation, so you can see exactly what each request was and how the Guardian decided. Open Opticon from a project (or its Guardian) — the Opticon link — then choose Tracing in the left navigation.
Opticon with the Tracing navigation item highlighted

Opticon → Tracing

​
The trace list

Each row is one Guard API / Desktop Agent call, showing the input, the Guardian’s output, latency, tags, and scores. For a Desktop Agent call, the trace’s session is the matched Control Profile name, and its metadata carries the request’s URL, HTTP method, Content-Type, and headers; the input call and its output call share one Trace ID, so you see a full request→response cycle as a single trace. For an API call, the session is the caller’s session_id, and the caller can link two calls by passing the same trace_id. Tags and scores make it easy to filter and aggregate:
  • the action — PASS, MASK, BLOCK
  • policy results — e.g. PII Masking Policy:MASK, TOPIC:BLOCK
  • the caller — e.g. the API key name
  • the stage — process_type:input
  • scores — per policy name, rolled up by policy type

​
A trace’s detail

Open a trace to see the full picture: the original input, the processed_content (masked output), the resolved action, every detected item, and the call metadata (API key, model config, process type).
Opticon trace detail with the MASK action highlighted

A MASK trace in detail — the action is MASK

Filter by the BLOCK or MASK tag to review exactly what was caught and which policy caught it — invaluable when tuning policies or troubleshooting.

​
Opticon Fail-Safe (Fail-Open / Fail-Closed)

Trace recording is normally asynchronous: if Opticon is down or unresponsive, the Guard verdict (PASS / MASK / BLOCK) is still returned and only the record is lost — the observation plane fails open. In audit-critical operations that gap matters: an unrecorded request is an unauditable request. Starting in v1.3, each project chooses what happens when a trace ultimately fails to record, with the Opticon Fail-Safe setting in Project Settings → General:
Project Settings with the Opticon Fail-Safe section highlighted, showing the Fail-Open and Fail-Closed options

Project Settings → General → Opticon Fail-Safe

Fail-Closed recording attempts are bounded — a time and retry ceiling — so an unresponsive Opticon results in a BLOCK, never an indefinitely hanging response. When Opticon recovers, requests flow normally again with no manual reset. The policy is per project because traces are recorded through the project’s Opticon binding — and even packets that reach a project without matching any Project Guardian (observe-and-log only) are logged under that binding. Audit posture can also differ per project within one company. What doesn’t trigger it — Fail-Closed applies only when a trace should exist but couldn’t be recorded. Requests that never produce a trace are unaffected:
  • entries whose Opticon logging is explicitly turned off (an intentional opt-out, not a failure)
  • paths that never generate a trace in the first place (auth failures, deterministic gates, unsupported inputs, over-limit rejections)
  • projects with no Opticon binding configured
Enforcement matches other fail-closed blocks: API callers receive a block response, and Desktop Agents don’t deliver the packet (with a user notification, if configured).

​
Retention and what Opticon doesn’t do

Opticon shows runtime data only. Org, project, and member management all live in the Console — you can’t create or delete them from Opticon (Starfort is the source of truth), and your Console roles carry over here. Trace retention is set in Opticon, but traces are never deleted by hand — there’s no per-trace or bulk delete, and deleting a project doesn’t remove its traces; only the retention cycle does. This is by design, so the record stays intact. (Governance changes — who changed configuration — are in the separate Audit Log.)