RIVER Brief | Edition 6
Brice Ominski on digital momentum, change-ready architecture, and AI guardrails designed to survive the next technology cycle
That’s the safeguard logic Brice Ominski used when I asked whether the rising river of AI risk and opportunity is ultimately glass half full.
His answer points to a larger enterprise question:
Could your governance survive replacing today’s model, agent, or platform with tomorrow’s technology—or would every control have to be rebuilt?
Enhanced Website Edition: What This Adds
The LinkedIn edition makes the central argument:
Govern the outcome, not the technology.
This enhanced edition goes deeper. It adds:
→ the Control Portability Test for separating durable enterprise obligations from implementation-dependent controls;
→ a decision-rights map for authorization, detection, challenge, and stop authority;
→ the full Cognitive Handshake analysis behind the material-change detection question;
→ a downloadable prompt pack readers can use to pressure-test another article, interview, memo, or proposal.
Why it matters: An enterprise cannot preserve resilience through technology change unless it knows which safeguards must travel, who must detect when conditions change, and who can act when the original approval no longer holds.
Digital momentum is not speed
“Real digital momentum isn’t about speed or deploying technology. It’s about outcomes.”
Brice is an enterprise architecture leader and the author of Digital Momentum: Building Real Change-Ready Enterprises.
Many organizations still treat transformation as a sequence of large projects. Teams spend months or years building toward a target state and hope the world remains stable long enough for that target to matter.
It often does not.
Technology changes. Customer expectations shift. New partners and risks emerge. By the time a program delivers, the original outcome may no longer be the right one.
Digital momentum therefore means building an enterprise that can continue delivering the right outcomes as technologies and operating conditions change.
From architecture to an enterprise operating system
Brice offered one of the most useful reframings in our conversation:
“I don’t even like to think of it as an architecture. I think of it more as an operating system for the environment where the company operates.”
That operating system is not one platform. It is the combination of capabilities, decision rights, integration patterns, governance, data, and leadership practices that allows the enterprise to evolve without redesigning everything when a new technology appears.
A capability should endure even when its implementation changes. The enterprise still needs to serve customers, manage risk, make decisions, and integrate partners. The tools used to deliver those capabilities will keep changing.
A change-ready enterprise is designed so that those implementations can evolve without forcing the entire organization back into another multi-year transformation.
Govern the outcome, not today’s AI
Brice was equally direct about AI:
“AI is one technology of many, and we need to stay focused on outcomes.”
Today, leaders are focused on large language models, copilots, and agentic systems. The dominant implementation will continue to change.
Controls built too narrowly around one model, vendor, or architecture may become obsolete when the technology changes. Durable governance should instead define:
- what outcome the system is authorized to produce;
- what it is prohibited from doing;
- which decisions require escalation;
- what evidence must be captured;
- how leaders will know whether the outcome remains acceptable.
The technology may change. The enterprise’s obligations should not.
That does not mean controls can be designed independently of the technology. Governance objectives should endure, while the controls that enforce them must be replaceable, testable, and revalidated as models, vendors, data, permissions, workflows, integrations, and system boundaries change.
Inside the RIVER Connection: The Control Portability Test
A control can exist and still fail to travel.
When an organization replaces a model, vendor, agent, workflow, or platform, ask which safeguards are:
Assumption-dependent — valid only while autonomy, transaction value, affected population, or consequence remains within the approved range.
Enterprise-owned — expressed as durable policy, authority, evidence, and escalation requirements;
Platform-dependent — configured inside the current product or vendor;
Workflow-dependent — reliant on a particular review step or human intervention;
Data-dependent — effective only while inputs, permissions, provenance, and use remain unchanged;
Then ask:
Which controls would have to be rebuilt, retested, or independently revalidated if the implementation changed tomorrow?
Why it matters: A control that cannot travel may still be useful. But leaders need to know whether they approved an enterprise safeguard—or rented a safeguard from today’s implementation.
Human judgment moves upstream
The growth of faster, more autonomous systems does not eliminate human judgment. It changes where that judgment must occur.
As Brice explained:
“The human’s still in the loop, but they’re upfront deciding what’s acceptable policy.”
Boards and executives cannot rely on reviewing every decision after it occurs. Human responsibility moves upstream into defining authority, establishing boundaries, setting escalation conditions, requiring evidence, and reviewing whether the system remains within policy.
Architecture determines how capabilities operate. Governance determines the limits within which they may operate.
The objective is not to slow every system down. It is to embed guardrails that allow systems to move quickly without giving up accountability.
Inside the RIVER Connection: Human Judgment Needs Four Rights
Moving human judgment upstream does not mean merely adding a human approval somewhere in the process.
It requires four distinct decision rights:
Stop right
Who can restrict or suspend operation while safeguards are retested or reapproved?
Authorization right
Who defines what the capability may do?
Detection right
Who must identify when data, permissions, integrations, workflow, or autonomy have materially changed?
Challenge right
Who can question whether the capability still operates within its approved boundaries?
These rights may sit with different roles. The governance failure occurs when everyone can advise but no one can decide—or when one function owns the outcome but lacks the authority to stop the system.
Why it matters: Human judgment is not meaningfully “in the loop” unless someone has both the responsibility and authority to change the outcome before consequence scales.
The hidden tension: adaptability can also create fragility
Composability, integration, and automation can make an enterprise more adaptable. They can also create dependencies that no single person fully understands.
That is where speed can quietly create Risk Debt: accumulated liabilities from choices that favor immediate progress over validation, production readiness, data integrity, ownership, or long-term resilience.
The issue is not whether organizations should experiment with AI. It is whether those experiments have a credible path into a governed operating environment before they connect to real decisions, customers, and consequences.
When a policy survives—but its controls do not
Consider a hypothetical example: a company approves an AI-enabled customer-service agent. Its prohibited actions, escalation triggers, permissions, and evidence trail are configured inside the original vendor’s platform.
Six months later, the company changes vendors. The business outcome and written policy remain the same, but the new platform handles permissions, monitoring, and escalation differently.
If leaders assume the original approval transfers automatically, the policy may survive on paper while the controls that made it credible no longer operate as intended.
The question is no longer only whether the new technology works. It is whether the organization has revalidated the authority, boundaries, evidence, and accountability attached to it.
The Outcome Guardrail Test
Before approving—or materially changing—an AI-enabled capability, leaders should be able to answer six questions:
- Outcome — What business outcome is the capability authorized to produce?
- Boundary — What is it prohibited from deciding or doing?
- Escalation — Which conditions require accountable human judgment?
- Evidence — What proves that its decisions and actions remain within acceptable limits?
- Durability — Would these safeguards still work if the model, vendor, data, permissions, workflow, integration, or level of autonomy changed?
- Accountability — Who decides whether a material change requires retesting, reapproval, restriction, or suspension?
If leaders cannot answer the fifth and sixth questions, the organization may have implemented controls around today’s technology without establishing governance that can survive tomorrow’s change.
Behind the Brief: The Cognitive Handshake Lens
I ran this edition through a Cognitive Handshake review to test whether it changed leadership judgment before action—not simply whether the argument sounded persuasive.
The review asked what decision this article should affect, where its reasoning was strongest, what assumption remained vulnerable, and which question was still missing.
Decision this piece should affect
Should an organization allow an AI-enabled capability to continue operating under its original approval after a material change in its model, vendor, data, permissions, integrations, workflow, or autonomy?
Strongest idea
Governance objectives should outlast individual technologies. The most durable safeguard is not a control built around one product; it is an enterprise obligation supported by controls that can be tested, replaced, and revalidated.
Weakest assumption
The argument can sound as though governance and technology can be cleanly separated. They cannot.
The obligation may endure, but the controls enforcing it may be highly implementation-specific. A new model, vendor, workflow, or permission structure can change monitoring, evidence, escalation, data exposure, and failure modes even when the business purpose remains the same.
Missing question
How would the organization know that the conditions supporting the original approval had materially changed?
Accountability begins only after the change is detected. A capability can retain the same name, owner, and stated purpose while its actual authority or risk profile changes underneath it.
Practical action test
A leader should be able to take one approved AI capability and identify:
what evidence proves the safeguards still operate as intended.
the assumptions supporting its current approval;
which technical or operating changes could invalidate those assumptions;
how the organization would detect those changes;
who determines whether they are material;
who can require retesting, restriction, reapproval, or suspension;
Scores from the read
Actionability Score: 9.2/10
Cognitive Handshake Decision Score: 9.1/10
Made-to-Stick Score: 8.8/10
Why it matters: The score is not the main result. The missing detection question is. An organization cannot revalidate a capability if no one knows that the conditions supporting its approval have changed.
This is where enterprise architecture and AI governance stop being separate conversations. They become two sides of the same executive decision.
Where the two books connect
Digital Momentum focuses on how enterprises build the architectural and leadership capacity to keep changing as technologies and ecosystems evolve.
My forthcoming book, Governing AI Risk — The RIVER Charter, addresses the complementary obligation: how leaders preserve resilience, accountability, evidence, trust, and human judgment as those systems move faster and become more interconnected.
One builds the capacity for continuous change.
The other asks how that change remains governable.
Together, they point toward the same leadership challenge:
Build the capacity to change. Govern the risks that change creates.
Watch the full conversation
Brice, congratulations again on Digital Momentum—and thank you for a thoughtful Cognitive Handshake.
Which of your current AI safeguards would stop working first if the underlying technology changed tomorrow?
And who has the authority to suspend the capability until those safeguards are revalidated?
Alex’s Governing AI Risk – The RIVER Charter Book
Try the Cognitive Handshake Read Yourself
You can use this prompt on any article, interview, memo, report, or argument you want to pressure-test.
Try it here in ChatGPT: Cognitive Handshake GPT
Learn more: Cognitive Handshake
See initial and followup prompts below In the example prompt pack.
Why it matters: Cognitive Handshake is designed to move from faster answers to better judgment before action. The prompt gives readers a way to test another article for decision quality.
