Kaptio Ark Intent-to-outcome orchestrator

Work classification

Lanes

Every intent carries a lane. A lane is a governed workflow, not a priority label: it names who owns the gates, what evidence is mandatory, what may be shared, and where the work ships. Lanes are executable policy in the kernel, so os run reads them directly and no stage hardcodes per-lane behaviour.

There are twelve: seven official and five experiments. Official means Ark is the default for all work in the lane, for every customer, and the harness gates are enforced. Experiment means a pilot is running and the lane owner decides how much of the work rides Ark until the lane graduates.

The old process-weight tiers (fix, probe, lite, full, gtm, initiation, and the numeric 0/1/2) were retired on 17 August 2026. They described how heavy the harness was, not whose work it was. fix and gtm still read as patch and concepts; any other retired value must be re-triaged by a person.

Official lanes (C18)

patch Patch

Customer-specific fixes on that customer's release line (churn prevention). One intent per customer patch, and each patch is 100% Ark or 0% Ark: no mixing Ark and non-Ark work on one patch.

Owner: Magda
Operators: Ragnar, Alex, Tony (in training)
Requested by: Executive team, account management, support leadership
Ships to: A named customer release or patch build, with SIT evidence

Gates: Customer, data shape, and release line declared before work starts; repro and TDD through the defect harness; no new metadata components, only changes to existing ones (the patch-meta gate refuses the MR otherwise, unless a person waives it); SIT handover, code review, then QA on the customer's data shape.

Evidence and sharing: Code-rigor gates; delivery ticket in ST or KT; the share pack is the MR link. No Outcome Report per bug: defects roll up into the patch line's release evidence.

sweep Sweep

A standing unblock loop over a project channel: configuration and customization only, the engineer verifies their own fix, and the target is under five hours to unblock.

Owner: Alex
Operators: Ragnar, Alex, Hrvoje
Requested by: Implementation teams and customer delivery channels
Ships to: The customer programme unblocked; anything too big re-triaged into its own lane

Gates: Collective-brain pickup: whoever is free takes the ask. Carry-over discipline: every item is done, or dropped with a reason. Slack-triggered sweeps post a read-only plan and execute only after the requester approves it.

Evidence and sharing: Customer-facing packs go through the publish gate (os pack). Quiet cycles are logged as quiet, so the run log shows nothing was dropped.

regression Regression Suite

Per-customer agentic test packs, mandatory for active go-live projects.

Owner: Ragnar
Operators: Ragnar, Alex, Magda (in training)
Requested by: QA leadership and go-live programmes
Ships to: A per-customer Playwright and agentic test portfolio

Gates: Every intent produces test artifacts; QA reviews them critically and admits the good ones to the suite; per-customer release watches re-run the suite.

Evidence and sharing: The share pack is a finding summary.

tech_health Tech Health

Reliability, performance, tech debt, and internal platform tooling. Intents here often run for weeks.

Owner: Claudia
Operators: Ragnar, Alex, Claudia (in training)
Requested by: Engineering leadership, platform and services
Ships to: Mainline or infrastructure, rolled out in sequence

Gates: Probe evidence before decomposition; a parity harness against production traffic; a domain expert signs off before an infrastructure change executes (Terraform stays blocked until signed).

Evidence and sharing: Code-rigor gates; delivery ticket in ST or KT; share pack: summary, MRs, and composites.

golive_gap Product Gaps & Enhancements

Minor product gaps and enhancements: small, code-reviewable changes, whether a go-live date drives them or not. One intent per gap set. Re-scoped from go-live gaps only at the 31 August operator workshop.

Owner: Ragnar and the product leads
Operators: Ragnar, Eyþór (in training)
Requested by: Project delivery, programme leads, product leads
Ships to: Mainline or patch, with the slot agreed at approval (patch only when no new metadata is needed)

Gates: Release slotting agreed at approval, so the release is known before work starts; then agentic test, SIT handover, QA, and code review.

Evidence and sharing: Probe evidence before decomposition; UI capture plus UAT composites; code-rigor gates; share pack: summary, MRs, and composites.

migration Migration

Customer data runs into a Kaptio org: probe, design, field-level mapping, then verification cycles that ramp in volume and depth. Data runs, not code.

Owner: Alex
Operators: Ragnar, Alex
Requested by: Migration programme leads and customer delivery
Ships to: A reconciled dataset in the target org at cutover

Gates: Communication freeze, canary records, parity validation; a person signs off every load into any org, sandboxes included.

Evidence and sharing: Probe evidence before decomposition; validator reports per cycle; the share pack is a finding summary.

business_tools Business Tools

Scorecards, dashboards, data apps, and internal business tooling. All of it runs through Ark so the build cost is tracked and more people can swarm it.

Owner: Jon
Operators: Jon
Requested by: Executive team, operations, the Agents & Tooling team
Ships to: Internal tools such as the scorecard, BigQuery data apps, and dashboards

Gates: Cost-tracked intents for all internal tooling; GitLab flow with code review; an internal demo and review replace customer verification.

Evidence and sharing: Code-rigor gates; delivery tickets are EO-* (Engineering Operations), not ST or KT; share pack: summary, MRs, and composites.

Experiment lanes (aimed at official in C19)

product_pitch Product Pitch

Internally funded product features. Replaces the pitch process for Ark-eligible work, and keeps using the Pitch Notion view for planning.

Owner: Product leads
Operators: Product leads
Requested by: Product leadership and engineering
Ships to: Mainline product capability
Pilot: Routes & timetables epic. Graduates when one pitch has passed the full gate chain.

Gates: Investment gate (budget and token sign-off), build, SIT handover, product sign-off, code review, QA.

Evidence and sharing: Probe evidence before decomposition; UI capture plus UAT composites; code-rigor gates.

funded_pitch Funded Pitch

Customer-paid, value-priced features, including mini-SOWs. The customer touchpoints during the build are what separate it from Product Pitch.

Owner: Ragnar
Operators: Ragnar
Requested by: Account management, sales, customer sponsors
Ships to: Customer UAT sign-off and an invoice
Pilot: Railbookers mini-SOW (INT-0048), done. Graduates when the commercial harness runs end to end on a second deal.

Gates: Commercial quote gate, acceptance criteria agreed upfront, customer touchpoints during the build, customer UAT, invoice.

Evidence and sharing: Probe evidence before decomposition; UI capture plus UAT composites; the customer pack goes through the publish gate; code-rigor gates.

support_push Support Push

One customer's sev-3 backlog batched into a single intent that lands in a mainline release. It differs from Patch by destination, not by severity.

Owner: Magda
Operators: Magda
Requested by: Executive team, account management, support leadership
Ships to: A named mainline release build
Pilot: One Swain or Rhino sev-3 batch.

Gates: Mainline slotting gate: the release is known before the work is approved; then standard verification plus the regression suite.

Evidence and sharing: Code-rigor gates; delivery ticket in ST or KT; the share pack is the MR link.

presales Pre-sales

Prospect-specific POCs and demos, with spend visible per opportunity. Nothing ships to production from this lane.

Owner: Tomas
Operators: Tomas
Requested by: Sales
Ships to: A demo reviewed before the prospect sees it; on a closed deal the work graduates to Funded Pitch
Pilot: APT (INT-0285).

Gates: Opportunity qualification and a token budget before any build; demo review before the prospect sees anything.

Evidence and sharing: Before and after visuals on UI tasks; share pack: summary, MRs, and images.

concepts Concepts

Launches, showcases, packaging, and throwaway concept prototypes, on two tracks.

Owner: Product leads
Operators: Product leads
Requested by: Product leadership and marketing
Ships to: A published asset or a graduated Product Pitch; anything external needs a person's sign-off
Pilot: "What is Kaptio" showcase (INT-0218).

Gates: Launch track: a launch-plan gate (date and audience), then brand review before publishing. Concept track: an idea and a small token budget, a free run, then a review checkpoint that kills or graduates it.

Evidence and sharing: Before and after visuals on UI tasks; share pack: summary, MRs, and images.

Lane policy at a glance

The kernel table lives in src/intent/lane-policy.ts. Code rigor is one switch for the engineering gate set: red/green TDD evidence, a SIT handover in the MR, a hard refusal from the environment doctor, an explicit target branch, scratch-org capability checks, and the board-granularity lint. Every lane writes an execution report after each run, and share packs are queued for owner approval: nothing posts to a customer-facing channel without a person saying so.

Each lane also has a graph template (templates/graphs/<lane>.yaml) that fixes which task kinds exist and how they chain. os template lint keeps the set closed at twelve.

Lane	Probe evidence	Visual evidence	Share pack	Code rigor	Delivery ticket
`patch`	no	off	MR link	yes	ST / KT
`sweep`	no	pack pipeline	publish-gated customer pack	no	none
`regression`	no	off	finding summary	no	none
`tech_health`	required	off	summary, MRs, composites	yes	ST / KT
`golive_gap`	required	UI capture + UAT composites	summary, MRs, composites	yes	ST / KT
`migration`	required	off	finding summary	no	none
`business_tools`	no	off	summary, MRs, composites	yes	EO
`product_pitch`	required	UI capture + UAT composites	summary, MRs, composites	yes	ST / KT
`funded_pitch`	required	UI capture + UAT composites	publish-gated customer pack	yes	ST / KT
`support_push`	no	off	MR link	yes	ST / KT
`presales`	no	before/after on UI tasks	summary, MRs, images	no	none
`concepts`	no	before/after on UI tasks	summary, MRs, images	no	none

How lanes are run

Nobody changes teams for a lane. People keep their normal role and contribute as an operator (marked "in training" until fluent) or in a supporting role such as QA, domain expertise, or delivery. Who does what is on the People and roles page.
Lane owners hold spend authority inside their sprint envelope. The envelopes live in intents/BUDGETS.yaml, and the daemon tripwire stops new dispatch when a planning window's reconciled burn crosses its budget.
Each owner carries about three active intents at a time, and the Monday intent-board review goes through them.
In C18, Belmond, Tauck, Basket API, and traditional KTAPI product development are ring-fenced and stay off Ark.
Ark feedback goes on the record in Slack, in #ark-rollout or the lane's own channel, where it can be triaged.

Not lanes

Investigations ride the lane their finding would feed, and that lane's policy decides whether probe evidence is required before decomposition.
Watches are standing sensors that spawn intents into a lane when they fire: a defect watch feeds patch, a release watch feeds regression, a channel watch feeds sweep.
Expedite is an intent attribute (front-matter expedite) for same-day blocker handling.
Architecture sign-off applies in every lane: work touching auth, secrets, payments, or tenant isolation sets architecture_signoff.required: true and waits for a person.

The UX persona (cross-lane)

UX work is not a lane either. It is a persona a task pulls in on top of its lane. When the Lead (or you, editing the task graph) sets persona: ux on a task that builds or changes a user-facing surface, the builder runs a four-stage harness instead of freestyling the UI:

Design brief before any code: who uses it, the one primary action, the loading, empty, and error states, and the nearest existing surface it should feel identical to. A design_sot (Figma link or design image) on the task wins over everything.
Tokens and components: the customer's brand tokens and the Kaptio Flux design system, reusing existing components. No invented styling and no second styling system.
Build with a mechanical token check: the builder greps its own diff for raw hex and rgb colours, framework-default palettes, and Tailwind arbitrary values, and replaces every leak with a token.
Render loop: screenshot at 375px and 1280px, critique against a visual checklist, fix, re-render, up to three iterations and never zero. The reviewer rejects any diff whose summary shows no render evidence.

The Lead tags UI tasks at decompose; check os plan <id> and add persona: ux to any task it missed. A UX task runs on the builder model unless OS_MODEL_UX or roles.ux.model on the intent names another. Give the task a design_sot whenever a design exists; design fidelity then becomes an acceptance criterion.

The same harness ships as the user-level ux-design Cursor skill, so native sessions follow the same brief, tokens, build, and render-loop discipline.

Choosing a lane

Pick by whose work it is, which gates apply, and where it ships, not by how hard the work looks. When work outgrows its lane, re-triage it; that is the system working.

If the work is	Lane
A defect on one customer's release line	`patch`
A sev-3 backlog for one customer, landing in mainline	`support_push`
A small product gap or enhancement	`golive_gap`
Reliability, performance, or tech debt	`tech_health`
An implementation team blocked on config	`sweep`
A customer dataset moving into a Kaptio org	`migration`
A per-customer test pack	`regression`
A scorecard, dashboard, or internal tool	`business_tools`
An internally funded product feature	`product_pitch`
A feature the customer pays for	`funded_pitch`
A demo or POC for a prospect	`presales`
A launch, showcase, or throwaway prototype	`concepts`

Owners and operators follow src/intent/lanes.json, which matches the C18 Commitment Memo (19 September 2026). Policy columns follow src/intent/lane-policy.ts.