--- title: "The Arkoria platform — how governed AI delivery works" description: "Five human decisions, six actions agents cannot take, independent review that blocks on criticals, proof of every merge, and an append-only record." url: https://arkoria.ai/platform --- 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. [Scope a pilot](https://arkoria.ai/contact) [The lifecycle](https://arkoria.ai/platform#lifecycle) On this page 1. [At a glance](https://arkoria.ai/platform#at-a-glance) 2. [Origin, clearance, descent](https://arkoria.ai/platform#model) 3. [The governed lifecycle](https://arkoria.ai/platform#lifecycle) 4. [Eight mechanisms](https://arkoria.ai/platform#principles) 1. [Approval comes first](https://arkoria.ai/platform#consent) 2. [Rules that hold](https://arkoria.ai/platform#enforcement) 3. [Independent review](https://arkoria.ai/platform#review) 4. [Proof and lineage](https://arkoria.ai/platform#proof) 5. [Delivery, measured](https://arkoria.ai/platform#measured) 6. [Documentation, owned by you](https://arkoria.ai/platform#docs) 7. [Governance that compounds](https://arkoria.ai/platform#compounding) 8. [Defects, found first](https://arkoria.ai/platform#defects) 5. [Where Arkoria sits](https://arkoria.ai/platform#agents) 6. [Adoption and autonomy](https://arkoria.ai/platform#adoption) 7. [The science](https://arkoria.ai/platform#science) 8. [Inside the product](https://arkoria.ai/platform#tour) ## 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](https://arkoria.ai/platform#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](https://arkoria.ai/platform#enforcement) 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](https://arkoria.ai/platform#proof) ### How Arkoria works: Agents build it. Your people approve it. Arkoria proves it. - Human decision - Gate - Proven landed #### Five human decisions 1. 01 **Request** 2. 02 **Epic charter** 3. 03 **Story spec and plan** 4. 04 **Testing and acceptance** 5. 05 **Governance 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–03 **Approved plan** 2. Enforced **Failing test first** 3. Agents **Built in a worktree** 4. Independent **Code review** 5. Enforced **Ship checks** 6. Proven **On the target branch** 7. Human · 04 **Accepted** #### 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 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. 01 · Approval comes first ### No code until a person approves the plan. People exercise their authority on the specification, before the work starts. No code is written until the plan is approved, directly or under an epic charter a person approved. - Stories are checked against INVEST before they can be approved, so size is enforced by the platform. - Once approved, a specification is locked. Changing it means a new decision, on the record. - Operators can stop, redirect or give feedback at any point, and what they report is recorded as reported. Across 22,000 developers, Faros AI finds the most leverage at the authoring stage, before code is written. [Faros AI, The Speed Trap, Sept 2026](https://www.faros.ai/blog/ai-speed-trap-takeaways) STORY-1042 · Specification Awaiting approval Billing admins can export a month of invoices as CSV 1. Given a selected month, when the export runs, then every invoice issued in it is included 2. Given any invoice, when it is written, then its amount uses the account's currency and two decimals 3. Given more than 10,000 rows, when a billing admin exports them, then the file is streamed, not buffered - Independent - Negotiable - Valuable - Estimable - Small - Testable 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 call git push, asked for by an operator while the story was in progress 2. DENIED Blocked: missing required stamps: review_ship — nothing reaches a branch before ship readiness, whoever asks 3. recorded gate-fail · critical · on the story's record 4. gates review and tests completed · ship readiness stamped 5. PASSED the same push, seconds later Modelled on a real session; identifiers changed. Runtime enforcement 1. DENIED Write production code without a story — every change descends from an approved origin 2. DENIED Write code before a failing test — tests come first, and must fail first 3. DENIED Commit on a stale review — the review must match the code being committed 4. DENIED Push without ship review — shipping is a gate, not a default 5. DENIED Run database commands in a worktree — agents stay inside their isolation 6. DENIED Change story state outside the API — only 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](https://survey.stackoverflow.co/2025/ai/) Gate Keeper · code review · STORY-1042 1. against project rules · domain rules · spec v3 2. findings critical 1 · major 0 · minor 2 3. BLOCKED returned to implementation — unbounded query in export path (critical) 4. re-review critical 0 · major 0 · minor 2 5. CLEARED gate 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](https://www.prnewswire.com/news-releases/spacelift-survey-93-of-organizations-have-experienced-ai-caused-infrastructure-incidents-as-vibe-coding-spreads-to-infrastructure-302809032.html) · vendor research · June 2026 **Lineage · STORY-1042** append-only 1. origin specification approved human consent 2. clearance plan reviewed · 0 critical independent 3. clearance criteria 3/3 verified observed 4. review 1 critical → blocked independent 5. review 0 critical → cleared independent 6. ship definition of done verified observed 7. descent a3f9c1e is ancestor of main observed 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](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) · [update, Feb 2026](https://metr.org/blog/2026-02-24-uplift-update/) - **Throughput** stories delivered per period - **Lead time** request to done - **Drift rate** weighted by how deep defects got **Five more, with definitions** - **Cycle time** work started to done - **Touch time** active agent time, from the agent's periodic check-ins - **Work in progress** open stories per agent, and across all agents - **Token cost** at API prices and on subscriptions - **Time to merge** pull 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 · Dossier Markdown · 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](https://arkoria.ai/platform#lifecycle)). Engineering canon carries over unchanged; stack and domain rules are reviewed for each new project. 1. **Record** gate verdicts, drift, errors 2. **Retrospective** run over recent stories 3. **Proposal** recurring problems ranked, a fix drafted 4. **Approval** a person edits and accepts 5. **Rule set** enforced 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](https://arkoria.ai/why-arkoria). - **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 agent **Claude Code · OpenAI Codex (soon)** writes the code, in its own worktree 2. Arkoria **Specs, gates, review, record** decides what may move forward, and proves what landed 3. Your repository and CI **Unchanged** never 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** | Question | Arkoria Hub | Coding agent | Independent reviewer | | --- | --- | --- | --- | | Runs on | Arkoria's cloud (Google Cloud, US region) | Claude Code, one git worktree per agent, on your infrastructure or ours, confirmed in writing for each account | A Claude Code subagent the coding agent starts, with a fresh context, on the same machine | | Inference | None: the hub makes no model calls | The 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 | | Reads | Your repository through GitHub's API (no clones), and what agents report | Its worktree, your governance rules, the story's record | The spec, the staged diff, your governance rules, the story's record | | On GitHub | Reads; opens and merges pull requests on projects that use pull-request review | Commits and pushes with the operator's GitHub credential | Nothing of its own | | Sends to the model provider | Nothing | Prompts and tool output, under the account's terms | The same as the coding agent | | Stores | Stories, specs, verdicts with their findings, gate stamps, execution logs, encrypted project secrets, token counts (never prompt content) | Commits and its own session transcripts | Nothing: 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”](https://xp123.com/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](https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html), 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](https://martinfowler.com/articles/exploring-gen-ai/refactoring-economic-benefit.html), 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](https://dora.dev/research/2025/dora-report/) - Proof by ancestry Done requires git's own ancestry check against the target branch. [git merge-base --is-ancestor](https://git-scm.com/docs/git-merge-base) ## 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. [Scope a pilot](https://arkoria.ai/contact) [See pricing](https://arkoria.ai/pricing) - **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