> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Monitor traces (Opticon)
> Use Opticon → Tracing to see every Guard evaluation, with its action, policy hits, and metadata.
**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.
## 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](/en/v1.3/admin/control-profiles) 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).
Filter by the `BLOCK` or `MASK` tag to review exactly what was caught and which policy caught it — invaluable when tuning policies or [troubleshooting](/en/v1.3/desktop/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**:
| Mode | Recording | When recording ultimately fails | Prioritizes |
| ----------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------ | --------------------- |
| **Fail-Open** (default) | Asynchronous, best-effort — the existing behavior | The record is lost; the verdict is returned as-is | Availability, latency |
| **Fail-Closed** | Recording success becomes a **precondition of the response** | The request is demoted to **BLOCK** — the content is not delivered | Auditability |
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](/en/v1.3/admin/audit-log).)