Paul André Couchoud

I have spent most of my adult life building software in places most people never go.

And I mean that literally.

I've been in basements of substance-abuse treatment centers. I've walked through juvenile detention facilities and jails. I've sat in courtrooms. I've worked in hospice centers and facilities caring for the elderly. I've eaten moose stew in Alaska while working with tribal communities. I've walked through the corridors beneath the Texas Capitol.

I've also worked in the other America.

I've sat in executive boardrooms in Boston with people making millions of dollars a month. I've worked inside Charles Schwab. AMD. KPMG's former consulting business, BearingPoint. I've worked with state CIOs and executives, judges, clinicians, software architects, developers, business analysts, and people whose lives were being directly affected by the systems we were building.

I've seen software from both ends of the building.

And somewhere along the way, I learned something that has shaped almost everything I've done since.

Software isn't really about software.

It's about what happens when software touches reality.

I started working in technology in the late nineteen nineties. By nineteen ninety-nine, I was already around software-development projects, process, reporting, databases, testing, and automation.

One of the tools I worked with was Rational Robot.

This was long before anybody was talking about AI agents. You could perform a process on the computer while Rational Robot recorded you. Fill out this form. Click this button. Submit it. Open the report. Verify the result. Then the system could replay those actions automatically.

I could create one automated test for purchasing something, another for reviewing a dashboard, another for producing a report.

It was primitive compared with what we call artificial intelligence today, but the fundamental idea fascinated me.

A human performs a sequence.

The machine receives instructions.

The machine executes them.

Then we test whether what came out was what was supposed to come out.

Around that same period, I began working in behavioral healthcare and social services.

For years I worked with tribal organizations and community-based treatment programs, including work connected with Cook Inlet Tribal Council in Alaska. We were building custom substance-abuse case-management systems.

And this is where software stopped being abstract for me.

Imagine a woman walks into a treatment center.

She's thirty-four years old. She's pregnant. She's seven months along. She has a history of intravenous drug use. She's Native Alaskan and belongs to a particular tribe. She has certain medical conditions and a particular family history.

Those aren't just fields on a screen.

Each fact can change what happens next.

Her tribal status may establish eligibility for a particular program. Her pregnancy may change the urgency of treatment. Her drug-use history may trigger another branch. Her medical history may introduce another requirement.

So we built business rules around those facts.

If this is true, do this.

If this box is checked, insert this language.

If these conditions occur together, the person becomes eligible for this program.

And then the system could take all of those structured facts and produce something remarkably human-looking: a biopsychosocial narrative.

It might produce language explaining that this particular woman, because of her age, pregnancy, tribal eligibility, substance-use history and medical circumstances, qualified for a particular program and required a particular level of intervention.

This wasn't a large language model.

There were no tokens predicting the next word.

We wrote the rules.

We wrote the sentences.

We determined the branches.

But look at the structure.

Human facts went in.

Rules operated on those facts.

Language came out.

And the output could affect what happened to a human being.

That's where I learned that requirements aren't paperwork.

They're responsibility.

Get a requirement wrong and sometimes somebody gets annoyed.

Sometimes somebody loses money.

Sometimes somebody loses access to a service.

Sometimes somebody's freedom can be affected.

And in healthcare, getting information wrong can contribute to somebody being seriously harmed or even dying.

So I became obsessed with the middle of that chain.

What does the person actually need?

What does this word mean?

What is the business rule?

What happens if the answer is yes?

What happens if it's no?

What happens when two conditions occur together?

Who has authority to make the decision?

What exactly must the system do?

And how do we prove that it did it?

I learned requirements engineering. Business rules. Logic gates. Process-flow diagrams. Use cases. Traceability. Functional testing. Regression testing. Change control. Risk management.

I learned the Rational Unified Process and IBM's Rational toolset: RequisitePro, Rose, ClearQuest, TestManager.

And I learned iterative development before most of the business world discovered that putting sticky notes on a wall made everyone Agile.

Then came BearingPoint.

And this is one of those places where a résumé can make something extraordinary sound almost painfully boring.

"Product Manager, BearingPoint."

That doesn't tell you what I was actually doing.

BearingPoint was the former consulting arm of KPMG. I joined its Texas government technology work and became part of the small team around TexasOnline.

Stephanie Weber was my direct boss. Kelly Stein and I became the right-hand pair working closely with Stephanie and Mike Griffith. Kelly taught me how to write rigorous use cases, back before everybody started calling everything a user story.

Mike became enormously important to my development. I became his right-hand man on eFiling for Courts.

That's why I ended up in those courtrooms.

That's why I walked beneath the Texas Capitol.

I wasn't touring government.

I was helping build the software running through it.

I became a certified product manager, and Stephanie gave me the Product Manager title. My responsibilities included eFiling for Courts, ETMS, and ePay.

And these weren't little internal applications.

TexasOnline was operating at enormous scale. Over its life under BearingPoint, the portal processed tens of millions of financial transactions and billions of dollars for state and local government.

I was responsible for product work on the electronic-payment systems inside that environment.

Think about what that means.

If a payment platform of that scale fails, "the website is down" isn't an adequate description of the problem.

Money stops moving.

Government services are affected.

Financial exposure accumulates by the minute.

Then there was eFiling for Courts.

Now the output wasn't primarily money.

It was law.

Court documents had to reach the right place. They had to be associated with the correct case. Fees had to be handled correctly. Documents had to be timestamped. Sensitive information had to be treated correctly. Evidence and filings had real legal consequences.

A defect could become something outside the computer.

A missed deadline.

A compromised filing.

A legal dispute.

Potentially something affecting another person's property, livelihood, or freedom.

That's when the lesson became permanent for me:

The output of a computer system doesn't stay inside the computer.

It enters reality.

After BearingPoint lost the TexasOnline contract to NIC, Kelly and I were laid off.

But by then I had spent years learning Texas government technology from inside the machine.

And that became extraordinarily valuable.

For the next several years I consulted across Texas.

I worked with AMD, reverse-engineering business processes and connecting requirements to strategic objectives and test scenarios for a global customer portal.

I worked with the Texas Workforce Commission, facilitating JAD sessions, documenting business rules, creating process flows and developing a case-weighting feature.

At the Texas Office of the Attorney General, I led junior business analysts and reviewed requirements, use cases and test scenarios for completeness and consistency.

At Travis County, I worked directly with CIO Tanya Acevedo, who would later become one of the more prominent public-sector technology executives in the country. I helped lead process-improvement and product-enhancement work across major initiatives.

Then at Charles Schwab, I worked between the business and engineering sides of StreetSmart Edge, Schwab's active-trading platform, helping define a newsfeed enhancement inside software being used by real investors making real financial decisions.

Different building.

Same problem.

Reality comes in.

The system represents it.

Rules operate.

Information comes out.

Something happens downstream.

My career continued through Benefitfocus and ValueLabs, where I eventually managed more than twenty business-analysis and QA resources working on payroll and integration delivery for a major benefits platform.

Then healthcare pulled me back in.

MedeAnalytics.

Net Health.

Home Health.

Hospice.

Wound Care.

At Net Health, I worked on cloud migration, legacy-product retirement, clinical integrations, UAT and the PointClickCare integration, where patient information had to move reliably between clinical systems.

Later I became Director of Operations at AMTdirect.

And eventually Director of IT Project Execution at Sevita, an enormous national community-based healthcare organization serving tens of thousands of people.

By then I had moved through almost every layer of software delivery.

Project coordinator.

Business analyst.

Project manager.

Product manager.

Program manager.

Product owner.

Director.

But I never really stopped doing the thing I had learned to do at the beginning.

Walk backward from the output.

Find the requirement.

Find the rule.

Find the decision.

Find the assumption.

Ask what happens when it goes wrong.

And ask who is responsible for making sure it doesn't.

For more than twenty-five years, that was my career.

I didn't know it yet, but those questions were preparing me for a very different kind of machine.

Because eventually the rules weren't going to be explicitly written by people like me.

The sentences weren't going to be the deterministic biopsychosocial narratives we had assembled from predefined paragraphs.

The machine was going to generate the sentences itself.

It was going to generate the explanations.

Generate the recommendations.

Generate the moral judgments.

Generate something that looked remarkably like reasoning.

And when that machine finally arrived, I found myself asking exactly the same question I'd been asking since the beginning of my career:

What governs the output?

That's where Part Two begins.

Why Anything and Alignment

If I had to reduce the thread running through my whole life and career to two ideas, they would be: why anything, and alignment.

Why anything? Why is this the way it is? Why does it work? Why is this rule true? Why is this output justified? Why is there truth, logic, morality, intelligibility, anything at all? That is the upstream question.

Then alignment: does the representation match reality? Does the requirement match the actual need? Does the software match the requirement? Does the output match the truth? Does the reasoning remain aligned all the way through?

Looking backward, those two questions were there long before I had the words Governed Logic. Why anything pushes toward the ground. Alignment asks whether everything downstream remains faithful to it.