Policies, operations and the factory map

Factory policy sets the outer limits for work: token budgets per card and day, run caps, concurrency, repository writes, tool use, external runtimes and handoffs. Station and worker permissions can narrow those grants.

Autonomy

The available levels range from observation and suggestions through approval-based execution to broader execution. The lowest effective level across the factory, station and worker governs a run. An outcome can reduce autonomy; a person raises it.

Changing an instruction prompt does not grant permission. Tools are checked against the effective policy and available grants.

Shared capacity pools

Open Factory settings → Capacity pools as a workspace administrator. Create a named pool with 1–64 simultaneous runs, then assign each participating factory to that pool from its settings. Pools belong to one workspace; a factory can belong to one pool. Each pool shows its factories, reserved slots and queued work. Use Refresh capacity for current counts.

Running and external jobs reserve slots across the pool’s factories. Database transactions serialize competing scheduler claims. Factory concurrency limits, budgets, holds and permissions still apply, and the server’s own execution slots can impose a lower throughput. An external reservation represents tracked work, not a guarantee that a remote process has stopped when its job ends.

Reducing a pool’s limit lets current work finish and holds new work until capacity is available. Detach all factories before removing an empty pool. Changes do not interrupt or checkpoint running jobs.

The dispatcher reads queued work across factories in effective-priority order, using bounded pages. Critical, high, medium and low cards start at 12, 8, 4 and 0 points; waiting adds one point per hour, so old work can overtake newly arrived urgent work. Human completions and escalations start at 100 points. Ties use the earlier run ID. Pauses, budgets and capacity limits still hold work; the dispatcher continues past held jobs to find eligible work.

Each dispatch pass considers jobs present when it began. New arrivals and concurrent priority edits are considered on the next tick. Running work is not preempted or checkpointed.

Capacity forecasts

Each pool includes a read-only forecast based on its factories’ finished runs from the last seven days. At least ten runs with valid recorded start and finish times are required. Missing history is shown explicitly. The calculation excludes queue wait and samples up to the latest 2,000 finished runs; failed and cancelled work can contribute when it has valid timings. Durations longer than seven days and invalid timestamps are excluded. History follows the factories currently assigned to the pool. The panel reports the usable sample count and any sampling limit.

Compare the current slot count with half or double that capacity, bounded to 1–64 slots. The scenarios estimate time to drain all currently queued and active runs, using observed mean or 90th-percentile duration. They assume every active run still needs a full run duration, all configured slots can work, and no new work arrives. These are planning scenarios, not a confidence interval or a promised completion time. Factory holds, human approvals, worker/runtime constraints and changes in task mix are not modeled and can make completion slower.

Forecasts neither reserve slots nor change scheduling. Use Edit on the pool to apply a capacity decision deliberately, and Refresh capacity to recalculate from current data.

Operations center

Inspect running, waiting, blocked and external work together. Alerts help identify stalled runs, repeated loops, exhausted budgets and other health conditions. Follow an alert to its card and run trail before retrying.

Pause a factory or runtime to stop new work from starting. Emergency stop and revocation controls are available for broader intervention. Inspect external effects before retrying an interrupted run: stopping local execution does not undo work already sent to another system.

Read the map

Choose Map inside a workflow. The breadcrumb takes you up to its factory, workspace or organization. Select a factory in the wider view to open its workflow map, then choose a workflow and a card to inspect its recorded path and runs. Moving between factories or workflows keeps you in Map view. Wider views list only factories you can access. Use Next page and Previous page to browse large organizations and workspaces. Counts describe the current page; access is checked again on every request.

The current map shows workflow paths, branches, gates and operational overlays for waiting work, failures and utilization. Use it to locate congestion, then inspect the underlying runs.

Use the map’s time controls to replay recorded workflow history within the last 30 days, either at a selected moment or as range playback. Replay combines recorded factory versions, station visits and run spans; removed stations are labeled. Before recorded history or when a matching version is unavailable, the map reports its limits instead of inventing history. Choose Now to return to live work.

Shared account boundaries

SSO manages organizations, membership and organization model credentials. CodeBook uses those identities and settings; it does not create an independent organization or provider-key system. See model providers.