It’s been several years since generative AI and large language models (LLMs) took the world by storm. LLMs surpassed earlier natural-language systems at generating text, while diffusion models enabled generating images, music, and videos.

These generative AI models work well in the digital world, but on their own, they have limited capabilities to comprehend the three-dimensional physical world and other spaces. This includes the objects occupying an area, how they relate to each other, tracking movement, and answering complex questions requiring an understanding of dimensions, distances, motion, and collisions.

Spatial intelligence is an AI capability that allows models to reason about three-dimensional space. These models can generate 3D scenes of the world and other spaces. This content can then be displayed through traditional renderers, game engines, or AR/VR systems that use spatial computing techniques. But it’s the spatial intelligence model’s ability to connect natural language with 3D models that has the most applications in robotics, manufacturing, construction, and other physical environments.   

Dr. Fei-Fei Li, often called the godmother of AI, published a manifesto on how spatial intelligence is AI’s next frontier, contrasting it with LLMs. “While current state-of-the-art AI can excel at reading, writing, research, and pattern recognition in data, these same models bear fundamental limitations when representing or interacting with the physical world,” wrote Dr. Li. “Our view of the world is holistic—not just what we’re looking at, but how everything relates spatially, what it means, and why it matters. Understanding this through imagination, reasoning, creation, and interaction—not just descriptions—is the power of spatial intelligence.”

The concept of spatial intelligence isn’t new and was described in Howard Gardner’s book, Frames of Mind, in 1983. Recent breakthroughs, including the launch of World Labs’ Marble and its $1 billion funding round, and competing approaches from Google’s Genie 3 and Nvidia Cosmos, should put spatial intelligence and world models on more R&D road maps.

What are spatial intelligence models?

It’s important to develop AI literacy and understand the terminology and concepts related to the physical world and 3D AI technologies: 

• Spatial intelligence encompasses specialized approaches such as geospatial models for mapping the physical world and building information modeling (BIM) for modeling physical structures. It also extends to generative 3D, robotics, and physical reasoning applications.
• World models are a class of neural network architectures and are currently a prominent approach to building spatial intelligence.
• Digital twins are live, virtual replicas of physical assets that combine 3D models with real-time sensor data. Spatial intelligence, an emerging capability of digital twins, adds natural-language prompting, generative scenario exploration, and physics-aware reasoning.
• Spatial computing refers to digital content anchored in and interacting with physical space, sensed and rendered in three dimensions and delivered through AR/VR and mixed-reality systems.

“Spatial intelligence models go beyond pixels to understand the 3D structure of the world—how objects are positioned, how they move, and how they interact,” says David Fattal, founder and CTO at Leia. “This enables applications like more realistic video generation, spatial computing interfaces, and AI systems that can reason about physical environments. As real-world 3D data becomes more available, these models will become foundational to the next generation of visual AI.”

Monitoring the built environment

To better understand spatial intelligence, let’s consider physical infrastructure such as bridges and buildings. The American Society of Civil Engineers estimates a $9.1 trillion investment is needed from 2024 through 2033 to achieve a state of good repair. When maintenance and monitoring lag, it can lead to major failures such as the 2022 collapse of the Fern Hollow Bridge in Pittsburgh.

Spatial intelligence and the development of digital twins may help identify issues earlier and prioritize where investments are needed. “Spatial intelligence models serve as the 4D digital blueprints for our built environment, allowing us to visualize and predict the complex interactions between aging assets and the shifting ground beneath them,” says Patrick Cozzi, chief platform officer at Bentley Systems. “By synthesizing disparate geospatial data into a living digital twin, these models provide the foresight necessary to mitigate the hidden risks of structural fatigue and subsurface instability.”

There’s a significant challenge in bridge health monitoring and transitioning from manual, infrequent structural inspections to leveraging sensors, digital twins, and spatial intelligence. Cozzi adds, “This integration of continuous field data moves beyond static documentation, empowering agencies to evolve from reactive repairs to proactive, resilient asset management that safeguards the long-term integrity of our most critical public systems.”

Avoiding collisions

Bridges are largely static, but the real world is increasingly being occupied by autonomous systems such as self-driving cars, robots, and drones. And where there are moving systems, there is a risk of collisions.

“Spatial intelligence models are AI systems that reason about the physical world by combining vision, sensor data, and contextual cues to understand space, motion, and object relationships,” says Sudeep George, CTO at iMerit. “The value of spatial intelligence models lies not just in perceiving an environment, but in enabling machines to act within it safely and in real time. That is especially important in robotics and autonomous systems, where decisions must be made in complex, multimodal, fast-changing settings.”

To see one example, this tutorial for simulating robotic environments combines Nvidia Isaac Sim, an open source robotics reference framework, with spatial intelligence in Marble from World Labs. 

Today’s collision detection systems, such as those used in autonomous vehicles, typically rely on modules for sensing, perception, planning, and control. Spatial intelligence models may offer improvements by assessing the collision risks of unidentified objects or by tracking objects that move out of sensor view. For example, Waymo’s World Model, built on Genie 3, is a simulator that generates complex weather conditions and other critical safety events.

For an out-of-this-world example, James Urquhart, field CTO and technology evangelist at Kamiwaza, has delivered several examples of spatial intelligence applications, including one for satellite collision detection and conflict analysis. Urquhart says, “Models that specialize in these types of data sets, as well as the physics and geography of the real world, enable faster and more accurate decision-making for tasks that depend on them.”

Applying spatial intelligence

Recent spatial intelligence announcements include creating 3D worlds from image or text prompts with Marble and simulating water physics, lighting, weather, and animal behavior with Genie 3. But difficulties remain in bringing spatial intelligence to physical-world use cases.

“Spatial intelligence and world models are laying the groundwork for future AI agents that will be able to interact in and with our physical world,” says Jason Corso, cofounder and chief scientist at Voxel51. “These models are significantly more challenging to develop and test, largely because the data underlying their development is complex, and it’s hard to handle all of the combinatorics involved in the physical world.”

In addition to learning the models and prototyping with them, development and data leaders need to review the data assets that will feed spatial intelligence models. “Spatial intelligence models translate location signals into a structured understanding of the real world, but they’re only as reliable as the data beneath them,” says Dan Adams, executive vice president and general manager of Enrich at Precisely. “The real unlock isn’t the model—it’s the reference layer with persistent identifiers, confidence metadata, and source lineage that lets AI reason about places, not just match strings.”

Even once applications are developed, there will be infrastructure challenges in deploying them at the edge. Ali Kayyam, principal research scientist at BrainChip, says, “The key to unlocking spatial intelligence at scale is having the low-power, event-driven hardware that can run it at the sensor in real time where it matters most.”

Where to get started

My suggestions for developers looking to get hands-on with spatial intelligence and world models:

• To try out Marble, review their API documentation and case studies, and then experiment with a developer-focused React application.
• Review the Nvidia Cosmos developer hub, documentation, and cookbook of case studies and learning paths.
• You can get an overview of Genie 3, but access is currently restricted through Project Genie, which requires a Google AI Ultra subscription.

It’s been several years since generative AI and large language models (LLMs) took the world by storm. LLMs surpassed earlier natural-language systems at generating text, while diffusion models enabled generating images, music, and videos.

These generative AI models work well in the digital world, but on their own, they have limited capabilities to comprehend the three-dimensional physical world and other spaces. This includes the objects occupying an area, how they relate to each other, tracking movement, and answering complex questions requiring an understanding of dimensions, distances, motion, and collisions.

Spatial intelligence is an AI capability that allows models to reason about three-dimensional space. These models can generate 3D scenes of the world and other spaces. This content can then be displayed through traditional renderers, game engines, or AR/VR systems that use spatial computing techniques. But it’s the spatial intelligence model’s ability to connect natural language with 3D models that has the most applications in robotics, manufacturing, construction, and other physical environments.   

Dr. Fei-Fei Li, often called the godmother of AI, published a manifesto on how spatial intelligence is AI’s next frontier, contrasting it with LLMs. “While current state-of-the-art AI can excel at reading, writing, research, and pattern recognition in data, these same models bear fundamental limitations when representing or interacting with the physical world,” wrote Dr. Li. “Our view of the world is holistic—not just what we’re looking at, but how everything relates spatially, what it means, and why it matters. Understanding this through imagination, reasoning, creation, and interaction—not just descriptions—is the power of spatial intelligence.”

The concept of spatial intelligence isn’t new and was described in Howard Gardner’s book, Frames of Mind, in 1983. Recent breakthroughs, including the launch of World Labs’ Marble and its $1 billion funding round, and competing approaches from Google’s Genie 3 and Nvidia Cosmos, should put spatial intelligence and world models on more R&D road maps.

What are spatial intelligence models?

It’s important to develop AI literacy and understand the terminology and concepts related to the physical world and 3D AI technologies: 

• Spatial intelligence encompasses specialized approaches such as geospatial models for mapping the physical world and building information modeling (BIM) for modeling physical structures. It also extends to generative 3D, robotics, and physical reasoning applications.
• World models are a class of neural network architectures and are currently a prominent approach to building spatial intelligence.
• Digital twins are live, virtual replicas of physical assets that combine 3D models with real-time sensor data. Spatial intelligence, an emerging capability of digital twins, adds natural-language prompting, generative scenario exploration, and physics-aware reasoning.
• Spatial computing refers to digital content anchored in and interacting with physical space, sensed and rendered in three dimensions and delivered through AR/VR and mixed-reality systems.

“Spatial intelligence models go beyond pixels to understand the 3D structure of the world—how objects are positioned, how they move, and how they interact,” says David Fattal, founder and CTO at Leia. “This enables applications like more realistic video generation, spatial computing interfaces, and AI systems that can reason about physical environments. As real-world 3D data becomes more available, these models will become foundational to the next generation of visual AI.”

Monitoring the built environment

To better understand spatial intelligence, let’s consider physical infrastructure such as bridges and buildings. The American Society of Civil Engineers estimates a $9.1 trillion investment is needed from 2024 through 2033 to achieve a state of good repair. When maintenance and monitoring lag, it can lead to major failures such as the 2022 collapse of the Fern Hollow Bridge in Pittsburgh.

Spatial intelligence and the development of digital twins may help identify issues earlier and prioritize where investments are needed. “Spatial intelligence models serve as the 4D digital blueprints for our built environment, allowing us to visualize and predict the complex interactions between aging assets and the shifting ground beneath them,” says Patrick Cozzi, chief platform officer at Bentley Systems. “By synthesizing disparate geospatial data into a living digital twin, these models provide the foresight necessary to mitigate the hidden risks of structural fatigue and subsurface instability.”

There’s a significant challenge in bridge health monitoring and transitioning from manual, infrequent structural inspections to leveraging sensors, digital twins, and spatial intelligence. Cozzi adds, “This integration of continuous field data moves beyond static documentation, empowering agencies to evolve from reactive repairs to proactive, resilient asset management that safeguards the long-term integrity of our most critical public systems.”

Avoiding collisions

Bridges are largely static, but the real world is increasingly being occupied by autonomous systems such as self-driving cars, robots, and drones. And where there are moving systems, there is a risk of collisions.

“Spatial intelligence models are AI systems that reason about the physical world by combining vision, sensor data, and contextual cues to understand space, motion, and object relationships,” says Sudeep George, CTO at iMerit. “The value of spatial intelligence models lies not just in perceiving an environment, but in enabling machines to act within it safely and in real time. That is especially important in robotics and autonomous systems, where decisions must be made in complex, multimodal, fast-changing settings.”

To see one example, this tutorial for simulating robotic environments combines Nvidia Isaac Sim, an open source robotics reference framework, with spatial intelligence in Marble from World Labs. 

Today’s collision detection systems, such as those used in autonomous vehicles, typically rely on modules for sensing, perception, planning, and control. Spatial intelligence models may offer improvements by assessing the collision risks of unidentified objects or by tracking objects that move out of sensor view. For example, Waymo’s World Model, built on Genie 3, is a simulator that generates complex weather conditions and other critical safety events.

For an out-of-this-world example, James Urquhart, field CTO and technology evangelist at Kamiwaza, has delivered several examples of spatial intelligence applications, including one for satellite collision detection and conflict analysis. Urquhart says, “Models that specialize in these types of data sets, as well as the physics and geography of the real world, enable faster and more accurate decision-making for tasks that depend on them.”

Applying spatial intelligence

Recent spatial intelligence announcements include creating 3D worlds from image or text prompts with Marble and simulating water physics, lighting, weather, and animal behavior with Genie 3. But difficulties remain in bringing spatial intelligence to physical-world use cases.

“Spatial intelligence and world models are laying the groundwork for future AI agents that will be able to interact in and with our physical world,” says Jason Corso, cofounder and chief scientist at Voxel51. “These models are significantly more challenging to develop and test, largely because the data underlying their development is complex, and it’s hard to handle all of the combinatorics involved in the physical world.”

In addition to learning the models and prototyping with them, development and data leaders need to review the data assets that will feed spatial intelligence models. “Spatial intelligence models translate location signals into a structured understanding of the real world, but they’re only as reliable as the data beneath them,” says Dan Adams, executive vice president and general manager of Enrich at Precisely. “The real unlock isn’t the model—it’s the reference layer with persistent identifiers, confidence metadata, and source lineage that lets AI reason about places, not just match strings.”

Even once applications are developed, there will be infrastructure challenges in deploying them at the edge. Ali Kayyam, principal research scientist at BrainChip, says, “The key to unlocking spatial intelligence at scale is having the low-power, event-driven hardware that can run it at the sensor in real time where it matters most.”

Where to get started

My suggestions for developers looking to get hands-on with spatial intelligence and world models:

• To try out Marble, review their API documentation and case studies, and then experiment with a developer-focused React application.
• Review the Nvidia Cosmos developer hub, documentation, and cookbook of case studies and learning paths.
• You can get an overview of Genie 3, but access is currently restricted through Project Genie, which requires a Google AI Ultra subscription.

Enterprises do not suffer from a lack of oversight. They have dashboards, risk forums, architecture boards, vendor reviews, cyber controls, transformation offices, capital committees, regulatory programs, audit findings, service reports and enough status updates to make even the most patient executive reach for stronger coffee.

The issue is not that senior leaders fail to recognize activity, but that they often miss understanding where the consequences will lead next.

A technology issue does not stay within technology. A control weakness does not stay within compliance. A vendor failure does not stay within procurement. A data-quality gap does not stay within a data office. A cyber incident does not stay within security. An AI initiative does not stay within innovation.

It extends to customer trust, regulatory exposure, operating capacity, capital allocation, scarce talent, legal risk, vendor obligations, brand credibility and strategic freedom.

That is why every enterprise now needs a consequence layer: a connected way for senior executives to see what else moves when something changes. Not another dashboard, system of record or management ritual.

Local failures no longer stay local

Enterprise failures are often described by where they start rather than by where they end. Knight Capital remains one of the clearest examples because the entire episode unfolded in less than an hour. According to the SEC’s order on Knight Capital, a software deployment issue generated more than 4 million executions across 154 stocks in about 45 minutes, leaving the firm with roughly $3.5 billion in net long positions, $3.15 billion in net short positions and a $460 million loss. A technical failure became a capital, regulatory and strategic event.

That is not just a trading story. It is a warning about enterprise coupling. A code path, a deployment gap, market access, execution speed and weak controls were linked. The enterprise did not see the connection until the market did.

TSB Bank offers a modernization version of the same lesson. In 2018, TSB migrated customer and corporate services to a new platform. The data itself migrated successfully, but the platform immediately experienced technical failures that disrupted branch, telephone, online and mobile banking. The FCA later announced that TSB had been fined £48.65 million for operational resilience failings tied to the upgrade program.

TD Bank shows the control version. In 2024, FinCEN assessed a record $1.3 billion penalty against TD Bank and imposed a four-year independent monitorship tied to anti-money-laundering failures. The OCC separately imposed a $450 million civil money penalty and a growth restriction. A control issue became an enterprise constraint.

The original issue is rarely the whole issue. It is just where the consequence first became visible.

The formal view is not the whole enterprise

Most large organizations are still managed through functional silos. Technology has its systems. Finance has its systems. Risk has its systems. Compliance has its systems. Operations has its systems. Business units have their workflows, spreadsheets, local tools and local truths. That is not inherently a flaw. At enterprise scale, different teams need different systems because they do different work.

The danger is pretending those boundaries reflect how consequences behave. They do not.

A strategic initiative may appear healthy in the formal portfolio view. The milestone is green. The budget is approved. The steering committee is comfortable. Meanwhile, the same data teams, security reviewers, infrastructure groups, vendors, release windows, compliance resources and business experts may be committed elsewhere.

The project is green in one system. The capacity is gone in another. The dependency is buried in a third.

This is where the consequence layer matters. It does not replace the systems teams already use. It sits above them, connecting the enterprise logic across them. It does not need to own every workflow or transaction. It needs to understand how work, capacity, funding, timing, dependencies, vendors, risks, controls and value interact.

A consequence layer limited to the strategic portfolio is incomplete by design. The constraint that undermines the strategy may lie in operations, cyber, vendor management, data quality, regulatory remediation, customer service, finance or shared technical capacity. If those signals are outside the model, leadership may get a clean view of the portfolio and still miss the enterprise reality.

Dashboards show position. They rarely show blast radius

Dashboards matter. Reporting matters. Governance matters. But visibility is not the same as control over consequences.

A dashboard may show that a major platform program is delayed, a vendor SLA has slipped, a cyber risk has increased or a customer metric has deteriorated. What it often fails to show is the blast radius.

Which commitments are now less realistic? Which teams are about to be overdrawn? Which customer journeys are affected? Which regulatory dates are at risk? Which cost assumptions no longer hold? Which downstream initiatives now depend on heroic recovery?

Silicon Valley Bank is a stark reminder that assumptions can collapse with extraordinary force. The FDIC reported that by the end of March 9, 2023, $42 billion in deposits had left the bank. A balance-sheet assumption, depositor concentration, social amplification, liquidity exposure and digital banking behavior converged into a real-time institutional crisis. The point is not that every enterprise faces an SVB-style event. The point is that assumptions are no longer safely confined to one domain.

Resilience work is already pointing to the consequence layer

Regulators are pushing financial institutions toward this realization, although they use different vocabulary. The Bank of England’s operational resilience guidance expects firms to identify important business services and test whether they can remain within impact tolerances under severe but plausible scenarios. DORA applies a similar logic across the EU financial sector, including oversight of critical third-party ICT providers whose failures could affect operational resilience.

This is not just compliance work. It is a map of enterprise consequences.

Important business services, third-party dependencies, recovery tolerances, cyber scenarios, critical operations and service continuity are not side documents for risk teams. They are the organization’s wiring diagram.

If that wiring diagram sits apart from technology roadmaps, investment commitments, capacity constraints, AI demand, vendor strategy and customer obligations, the enterprise has only partial control.

This also connects to the project and transformation profession. PMI’s Manifesto for Enterprise Agility frames enterprise agility around adapting at scale without losing coherence, and PMI’s 2025 Pulse of the Profession emphasizes the shift from tactical troubleshooting to strategic value creation. A consequence layer helps the enterprise adapt without losing the thread between commitment, capacity, risk and value.

The CIO may see the systems. The CRO may see the control exposure. The CFO may see the funding and capital implications. The COO may see the operating strain. The business may see customer and revenue impact. The consequence does not care which executive owns the first signal. It travels anyway.

AI adds new consequence paths

AI does not reduce consequence complexity. It increases it.

Every AI use case creates new enterprise edges: data readiness, model risk, explainability, privacy, security, cloud cost, workflow redesign, legal exposure, human adoption, vendor reliance and value measurement. The risk is not only hallucination or misuse. It is untested assumptions presented with executive polish.

A leadership team can approve an AI ambition in one room and discover months later that the real constraint lives in model-risk capacity, data lineage, customer consent, cloud architecture or operational absorption. That is not an AI problem alone. It is the absence of a consequence layer wearing an AI badge.

AI value depends on technology, yes, but also on risk, legal, finance, operations, HR, customer experience and the business model itself.

Manual consequence tracking will not scale

This cannot be solved through another standing meeting. The people involved are not the problem. They know their domains, the risks, the workarounds and where the bodies are buried, sometimes in a spreadsheet named something like “final_final_v9.” The issue is scale.

Every serious enterprise move now touches systems, people, controls, vendors, data, security, funding, customers, regulators and operating tolerance. The number of interactions grows faster than any manual review process can keep up with.

If a regulatory program accelerates, which modernization work gets displaced? If AI demand expands, which data, legal, cyber, architecture, privacy and model-risk teams are now consumed? If a core migration slips, which cost-takeout, customer migration, vendor and operating assumptions move with it? If funding tightens, which initiatives still make sense and which business cases are quietly eroding?

Those questions require a consequence layer. Not to make the call. To make the call more honest. The math should not replace judgment. But judgment without connected consequence math becomes too dependent on meetings, memory, optimism and politics.

The lesson extends well beyond banking

CrowdStrike made the ecosystem lesson visible across industries. Microsoft estimated that the July 2024 update affected 8.5 million Windows devices, less than one percent of all Windows machines. Microsoft also wrote that the incident demonstrated “the interconnected nature” of the technology ecosystem. Small percentage. Large consequence. The details are in Microsoft’s CrowdStrike outage update.

Change Healthcare showed a similar pattern in healthcare. The American Hospital Association described the February 2024 cyberattack as disrupting health care operations on an unprecedented national scale, endangering patient access, disrupting clinical and eligibility operations and threatening provider solvency. A separate Office of Financial Research brief described the disruption as triggering a “medical sector liquidity event.”

Manufacturing sees the same pattern when a supplier delay hits sequencing, inventory, commitments, margin and revenue. Retail sees it when demand or data-quality issues move from merchandising into warehouses, stores, pricing and customer trust. Utilities see it when grid delays affect reliability targets, field crews, regulators and outage response.

Different industries. Same structure. The original issue is local. The consequence is not.

From visibility to consequence

The dashboard era trained executives to ask, “What is the status?” The consequence layer asks a harder question: “What else moves because this moved?”

That question now sits at the center of modernization, operational resilience, AI governance, third-party risk, cyber preparedness, regulatory credibility, customer trust and enterprise value.

The next leadership advantage depends not on generating more activity metrics, but on proactively detecting consequence movements early—before they escalate into losses, outages, fines, stranded investments, customer harm or the loss of strategic freedom.

Every serious enterprise has systems of record. What many still lack is a system of consequence.

Not another dashboard or workflow tool. A consequence layer gives senior leaders a way to test what happens when priorities, capacity, timing, funding, risk, vendors and dependencies pull in opposite directions.

That is the missing space between strategy and execution. In a complex enterprise, the original issue is rarely the whole issue. It is just where the consequence first became visible.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

We are auditing a curated version of history.

I’ve worked in security long enough now to know something most of us don’t really say out loud. A lot of compliance is theatre. Not all of it, and not all auditors or frameworks, but enough of it that most experienced CISOs know exactly what I mean. If you understand how audits work, know how controls are interpreted and can manage scope and narrative well enough, you can often steer things where you need them to go.

That’s uncomfortable to admit, but it’s true. The market now treats things like SOC 2 and ISO 27001 as direct statements about operational maturity and security posture when they really aren’t. They are snapshots. Point-in-time reviews based on selected evidence and sampled testing. That doesn’t make them useless. These frameworks were built for a completely different world where cloud infrastructure was less dynamic, APIs weren’t everywhere and continuous telemetry at scale simply wasn’t realistic. Sampling existed because there wasn’t much of an alternative. That’s before we even mention AI, where technology now changes on a monthly cadence against a regulatory backdrop that speaks in years.

The issue is that the world moved on, but assurance largely didn’t. The team behind  FedRAMP 20x are attempting to address exactly that problem, pushing assurance towards automation, machine-readable evidence and continuous validation rather than documentation-heavy compliance exercises. Most compliance programs still revolve around screenshots, exported evidence, manually curated narratives and carefully staged representations of reality. And that word, reality, is the important bit because in many cases, we are not auditing reality at all. We are auditing a curated version of history.

That’s why one of the most important things I’ve heard said around FedRAMP 20x is this: Passing audits does not equal security.

Exactly. A company can pass an audit while engineers bypass processes every Friday night to hit deadlines. Controls can drift quietly over time while nobody notices because the evidence only exists for a specific audit window. The audit passes because the story passes, and honestly, I think that’s the bit the industry is becoming increasingly uncomfortable with. How many times a year is the production push made as a “hot fix”?

And honestly, I think that’s why movements like GRC engineering are getting so much traction. Not because people suddenly wanted a trendy new title for compliance. But because there’s growing frustration with how artificial parts of the industry have become.

A few months ago, I gave a talk in Seattle comparing the rise of GRC engineering to the rise of grunge music. I’m a huge Nirvana fan, so maybe the analogy was inevitable, but the more I thought about it, the more it made sense. Grunge didn’t emerge because people desperately wanted something shiny and new. It emerged because people stopped believing the polished version was real. Hair metal had become overproduced and performative. Grunge felt rough around the edges, but it also felt honest.

That’s exactly where GRC feels like it is right now. Too much compliance has become about presenting the cleanest possible version of reality instead of exposing operational truth. Too many clean reports. Too many green ticks on trust centers. Too many perfect policies.

The sat nav problem

Which brings me to one of the dumbest weekends of my life.

Many years ago, my wife decided she wanted to go glamping in the Lake District for Valentine’s Day.

We drove north through classic, miserable British weather in a tiny little car completely unsuited for what was coming.

As we got closer to the Lakes, the rain slowly turned into heavy snow.

Then a full blizzard.

The sat nav confidently directed us up a tiny snow-covered road that we physically could not drive up.

We got stuck.

Eventually, we got free.

The sat nav recalculated and sent us up another equally impossible road.

Same outcome.

This happened multiple times until we eventually ended up buried in a snow drift somewhere in the middle of nowhere, waiting for a bloke in a 4×4 to rescue us while trying not to laugh too hard at the idiots in the tiny car.

After about seventeen hours of driving, we gave up and drove home.

Completely failed Valentine’s trip.

But honestly, I think about that weekend a lot when I think about GRC because the sat nav had data. What it lacked was context. It didn’t understand the environment, the conditions, the capability of the vehicle or even the actual outcome we were trying to achieve. We became obsessed with following the prescribed route instead of stepping back and asking whether the route itself still made sense. It reminds me of stories like tourists literally driving into the sea while blindly following GPS directions. The problem wasn’t the absence of data. The problem was understanding the context around the data.  Tourists drive into sea following GPS directions.

A lot of compliance programs behave the same way. The objective quietly becomes “pass the audit” instead of “reduce meaningful risk”, and once that happens, teams start optimising for the framework rather than the security outcome. That’s the shift I think FedRAMP 20x and the broader GRC engineering movement are trying to force. Not just better automation or more integrations, but a fundamentally different way of thinking about trust.

Compliance becomes an engineering problem

One of the central ideas behind FedRAMP 20x is that assurance increasingly needs to be treated as an engineering challenge rather than a documentation exercise.

Historically, most compliance has been based on samples. Sampled pull requests, sampled access reviews and sampled infrastructure evidence. FedRAMP 20x pushes in a very different direction with machine-readable evidence, APIs, telemetry and complete datasets instead of manually curated snapshots. Many of these principles closely mirror those outlined in the GRC Engineering Manifesto, which argues that modern assurance should be built on automation, telemetry and engineering disciplines rather than static evidence collection.

One of the biggest mindset shifts for our engineering teams was realising FedRAMP wasn’t really asking for selected evidence anymore. They wanted the underlying operational data itself. Not a screenshot proving something was configured correctly on one specific day, but the actual flow of telemetry that underpinned the control or assurance statement. That’s a completely different way of thinking about compliance because the conversation moves away from “prove this existed once” and towards “show me the operational reality continuously.”

Instead of showing a screenshot proving a virtual machine was configured correctly on one day, you expose every VM in the environment alongside drift data over time.

Instead of selecting a handful of GitHub pull requests, you expose the entire development workflow, including the messy bits where processes were bypassed.

Instead of showing sampled JML evidence, you expose the full lifecycle history of identity management over years.

Honestly, it should feel uncomfortable because that discomfort is probably a sign you’re finally exposing operational truth instead of polishing it away. Trust shouldn’t come from perfection. It should come from transparency.

We thought we were ready

And honestly, that’s exactly why our own FedRAMP 20x journey became so interesting.

We originally planned to move towards moderate through a much longer runway. Then the programme timings changed, government shutdowns caused disruption, and suddenly we found ourselves with around six or seven weeks before audit activity started.

We thought we had a solid plan.

We didn’t.

Or at least not one that was mature enough yet.

We had missed the low pilot earlier in the journey and entered the moderate phase without having already gone through that foundational learning process. We were also the only organization in our pilot group that hadn’t already completed the low pathway first.

That mattered.

We didn’t yet have the operational muscle memory.

No established playbook.
No previous iteration.
No deeply embedded understanding of how this model actually behaved in practice.

At the same time, we weren’t trying to approach FedRAMP 20x like traditional compliance.

We built direct API connectivity that allowed FedRAMP and auditors to pull complete machine-readable datasets in JSON format directly from the platform. Human-readable exports still existed where required, but the focus was on exposing operational truth rather than curating static evidence.

That’s also one of the core principles behind FedRAMP 20x itself. Controls increasingly need to be both machine-readable and human-readable. The baseline expectation is that a large percentage of controls should be automated with continuous evidence flowing behind them instead of static evidence being manually assembled before an audit.

What that means in practice is that auditors no longer just review a point-in-time evidence pack. They gain ongoing visibility into operational datasets and can interrogate those environments in a much more dynamic way.

That’s a very different mindset from traditional compliance.

And honestly, I think that difference is part of what made the journey so valuable.

We didn’t fail. We iterated

Because I don’t actually think what happened next was failure.

I think it was iteration.

Modern engineering teams don’t release perfect software on day one. They test, rebuild, refactor, improve and iterate continuously based on telemetry and feedback.

Applications go through:

• Testing
• User feedback
• Redesign
• Bug fixing
• Telemetry analysis
• Continuous improvement

Nobody expects version one to be perfect.

Yet historically, GRC has behaved completely differently.

Build the controls.
Collect the evidence.
Pass the audit.
Repeat next year.

The audit becomes the finish line. Our finish line became a “good effort,” “we think you’re ready for a Low authorization, but not Moderate just yet.” For a moment, it felt like failure. It hurt. It felt fundamentally different from any other assessment or audit as we genuinely didn’t know what we’d achieved. In fact, FedRAMP 20x feels fundamentally different and maybe that’s the whole point.

The process itself became feedback.

Not: Can you tell a convincing enough story?

But: What does your environment actually look like and how do you continuously improve it?

That’s a completely different mindset.

One of the recurring themes throughout FedRAMP 20x is that assurance should improve through continuous iteration rather than annual point-in-time validation.

Exactly.

That’s how engineering works.

The Low authorization wasn’t the end state. It was a checkpoint and a recalibration moment that helped us understand where the next iteration needed to go.

And honestly, if you can speedrun moderate FedRAMP with perfectly polished dashboards and no uncomfortable truths exposed, then the framework probably isn’t doing its job.

That’s one of the things I genuinely appreciate about FedRAMP 20x.

It challenges your assumptions.

It forces you to rethink approaches that have become normalized across large parts of the compliance industry.

Historically, proving infrastructure security often meant screenshots or exported configs. Now we can expose every VM, every drift event and the full history of posture changes across the environment.

That changes behavior massively because you can no longer optimize around the cleanest possible sample. You have to maintain the actual posture continuously.

Historically, proving SDLC maturity meant selecting a handful of pull requests. Now we can expose the entire workflow, including every bypassed approval or manual push into production.

Historically, proving identity governance meant sampled JML reviews. Now we can expose the operational history of the full identity lifecycle over years.

And honestly, that was one of the areas that challenged some of our own assumptions the most.

Traditional sampled evidence can make processes look consistently successful because you’re only reviewing selected examples. But operational truth is different. You only need one joiner, mover or leaver process to fail in the wrong way for the risk to become real.

That’s exactly the kind of thing continuous operational visibility exposes much more quickly than traditional evidence collection.

That’s not just better evidence.

It’s a fundamentally different philosophy of assurance.

The rise of GRC engineering

And this is where I think GRC engineering becomes genuinely important.

Not because everybody suddenly needs to become a software engineer, but because the discipline itself is evolving from a documentation exercise into an operational engineering problem.

Modern GRC teams are increasingly building telemetry pipelines, integrations, APIs, infrastructure visibility and continuous assurance layers. And honestly, some of those pipelines are much harder to build than people realize. Cloud infrastructure, CSPM tooling and application security platforms are relatively straightforward because the data is already fairly structured and accessible. The really difficult parts are the messy operational systems that organizations historically handled through process and human coordination.

Things like policy management workflows, budget approvals, software bill of materials tracking and non-standard operational processes are far harder to standardize and expose consistently.

That’s another reason this shift matters so much. It forces organizations to operationalize areas that historically lived in spreadsheets, meetings or tribal knowledge.

That’s a very different skillset from managing spreadsheets and coordinating screenshots.

More importantly, it changes the conversations.

One of the things I enjoyed most throughout the FedRAMP 20x process was that discussions increasingly stopped being: How do we satisfy this control?

And became: What risk are we actually trying to reduce here?

That’s such a healthier conversation for security teams to have. Because not every risk matters equally to every organization. Not every control meaningfully improves security posture. Not every framework requirement deserves the same operational investment.

Traditional compliance often struggles with that nuance because it optimizes around consistency and uniformity.

Modern engineering-led assurance feels different.

It feels more contextual, more operational and honestly far more honest.

And honestly, honesty is probably the biggest thing missing from large parts of compliance today.

We’ve built an industry where everyone feels pressure to look perfect.

Perfect dashboards. Perfect controls. Perfect audit outcomes.

But real engineering environments are never perfect.

They have bugs, drift, exceptions, failures, temporary workarounds and weird edge cases.

That doesn’t automatically mean the environment is insecure. It means it’s real.

I actually think one of the biggest mindset shifts FedRAMP 20x and the broader GRC engineering movement are pushing is this: nonconformities should not automatically destroy trust. Handled correctly, they should build it.

Because mature organizations are not the ones pretending problems don’t exist. They’re the ones capable of identifying issues quickly, exposing them honestly and improving continuously. That’s engineering. And maybe that’s where compliance finally starts becoming useful again.

The future of trust

For organizations participating in the current pilots, many of these concepts are already being tested through automation-first assessments, machine-readable evidence and continuous visibility.  FedRAMP 20x Phase 2.

Because right now, most compliance still works like we’re printing MapQuest directions in 2004 and hoping nothing changes between point A and point B.

The environment changes constantly. Cloud infrastructure drifts, engineers move quickly, businesses evolve and threat actors adapt far faster than annual audits ever could.

Yet most assurance still relies on frozen snapshots and sampled evidence that were already out of date the second they were exported into a PDF.

That’s the bit I think FedRAMP 20x genuinely understands. This isn’t just about modernising audits. It’s about acknowledging that modern systems are living systems.

They are transient, constantly changing and impossible to understand properly through static evidence alone.

That’s why the move towards APIs, telemetry and machine-readable evidence matters so much.

Not because APIs are trendy.

Because they allow us to expose operational truth continuously instead of periodically reconstructing it after the fact.

And honestly, I think that changes the future of trust.

In five years, I don’t think organizations will primarily send customers PDFs and certifications.

I think they’ll expose assurance layers.

APIs.
Telemetry.
Machine-readable evidence.

Instead of saying: Here’s our SOC 2.

They’ll say: Here’s the operational data. Query it yourself.

Auditors won’t disappear, but I think their role changes significantly.

Less time auditing screenshots and selected controls. More time validating whether the underlying evidence pipelines are complete, accurate and trustworthy.

Modern audit becomes less about auditing controls and more about auditing data integrity.

And honestly?

That feels like a much healthier future than the one we’ve built today.

Because the future of trust probably isn’t polished dashboards and carefully curated evidence. It’s operational truth, and operational truth is messy. It contains drift, exceptions, bypasses, gaps and uncomfortable findings, but that’s exactly why it’s valuable.

Stop rewarding the best storytellers

Maybe that’s the biggest shift FedRAMP 20x is trying to create. Not better paperwork. Better visibility.

For years, we’ve rewarded organizations for telling the cleanest story. Maybe it’s finally time we reward them for exposing the truth instead. That’s the revolution FedRAMP 20x and GRC engineering are leading.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?