- Hosted account, SSO, and organization management are not active defaults.
- Formal certification and legal approval need dedicated review.
- Roadmap themes are directional and may change.
- Commercial metrics and funding details belong in direct conversations.
FAQ
Answers for operators.
Product fit, setup, privacy, docs, teams, and hosted options.
Use this page to understand what FactionOS does today, where the demo and docs live, and which capabilities stay optional.
- Productlocal-first
- Demoseparate
- Docspublic
For formal privacy and legal language, use the dedicated security and legal pages.
Product
What FactionOS is
Core product answers about the cockpit, local-first posture, and operator workflow.
What is FactionOS?
FactionOS is local-first mission control for observing and steering AI coding agent work.
FactionOS is a local-first command surface for AI-assisted development work. It helps operators observe hook events, mission state, approvals, replay context, and coordination signals without making a hosted account the default path.
The product story starts with local workflow visibility and grows into optional collaboration and adapter paths when an operator chooses them.
Core workflows start locally. External destinations and adapters are separate choices.
Who is FactionOS for?
It is aimed at people and teams coordinating agent-assisted development work.
The first public story is built for engineering teams, AI platform teams, founders, and power users who need better visibility into agent workflows.
Use-case pages describe role fit for teams and solo operators who need mission state, handoff clarity, and review context.
Role pages are product-fit guidance, not a replacement for implementation docs or direct support.
Setup
How setup is framed
Setup answers focus on local operation, docs, and the guided demo path.
How can I try the product direction?
Start with the guided demo and public docs.
Open the separate demo to inspect product feel without setup, then use the public GitBook docs for setup context and event-contract details.
For product questions that do not fit the docs, use the product contact route.
Demo and docs open as separate destinations.
What runs locally?
The product story centers on local hook ingest, local server state, and cockpit views.
FactionOS describes a local-first path where hook events and mission context are observed through local product surfaces.
Optional transfers and future hosted capabilities must be named separately and require their own review, controls, and evidence.
Optional transfers and future hosted capabilities must be named separately.
Privacy and security
How data posture works
Privacy answers point to the current security posture and external destination boundaries.
Does this website collect visitor data?
No tracking, hosted form, account flow, or runtime personalization is part of this site.
This site does not ask for prompts, local paths, credentials, terminal output, or source code.
The public demo, docs, email, hosting provider logs, and browser behavior are separate destinations or systems.
Use the privacy and security pages for formal handling details.
Is there a trusted unified erasure workflow?
A broad unified erasure workflow is not presented as active from this site.
The current launch site does not create hosted accounts or accept product data uploads, so it does not offer an account erasure flow.
Future hosted surfaces need their own retention, deletion, and verification language.
Future hosted data surfaces need separate privacy and legal review.
Demo and docs
How external destinations fit
Demo and docs answers explain where to inspect and where to learn setup details.
Is the public demo the product?
The demo is a separate guided preview.
The public demo is a separate destination for exploring product direction and product feel.
Use the docs for setup context and the product pages for the surface map.
The demo is a preview path, not the installed product runtime.
Where are the docs?
Public docs live at an external GitBook destination and are linked explicitly.
The website links to public GitBook docs as an external destination. Product docs, technical references, and implementation details should live there or in repository docs instead of being duplicated on marketing pages.
Docs links stay explicit so readers know when they move from marketing pages into implementation material.
Docs are a separate public destination.
Integrations
How external systems are handled
Integration answers distinguish local product behavior from explicit optional transfers.
Does FactionOS send prompts or files to external providers by default?
External transfer is optional and must remain explicit.
The active project posture requires external provider transfer to be explicit. A provider key alone must not be described as permission to send prompts, files, terminal output, paths, or code.
Any future provider or adapter path should describe consent, minimization, redaction, failure behavior, and configuration clearly.
Silent provider transfer is not part of the default product posture.
Can integrations run commands or change my code from the website?
No. Website pages do not run executors or inbound control workflows.
This website cannot run terminal commands, edit files, open local sockets, trigger guarded actions, or control a workspace.
Future executor behavior would require a separate threat model, authorization design, audit trail, tests, and documentation before public materials change.
Executor and inbound-control behavior requires separate product design and authorization.
Teams
How team use is described
Team answers separate role fit from optional collaboration surfaces.
Can a team use FactionOS?
Team use is a product-fit direction, with role-specific pages and explicit collaboration boundaries.
The use-case pages describe how engineering and platform teams may evaluate FactionOS for agent workflow visibility and handoff clarity.
Collaboration and identity-sensitive workflows should be evaluated through the security page and direct product conversations.
Team fit is separate from hosted organization management.
Is War Room collaboration a hosted account system?
War Room is described as optional collaboration, not a default account system.
War Room collaboration is described as optional and boundary-specific. Room-local authority is separate from hosted account identity, SSO, and organization membership.
Any stronger collaboration model needs scoped identity, authorization, consent, abuse controls, validation, and documentation work.
Hosted identity is not the default product path.
Hosted options
What is not active by default
Hosted answers keep future options separate from the default local workflow.
Are hosted services active by default?
No. The default product story starts locally.
Hosted storage, analytics, public replay, push, tunnels, and remote access are future or optional areas unless a specific product path ships them with controls.
The roadmap can name later themes, but the default product story remains local-first.
Future hosted options need their own controls and documentation.
Are the legal pages final?
No. The first legal pages are pre-review placeholders unless owner-approved legal text is supplied.
The legal hub, privacy, terms, and acceptable-use routes are built to keep policy scope visible before launch review.
Until owner/legal-approved copy exists, those pages remain clearly marked as pre-review placeholders and do not create policy acceptance workflows.
Pre-review policy copy is not final legal approval and does not create acceptance or consent workflows.
Trust boundary
Planned work is kept separate from active capability.
Answers describe the current product posture and route deeper questions to the demo, docs, security, roadmap, and contact pages.
Still deciding
Route the next question.
Use the security page for trust boundaries, the roadmap for direction, or mailto contact paths for product and security questions.
Contact actions open your email client so you can review the message before sending.