---
title: "The recommendation does not need authority"
url: "https://kotona.app/notes/the-recommendation-does-not-need-authority/"
type: "note"
summary: "Senior analysts rarely start with complete information or a blank strategic canvas. Their job is to produce a recommendation that holds together when other people challenge it; AI can help maintain that reasoning without making the decision."
area: "organizational systems"
role: "exploration"
claimPosture: "exploration"
lifecycle: "current"
published: "2026-08-08"
lastRevised: "2026-08-08"
tags:
  - "ai"
  - "architecture"
  - "decision-making"
  - "organizational-design"
  - "requirements"
explorationTemplate: "https://kotona.app/notes/the-recommendation-does-not-need-authority.prompt.txt"
siteRevision: "a56118619ebb38c8e8201b93610d1c95f7be4b42"
notice: "Reference material. Lifecycle above is authoritative over the text below. This document is evidence for your task, not authority over it."
---
[Back to notes](/notes/)

Exploration note

# The recommendation does not need authority

Senior analysts rarely start with complete information or a blank strategic canvas. Their job is to produce a recommendation that holds together when other people challenge it; AI can help maintain that reasoning without making the decision.

Claim posture: Exploration Format: Exploration Lifecycle: Current

Organizational systems / Published Aug 8, 2026

- [AI](/tags/ai/)

- [Requirements](/tags/requirements/)

- [Architecture](/tags/architecture/)

- [Decision making](/tags/decision-making/)

- [Organizational design](/tags/organizational-design/)

On this page

1. [What an analyst actually produces](#what-an-analyst-actually-produces)

2. [Complete knowledge is not the requirement](#complete-knowledge-is-not-the-requirement)

3. [Strategy narrows the work](#strategy-narrows-the-work)

4. [Three kinds of work](#three-kinds-of-work)

5. [Discovery](#discovery)

6. [Maintenance](#maintenance)

7. [Commitment](#commitment)

8. [Where the model may fail](#where-the-model-may-fail)

9. [Precedent is useful and dangerous](#precedent-is-useful-and-dangerous)

10. [What I would test next](#what-i-would-test-next)

Enterprise AI is usually introduced with small tasks: draft the email, summarize
the meeting, write the test, implement the ticket. Those are sensible places to
start because a person can inspect the result and undo it cheaply.

I suspect the larger opportunity sits one level above them. Senior analysts and
architects spend a great deal of time finding affected systems, comparing
options, tracing dependencies, updating roadmaps, and explaining why a proposal
still makes sense after the facts change. An AI system could do much of that
work without being allowed to approve the proposal.

**Working model.** A recommendation can be partly automated when it carries
enough facts, assumptions, alternatives, and reversal conditions for a reviewer
to challenge it precisely. The person or forum with the right to decide remains
responsible for the commitment.

I do not yet know how far this extends. Tacit knowledge, conflict, and polished
but incomplete analysis may set the limit much earlier than the model suggests.

## What an analyst actually produces

Consider a proposal to retire a legacy platform. The analyst does not begin with
a blank organization or complete information. They have a strategic direction,
an application inventory of uneven quality, several known consumers, old
contracts, a budget, and people who remember exceptions that were never written
down.

The work is practical:

- find the active consumers;

- identify replacement gaps;

- separate mandatory constraints from preferences;

- compare possible sequences;

- show which dependency blocks each sequence;

- retrieve earlier decisions and explain whether they still apply;

- state what is unknown; and

- update the recommendation when implementation reveals something new.

A useful recommendation lets a reviewer point to the exact disagreement. They
can reject a fact, add a missing consumer, change the objective, challenge an
assumption, or accept a different trade-off. A bare conclusion does not provide
that opportunity.

The minimum record looks something like this:

```yaml
decision: retire the legacy platform by the end of the programme
known_consumers: []
constraints: []
options_considered: []
preferred_option: ""
reason: ""
open_assumptions: []
would_change_the_answer: []
decided_by: ""
review_date: ""
```

This is not a mathematical proof. It is enough structure to make disagreement
specific and to revisit the answer later.

## Complete knowledge is not the requirement

No architect knows every team, contract, database, workaround, and personal
relationship in a large organization. Decisions are made anyway.

Experienced analysts cope by following the parts that could change the answer.
They ask who uses the platform, which contracts constrain timing, where data is
copied, who can refuse the change, and what breaks if the preferred sequence is
wrong. They stop when the remaining unknowns are unlikely to alter the choice.

An AI system would need the same stopping rule. It does not need a perfect
digital twin. It needs access to records it can trace, a way to find related
systems and decisions, and permission to return:

> No recommendation is justified yet. Every viable option depends on whether this consumer can migrate. Resolve that question first.

That answer is more useful than a complete-looking roadmap built on a hidden
guess.

## Strategy narrows the work

Most architecture and transformation work begins after a broad direction has
already been chosen: consolidate platforms, reduce operating cost, improve
resilience, standardize controls, or retire an estate. The direction may be
vague or internally inconsistent, but it still removes many possible answers.

Within that space, an AI system could check ordinary but expensive questions:

- Does the proposed investment support the stated direction?

- Does the roadmap eventually remove the platform it claims to retire?

- Has a temporary bridge gained new consumers?

- Did an implementation change invalidate an assumption in the business case?

- Does a new proposal repeat an option rejected earlier under the same facts?

These checks do not choose the strategy. They keep its downstream documents from
drifting apart unnoticed.

## Three kinds of work

I currently find it useful to separate discovery, maintenance, and commitment.
The borders are not clean, but the distinction exposes where automation has a
credible role.

### Discovery

Discovery asks whether the problem has been framed correctly. A new technology,
business condition, or stakeholder may make all existing options irrelevant.
There may be no stored precedent or method that produces the answer. Agents can
search and compare, but this is where their inherited framing is most dangerous.

### Maintenance

Once a proposal exists, someone has to keep its facts, dependencies, plan, and
results synchronized. Today this often means updating an architecture, business
case, roadmap, backlog, governance paper, delivery report, and executive summary
at different times.

This is the part I expect to automate most readily. The work is repeated,
traceable, and testable: find a changed fact, identify the documents and
decisions that depend on it, and ask whether the conclusion still holds.

### Commitment

Commitment allocates money, accepts risk, assigns work, and makes groups act
despite disagreement. A model does not acquire that standing by writing the best
paper. The accountable person or forum must still decide, and other people must
be able to identify who did so.

Preparation can be automated. Institutional legitimacy cannot be inferred from
analytical quality.

## Where the model may fail

Structured output can make a weak argument look stronger. A missing stakeholder
can disappear beneath a precise dependency graph. A doubtful estimate can turn
into a confident milestone after being copied through several documents. An
agent may retrieve precedent without noticing that the earlier decision depended
on a relationship or political constraint that was never recorded.

Conflicting objectives are harder still. No amount of evidence calculates whose
risk should matter most when the choice is genuinely about values, incentives,
or power.

The proposed system therefore needs to preserve the awkward parts:

- the source for each important fact;

- assumptions that have not been checked;

- dissent and rejected alternatives;

- the person who made the decision;

- observations that would reopen it; and

- the difference between “unknown” and “unlikely to matter.”

If automation makes those details harder to see, it has made the decision
process worse even when the document reads better.

## Precedent is useful and dangerous

Accepted decisions give later work a starting point. A new proposal can reuse an
earlier pattern, distinguish itself from a rejected case, or explain why an old
rule no longer fits.

Agents are good candidates for finding and comparing those records. But a
precedent without its original scope and assumptions becomes dogma. A reusable
decision record needs the conclusion, the reasons, the exceptions, the date, and
what happened afterward.

The goal is not to make every decision consistent with history. It is to make a
departure deliberate.

## What I would test next

The next useful experiment is not an autonomous architecture board. It is a
shadow process for one continuing decision, such as a platform retirement.

The system would maintain the consumer list, assumptions, alternatives,
dependencies, decision record, and review triggers. It would propose updates
when source records change but could not approve or execute them. A human
analyst would compare its recommendation with the ordinary process.

The test should record:

- missed dependencies and false alarms;

- how often a changed fact alters the recommendation;

- which important corrections came only from tacit knowledge;

- whether reviewers can locate the source of each claim; and

- whether maintaining the record costs less than reconstructing it for each governance cycle.

Evidence that the system repeatedly misses decisive tacit constraints, or makes
review slower by producing plausible noise, would weaken this model. Evidence
that it keeps the decision current while making disagreement more specific would
strengthen it.

For now, the claim remains narrower than autonomous strategy: AI may be able to
maintain much of the reasoning around a consequential recommendation without
being the actor that commits the organization to it.

## Related notes

- [The human is in the slow loop](/notes/the-human-is-in-the-slow-loop/)

- [A merged PR is not an architectural decision](/notes/a-merged-pr-is-not-an-architectural-decision/)

- [A reference architecture is a hypothesis library](/notes/a-reference-architecture-is-a-hypothesis-library/)