Skip to main content

​
Account and project structure

An organization is a team and billing boundary in Kiwi. It contains one or more projects. Project membership is separate from organization membership, so an organization member does not automatically see every project. Each project has its own Admin, Contributor, and Reviewer roles. Use the organization selector and project areas in the hosted app.

​
Workflow and run

A workflow definition declares an ordered set of steps, the actors and project roles that may perform them, the outputs each step must submit, and its acceptance rule. Publishing creates an immutable revision. A run is one request tracked against one published workflow revision. It pins that revision and records its responsible person, designated decision makers, current state, candidate, plan revision, step graph, check results, and event history. Publishing another workflow revision does not change a run already in progress. An attempt is one try at one step. A run keeps previous attempts when work is resumed or sent for rework. Each attempt records its state, performer and session when applicable, submitted outputs, and whether its evidence has been superseded.

​
Actors and authority

Kiwi records a report as human-attested, agent-reported, or checker-reported. It checks the signed-in identity, project membership, role, step assignment, current attempt, and gate for each action. Declared harness and session values help identify an agent session; they are not proof of remote execution. The default Development workflow has six ordered steps:
  1. Plan — the designated owner decides whether to accept the submitted scope, criteria, and required checks in the app.
  2. Implement — an eligible person or agent reports a candidate reference, summary, and handoff notes.
  3. Verify — authorized humans or checker credentials report each planned check against the current candidate.
  4. Independent review — a different performer and a different session review that candidate and submit a verdict and findings.
  5. Human acceptance — the designated reviewer makes the decision in the app.
  6. Handoff — an eligible performer records the delivery reference, summary, and remaining limitations.
A report can make the next step ready, but Kiwi does not start that work automatically. Failed checks and failed or blocked review prevent completion. See Workflows and gates for the accepted schema and Retries and recovery for blockers, handoffs, rework, and cancellation.

​
Check definitions and results

The accepted Plan defines each required check with an id, name, expectedResult, permittedOrigins, and authorizedReporterIds. The id is the stable name used by CI and the check API. A checker must be allowed that ID in its credential and its reporterId must be assigned in the accepted Plan. A human check reporter must be an eligible project Admin or Reviewer and be listed as an authorized reporter. Each recorded check binds to the current Verify attempt, accepted plan revision, implementation attempt, and candidate reference. Verify’s check_results output is synthesized from those reports; an agent cannot submit a made-up list of check results. For first-run steps and exact output fields, continue to the hosted quickstart. For human, MCP, and checker authority boundaries, see Manual participation, Remote MCP, and CI reporting.