The ExecutionIntent

A clear, versioned record
of what the organisation decided.

An ExecutionIntent records the option, reason, owner, constraints, budget, measures and approved delivery route in one package. People and authorised systems can work from the same instruction.

Anatomy

Nine fields keep the decision clear.

Hover or tap a line in the package, or a card beside it, to see what each field records.

execution_intent · EI-2041v3 · approved
selected_option: rebuild onboarding flow, option Brationale: lowest risk path to cycle targetobjective: onboarding cycle time under 5 daysexpected_outcome: -30% cycle, NPS steady or betterconstraints: GDPR, no PII in prompts, UK data residencyevidence_refs: proto-77, churn-study-Q2, D-098owner: l.okafor@company.combudget: £50,000deadline: 2026-09-30success_measures: cycle_time, rework_rate, NPSapproved_executors: claude-code, github, linearmodel_posture: frontier, no fine-tuning, loggedreview_gates: design sign-off, pre-deploy checkescalate_on: budget 80%, policy exception, driftfingerprint: sha256:9f2c…a1d4
controlled · versioned · reviewablebridgly
field 01

Selected option and decision rationale

The chosen option and the reason it was selected over the alternatives. This preserves the decision context when priorities change later.

field 02

Objective and expected outcome

What the work is meant to change, stated before delivery begins. The outcome is measured against this expectation.

field 03

Constraints and required policies

The regulatory, security and organisational rules that delivery must follow. They stay attached to the instruction sent to an approved system.

field 04

Permitted evidence references

The documents, datasets and earlier decisions that delivery may use. An authorised reviewer can trace a claim back to its source.

field 05

Accountable owner

The named person who receives escalations, review requests and outcome records.

field 06

Budget, deadline and success measures

The cost limit, delivery date and measures used to assess the result. These are agreed before delivery begins.

field 07

Approved agent, runtime and model posture

The agents, runtimes and models authorised for the work, with the limits that apply to them.

field 08

Review and escalation requirements

The points where a person must review the work and the conditions that pause delivery or notify the owner.

field 09

Configuration fingerprint

A cryptographic fingerprint of the package. A change creates a new version and a different fingerprint, making the history reviewable.

Versioning

Keep a clear history when the decision changes.

Budgets, constraints and scope can change. Each version is kept, every change has an owner and delivery systems can identify the version they received.

v1 · approved 2026-06-02

Initial intent from decision D-118. Budget £40k, deadline 31 August, two approved executors.

sha256:2b81…c9e3
v2 · approved 2026-06-24

Constraint added after security review: UK data residency. Escalation threshold tightened to 80% of budget. Change attributed to the accountable owner.

sha256:d417…08aa
v3 · approved 2026-07-08 · current

Budget raised to £50k, deadline moved to 30 September, Linear added as an executor. Approved at a review gate; the receipt will be judged against this version.

sha256:9f2c…a1d4
Dispatch

One package for different delivery systems.

The intent keeps the same fields whichever approved system receives it. Progress, exceptions and outcome records then return to the same decision.

Software and app implementationship the change
CodexClaude CodeOmnigentGitHubLinear
Analytics initiativeanswer the question
Databricks JobsGenieSQLSpecialist BI tooling
Operational programmerun the programme
JiraAsanaMondayServiceNow
Security responsecontain the threat
LakewatchYour SOARYour SOC tooling
Commercial executionwin the revenue
SalesforceYour CRM
Data productpublish the product
Databricks pipelinesUnity CatalogOpenSharing
Follow the result

A decision is complete
when the result is reviewed.