Designing the battlefield without pretending it is omniscient

The battlefield model is a product design tool, not a claim that FactionOS has perfect knowledge of every agent action. It gives messy development work a shape that humans can scan: where sessions are, what changed recently, what is blocked, and where review is needed.

That distinction matters. The cockpit can make state legible without pretending to be the agent, the terminal, the repository, or a hosted command center.

Why game language works here

Game interfaces are good at showing multiple streams of state without making the player read a log from top to bottom. They use position, status, resources, labels, and event trails to help people decide what needs attention.

Agentic development has the same coordination problem. A developer might have a planning session, an implementation session, a validation pass, and a bug hunt running across different tools. A cockpit can turn those fragments into a stable operating view.

The features page describes the practical pieces behind that view: session status, review points, local event flow, and evidence that can be read without opening every terminal.

What the battlefield should show

The useful version of the battlefield is concrete:

• A session has a name, status, scope, and recent activity.
• Work can be grouped by phase, package, route, or task list.
• Blocked or failed work is visible instead of buried in scrollback.
• Static sample panels are labelled as samples so they do not look like live telemetry.

The model should not imply automated execution. It should help a human decide where to look next.

What stays outside the claim

The current public website does not claim production-hosted validation, hosted identity, real executor behavior, remote execution, inbound commands, or full trusted erasure. Those are separate product and security surfaces that need implementation, tests, documentation, and evidence before they become launch language.

That is why the security page and the cockpit story need to stay aligned. A more readable interface is useful only if it keeps the boundary between observed local work and unsupported hosted behavior clear.

The design target

The target is not spectacle. The target is a working screen that can survive real development pressure:

• A developer can tell which sessions need attention.
• A reviewer can see what changed before approving a handoff.
• A team can discuss agent work through shared state instead of scattered transcripts.
• A future product page can show richer visuals without changing the privacy promise underneath them.

That is the role of the battlefield: make agent work visible enough to steer, and bounded enough to trust.