Admin

Overview

The Admin area is the control centre for platform configuration. It is where administrators manage users, define access rules, configure branding, and maintain the reference data that underpins other areas. Most settings here apply platform-wide.

Key Concepts

Diagnostic outcomes. A command can run and still fail. Your coworker’s result keeps its diagnostic output and reports failure when the command exits with an error. A successful command reports its exit status; an unavailable status stays unknown. Approval gives permission to attempt an action, rather than proof that it worked. Checking a recent approved request returns the actual action’s recorded outcome and does not repeat the action. If no execution evidence is available, the outcome remains unconfirmed.

• User Management — Creating, editing, and deactivating user accounts. Each user has a role, optional superuser status, and profile information.
• Role & Capability Matrix — The mapping of roles to capabilities. Admins can review the full matrix and understand what each role can and cannot do.
• Branding Configuration — The organization’s name, logo, colours, and display preferences. Applied across the internal shell and the customer-facing storefront.
• Reference Data — Lookup tables and configurable values used throughout the platform (e.g., product categories, status labels, regulation types). Changes here affect all areas.
• Storefront Admin — Configuration for the public-facing storefront, including domain routing, archetype selection, and presentation settings.

What You Can Do

• Create and manage user accounts, set roles, and grant or revoke superuser status
• Review the capability matrix to understand and communicate access rules
• Update branding settings and preview how they appear across the platform
• Maintain reference data tables used by portfolios, compliance, HR, and other areas
• Configure storefront settings including domain routing and public storefront behaviour
• See and change the organization’s accountable owner under Admin > Settings. The page shows one line — **Accountable owner: · Change** — and **Change** opens a picker of active people with sign-in accounts. Every Workroom without its own owner answers to this person. First-install setup records the owner account here; changing it requires platform-management rights and is recorded in the compliance audit trail with the previous and new owner. When nothing is recorded, the line reads **No accountable owner recorded · Set**.
• Turn monitoring (Prometheus and Grafana) on or off at /admin/settings/monitoring. The page shows whether it is really running, its memory and CPU cost, and the last change; turning it on or off needs platform-management rights and reports the outcome. If the monitoring record disagrees with what is running, the button offers to match the record to the install instead; it stays locked only when the capability records are incomplete or unreadable, and says why. Details: Turning monitoring on or off.
• Choose your own language and time zone under Admin > Settings > Language and region. Both default to the organization’s settings. English is the only language available today; administrators also see two test languages that show every screen in placeholder text, so untranslated wording and right-to-left layout problems are easy to spot.
• End one person’s access to a shared AI client under Admin > Platform Development. In Keys for automated tools, open People on a client such as Claude Code to see who is connected through it and when they last used it. Revoke this person’s access asks for a reason, disconnects only that person, and records who revoked it and why. Everyone else stays connected, and the person can reconnect by signing in again. Revoke on the row itself still disconnects everyone using that client.
• Let Build Studio pick up work on its own, and choose whether spare weekly AI allowance is used, under Admin > Platform Development on the card Let Build Studio pick up work on its own. The main switch turns on the governed backlog lane. Under Daily limit and the autopilot switches you set how many items are teed up per day and turn Use spare weekly AI allowance (the capacity drain) on or off; the drain only acts while the lane is on. Select Save to apply. Details: What Build Studio starts next.
• Let the daily acceptance sweep close finished work, or stop it, under Admin > Platform Development on the card Let the acceptance sweep close finished work. When it is on, the sweep closes only items that already pass every completion check, up to a limit per run. The card shows who allowed it, when and why, and what the last sweep closed. Allowing or stopping it asks for a reason. You see the card only if you can manage both the platform and the backlog. Details: Acceptance sweep.
• Let agents run delivery stages within budget, or stop them, under Admin > Platform Development on the card Let agents run delivery stages within budget. It is off until you allow it. When it is on, a delivery room’s author stages (the design note, reproducing a fault, implementing) go to the Software Engineer coworker, but only when the work’s portfolio has a budget set this quarter and its committed points still fit that budget. Merging, deploying and acceptance still wait for a person, and xlarge work never starts. A room that cannot run waits for a person as before, and its drive record says which condition is missing: the setting is off, no budget is set, the budget is used up, or the work has no size or portfolio. Allowing or stopping it asks for a reason, and the card shows who did it and when. You see the card only if you can manage the platform.

Graph Explorer

Open Admin > Graph Explorer to see how the platform is connected. It draws one graph over four corpora that used to be separate: the source code (files, symbols, routes, MCP tools, tests), the data model (models and their fields), the architecture ontology (EA / ArchiMate elements), and discovered infrastructure.

The top of the page is a census — how many things the platform currently knows about in each of those domains. That count is live, so it also answers “how much does this install actually understand about itself?”.

To explore, type a name, path, or key into Find a starting point — a data model such as BacklogItem, a route such as /admin, a tool such as search_code_graph. Pick a result and its neighbourhood is drawn. From there:

• Hops controls how far out from your starting point the drawing reaches.
• Clicking a node opens Details, which shows what it is, its stored properties, and how many links it has across the whole graph.
• Expand from here adds that node as a second starting point, growing the picture instead of replacing it.
• Selecting one or more domain tiles narrows both search and expansion.
• More filters exposes the individual node types and link types with their counts, for when you want to follow only, say, “Imports”.

The corpus is large enough that a view can be clipped; when that happens the page says so and names the three ways to narrow it. Nothing on this page changes any data — it is read-only.

Hive result review

Open Admin > Hive Contributions to review result-only contributions received from trusted reseller channels. The intake record is saved before any GitHub operation. It may contain a code result, verification evidence, DCO/provenance, attribution, and a review recommendation; source backlog items, priorities, estimates, discussions, workrooms, and customer-private context are rejected before persistence.

Choose Accept to approve the result and attempt delivery to the configured forge, or Reject to retain the audit without delivery. A GitHub outage leaves the accepted contribution intact and shows retry state in the ledger. Use Retry forge delivery after credentials or connectivity recover.

Scheduled work

Open Admin > Advanced > Scheduled Jobs to see everything the platform runs on a cadence — proactive AI coworker tasks and platform crons together.

The register is split into three lanes, because they are different kinds of thing:

• Coworker work — a coworker doing a job on a cadence. Each row names the coworker, the route its output lands on, and its last run.
• Platform crons — code-defined jobs. Core-locked ones protect platform integrity and are read-only.
• Spent & run-slots — one-off dispatches that already fired, and run-slot claims that were never scheduled work at all. Nothing here runs again; Retire clears it from the register.

The hourly Backlog triage drain assesses new or changed items. Once an item needs review, unchanged work is skipped on subsequent sweeps; it stays visible in triaging for you or a coworker to decide. Editing its decision inputs or returning it to triaging after another status makes it eligible again. Model, ledger and apply failures retry with backoff, up to three attempts. Each sweep starts at most 25 assessments and waits at most five minutes for model work. Provider transports keep their own cancellation limits; a late reply cannot advance an item after the assessment has timed out.

Expand Last result on the row to see assessed, advanced, review, error, unchanged/waiting, changed and unassessed counts. Idle means the sweep ran with no eligible assessment; needs-review means it produced judgments for review. Errors name their category, and a budget-limited run says work remains.

What needs attention sits at the top and counts only real problems: a job that reported an error, and a job that is overdue — its next run came and went. A job that has stopped firing no longer looks healthy.

Two labels are worth knowing:

• No reporting — the job runs, but records nothing, so its last run cannot be shown. This is normal for most crons and is not a fault.
• No kill switch — disabling this job would not stop it, because it never reads the enabled flag. The control is withheld rather than shown as a button that does nothing.

On a coworker row, the proactivity level explains the cadence: a coworker set to assertive self-drives daily, balanced weekly, and quiet produces no scheduled work at all. The level is shown next to the coworker, with the cadence it implies for that coworker’s own recurring task. A level marked inferred was derived by the platform from an existing task rather than chosen by you. Tasks that are not the coworker’s own self-task say so, because proactivity does not set their cadence.

What is going to run projects the live cadences over the next day, week, or month. Jobs that fire more often than the chart can usefully plot are listed below it instead. Click any name to filter the register to it.

Anything in the register can be run on demand with Run now — a cron dispatches immediately, a coworker task is queued for the next dispatcher tick. Edit opens on the cadence the job actually runs at, accepts either a frequency or a cron expression, and previews the next fire before you save. Coworker work cannot be scheduled more often than daily.

The Agent task dispatch job starts coworker work every five minutes, up to 20 due tasks per tick. Those tasks run side by side rather than one after another. How many run at once is the lower of two limits: the coworker’s own concurrency limit (a coworker with a limit of 2 never runs more than two of its tasks at once) and the free slots in the shared AI CLI pool (four by default). When a provider in that pool reports it is rate-limited or out of its weekly allowance, the tick runs tasks one at a time. A task that fails does not stop the rest of the tick. If a platform upgrade starts draining work part-way through a tick, tasks that have not started yet wait for the next tick after the upgrade.