Separating decision cadence from delivery execution

← Architectures

Reference structure · Operating structure · Organisations × Technology

One arrangement in which the surface where decisions are recorded is deliberately kept separate from the systems where delivery happens.

This is one possible structure, not a target state and not a record of a system observed in a specific environment. It is useful while its assumptions hold, and it says where a different arrangement would fit better.

The structural question

Where should a decision live, if the tools that carry out the work change more often than the reasoning behind it?

Components

Each part is here for a reason: what it owns, and what it depends on.

• Signal inputs

  Owns: Nothing. It reads from delivery, commercial and customer systems.

  Depends on: Depends on those systems exposing state; goes stale when they do not.

• Decision record

  Owns: The source of record for what was decided, when, and on what basis.

  Depends on: Depends on people writing decisions down rather than leaving them in meetings.

• Delivery systems

  Owns: Work items, sequencing and release state.

  Depends on: Depends on a decision reference existing; otherwise priority is re-litigated locally.

• Outcome read-out

  Owns: The observed result attached to a decision, including the absence of a result.

  Depends on: Depends on measurement that existed before the decision was taken.

Ownership and source of record

The decision record is source of record for reasoning, not for work. Delivery tooling remains source of record for delivery state. The boundary is organisational as much as technical: whoever can change the decision record can change the priority.

Movement through the structure

1. 01

   Signal inputs

2. 02

   Decision record

3. 03

   Delivery systems

4. 04

   Outcome read-out

The fragile point is the return path. Most organisations can push a decision into delivery; far fewer can find, months later, what the decision assumed and whether it held.

Dependencies

The question is whether the dependency matches what the organisation needs.

Intentional coupling

Decision and outcome benefit from moving together — a decision without its read-out cannot be examined later.

Costly coupling

When the decision record lives inside the delivery tool, changing the delivery tool loses the reasoning history, and the reasoning becomes shaped by whatever the tool can represent.

What is hard to reverse

The decision record is deliberately low-technology and portable. Coupling it to a vendor workflow engine is the choice that becomes hardest to unwind.

When something fails

If signal inputs fail, decisions continue on stale state and the staleness is invisible unless recorded. If the decision record is unavailable, delivery continues but priority arguments return to whoever is in the room.

Assumptions

A reference structure is only reusable when its assumptions travel with it.

What must hold

If these are not true in a given environment, the structure is the wrong starting point.

• Decisions recur often enough that recovering earlier reasoning has value.
• Someone is accountable for writing the decision down; the structure does not create that accountability.
• Measurement exists, or can exist, for at least some decisions.
• Delivery tooling is expected to change on a shorter horizon than the organisation's way of deciding.

Trade-offs

Each improves something and costs something. Neither side is universally preferable.

• Portability of reasoning against the convenience of keeping everything in one tool.
• An explicit decision surface against the overhead of maintaining it when volume is low.
• Fewer re-openings of settled questions against slower initial decisions.

What this makes possible

Earlier reasoning becomes recoverable, which makes it possible to examine why a decision failed rather than only that it did.

What it constrains

It makes informal, fast, undocumented decisions harder — which is a cost in environments where speed matters more than recoverability.

How you would know whether it helped

Whether decisions get re-opened less often, and whether anyone actually consults the record six months later.

What informed this

Technical reasoning about tool lifespans, and repeated practice in organisations where delivery tooling was replaced mid-programme.

Another structure may fit when

Another structure may fit when decisions are few and slow: recording them inside the delivery tool is cheaper, and the loss of portability may never be felt.

Where this stops fitting

Stops fitting where the organisation is small enough that reasoning is genuinely shared, or where decisions are rarely revisited.

Related

Related reading

Industry

• Retail
• D2C
• Enterprise SaaS
• BFSI

Knowledge · Playbook

• When Delivery Slows and the Cause Sits Upstream
• When the Organisation Waits on One Person

Evidence · Observed Situation

• When every team had a dashboard and no team had a decision
• When the platform was the reason decisions felt expensive
• When routine decisions were being escalated because no system carried the context

The situations linked above informed this representation. They do not establish that this structure is right for another environment — that remains a question about the specific organisation, its ownership and its constraints.

Architecture, as a question →Work with Cralgo →