Governance as the objective function

Before I ask what an AI system should execute, I want to know what the organization is trying to become. Governance is where that purpose is made explicit: the objective, the constraints, and the authority to resolve conflicts between them.

Tool selection and workflow design follow from that choice. A team can improve its process considerably while making the larger organization worse. If we make execution more capable without examining its direction, we can accelerate the wrong behavior.

The frame around the work

Picture an organization as a space of knowledge that can be examined at different depths. At one depth are individual records, tools, and actions. At another are the functions those actions perform. Higher still are the outcomes those functions are supposed to serve.

Moving between those views changes the question. An analyst asks whether a record is accurate. A manager asks whether the process produces a dependable result. A functional leader asks whether that result serves the business. An executive must decide which outcomes the business should pursue and what it must refuse to do in pursuit of them.

This is the value of abstraction for me: it lets us change the implementation while keeping its purpose visible. The view from above still depends on information from the people doing the work. Abstraction should help organize that knowledge, not erase it.

Why I use the image of a summit

I describe a department as a system receiving inputs, transforming them, and producing outputs. Its improvement process searches for a configuration that creates more value. Gradient ascent gives me a useful image for that search: climbing toward a better outcome on a landscape that is only partly understood.

The image needs a boundary. Maximizing a value function and minimizing its negative are mathematically equivalent formulations. I am using ascent to emphasize the question “What valuable outcome are we pursuing?” rather than claiming that ascent and descent imply incompatible management practices.

Nor does a department automatically have a differentiable objective or an optimizer with access to gradients. The organizational model becomes quantitative only when objectives, constraints, measurements, and a method of evaluating changes are specified. Until then, the summit is a way to reason about direction.

The ordinary case is not the whole job

The unusual invoice, the ambiguous customer request, and the deal that does not fit the pricing matrix reveal the quality of a process. A workflow designed around clean examples may appear excellent while repeatedly failing at the edges of the real work.

These cases are useful stress tests. I want to understand which inputs produce dependable outcomes, which create confusion, and which should leave the automated path entirely. The design should make missing evidence, conflicting rules, and exceptions visible.

In the original framing, I used ideas such as activation maximization to explore this relationship between inputs and outputs. For organizational design, the useful question is concrete: which conditions help a function create the intended value, and what happens outside those conditions? That analogy does not establish a neural mechanism inside the organization.

The executive charter defines the objective

The first layer is a charter set by leadership accountable for the entity in scope. That entity might be a company, business unit, or department. Its leadership needs enough authority to resolve the conflicts the initiative will expose.

The charter states the destination, the principles that constrain valid solutions, and the common schema used to describe work. It also assigns decision rights. If speed, margin, customer experience, and risk pull in different directions, who decides what takes precedence?

A KPI is a measurement, not a complete statement of purpose. Reducing support time may be useful, but it should not reward leaving customers unresolved. Increasing revenue may be useful, but it does not settle acceptable discounting, contractual promises, or delivery commitments.

The charter should make those tensions discussable. I want it to give downstream teams enough direction to make decisions without asking executives to approve every implementation detail.

Functional objectives add resolution

The second layer belongs to functional leaders. They define the work their department serves, the outputs it produces, and the process connecting the two. Their objective must be evaluated against the charter and against the consequences for other functions.

Sales can optimize close rate while creating commitments that customer success cannot fulfill. Billing can optimize collection efficiency while making a customer relationship harder to repair. Local measures can improve even as the shared result deteriorates.

A functional objective should therefore include the quality of its handoffs. What does the next team receive? Is the evidence complete? Are unresolved assumptions visible? Does the result create value or merely move effort elsewhere?

I see four levels in the resulting architecture: the global objective; the local objectives constrained by it; the process architecture describing roles, tasks, data, and handoffs; and the execution that uses tools within defined permissions. Each level adds detail without losing the purpose above it.

Make tools replaceable through explicit interfaces

At the implementation layer, a tool is important because of the capability it provides. At the architectural layer, the enduring question is what that capability must accept, produce, and guarantee to its consumers.

My early notes used four or five tools as a rough prompt for examining a role’s abstraction. I would not treat that count as a design law. A long tool list may indicate a missing interface, or it may simply reflect the job. The useful test is whether responsibilities are understandable and dependencies can be changed without redefining the role.

This connects governance to the Role Programming Interface. Leadership defines the outcome and constraints; the contract makes a capability explicit; the implementation can change behind it.

Move between leadership and the work

I would develop this through a repeated fan-out, fan-in process. Teams map their actual functions, inputs, decisions, exceptions, and handoffs. Leaders then compare those maps, reconcile conflicting objectives, and identify common components.

Several processes may use the same data, tools, and sequence for different downstream purposes. That is an opportunity for a shared capability. But consolidation should follow a clear understanding of the differences, rather than forcing every team into one premature abstraction.

Where a rule is explicit, implement and test it as a rule. Where interpretation is needed, define the evidence and review boundaries around the model. Deterministic code can still be wrong; its value is that the rule and its behavior can be inspected and tested directly.

People closest to the work must help describe it. IT must support the access and integration boundaries. Leadership must resolve permissions and priorities that cannot be negotiated independently by each role. The implementation framework explains that operating rhythm in more detail.

Judgment remains a responsibility

My aim is to give knowledgeable people more room to exercise judgment: better context, fewer repetitive handoffs, and clearer choices. That is an architectural intention, not a guarantee about employment outcomes.

Organizations will make their own staffing and economic decisions. I do not think it is honest to promise that automation cannot affect a role. The useful discussion is how people participate in defining the work, how their knowledge is recognized, and how they gain the ability to question and improve the system around them.

I call the broader principle Executive Incompleteness. An agent working inside an assigned frame may be able to critique it, but its execution does not supply the legitimacy to choose the organization’s purpose. Accountable people still have to decide which frame to adopt.

For me, that is the central work of governance: authoring and revising the context in which optimization makes sense. Before asking how fast the system can climb, decide which summit is worth climbing toward.

Adapted for this notebook from my Governance as the Objective Function.