Governance

People and roles

Ark does the execution; people own the judgment. This page says who holds which decision, what an operator is expected to do, and which agent runs on which model. The per-lane owners and operators are on the Lanes page.

Who holds which decision

Role Who What they decide
Agents & Tooling team Slack @agents-and-tooling, led by Alex Martin Owns the kernel, the board, and the rules. Kernel and capability work runs on INT-0001. Ark belongs to the team, not to one person: when nobody in particular is running it, Ark speaks for the team.
Board owner Ragnar Keeps the board to programmes and genuinely singular outcomes. Signs off any granularity exception in the run log before os run, and ratifies programme approver sets.
Lane owner Named per lane on the Lanes page Owns the lane's gates and its sprint budget envelope, with spend authority inside it. For an experiment lane, decides how much of the work rides Ark.
Lane operator Named per lane; "in training" until fluent Runs Ark on the lane's intents. Operators keep their normal team role; lane work is a contribution model, not a reorg.
Intent owner The owner field on each intent Accountable for the outcome end to end: aligns the intent, accepts the verdict, and keeps it moving. Operating an intent for a day does not change its owner.
Approver Per programme, in automations/approvers.yaml Signs Org & data writes: one Kaptio approver and one customer approver react on the Kai-posted plan. An unconfirmed approver set cannot authorise execution.
Merging reviewer A named person per MR Reviews and merges application-code MRs, which Ark opens as Drafts. Config-only repos on the auto-merge allowlist are the one exception.
Requestor Anyone named in a lane's requestor list Brings work into a lane. In an official lane the requestor path is open to everyone the lane names.

The intent owner's week

Each owner carries about three active intents at a time, and the Monday intent-board review goes through them. Between reviews:

  • Read os status (no id) for every active intent's freshness, stuck signal, unreconciled review backlog, and charged cost against estimate.
  • Reconcile branches a reviewer sent back with os integrate <id>, never by a silent merge.
  • Escalate a stuck intent in its Slack thread, naming the reason and who has to act. A block recorded only in the run log is invisible to the people waiting on it.
  • Report cost from os status <id> or os ledger <id>.
  • When a person finishes a task outside Ark, record it with os task done <id> <task> --note "..." so the graph, the run log, and the ledger all show it.

Operating a session

An operator is whoever is driving Ark from Cursor right now. The rules that keep two operators from colliding:

  • Run from main, pulled fresh. Intent state written anywhere else is invisible to the sweep loops and cloud builders, and the kernel refuses to write it from a feature branch.
  • Say in the intent's Slack thread that you are on it, and claim the intent with a pushed run-log entry before a run. os run holds a lock per intent on one machine only; across machines, the claim is the lock.
  • Hand over with a run-log entry that says what shipped, what remains, where the branch or MR is, and a concrete next step. Push it the same session.
  • Install the Cursor prompt hook with os session install-hook and publish your rows with os session publish, so interactive spend lands on the intent you worked instead of on the unattributed list. os session status shows your coverage.
  • Leave CURSOR_API_KEY out of .env. The kernel fetches the ark service-account key with your GITLAB_TOKEN; a personal key bills its owner and warns on every run.

Who Ark speaks for

Ark posts to Slack as the Kai bot, and every post names who it speaks for:

  • From an interactive session, the post starts On behalf of @person, naming whoever is running it.
  • A Slack-triggered sweep post opens with the broom-emoji Ark marker instead; the person who asked is already in the thread.
  • When nobody is identifiable (scheduled automations, the trunk watchdog), the post names the @agents-and-tooling team tag. Ark reporting on itself posts to #devops-support first.

The roster, team tag, and default channels live in automations/ark-identity.yaml; os identity prints the exact attribution line. Ark never defaults to one person's name.

Agent roles and models

Roles, not personalities. Every role runs as a Cursor agent. Since 28 September 2026 the defaults are one model, Claude Opus 5.5, with effort setting the tier: extra-high for the two roles that run least and decide most, high for the rest.

Role Job Default model
Lead Drafts, decomposes the intent into a task graph, and validates the result. claude-opus-5-5-xhigh
Reviewer Independent review from a clean context. A context-aware and an independent reviewer both run by default. claude-opus-5-5-xhigh
Builder Executes one task in an isolated git worktree and opens the MR. Never merges. claude-opus-5-5-high
Verifier Read-only QA, and measurement of live signal after release. claude-opus-5-5-high
Probe Read-only investigation against live systems, to ground the brief in evidence. claude-opus-5-5-high
UAT Runs persona journeys: boots the app, screenshots it, files findings. the builder model
  • A builder that stalls or produces no changes gets one automatic retry on gpt-5.3-codex-fast.
  • An intent's roles.<role>.model wins over the defaults for that intent. New intents get Opus 5.5 pins from the templates. Existing intents keep their pins until the person working on one changes them; nobody rewrites them across the board.
  • Operators set the defaults for their own runs with OS_MODEL_*. The deployed daemon on SF Devs sets its own through Terraform; intent pins still win there.
  • Slack-triggered sweeps choose their own models: execution defaults to Kimi K3 unless the intent pins a builder model, planning uses the intent's lead model, and verdict reads, the read-only fast lane, and the retry after a failed execution use Claude Sonnet 5.
  • Claude Fable 5.1 is not a default. It costs 2.5x Opus 5.5 on input and output and needs a data-retention approval, so an owner pins it on an intent only with a reason.