From hook events to a local cockpit
A technical explainer for how FactionOS turns local agent events into readable cockpit state without adding hosted transfer by default.
FactionOS starts with a narrow idea: when an agent workflow emits local events, the operator should be able to see those events as useful operating state. A hook event by itself is only a signal. A cockpit turns a sequence of signals into context a human can use.
This article describes the product direction at a high level: local agent events should become readable cockpit state before any optional handoff exists.
The local event boundary
Agent events can describe sensitive development context: session names, task notes, command outcomes, file references, validation status, and human review points. FactionOS treats those signals as local development state first.
That default is why the security page and local-first architecture post both avoid surprise data-path language. A useful cockpit can be local, explicit, and scoped.
From event to state
The practical flow is simple:
- A local tool emits a structured event about a session or task.
- The local runtime normalizes the event into a stable shape.
- The cockpit presents the event as status, history, review context, or a validation signal.
- A human uses that state to decide what to inspect next.
The important part is not the volume of data. It is whether the state helps a operator answer concrete questions: What is active? What changed? What failed? What needs review?
Why normalization matters
Raw hook output can be noisy. A cockpit should not require an operator to read unstructured logs. It should show reviewable labels, counts, statuses, timestamps, and scoped messages that fit the product contract.
The how it works page explains that flow without turning this website into a runtime surface. Setup and usage details belong in the public docs, which are hosted as a separate destination.
What stays separate
Hosted persistence, hosted identity, remote execution, inbound commands, and executor behavior are separate product concerns. Those capabilities require authorization, data handling, tests, documentation, and launch evidence.
The current editorial job is narrower: explain how local hook events can become readable cockpit state while keeping the default data boundary clear.