The platform

Best practice, enforced as infrastructure.

One workspace where your people and your agents pull from the same board. People make five decisions, agents do the building, and every story passes automatic checks and an independent review before it ships, with each step recorded.

At a glance

  1. 01

    When an agent says the work is done, who checks?

    A reviewer with a fresh context, the Gate Keeper, checks every specification and every change against the written spec and your rules, and its critical findings stop the work. Independent review

  2. 02

    What has to be true before a change reaches your customers?

    A person approved the plan, a failing test came first, the review passed on the exact diff, and the full test suite passed on the exact tree that ships. Rules that hold

  3. 03

    When an auditor, a client or your board asks what happened, what do you hand them?

    The story's record: who approved what, every verdict, and the proof the commit landed, in order and unedited. Proof and lineage

How Arkoria works People make five decisions: the request, the epic charter, the story specification and plan, testing and acceptance, and governance changes. Every agent works under your rules, through one governed board with an append-only record. Each story moves from an approved plan through a failing test, implementation in a worktree, independent code review, ship checks, and proof that the commit is on the target branch, before people test and accept it. Agents cannot skip six actions, and delivery is measured from the record. How Arkoria works Agents build it. Your people approve it. Arkoria proves it. Human decision Gate Proven landed Five human decisions 01 02 03 04 05 Request Epic charter Story spec and plan Testing and acceptance Governance change Your rules Engineering canon Your stack and conventions Your domain every agent Arkoria hub One governed board Stories and their state Gate verdicts and evidence Append-only record of every step fresh context Independent review Spec and plan Code Epic Onboarding Critical findings block the work. recorded Every story 01–03 04 Approved plan Failing test first Built in a worktree Code review Ship checks On the target branch Accepted human enforced agents independent enforced proven human Six things an agent cannot do Write code without a story · Write code before a failing test · Commit on a stale review Push without ship review · Run database commands in a worktree · Change story state outside the API Measured from the record Throughput · cycle time · drift rate 05 Retrospectives propose rule fixes; a person approves.

How Arkoria works

Agents build it. Your people approve it. Arkoria proves it.

  • Human decision
  • Gate
  • Proven landed

Five human decisions

  1. 01Request
  2. 02Epic charter
  3. 03Story spec and plan
  4. 04Testing and acceptance
  5. 05Governance change

Your rules

  • Engineering canon
  • Your stack and conventions
  • Your domain

Your rules apply to every agent, through the hub.

Arkoria hub

One governed board

  • Stories and their state
  • Gate verdicts and evidence
  • Append-only record of every step

The reviewer reads in a fresh context, apart from the builder.

Independent review

  • Spec and plan
  • Code
  • Epic
  • Onboarding

Critical findings block the work.

Every step of every story is recorded on the board.

Every story

  1. Human · 01–03Approved plan
  2. EnforcedFailing test first
  3. AgentsBuilt in a worktree
  4. IndependentCode review
  5. EnforcedShip checks
  6. ProvenOn the target branch
  7. Human · 04Accepted

Six things an agent cannot do

  • Write code without a story
  • Write code before a failing test
  • Commit on a stale review
  • Push without ship review
  • Run database commands in a worktree
  • Change story state outside the API

Measured from the record

Throughput · cycle time · drift rate

05 Retrospectives propose rule fixes; a person approves.

How work moves through Arkoria: people make five decisions, every agent works under your rules through one governed board, independent review blocks critical findings, and a story is done only when its commit is proven on the target branch.
The Arkoria mark: an origin node, two descending branches, two hollow gate nodes on the crossbar, and two landed commits at the feet. The origin is a person's approval; the gates are the checks a change must clear; the landed commits are the proof it reached the target branch.

The model

Origin, clearance, descent.

Every unit of work is a small graph. It starts at an origin a person approved, passes gates it cannot skip, and ends as a commit that must prove it descends from that same origin. That is the first principle the platform is built on, and our mark draws it.

Origin
The approved plan: a story specification, or the epic charter it belongs to. Nothing downstream is legitimate unless it traces back here.
Clearance
A gate passed on evidence: a failing test before code, a current independent review, ship checks.
Descent proof
Done requires proof that the commit is an ancestor of the target branch. An agent's report that it merged doesn't count.
Lineage
The append-only record of every transition, who or what authorized it, and on what evidence.

The governed lifecycle

People make five decisions, and gates check everything in between.

People decide what gets built, and whether it was built right. From approval to acceptance, agents work on their own, inside gates they cannot skip, with every step written to the record.

Agents work on their own, and every step is recorded

  1. Human

    Request

    A person says what is needed.

  2. Human

    Epic charter

    Scope and intent are approved before any story exists.

  3. Human

    Story spec and plan

    Small and testable, or it is rejected. No code until the plan is approved.

  4. Enforced

    Failing test first

    A test must exist, and fail, before any code is written.

  5. Agents

    Implementation

    Agents build in isolated worktrees, pulling from one governed board.

  6. Independent

    Independent review

    A fresh-context review against your rules. Critical findings block.

  7. Platform

    Ship, with proof it landed

    Ship checks pass. Done only when the commit is proven on the target branch.

  8. Human

    Testing and acceptance

    You test and accept the outcome.

  • Human consent
  • Gate: enforced, or independently reviewed
  • Proven landed

The fifth human decision, governance change, closes the loop: a retrospective proposes fixes to the rules, and a person edits and approves them before they take effect.

From principle to practice

Eight mechanisms carry the principles out, and each leaves a record.

02 · Rules that hold

Six things an agent cannot do.

An instruction in a prompt is a suggestion, and an agent under pressure will route around it. Arkoria enforces practice at runtime: the tool call is denied before it executes, and the denial is recorded.

Agents can't rewrite their own rules, either: governance changes only happen inside a governed story.

  • Hooks run before every file write, shell command, subagent launch and git commit or push. Reads are not gated.
  • A gate that needs the hub refuses when the hub can't answer, and says the cause is infrastructure.
  • One emergency release covers the core gates: off by default, announced in the session, and recorded as a critical event.
One denial, step by step
Push gate · STORY-1042
  1. tool callgit push, asked for by an operator while the story was in progress
  2. DENIEDBlocked: missing required stamps: review_shipnothing reaches a branch before ship readiness, whoever asks
  3. recordedgate-fail · critical · on the story's record
  4. gatesreview and tests completed · ship readiness stamped
  5. PASSEDthe same push, seconds later

Modelled on a real session; identifiers changed.

Runtime enforcement
  1. DENIEDWrite production code without a storyevery change descends from an approved origin
  2. DENIEDWrite code before a failing testtests come first, and must fail first
  3. DENIEDCommit on a stale reviewthe review must match the code being committed
  4. DENIEDPush without ship reviewshipping is a gate, not a default
  5. DENIEDRun database commands in a worktreeagents stay inside their isolation
  6. DENIEDChange story state outside the APIonly the platform moves work forward

03 · Independent review

The builder never grades its own work.

Before work moves forward, a fresh-context reviewer, the Gate Keeper, evaluates it against your rules and the approved specification. It judges the work itself. Progress is unlocked by its verdict.

  • Specifications and plans, code, whole epics and onboarding each have their own review.
  • Critical findings block while the work is still open, before anything ships.
  • Every verdict is appended to the log with the reviewer named.
When a story can't clear
  • There is no fixed number of retries. A FAIL sends the agent back to fix the critical findings, and the re-review checks the failing categories again.
  • If two rounds in a row fail the same way with no progress, the agent shelves the story and writes down why; the operator sees "Replan needed" and the reason.
  • The operator sees every attempt with its findings, and is alerted when an agent is stuck or waiting for input. They can send the story back, release, reassign, block or cancel it, message the agent, or edit the spec, which forces a replan. A customer who approves specs can request changes.
  • There is no "pass anyway". A FAIL can't be waived and the verdict history can only be added to; overruling a FAIL means changing the work: re-scope it, split it or cancel it.
  • No per-story token cap is enforced; spend is measured per story and per phase.

46% of developers distrust the accuracy of AI tools' output; 33% trust it. Stack Overflow 2025 Developer Survey

Gate Keeper · code review · STORY-1042
  1. againstproject rules · domain rules · spec v3
  2. findingscritical 1 · major 0 · minor 2
  3. BLOCKEDreturned to implementationunbounded query in export path (critical)
  4. re-reviewcritical 0 · major 0 · minor 2
  5. CLEAREDgate passed · verdict recorded with provenance

04 · Proof and lineage

Compliance you can prove.

For every change, the record shows who said yes, what was checked and who checked it, in the order it happened, and nothing in it can be edited afterwards. Nothing reaches Done on an agent's word: before a story can close, the platform checks that the commit is an ancestor of the target branch.

  • Approvals come in three authority classes, human consent, observed evidence and independent review, required in order.
  • The explanation of what happened is a by-product of the work; nobody writes a report after the fact.
  • What an operator reports is logged as reported, never as verified. Credentials are redacted at every surface the record publishes to.

86% of 406 North American infrastructure leaders were confident they could govern AI; 30% had a formal policy. Spacelift, 2026 State of Infrastructure Automation · vendor research · June 2026

Lineage · STORY-1042append-only
  1. clearanceplan reviewed · 0 criticalindependent
  2. clearancecriteria 3/3 verifiedobserved
  3. review1 critical → blockedindependent
  4. review0 critical → clearedindependent
  5. shipdefinition of done verifiedobserved
  6. descenta3f9c1e is ancestor of mainobserved

The record ends at proof. Acceptance happens after it, by your people, as the lifecycle shows.

05 · Delivery, measured

Quality gets a number.

Delivery metrics are computed from the record, snapshotted daily, each with its definition stated. Drift is scored in four kinds, friction, plan drift, escaped bugs and regressions, each weighted by how late it was caught, and summed into a drift rate across all agents.

  • Throughput, cycle time, drift and token cost sit next to the proof behind them.
  • Delivery plans use the same data to schedule milestones across agents and project the finish at the current pace.

In METR's 2025 randomized trial, experienced developers believed AI had sped them up by about 20%; measured, their tasks took 19% longer. METR's 2026 follow-up suggests tools have since improved; self-reported productivity still isn't proof. METR, July 2025 · update, Feb 2026

  • Throughputstories delivered per period
  • Lead timerequest to done
  • Drift rateweighted by how deep defects got
Five more, with definitions
  • Cycle timework started to done
  • Touch timeactive agent time, from the agent's periodic check-ins
  • Work in progressopen stories per agent, and across all agents
  • Token costat API prices and on subscriptions
  • Time to mergepull request opened to merged

06 · Documentation that stays current

The documentation is updated with every story, and it is yours.

Every story carries its own dossier, exported as Markdown or PDF. The reviewer checks that docs and API contracts changed with the logic. Your code, backlog and documentation are yours.

  • Only the documents a change touches are updated, so nothing bloats.
  • Generated documentation has to be current before a commit is allowed.
STORY-1042 · DossierMarkdown · PDF

Billing admins can export a month of invoices as CSV

  1. Specification goal, user journey, edge cases, risks, security, test plan
  2. Acceptance criteria Given/When/Then, each with its evidence
  3. Review verdicts spec, plan and code, with their findings
  4. Transition log every state change and what authorized it
  5. Commit a3f9c1e, confirmed on main

07 · Governance that compounds

Every engagement starts further ahead.

An operator runs a retrospective over recent stories; the platform mines the record, ranks the recurring problems and proposes a fix to the rules, which a person edits and approves (the fifth human decision). Engineering canon carries over unchanged; stack and domain rules are reviewed for each new project.

  1. Recordgate verdicts, drift, errors
  2. Retrospectiverun over recent stories
  3. Proposalrecurring problems ranked, a fix drafted
  4. Approvala person edits and accepts
  5. Rule setenforced from the next story

08 · The platform hunts its own defects

The platform finds its own defects, and never bills for them.

The platform goes looking for defects, regressions and drift. It opens its own bug stories, scores each by how far it got through the gates, and feeds the result back into policy. Bug stories are never billable. Why we price this way.

  • Opened automatically

    A failed epic review opens bug stories on its own. Nobody has to remember to file a ticket.

  • Scored by depth

    A defect caught at review weighs less than one that reached main.

Where Arkoria sits

Arkoria governs agents. It isn't one.

Regardless of which agent writes the code, Arkoria's hub decides which work may proceed and confirms each commit reached the target branch.

  1. Your coding agentClaude Code · OpenAI Codex (soon)writes the code, in its own worktree
  2. ArkoriaSpecs, gates, review, recorddecides what may move forward, and proves what landed
  3. Your repository and CIUnchangednever modified by takeover; governance files are added alongside

An agent qualifies once it implements five primitives

  • System prompt
  • Skills
  • Rules
  • Hooks
  • Subagents

Where it runs, and what it touches

What the Arkoria Hub, the coding agent and the independent reviewer each run on, read, send and store
QuestionArkoria HubCoding agentIndependent reviewer
Runs onArkoria's cloud (Google Cloud, US region)Claude Code, one git worktree per agent, on your infrastructure or ours, confirmed in writing for each accountA Claude Code subagent the coding agent starts, with a fresh context, on the same machine
InferenceNone: the hub makes no model callsThe provider account set for the project: Arkoria's (Managed Delivery, Managed Inference) or yours (Bring Your Own Inference)The same account as the coding agent
ReadsYour repository through GitHub's API (no clones), and what agents reportIts worktree, your governance rules, the story's recordThe spec, the staged diff, your governance rules, the story's record
On GitHubReads; opens and merges pull requests on projects that use pull-request reviewCommits and pushes with the operator's GitHub credentialNothing of its own
Sends to the model providerNothingPrompts and tool output, under the account's termsThe same as the coding agent
StoresStories, specs, verdicts with their findings, gate stamps, execution logs, encrypted project secrets, token counts (never prompt content)Commits and its own session transcriptsNothing: its verdict goes to the hub

The reviewer's independence is its context: it starts clean, reviews against the written spec, and returns a finding for every check that applies. It runs on the coding agent's machine, with the coding agent's credentials.

Where the pull request and the merge sit

  1. 01 · Before commit and push

    Hooks ask the hub before every commit and push, and refuse unless the story holds current evidence: spec review, code review of the exact diff, tests green on the exact tree, ship readiness. Any later edit voids it.

  2. 02 · On the hub

    A story can't reach shipping or done without those stamps, and done needs the commit confirmed on the target branch, through GitHub.

  3. 03 · Into main

    Straight to main, the gated push is the landing. Under pull-request review, each epic or standalone story becomes one pull request that a person approves.

  4. 04 · Your branch protection

    Arkoria neither configures nor bypasses it. Under pull-request review, main can be fully protected; a merge GitHub refuses goes back for rework.

Who merges, by project setting
  • Direct to main (the default): a tech lead approves each epic's plan once; stories inside it are approved by the reviewer under that consent, standalone stories one by one. The gated push to main is the landing; nobody merges.
  • Customer spec approval, added to either path: a named, signed-in person approves every spec before any agent may build it, and the platform verifies it.
  • Pull-request review: each story pushes one squashed commit to a reference branch; when the epic or standalone story is done, the platform opens one pull request to main. A person approves it on GitHub, and the person or the platform merges.
  • Acceptance checks, added after delivery: a person accepts or rejects each check, and a rejection files a bug.

Not built yet: a required status check on GitHub's side, which would make GitHub itself refuse a push made outside the governed harness.

Adoption

Bring the repository you already have.

Takeover never modifies your source, CI, database or dependencies. Arkoria adds its governance files alongside them, detects the stack, drafts the architecture documentation, and puts the onboarding itself through review.

  • Brownfield

    Take over what you have

    Onboarding an existing repository (the product calls it a takeover) brings it under governance one reviewed step at a time, and never modifies your source, CI, database or dependencies.

  • Greenfield

    Start governed from day one

    New projects begin with the rules, templates and gates in place from the first story.

  • Reviewed

    Onboarding clears a gate too

    Onboarding has its own review, and must pass it before the first story is pulled. No exceptions for the setup.

Autonomy, in four levels

Every level is enforced; start where you're comfortable.

Each level below maps to gates that exist today.

  1. Level 01

    Observe

    Agents read and report; nothing is written. A zero-commitment first step that still produces a real artifact.

  2. Level 02

    Advise

    Agents draft the specification and the plan; the independent reviewer audits both before anything is built.

  3. Level 03

    Act with approval

    A person's approval of the spec unlocks the code-writing tools. Epic charters and pull-request review stay human.

  4. Level 04

    Act autonomously

    Inside an approved story only: failing test, code, docs, independent review, ship. All on the record.

The science

Built on practices engineering already trusts.

Arkoria comes out of years of research into multi-agent governance. What it enforces is not new. It is the practice the discipline already validated, made to hold when most of the work is done by agents.

  • Small, independent, testable stories The specification gate rejects any story that fails INVEST. DORA's 2025 AI Capabilities Model lists working in small batches among the practices that amplify AI's benefits. Bill Wake, “INVEST in Good Stories, and SMART Tasks”, 2003
  • Tests against approved criteria Tests trace to acceptance criteria a person approved, must fail before code exists, and are checked by a reviewer that didn't write them. Test-first left inside an agent's own loop adds cost without clear quality gains; the value is in human-approved expectations checked independently. Kent Beck, Test-Driven Development: By Example, 2002 · Birgitta Böckeler, martinfowler.com, 2026
  • Independent inspection A fresh-context reviewer checks the work against your rules; critical findings block. M. E. Fagan, IBM Systems Journal, 1976
  • Code kept cheap to change Docs, specs and contracts change in the same commit as the logic. In one published experiment, refactoring an agent-written codebase cut the input tokens an agent needed for the same change by 83%. Giles Edwards-Alexander, martinfowler.com, 2026
  • Measured delivery Lead time, cycle time, throughput and drift come from the record, daily and with definitions. Forsgren, Humble & Kim, Accelerate, 2018 · DORA, 2025
  • Proof by ancestry Done requires git's own ancestry check against the target branch. git merge-base --is-ancestor

Inside the product

The workspace, as your team sees it.

Lanes
The governed board. People and agents pull from the same lanes, and every card shows which gates it has cleared.
Story · Overview
Acceptance criteria in Given/When/Then, and the approval that unlocks the work.
Story · Execution
Verdicts at each gate, the compliance checklist and the drift review.
Story · Transition log
Every state change, what authorized it, and on what evidence.
Intel · Quality
Drift, time metrics and throughput, computed from the record rather than reported.
Delivery plan
Milestones scheduled across agents, with the critical path, a defect budget and the projected finish at the current pace.

Start small

Start with the project you keep putting off.

We'll scope a first piece of it as a Governed Pilot, built and shipped on your own codebase at a fixed price.

Duration
4 weeks from requirements
Price
$3,500 fixed, half on signature and half on delivery
Delivered
One epic of up to 10 stories, shipped with every approval and review recorded
You keep
The code, the documentation, the planning report, a backlog of small, testable stories and a governance report
Scope
One workload, up to five users; cutover, migration and certification out of scope
If you stop
Nothing to unwind, because your source, CI, database and dependencies were never modified