Docs Learn
How Phigon works
Phigon separates collection, transport, evidence evaluation, and presentation. That separation keeps privileged code small, privacy controls local, and uncertainty understandable.
The simple mental model
Observer → Control plane → Phigon app
The observer sees approved machine-local signals. The control plane receives scoped records and preserves evidence boundaries. The Phigon app turns those records into a reviewable operational view.
1. The observer
The observer runs on the supervised machine. Its privileged sensor responsibilities stay narrow: detect approved signals, apply local collection policy, redact locally, and send the permitted record.
Parsing, credentials, long-term storage, and UI concerns belong outside privileged sensor code.
2. The control plane
The control plane receives authorized records and keeps them scoped to the correct tenant. It evaluates evidence without collapsing every claim into a single unquestioned event.
Machine identity, consent, credentials, audit history, telemetry, and deletion operations remain tenant-bound.
3. The Phigon app
The Phigon desktop app presents machine health, supported agent activity, history, and evidence state to authorized administrators. It holds the workspace access key, encrypted by the operating system, and makes every request to the control plane on the administrator's behalf. It should make limitations obvious enough that a reviewer does not mistake “unknown” for “inactive.”
Independent evidence sources
Phigon can work with three kinds of evidence. They support one another, but they do not overwrite one another.
| Source | What it can support | Important limitation |
|---|---|---|
| Agent-native | Agent identity and self-reported lifecycle | An agent can omit or misreport activity. |
| OS-native | Process presence and machine-local behavior | A PID alone is not a stable process identity. |
| Gateway | Approved network-side request evidence | Traffic can bypass the observed gateway. |
How attribution works
Attribution is strongest when the required coverage is present and independent sources agree.
- Supported: sufficient evidence is present and the available sources agree.
- Limited: some useful evidence exists, but full coverage is unavailable.
- Conflicting: sources disagree, so Phigon preserves the conflict.
- Missing: the system cannot responsibly attribute the activity.
No evidence, no claim. When evidence conflicts, disappears, or loses coverage, Phigon surfaces the limitation rather than inventing attribution.
Process identity
Operating systems reuse process IDs. For that reason, Phigon treats a PID as display metadata—not as process-lifetime identity.
A stable process key follows the process lifetime and prevents unrelated activity from being joined simply because two processes used the same PID at different times.
Why this design matters
In a world full of autonomous agents, monitoring has to be trustworthy. More data is not automatically better. The useful system is the one that can explain what it observed, what supported the observation, and what remained outside coverage.