Governance as an Operating Capability

How to connect responsibility, evidence, and correction to the decisions people make in ordinary work.

An organization needs a dependable way to make decisions when the answer is disputed, the evidence is incomplete, or the person who usually resolves the issue is unavailable. I think of governance as the operating capability that makes those decisions possible. It establishes who can act, what they need to know, and how the organization handles the consequences.

My perspective comes from technology leadership in congressional committees and current work in data governance and platform delivery. At the House Committee on Rules, I helped operate a publishing workflow in which the release of legislative materials was critical to the work of the institution. The website was part of a larger process involving people, authoritative documents, deadlines, and responsibility for what became public.

That experience continues to shape how I approach governance. The practical question is whether people can carry out their responsibilities consistently, including when something goes wrong. A policy becomes useful when it helps the next person make and execute a sound decision.

Start with a recurring decision

Consider a hypothetical company publishing product information from multiple sources. Two documents disagree about an important specification. An automated extraction tool produces a plausible value, but the evidence remains unresolved. Someone must decide whether to publish, seek clarification, qualify the information, or hold that part of the record.

The workflow needs to identify who evaluates the evidence and who has authority to release the result. Those responsibilities may belong to the same person in a small organization. What matters is that the person understands the decision, can see the relevant sources, and has the authority to withhold an unsupported claim.

The decision also needs somewhere to live. A short record can identify the disputed claim, the sources considered, the disposition, and the reason for it. The record should remain connected to the information that people actually use. Otherwise, the next disagreement may begin with another search through old messages.

Match the review to the consequence

Leaders should distinguish decisions people can make within established boundaries from exceptions that require additional judgment. A routine formatting correction may need a simple check. A change to a consequential factual claim may require stronger evidence and explicit approval. Applying the same review burden to both can consume attention that would be more useful on the second.

The boundaries should be understandable to the people doing the work. They should know what they may change, what evidence is sufficient, and when to escalate. An exception needs an owner and a path to resolution. It should also have a clear interim treatment so that an unresolved question does not quietly become an accepted answer.

This requires capacity as well as authority. If every exception reaches one specialist, the organization should examine the workload, clarify repeatable rules, and train additional reviewers where appropriate. Assigning accountability without providing time or access to evidence creates a responsibility that may be impossible to fulfill.

Connect the decision to the system

An approval should have an observable effect on what the system permits. If a record is being held, the publication process should respect that status. If a claim has been superseded, users should be able to identify the current version. When a rule changes, the team should understand which existing records need another look.

The mechanism can be modest. A small team may use a shared register and a controlled release step. A larger operation may need validation rules, access controls, and automated routing. The design should fit the volume and consequence of the decisions. The essential requirement is that the working process carries out the decision reliably.

AI makes this connection especially important. A model can propose an interpretation, organize evidence, or flag an inconsistency. The organization still needs to establish which outputs may be used automatically and which require review. NIST’s AI Risk Management Framework 1.0 treats governance as a continuing function across AI risk management, with defined responsibilities and executive accountability. (NIST AI RMF: Govern) My concern here is how those responsibilities become part of ordinary work.

Make corrections improve the process

An error report should help someone locate the affected information and understand the evidence for a correction. The person reporting the problem should not have to design the remedy. The organization should acknowledge the issue, assign responsibility, and record the result in a place the reporter can reasonably find.

A resolved exception may reveal a missing rule, an ambiguous definition, or a training need. Leaders should decide whether the lesson applies more broadly before changing the process. Repeated corrections to the same kind of claim are a reason to examine how that claim enters the system.

I would assess this capability through a few practical measures: how long consequential exceptions remain unresolved, how often the same issue returns, and whether approved corrections reach the affected outputs. Review workload matters too. A process that catches errors but cannot keep up with the work needs attention.

A useful starting point is one recurring decision that currently causes delay or disagreement. Follow it from the first question through resolution and any resulting change. Establish who owns it, what evidence is needed, and how the outcome is enforced. Then check whether the next occurrence is easier to handle. That gives leadership a concrete way to build governance into the operation it is responsible for running.