Organisations are systems of decision objects not hierarchies of roles

Decision Architecture has largely been discussed on this site in structural terms.

Authority boundaries.
Decision latency.
Coordination cost.
Option space.

These describe how organisations behave as systems.

A useful next step is to describe them using conceptual primitives.

Organisations behave like systems of interacting decision objects.

From structure to objects

Structural thinking focuses on boundaries and flows.

Which domain owns a decision.
Where escalation occurs.
Where coordination becomes expensive.

Object thinking introduces a different lens.

Instead of only describing flows it identifies the entities participating in those flows.

Actors.
Decisions.
Constraints.
Authority boundaries.

These become the building blocks of the system.

Complex organisations emerge from the interaction of simple decision objects.

The core object types

Several conceptual objects appear repeatedly across organisations.

Actors generate decisions.
Decisions operate within constraints.
Authority boundaries determine who can commit outcomes.
Feedback loops reshape future behaviour.

Each object has state and behaviour.

Actors possess capabilities and authority scope.
Decisions contain context and option space.
Constraints narrow the available path.

Systems evolve through the interaction of these objects over time.

Decision Architecture becomes clearer when the system is described through its objects.

Why this framing matters

Hierarchies encourage people to think about authority through job titles.

Systems behave differently.

Decisions appear continuously across domains. They intersect constraints and dependencies. They must converge through authority surfaces.

An object model allows these relationships to be expressed precisely.

Engineers recognise this pattern immediately.

Software systems operate the same way.

Organisations resemble distributed decision systems more than management charts.

Decision objects in practice

Consider a cross domain architectural decision.

The actor may be an engineering lead.
The decision concerns API behaviour.
Constraints include performance and security.
The authority boundary sits with the platform architect.

The decision object moves through the system until it reaches a commit surface.

If that surface is unclear latency emerges.

The system stalls while actors search for authority.

Clarity about decision objects reduces organisational friction.

The deeper implication

Object models are powerful because they compress complexity.

Large systems become understandable when described through a small set of interacting primitives.

Decision Architecture may follow the same path.

A small vocabulary of objects could describe most organisational behaviour.

Actors.
Decisions.
Authority boundaries.
Constraints.
Feedback loops.

Understanding these objects reveals the hidden mechanics of organisations.