HQ DOCS
Documentation
Everything needed to install HQ, understand its mission model, and configure local or cloud inference.
Requirements
- Windows 10 or Windows 11, x64.
- Installer download: AnxCorTex-HQ-Setup-0.9.8-rc.1.exe, 429.6 MiB (450,447,850 bytes).
- No auto-update: upgrades are manual, by running a newer installer over the existing installation.
- Local inference needs a local runtime such as Ollama or llama.cpp.
- Cloud inference needs an API key you supply.
- Interface zoom controls are available: Ctrl/Cmd +, −, 0, plus a −/%/+ cluster in the header.
Install and first run
- Run AnxCorTex-HQ-Setup-0.9.8-rc.1.exe.
- The installer is unsigned, so Windows SmartScreen or Unknown Publisher prompts are expected.
- The installer lets you choose the installation directory; installation is per user.
- On launch, the app starts a local backend bound to 127.0.0.1.
- Application data lives in %APPDATA%\anxcortex-hq.
- Uninstall retains that folder until you remove it manually.
Core concepts
- Mission
- A durable record of a unit of work with an explicit state machine.
- Department
- One of ten specialized roles.
- Mission state
- One of Draft, Planning, Running, Waiting, Needs Approval, Failed, Completed, Cancelled.
- Change Set
- A proposal for file changes that must be approved before it is applied.
- Execution approval
- Per-command approval before a command runs.
- Validation plan and execution run
- How results are checked with real evidence.
- Evidence
- Redacted, persisted output such as command results and validation findings.
- War Room
- Advisory coordination chat.
- Sentinel
- Policy and approval enforcement.
- Release Center
- Read-only release readiness aggregation.
How work moves
Pipeline
Work routes through the canonical seven-stage pipeline. Department sequence:
Manager → Architecture → Engineering → QA → Security → Documentation → Manager
- 1Plan missionVantage · Manager
- 2Analyze architectureLattice · Architecture
- 3Develop implementation reasoningCobalt · Engineering
- 4Review available evidenceRift · Quality Assurance
- 5Review trust boundariesOnyx · Security
- 6Prepare technical handoffSlate · Documentation
- 7Finalize missionVantage · Manager
Three optional stages exist; each is inserted only when the Manager plan routes there.
- +Gather precedent and constraintsUmbra · Research — inserted only when the Manager plan routes there
- +Review product and UX behaviorPrism · Product / UX — inserted only when the Manager plan routes there
- +Assess release readinessKeystone · Release — inserted only when the Manager plan routes there
Mission lifecycle
Six phases, each mapped to the real persisted mission state and the mechanism that produces it.
-
01
Request
A request becomes a durable mission record.
Draft — durable mission record
-
02
Plan
The Manager produces the mission plan.
Planning — Manager plan
-
03
Route
The plan is assigned to departments under the routing policy.
Running — department assignment and routing policy
-
04
Execute
Department stages run; code changes and commands remain proposals until approved.
Running — department stages, Change Set approval
-
05
Verify
QA and Security validation run against recorded evidence.
QA and Security validation, Sentinel evidence ledger
-
06
Report
Documentation prepares the handoff, and Release Center reports readiness.
Documentation handoff, Release Center readiness
Approval and repair
Code changes and commands stay proposals until the Change Set and execution-approval architecture authorizes them.
Validation runs after approval with real execution evidence.
If validation fails, engineering may propose a repair, but every repair is a new Change Set with a new explicit approval, and revalidation requires a new execution approval. The bounded repair loop is capped at two cycles; reaching the limit stops the mission for human attention.
A recovery snapshot is written before an approved change set is applied.
Departments
| # | Department | Role | Canonical description |
|---|---|---|---|
| 01 | Vantage | Manager | Mission orchestration & synthesis |
| 02 | Umbra | Research | Prior art, precedent & external constraints |
| 03 | Lattice | Architecture | System design & risk |
| 04 | Cobalt | Engineering | Implementation & integration |
| 05 | Prism | Product / UX | User flows, states & product tradeoffs |
| 06 | Rift | Quality Assurance | Validation & quality |
| 07 | Onyx | Security | Threat analysis & controls |
| 08 | Pylon | DevOps | Runtime & delivery |
| 09 | Slate | Documentation | Technical knowledge & handoff |
| 10 | Keystone | Release | Release readiness & rollback posture |
Recovery is an event actor for blocked-mission reconciliation, not a department.
Local AI
Local runtimes
Local inference runs through Ollama or llama.cpp.
Provider and model readiness is visible in the interface.
Readiness and queue
The Local AI Queue shows what is waiting and why.
Ollama readiness is separate from queue occupancy.
Model assignment
Departments can be assigned models through per-department assignments.
Routing policies
- local-only (default) — cloud models are never auto-routed; explicit cloud requests are rejected before any content is sent.
- prefer-local — local models win whenever one is available; cloud is a fallback.
- balanced — cost, quality, and performance are weighed; local keeps a stability bonus.
- prefer-quality — capable cloud models win complex tasks even at higher cost.
Cloud AI (opt-in)
Cloud adapters exist for OpenAI and OpenRouter only. Nothing is sent unless all three conditions hold:
- An API key for that provider is stored; the provider becomes configured.
- The provider is enabled in Settings.
- The routing policy allows cloud use and the route actually selects a cloud model.
When a cloud request is made, HQ transmits the assembled prompt (system instructions plus the task or conversation prompt and any bounded mission, context, or code excerpts the planner includes), the selected model id, output limits, and request options such as temperature and streaming. The API key is sent as an Authorization: Bearer header; OpenRouter requests additionally include an X-Title: AnxCorTex HQ header. HQ sends nothing else, and the local database is never uploaded.
Once enabled, the selected provider receives and processes the transmitted content under its own terms of service and privacy policy. The operator supplies the API key, and provider billing applies.
The default routing policy is local-only. Read the privacy disclosure.
When a cloud provider is used, prompts and context can leave this machine.
Security model
- Destructive, secret, git-push, deployment, and privileged actions stay approval-gated in every access mode.
- Sentinel policies are enforced, never optional.
- Credentials are stored through OS-level protection and never exposed to the interface.
- Execution evidence is redacted before it is kept.
This is controlled execution, not an OS sandbox.
Updates
- There is no auto-update client; upgrades are manual.
- Installing a newer build does not delete %APPDATA%\anxcortex-hq.
- Release notes and the changelog are on the Releases page.
Troubleshooting
SmartScreen or Unknown Publisher warning
This is expected because the installer is unsigned.
Nothing happens before setup
Idle states such as "no model assigned" and "AI checking" are normal before you configure a provider or assign a model.
Local inference is unavailable
Local runtimes must be installed separately and be reachable on 127.0.0.1.
Back up your data
Application data lives in %APPDATA%\anxcortex-hq.
Remove all local data
Close the app and delete %APPDATA%\anxcortex-hq. This is irreversible.
Known limitations
- Windows x64 only.
- The release candidate installer is unsigned.
- No auto-update; upgrades are manual.
- No project license has been selected yet; all rights are reserved by default. See Legal.
- A small local model can fail the Manager finalize evidence contract; the mission stays retryable rather than being force-passed.
- Cloud behavior depends on the provider's terms and availability.
Where to next
- Download — installer details for the current release candidate.
- Releases — release notes and changelog.
- Privacy — what is stored locally and when data can leave the machine.
- Legal — licensing status and legal information.
- Third-Party Notices — bundled component notices.