Kaptio Ark Intent-to-outcome orchestrator

The core idea

Intents, not tickets

A task is a unit of work. An intent is a unit of outcome: a versioned contract that says what problem we are solving, what outcome we want, and how we will know it worked. Tasks live inside intents. Feed Ark a ticket as if it were an intent and you get a correct fix with no context, no shared branch, no shared memory, and a board full of noise.

The altitude ladder

How high can an intent go? As high as you can shape. How low may it go? There is a floor.

The dream

"Kaptio signs Disney Cruises by 2027."

The direction of travel. Ark is designed so intents can keep climbing toward this altitude as trust builds.

A commercial or programme outcome

"Luxury Escapes Foundation SOW countersigned by 31 August."

Deal closes, go-lives, migration cutovers. Weeks of coordinated work across repos, people, and customers.

The lowest acceptable intent

"Belmond needs patch 23.2.8 on 10 August to unlock UAT."

A release a customer is waiting on, carrying its whole family of defects. This is the floor. Below this line, it is a task inside an intent.

Below the line: not an intent

"Fix ST-3981."

A single ticket is a task. It joins the patch-family intent that already owns its release, or the standing patch line.

A lesson from the field

An operator fed Ark three Belmond tickets one evening, each as its own intent. Each run did a great job in isolation. But none of the three knew the other two existed: three branches, three merge requests, no shared understanding of the patch they were all part of.

A few hours later he ran it again with one intent: "I have three Belmond tickets, I want them out in the release." Ark did all three tickets together, on one branch, in a single merge request, each fix aware of its siblings.

Same tickets, same kernel, same models. The only thing that changed was the shape of the intent. Shaping intents is the human job; that is where the expertise goes.

Three tickets as three intents Ticket A branch a MR 1 Ticket B branch b MR 2 Ticket C branch c MR 3 Three MRs. No shared context. Each fix blind to its siblings. One intent, three tasks One intent "Belmond needs the patch" Task A Task B Task C one integration branch One MR Shared fixtures, shared root causes. The board learns once.

Why ticket-intents fail, mechanically

No shared context at build time

Tickets from the same release usually share root causes, fixtures, and regression surfaces. Separate intents mean separate worktrees, separate probes, separate scratch orgs, and fixes that can silently conflict on the same branch.

No memory palace

Ark learns by reading prior intents. One intent per ticket fragments that record into confetti. The patch-family intent accumulates the org recipes, the seeding scripts, and the regression pins that make the next defect cheap.

Cost-to-outcome becomes meaningless

The board's headline metric is what an outcome cost. Nobody cares what ST-3981 cost in isolation; everybody cares what the Belmond patch cost against what it unlocked.

Board noise drowns the signal

Leadership plans against the board. A hundred ticket-intents make prioritisation impossible; ten outcome-intents make it a ten-minute conversation.

You have a ticket. What now?

This is the standing board rule (owner decision, 30 July 2026). It is also lint-checked: the index fails on active single-defect intents.

  1. 1. Is there a per-release patch intent for this customer or version?

    Then the ticket is a task there. If the ticket is already in that intent's scope and got reopened by QA, the residual returns to the same family intent. It never mints a new one, even if the original task is done.

  2. 2. No release intent, but it is a core defect fix?

    It is a task on the standing patch line: the programme intent whose outcome is that every accepted defect fix ships in a named build with evidence.

  3. 3. Genuinely neither?

    Only then draft a new intent, and record in the front matter which family intents you checked and why they do not fit. A granularity exception requires board-owner sign-off in the run log before os run. For defect tickets it is almost never granted.

What a good intent carries

outcome_when One paragraph: the world-state that makes this done. Not a list of work.
problem Why this matters now, grounded in real signal: who is blocked, what breaks, what it costs.
success_metrics Baseline, target, and how each is measured (script, SOQL, Loki, BigQuery, governance). These drive the verdict.
constraints The guardrails: which orgs, which branches, what agents may never do, who signs off on what.