The Architecture of Possibility

For a long time, I struggled to articulate my affinity for federal grant regulations. I would joke about it, usually in a self-deprecating way, as though my fondness for the intricacies of regulatory language were some peculiar professional quirk. Every so often, I would return to the question of why I enjoyed this work so much. Over the last several months, however, a few experiences have helped me see something that I hadn't quite put into words before.

I'm a person who loves thinking about complex things. I have my limitations, like everybody else, and I don't like to waste time, so I'm clear about those limitations up front. But oh, how I love something complex. I love working with complex systems, understanding how their parts interact, identifying the constraints that matter, and discovering what becomes possible when you understand how everything fits together.

I think I've been doing this for much longer than I've had the language to describe it.

When someone walked into my office and said, "I have a problem," I'd usually tell them, before I even knew what it was: "Trust me. We're going to figure it out. And when we're done, this probably isn't going to seem like such a big deal."

I didn't know the answer yet. I didn't know what had happened or which requirements applied. What I did know was that a problem rarely has only one way through it. There are requirements to interpret, controls to examine, facts to establish, alternatives to weigh, and chances to correct course. Having a problem doesn't mean you're out of options.

I knew something else, too. If that person brought the problem to me before it reached an auditor or a federal agency, we were already winning. Someone who finds a problem and brings it forward isn't evidence of a failed system. They're evidence the controls are working.

Design space

I was teaching a class at an emergency management conference recently, and I explained to an attendee that the Uniform Guidance has design space. It has its musts and shalls. But where it says your policies and procedures, that's intentional. It's not a missing answer.

The attendee's reaction stayed with me: "Oh my goodness, that makes so much sense. I never really thought about it like that. I always get to those sections and I'm like, tell us what to do. Why doesn't it say what we need to do?"

You can see it at two levels. At the top, § 200.106 has each federal agency adopt the Uniform Guidance in its own regulations. One framework governs every agency without every agency's rules being identical.

At the recipient level, it's even more concrete. Under § 200.1, equipment is property with a useful life of more than a year that costs at least the lesser of two numbers: your own capitalization threshold or $10,000. If your threshold is $5,000, equipment starts at $5,000. If it's $2,500, equipment starts at $2,500. The federal rule is the same for everyone. Your own accounting policy decides where it starts to apply.

That isn't unlimited discretion. The $10,000 ceiling still holds. But the regulation doesn't need one threshold for every recipient. It defines a mechanism that lets your policy matter.

That's two ways of reading the same text. One person sees a gap. The other sees a boundary they're expected to work within. The difference isn't in the text. It's in knowing what the text is designed to do.

A regulation doesn't have to prescribe every detail to establish real control. Across thousands of recipients of every size and kind, prescribing every detail would be impossible, and it would get in the way. The design is deciding what has to stay the same everywhere, where variation is allowed, and who decides inside that space.

That's a more interesting problem than memorizing regulations. It's architecture.

From the regulation to the decision

It shapes how I think about compliance systems. Take a local government deciding whether one expenditure is allowable under a federal award. Finding the right passage in 2 CFR Part 200 isn't enough. You need the award, the recipient, the version of the requirements that applies, the cost category, the award terms, any restrictions or exceptions, the evidence, and the person authorized to decide.

You also need the recipient's own policies. Federal requirements set the boundary; the recipient's policies give it operational form. A system that pulls the federal provision without that context can sound authoritative and still be wrong.

So the pieces line up like this: the regulation sets the boundaries, the policies give them form, the evidence establishes the facts, and an authorized person decides within that structure. A useful system has to understand how those pieces work together, not just repeat what any one of them says.

Specifying computational governance

That's where the Decision Lineage Protocol comes in.

Writing the specification, I understood design space before I had the words for it. As a builder, you have to know where to draw the line on what you decide, and how much agency the user keeps to define what they need. Maybe that comes from years of working with off-the-shelf and custom implementations. Every design decision closes some possibilities and keeps others open for whoever comes after you.

The DLP doesn't exist to automate an answer. It makes the reasoning, the evidence, the constraints, and the decision authority visible enough that the result can be examined and governed. It establishes what must be established, keeps the context needed to apply it, and leaves judgment where it belongs.

The good regulator

The design fits a pair of ideas from systems theory. Roger Conant and W. Ross Ashby's Good Regulator Theorem (1970) says that every good regulator of a system must be a model of that system. Ashby's Law of Requisite Variety says a regulator needs at least as much variety in its responses as the disturbances it has to handle.

One framework that covers every kind of recipient can't carry all that variety itself. So the Uniform Guidance fixes what has to hold everywhere and hands the rest to each recipient's policies and procedures. Ashby doesn't explain why it was written that way. He gives me words for why the design works when it does.

Why I love this work

So when I joke about loving grant regulations, here's the better answer: I love the design. I love that a framework can set common obligations and still leave room for judgment. I love that a problem that looks overwhelming becomes workable once you understand its parts, its constraints, and the paths still open. And I love that the same questions followed me into building something new.

And if you're the person who brings the problem forward before it reaches the auditor or the federal agency: thank you. You've given the system a chance to work as intended. Now let's figure out what we can do with it.

I love the architecture of possibility: systems that establish what must be true and leave room for people to decide what's possible.