Federated Decision Rights

The previous lesson settled who owns a data product. This lesson settles something harder: when a decision crosses domain boundaries, who gets to make it, and what happens to domains that need a different answer. Federated computational governance is the fourth mesh principle, and it fails most often not because the rules are wrong but because nobody wrote down where each rule's authority sits.

In this lesson, you will learn to:

• Distinguish decision authority from the way a decision is enforced.
• Place decisions in global policy, shared-standard, or domain-decision authority using a decision-rights map.
• Assess exception requests through evidence, conditions, expiry, and accountability.

There are three places decision authority can sit:

• A global policy is an enterprise-wide authority: one answer, binding everywhere, typically because law or regulation demands it.
• A shared standard is a cross-domain authority for a common convention, agreed by domains together so that products from different domains can be combined.
• A domain decision deliberately leaves authority with the domain that holds the context and bears the consequence.

The computational part of federated computational governance is about how an already-agreed rule is applied through the platform; automated enforcement is not a fourth authority option on that list. It is a separate choice about how an already-decided rule gets applied: manually, mechanically, or a mix of both. This distinction sounds pedantic until you watch it collapse in a governance forum.

In a federated-governance forum, Ryan, a platform representative, proposes automation while Natalie, a governance lead, keeps the group focused on the authority for the sensitivity-classification decision.

• Ryan: Let's just automate the sensitivity classification. Then we don't have to argue about it.
• Natalie: Automate what, exactly? We haven't agreed what counts as sensitive yet.
• Ryan: The platform team can encode the rules from the policy draft.
• Natalie: That encodes one reading of a draft nobody has approved. Authority first: is this a global policy or a shared standard? Once the forum decides that, we choose whether enforcement is manual, automated, or mixed.
• Ryan: So automation is the delivery of the decision, not the decision.
• Natalie: Right. Automating an unagreed rule just makes the disagreement harder to find later.

Notice that Natalie did not reject automation. She sequenced it. Encoding a rule before its authority is settled hides the political question inside a technical artifact, which is exactly how governance loses domain trust.

A decision-rights map is the artifact that makes all this visible: one row per decision, its authority placement, and a one-line reason. The reason matters as much as the placement. Forums accept unwelcome placements when they can see the test being applied consistently; they reject papers that assert.

The test itself has two halves. A decision belongs at enterprise level when inconsistency across domains would create regulatory exposure or break comparability across domains. It belongs at domain level when the domain holds the contextual knowledge and bears the consequence of getting it wrong. Retention periods for customer data usually land global because a regulator does not care which domain held the record. A domain's locally derived operational indicator usually lands domain because nobody outside that domain interprets it.

Consequently, resist the pull toward placing everything at enterprise level. A map with every row marked "global policy" is read as a centralisation attempt, and it is also usually wrong: it loads the forum with decisions it lacks the context to make well. The genuinely contested items are the ones that sit between the two halves of the test, where a domain holds the context but the consequence lands somewhere else. Name those explicitly: place them provisionally, flag the contest, and state what evidence would move them. When a contested item needs temporary domain autonomy, use the same exception elements: evidence, conditions, expiry, and accountability.

First place authority. Then choose how that already-decided rule is enforced.

Federated governance without an exception route produces quiet non-compliance. Domains that cannot meet a standard simply do not tell you. So the useful question is not whether to grant exceptions but what a well-formed exception request must contain.

Four things:

• Evidence: what specifically makes conformance infeasible or harmful right now, stated as fact rather than inconvenience.
• Conditions: the circumstances under which the exception holds, including any compensating measure the domain accepts in place of the standard.
• Expiry: a date or trigger at which the exception lapses and must be re-argued, because an exception without an end date is a silent amendment to the rule.
• Accountability: the named person who carries the consequence if the exception causes harm, which is rarely the person requesting it.

The core takeaway is that federated governance is a placement problem before it is a control problem: decide where authority sits, then decide how the decision is applied. A quick check and a matching exercise will test whether you can hold the authority-versus-enforcement line under pressure, and then you'll build a real decision-rights analysis of the kind a governance forum would actually read.