Local-first agent observability without surprise data paths

Agent observability is useful only when it respects the boundary of the work it describes. A coding agent can touch repository paths, shell output, file names, task notes, logs, and prompts. Those signals are valuable to a developer, but they are also context that should not move somewhere else without a clear reason.

FactionOS treats that context as local development state first. The security and privacy page uses the same boundary: this public website is static, the product baseline is local-first, and optional hosted surfaces must earn their own review before they become claims.

Local state is the default

The product direction is a local runtime that can ingest and present agent events without requiring an account, hosted database, or analytics provider. The goal is to help the person at the keyboard understand what is happening across sessions while preserving a simple default: the machine running the work is the place where the work is observed.

That default matters because agent events are not generic page views. They can describe commands, plans, file operations, and human review decisions.

That is also why the public website does not add analytics by default. A page view is not worth weakening the product story. If analytics is ever approved, it needs a separate consent, minimization, and documentation pass that excludes prompts, local paths, replay payloads, and user-provided code.

Observability should be narrow

The useful cockpit view is not a dump of everything an agent sees. It is a curated operational surface: which sessions are active, which tasks changed, which steps are waiting, which errors need attention, and which workflows need a human decision.

Keeping that view narrow helps avoid a common failure mode in developer tools: collecting broad data because it is convenient, then trying to justify it after the fact.

The features page frames this as operational visibility rather than broad capture. The cockpit should show useful state: active work, handoffs, errors, and review points. It should not imply hidden telemetry, public replay, or hosted storage by default.

Optional services need explicit contracts

Some future integrations may be useful, but they need explicit controls, documented payloads, and local-only fallback behavior. A product page or blog post should not imply that prompts, terminal output, local paths, diagnostics, or replay data are sent to an external system by default.

That boundary is part of the product, not a footnote. The public GitBook documentation remains the place for setup and usage details, while this site keeps the product story short, static, and reviewable.

What this means for publishing

Every publishing surface should reinforce the same contract:

• Static pages should not collect visitor prompts, local paths, or code.
• External demo and docs links should be named as external destinations.
• Hosted identity, production-hosted validation, full trusted erasure, and formal certification should stay no-claim until separately implemented and verified.

That keeps the architecture story aligned with the product boundary instead of using marketing copy to race ahead of the system.