Some things are best described as the absence, or privation, of something good. Normalization of deviance, drift to failure, unsafe conditions, and unsafe acts all take their meaning from a positive prior. We first define what it means to be safe. Integrity is a measure of how well that state is maintained, and any loss of integrity is what we call “unsafe.” The Challenger accident shows how this works. The solid rocket booster joints were designed so that the O-rings would never erode. On earlier flights, engineers found that they had. Because those flights returned safely, the erosion was reviewed and formally accepted as a tolerable risk, and the standard shifted from “no erosion” to “some erosion is acceptable.” Each successful launch reinforced the new standard. By the time of the cold-weather launch, the original definition of safe had been replaced, one reasonable decision at a time, through the organization’s own review process. A system risk approach such as STAMP helps us understand how hazards behave and how risk propagates through a system. It treats safety as a control problem, and every control system needs a reference to steer toward. For safety, that reference is a definition of what it means to be safe. In engineered systems, safety is the intended state we define and work to maintain. It is an outcome delivered by the parts of the system working together as designed. What emerges, often from interactions we did not foresee, is the departure from that state. The same premise applies to AI systems. Whether or not they are built with general-purpose AI, they are engineered systems, and much of the current conversation about AI safety skips the first step. We talk about guardrails, safeguards, and red-teaming. Each of these assumes we know what failure looks like. Failure can only be defined against an intended state, and few organizations have defined that state for their AI systems: what each system promises to do, for whom, within what limits, and under what conditions. Without that definition there is no reference against which to measure drift, no basis on which to design controls, and no basis to identify failure. AI systems also produce many unforeseen interactions. Models are probabilistic. They are composed with other models and tools, and they are deployed into environments that keep changing. Unsafe outcomes will emerge from these interactions. We can recognize them as unsafe only if we have first defined what it means to be safe. Normalization of deviance is already visible. Hallucinations are accepted as a known limitation of the technology, and that acceptance is itself normalization of deviance. Outputs that miss the mark are corrected downstream by people who absorb the cost. Each tolerated departure becomes the new baseline. This is the Challenger pattern, applied to intelligence systems. AI safety begins with defining what it means to be safe for each system. Loss of integrity is a measure of safety: how far we have drifted from that definition. The lesson of Challenger is that each reasonable decision can increase the drift from what it means to be safe. As AI adoption accelerates, pressure will build to accept whatever these systems do as the cost of progress. Without defining what it means to be safe, we will not see the departures we are accepting, and the loss of integrity will grow unnoticed. We do not have to let that happen. Define what it means to be safe for your AI systems, measure the loss of integrity against it, and treat every departure as a warning to investigate.

The Future of Compliance - Digital Threads In response to the Grenfell Tower Fire, the UK government introduced new regulations and a new regulator to address shortcomings in building safety. This new safety regime is intended to prevent the occurrence of incidents similar to the Grenfell Tower disaster that resulted in 72 deaths in 2017. Among the measures that this regulation introduces is what is being called, "A Golden Thread." This is in fact a "Digital Thread" the first of its kind to be used by regulators as an instrument of regulation. The future of compliance looks like it is here so let's find out what digital threads are all about and why it is so important for compliance. What is a Digital Thread? To understand digital threads we first need to understand digital twins. What is a Digital Thread The concept of digital twins is attributed to Michael Grieves based on a presentation he made in 2002 at the University of Michigan. In this presentation he proposed the digital twin as a conceptual model underlying a product life-cycle with three components: real space, virtual space, and the data between and about them. However, the idea of modelling the real-world with computer simulation is not new and can go back to as early as1960s when NASA used basic concepts of twinning in the development of its space program. What makes digital twins different from computer-based modelling are the connections between the real and virtual worlds. In essence, a model becomes a digital twin when it connected with its real life counterpart. This connection closes the loop and is referred to as the digital thread. How are digital twins and threads defined today? Digital Twin The definition commonly used in defence, aerospace and related industries in the US is: “an integrated multiphysics, multiscale, probabilistic simulation of an as-built system, enabled by Digital Thread, that uses the best available models, sensor information, and input data to mirror and predict activities/performance over the life of its corresponding physical twin.” A digital twin is a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity. This synchronization is enabled by a digital thread infrastructure or framework. Digital Thread The digital thread is used to refer to the lowest level design specification for a digital representation of a physical item. The digital thread is a critical capability in model-based systems engineering (MBSE) and the foundation for a digital twin. However, the term digital thread is also used to describe the traceability of the digital twin back to the requirements, parts and control systems that make up the physical asset. It is this latter aspect which is of significance for compliance specifically where traceability and accountability are regulated. Regulatory Use of Digital Threads: UK Building Safety In 2021 the UK Parliament introduced the Building Safety Bill to address shortfalls in building safety not limited to but largely in response to the Grenfall Tower Fire in 2017. This bill introduces a new regulator and regulation with the purpose that safety is ensured throughout every stage of a building's life. It also addresses specific failures with the lack of accountability and compliance throughout design, construction, and operations. UK - The Golden Thread The concept of a digital thread will now be part of this regulatory regime to provide traceability of information so that nothing falls between the cracks. This digital thread is not necessarily part of a digital twin but will instead become a measure of compliance and a critical one. Using the name "Golden Thread" to describe this particular application makes sense. It is an idea or feature that is present in all parts of something, holds it together and gives it value (Oxford's Learner's Dictionary); and in this case the value is improved safety. The Building Safety Bill further defines The Golden Thread: Full Definition: The golden thread is both the information that allows you to understand a building and the steps needed to keep both the building and people safe, now and in the future. The golden thread will hold the information that those responsible for the building require to: (a) how that the building was compliant with applicable building regulations during its construction and provide evidence of meeting the requirements of the new building control route throughout the design and construction and refurbishment of a building (b) Identify, understand, manage, and mitigate building safety risks in order to prevent or reduce the severity of the consequences of fire spread or structural collapse throughout the life cycle of a building The information stored in the golden thread will be reviewed and managed so that the information retained, at all times, achieves these purposes. The golden thread covers both the information and documents, and the information management processes (or steps) used to support building safety. The golden thread information should be stored as structured digital information. It will be stored, managed, maintained, and retained in line with the golden thread principles (see below). The government will specify digital standards which will provide guidance on how the principles can be met. The golden thread information management approach will apply through design, construction, occupation, refurbishment, and ongoing management of buildings. It supports the wider changes in the regime to promote a culture of building safety. Building safety should be taken to include the fire and structural safety of a building and the safety of all the people in or in the vicinity of a building (including emergency responders). Many people will need to access the golden thread to update and share golden thread information throughout a building’s lifecycle, including but not limited to building managers, architects, contractors, and many others. Information from the golden thread will also need to be shared by the Accountable Person with other relevant people including residents and emergency responders. The Golden Thread is based on the following principles which you could also consider as system properties: Principles: Accurate and Trusted: the dutyholder/Accountable Person/Building Safety Managers and other relevant persons (e.g. contractors) must be able to use the golden thread to maintain and manage building safety and ensure compliance with building regulations. The Regulator should also be able to use this information as part of their work to assess the compliance with building regulations, the safety of the building and the operator’s safety case report, including supportive evidence, and to hold people to account. The golden thread will be a source of evidence to show how building safety risks are understood and how they are being managed on an ongoing basis. The golden thread must be accurate and trusted so that relevant people use it. The information produced will therefore have to be accurate, structured, and verified, requiring a clear change control process that sets out how and when information is updated and who should update and check the information. Residents feeling secure in their homes: residents will be provided information from the golden thread – so that they have accurate and trusted information about their home. This will also support residents in holding Accountable Persons and Building Safety Managers to account for building safety. A properly maintained golden thread should support Accountable Persons in providing residents the assurance that their building is being managed safely. Culture change: the golden thread will support culture change within the industry as it will require increased competence and capability, different working practices, updated processes and a focus on information management and control. The golden thread should be considered an enabler for better and more collaborative working. Single source of truth: the golden thread will bring all information together in a single place meaning there is always a ‘single source of truth’. It will record changes (i.e. updates, additions or deletions to information, data, documents and plans), including the reason for change, evaluation of change, date of change, and the decision-making process. This will reduce the duplication of information (email updates and multiple documents) and help drive improved accountability, responsibility and a new working culture. Persons responsible for a building are encouraged to use common data environments to ensure there is controlled access to a single source of truth. Secure: the golden thread must be secure, with sufficient protocols in place to protect personal information and control access to maintain the security of the building or residents. It should also comply with current GDPR legislation where required. Accountable: the golden thread will record changes (i.e. updates, additions or deletions to information, data, documents and plans), when these changes were made, and by who. This will help drive improved accountability. The new regime is setting out clear duties for dutyholders and Accountable Person for maintaining the golden thread information to meet the required standards. Therefore, there is accountability at every level – from the Client/Accountable Person to those designing, building or maintaining a building. Understandable/consistent: the golden thread needs to support the user in their task of managing building safety and compliance with building regulations. The information in the golden thread must be clear, understandable and focused on the needs of the user. It should be presented in a way that can be understood, and used by, users. To support this, dutyholders/Accountable person should where possible make sure the golden thread uses standard methods, processes and consistent terminology so that those working with multiple buildings can more easily understand and use the information consistently and effectively. Simple to access (accessible): the golden thread needs to support the user in their task of managing building safety and therefore the information in the golden thread must be accessible so that people can easily find the right information at the right time. This means that the information needs to be stored in a structured way (like a library) so people can easily find, update and extract the right information. To support this the government will set out guidance on how people can apply digital standards to ensure their golden thread meets these principles. Longevity/durability and shareability of information: the golden thread information needs to be formatted in a way that can be easily handed over and maintained over the entire lifetime of a building. In practical terms, this is likely to mean that it needs to align with the rules around open data and the principles of interoperability – so that information can be handed over in the future and still be accessed. Information should be able to be shared and accessed by contractors who use different software and if the building is sold the golden thread information must be accessible to the new owner. This does not mean everything about a building and its history needs to be kept, the golden thread must be reviewed to ensure that the information within it is still relevant and useful. Relevant/proportionate: preserving the golden thread does not mean everything about a building and its history needs to be kept and updated from inception to disposal. The objective of the golden thread is building safety and therefore if information is no longer relevant to building safety it does not need to be kept. The golden thread, the changes to it and processes related to it must be reviewed periodically to ensure that the information comprising it remains relevant and useful. These definitions and principles will help set the direction for how digital threads will be built in the compliance domain not only within the UK but also other jurisdictions. What Digital Threads Mean For Compliance Evidence of compliance has always been needed and this means more than attestations as the way to verify that what should have been done was actually done. This approach was always to slow, too late and not always accurate. And that is why the concept of a Golden Thread as a means to provide evidence and assurance of compliance throughout the design, building and maintenance of buildings is a game changer. However, it will still take time for digital thread infrastructures to be established particularly those that meet the properties outlined for the UK's Golden Thread. At one level digital threads are still retrospective and on the lagging side of risk events. However, they could become more than feed-back processes particularly for downstream activities. When combined with digital twins they could become feed-forward and provide predictive utility particularly to improve and validate design models. At a minimum, digital threads will provide more up-to-date and reliable information for all stakeholders during every stage of building's life cycle. Now that we have defined purpose and properties for digital threads in the compliance domain it is likely that "Golden Threads" will become part of other regulator regimes. Medical device manufacturers are already using digital threads to provide traceability across DHF, DMR, and DHRs. There are also examples of digital threads in Oil & Gas and other regulated industries with respect to safety-critical data. In addition, using digital threads as part of Management of Change (MOC) process may help ensure design integrity as a result of planned changes. Instead of trying to integrate systems together, digital threads may provide a more effective means for compliance critical information to be made available not only as evidence of compliance but as a proactive measure to prevent risk. Proactive organizations should begin to plan pilot projects to explore how digital threads would be used in response to regulatory reforms but also as part of their own internal compliance efforts. If you are interested in developing and implementing digital thread strategies please contact our project management office to learn how Lean Compliance can help. References: GoldenThread.co.uk Developing a Digital Twin and Digital Thread Framework for an ‘Industry 4.0’ Shipyard What Are Digital Twins and Digital Threads? Industry 4.0 How to navigate digitization of the manufacturing sector

The Enterprise Digital Cognition Map For decades, enterprises have been climbing what we used to call the IT ladder. We started with data processing. We moved to information systems. Today we are building intelligence technology with AI. At each step, we named the technology after the highest rung it reached. Each name described what the technology processes. None described what it is for. I have been working on an updated map to address this. It combines three ideas: the DIKIW model (Data, Information, Knowledge, Intelligence, Wisdom), the stages of digital transformation, and the quantitative and qualitative capabilities needed at each level. I call it the Enterprise Digital Cognition Map. Its purpose is to help define what an enterprise digital system now needs to support. Why Cognition The business does work to create value. To manage this work, it needs a management system. That management system requires cognition at five levels: data, information, knowledge, intelligence and wisdom. At each level, cognition takes a different form: we observe, organize, learn, reason and judge. Cognition requires capabilities. At each level, the enterprise needs qualitative and quantitative capabilities, and a digital capability to support them. Digital Capability Each level of the map pairs with a digital capability: Digitize reality at the level of data. Describe reality at the level of information. Model reality at the level of knowledge. Augment reality at the level of intelligence. Create reality at the level of wisdom. Each digital capability must support both what is and what should be at its level. Digitizing reality requires measurement and classification. Creating reality requires targets and purpose. Each level also builds on the levels beneath it. An enterprise cannot responsibly augment or create reality without the cognition and capabilities required at the levels below. Qualitative and Quantitative Capabilities At every level, cognition has two sides. Quantitative capabilities describe what is. Qualitative capabilities define what should be. Data: classification and measurement Information: relevance and context Knowledge: explanation and correlation Intelligence: strategy and optimization Wisdom: purpose and targets The qualitative side comes first in each pair. We classify before we measure. We decide what is relevant before context matters. We explain before we trust a correlation. We choose a strategy before we optimize. We establish purpose before we set targets. As we move up the map, the qualitative side matters more. At the top, purpose answers the terminal why. Every other why points to the one above it. Purpose is where the questions end. What the Map Suggests Each level carries a substitution risk. When the quantitative side stands in for the qualitative side, the enterprise fails in a specific way: Measurement without classification measures the wrong things precisely. Context without relevance produces dashboards that say nothing. Correlation without explanation produces patterns that break when conditions change. Optimization without strategy makes the wrong path more efficient. Targets without purpose succeed on paper and fail in fact. A data-first approach makes these substitutions at every level. AI accelerates them. It climbs the quantitative side faster and produces outputs that look qualitative. Relevance, explanation and strategy appear in the output. The grounding behind them is often missing. Machines can perform qualitative work. They cannot originate purpose or answer for it. Machine cognition can go as far up the map as human cognition has grounded it, and no further. What Enterprise Digital Systems Need to Support Most enterprise digital systems were built to support the quantitative side. We digitized reality. We described it. We are now modelling it with machine learning. Very little has been invested in formalizing the qualitative side: classification schemes, relevance, causal understanding, strategy and purpose. Enterprise digital systems now need to support both. Descriptions of what is must flow up. Descriptions of what should be must flow down. The management system acts on the gap between them. This is what it takes to stay between the lines, ahead of risk, and on-mission in the intelligence age.

In this article we will explore sustainability and how it relates to AI technologies. To get there we will first consider AI Safety and the challenges that exist to design safe and responsible AI. Is AI Sustainable? AI technology such as ChatGPT should be designed to be safe. I don’t think many would argue with having this as a goal, particularly professional engineers who have a duty to regard the public welfare as paramount. However, ChatGPT is not designed in the traditional sense. The design of ChatGPT is very much a black box and something we don’t understand. And what we don’t understand we can’t control and therein lies the rub. How can we make ChatGPT safe when we don’t understand how it works? ChatGPT can be defined as a technology that learns and in a sense designs itself. We feed it data and through reinforcement learning we shape its output, with limited success, to be more of what we want and less of what we don’t want. Even guard rails used to improve safety are for the most part blunt and crude instruments having their own vulnerabilities. In an attempt to remove biases, new biases can be introduced. In some cases, guard rails change the output to be what some believe the answer should be rather than what the data reveals. Not only is this a technical challenge but also an ethical dilemma that needs to be addressed. The PLUS Decision Making model developed by The Ethics Resource Center can help organization’s make better decisions with respect to AI: P = Policies - Is it consistent with my organization's policies, procedures and guidelines? L = Legal - Is it acceptable under the applicable laws and regulations? U = Universal - Does it conform to the universal principles/values my organization has adopted? S = Self - Does it satisfy my personal definition of right, good and fair? These questions do not guarantee ethical decisions are made. They instead help to ensure that ethical factors are considered. However, in the end it comes down to personal responsibility and wanting to behave ethically. Some have said that AI Safety is dead or at least a low priority in the race to develop Artificial General Intelligence (AGI). This sounds similar to on-going tensions between production and safety or quality or security or any of the other outcomes organizations are expected to achieve. We have always needed to balance what we do in the short term against the long term interests. In fact, this what it means to be sustainable. “meeting the needs of the present without compromising the ability of future generations to meet their own needs.” - United Nations This is another test we could add to the PLUS model. S = Sustainability - does this decision lead to meeting the needs of the present without sacrificing the ability of future generations to meet their own needs? I believe answering that question should be on the top of the questions being considered today. Is our pursuit of AGI sustainable with respect to human flourishing? AI Sustainability is perhaps what drives the need for AI safety, security, quality, legal, and ethical considerations. For example, just as sustainability requires balancing present needs with future well-being, prioritizing AI safety safeguards against unforeseen risks and ensures AI technology serves humanity for generations to come. However, it sustainability that drives our need for safety. In addition to asking, is AI Safe, perhaps we should be asking is AI Sustainable?

Much of the current discussion on AI governance focuses on evaluating decisions at the point of execution. An agent proposes an action, and the action is checked to see whether it is admissible. In earlier posts I raised two problems with this approach. It does not account for acts of omission, and actions that are acceptable on their own can still be unsafe in aggregate. There is a third problem, and it concerns what the decision is being evaluated against. Positive Priors To evaluate anything, we need something to evaluate it against. A prior is what must be known or established before an evaluation can take place. It is the reference point that gives the evaluation meaning. When we ask whether a decision is a good one, we are really asking whether it moves the system toward or away from something we have already defined. A positive prior is a defined state that we intend a system to achieve and maintain. It describes what good looks like. Safety is a good example. Safety is a positive state of a system. It describes the condition we intend the system to remain in, and any deviation or drift from that condition is what we call unsafe. This means safety must be defined before it can be evaluated. A decision cannot be judged as leading to unsafe actions unless we first know the state the system is meant to keep. That state is the positive prior. The same is true of other outcomes we care about, such as quality, security, and integrity. Each is a positive state, and each needs to be defined before deviation from it can be recognized. Without these priors, evaluating a decision at the point of execution has nothing to measure against. Two Causes of Risk Risk theory adds a second principle. A risk requires two causes: an unsafe condition and an unsafe action. For an explosion to occur, an ignition source (the unsafe action) must be brought into the presence of a flammable gas (the unsafe condition). Either one alone does not produce the explosion. This tells us that an action cannot be evaluated by examining the action alone. The same action can be harmless in one setting and catastrophic in another, depending on the conditions present. Knowing which hazards exist, that is, the sources of uncertainty an action will encounter, is therefore another essential prior. It provides the context against which actions must be evaluated. Evaluating Against a Risk Profile If this sounds like risk management practice, you are right. In the domains I work in, such as oil and gas, pharmaceuticals, and chemical processing, consequential decisions are evaluated against a risk profile. The risk profile captures the hazards present and the positive states the operation must keep. A decision is approved only when the risks are reduced to what is tolerable, or when a sufficient margin is established to cushion the effects should something go wrong. This work is done in advance. The priors are established before decisions are made, so that each decision can be evaluated against them when the time comes. Commitments as the Backbone For AI agents, Promise Theory offers a way to carry these priors forward. An agent can be designed to keep commitments made in advance, and those commitments form the basis for evaluating whether a decision aligns with what was promised. In this sense, commitments become the backbone of agent governance. For that backbone to be sound, the commitments must express the priors. They need to include the positive states the agent is expected to keep and the hazards it will contend with. When they do, a decision can be evaluated against something meaningful: the promises the agent was designed to keep, in the conditions it is operating in. Where Governance Begins A governance state provides the basis on which decisions are evaluated before they proceed. It can only serve that purpose if it records what each decision must be evaluated against: the positive states the agent is expected to keep, and the hazards present in the conditions it operates in. Without these priors, a governance state describes what has been committed and what has happened, but it offers no basis for judging whether the actions will be safe. This is why defining the priors comes first. Before an agent is deployed, we need to establish what safe operation looks like and what hazards it will encounter, and then express these as commitments the agent is designed to keep. Every decision the agent makes can then be evaluated against those commitments. Raimund (Ray) Laqua, P.Eng., PMP, is the Founder and Principal Consultant of Lean Compliance Consulting, Inc., and the person who defined the practice of Lean Compliance. He advises organizations in highly regulated, high-risk industries on how to meet their obligations and contend with risk. Ray is one of the first licensed software and computer engineers in Canada and has practised digital engineering for more than 40 years. He chairs the Digital Engineering Committee for Engineers for the Profession (E4P), serves on OSPE’s AI in Engineering Task Force, and advocates nationally for Professional Digital Engineering (PD.Eng.) licensure.

Enterprise architecture was built for information technology. Its domains cover business, data, applications and technology. Its tools describe how data is stored, moved and turned into information. That work remains essential. Yet AI operates further up the DIKIW model, where knowledge and intelligence live, and our architecture has no place for them. I call this next layer Intelligence Technology (I²T). DIKIW Model Applied to EA Applied to enterprise architecture, the DIKIW model gives us two pillars. On the left is IT architecture, built on a data base and a media repository, producing data and information. On the right is I²T architecture, built on a knowledge base and a model repository, producing knowledge and intelligence. The bridge between them is where models learn from enterprise information and where intelligence acts back on enterprise systems. Wisdom spans both. Judgment, purpose and governance apply to how we handle data as much as to how we deploy intelligence. Organizations are deploying intelligence into architectures that end at information. Much of the risk in AI adoption comes from that gap. Closing it starts with recognizing that I²T needs an architecture of its own.

In August 2017 I wrote a short post called Where to Make Compliance Improvements. It was one of the first things I published on my site. Nine years later I still point people to it. The core ideas have not changed. They have only become more important. The post made a simple claim. Programs, systems, and processes are different things. Each does a different job. If you confuse them, you will make improvements in the wrong place and wonder why outcomes do not change. Three Levels, Three Jobs Here is the short version. A process is a set of ordered steps that transforms inputs into outputs. Its purpose is to execute the plan. Consistent output comes from consistently following standard work. A system is a process connected to other elements, most importantly to measurement. The feedback loop is what makes it a system. Its purpose is to keep output within specified limits. A system resists change. That is its job. A management program defines the outcomes the systems and processes are meant to achieve. It provides the resources and capabilities to support them. Its purpose is to change the state of the organization: fewer incidents, lower risk, more near misses reported. A program introduces change. That is its job. One level stabilizes. The other adapts. The tension between them is healthy and necessary. An organization needs both. Why the IDEF0 Diagram Matters The most useful part of the 2017 post was the following diagram. It shows a modified PDCA cycle drawn in IDEF0 format, with the program level in red and the system level in blue. IDEF0 Diagram for PDCA IDEF0 is a functional modelling notation. Every function is a box. Inputs enter from the left. Outputs leave on the right. Mechanisms, the people and tools that perform the work, come in from the bottom. Controls come in from the top. That last convention is the point. When controls enter from the top, you can see where regulation acts on a function. You can see which signals regulate which activities. You can see where a change is triggered and at which level it lands. The diagram also splits the Act step of PDCA into two functions: Manage and Provide Resources. This makes the boundary between system and program visible. Managing adjusts the process to keep it in control. Providing resources changes the capabilities and capacity available to the system. The first is a system function. The second is a program function. This split is especially helpful when deploying ISO standards. ISO has adopted PDCA as the overarching process for its management system standards. When PDCA is applied as a single loop, every clause is treated as part of one system. The IDEF0 view shows which requirements stabilize the system and which change it. Operational planning and control is a system function. Support, which provides resources and competence, is a program function. Knowing the difference tells you where to look when a standard has been implemented and outcomes still do not change. Why This Is Still Missed I am often asked why these distinctions are not more widely understood. I see a few reasons. The language is used loosely. Management system standards use "system" to describe almost everything. Programs, systems, and processes become interchangeable words in policy documents and audit reports. PDCA is taught as one loop and the solution to solving all problems. Organizations apply PDCA to tighten procedures when they should be building capabilities. We draw flowcharts but not control diagrams. Flowcharts show steps in order. They rarely show what regulates those steps. Without a picture of control, people cannot reason about how to better regulate outputs, never mind outcomes. Projects substitute for management programs. In 2017 I wrote about management initiatives where a project performed the program function, delivered new capabilities, and then disbanded, leaving the system in maintenance mode with audits as the only remaining governance. I continue to see the same pattern today, particularly when it comes to implementing AI governance. Audits verify systems but do not assess capability. Audits are good at checking whether a system executes as specified. They are poor at telling you whether the program is achieving its intended outcomes. You can have an efficient system that produces the specified outputs and still fail to achieve the outcome. Audits can help you verify systems, but you need something else to validate management programs. Where to Start Improving The diagnostic order from 2017 still applies. If a program outcome is not being achieved, first verify that the systems are executing consistently. This can be done through audit or, better, through measurement embedded in the process itself. If the systems pass verification, the problem is at the program level. The program must assess its capabilities and either mature them or introduce new ones. New capabilities can be introduced quickly with a minimum viable approach. Continuous improvement through PDCA then stabilizes them on the system side. This order matters. Changing programs when systems are inconsistent adds variation. Tightening systems when capabilities are missing adds effort without improving outcomes. What Has Grown Since 2017 The 2017 model became the foundation for our Operational Compliance Model. The OCM adds a fourth level above programs: governance. Governance sets direction. Programs introduce change. Systems resist change. Processes do the work. Each level regulates the one below it. Each needs its own feedback. Each needs its own measures. This is why I talk about full-stack metrics: adherence, conformance, performance, effectiveness, and integrity. A single measure cannot tell you which level is failing. The underlying idea is cybernetic. Every regulator needs a model of what it regulates. The IDEF0 diagram is one such model. It gives you a way to see where regulation happens in your organization and where it is missing. The Takeaway The first question in any improvement initiative is deciding what outcomes require improvement followed by where best to make the change. Organizations regulate themselves through levels, and each level has its own purpose: processes do the work, systems keep it in control, programs change outcomes, and governance sets direction. Every improvement effort lands at one of these levels, whether it is deploying an ISO standard, responding to an audit finding, or introducing AI. When the level is wrong, effort increases and outcomes stay the same. This is why a model matters. You cannot improve what you cannot see, and most organizations have no picture of how they regulate themselves. Read the original post here: Where to Make Compliance Improvements

Every organization is regulated. The question worth asking this Sunday is by whom. Most organizations would answer by naming an external body. A safety regulator. A privacy commissioner. A certification body that audits their management system. These bodies impose obligations and specify the instruments they will audit against. They are real regulators, and their oversight matters. They are also limited. An external regulator touches the organization only where its instruments apply. Everything outside those touch points is regulated by the organization itself, or it is not regulated at all. This is where compliance often fails. Here are the patterns I see most often. 1. Self-regulation stops at the external obligation Many organizations build enough regulation to meet the obligations imposed by external bodies. Procedures are written for the rules. Records are kept for the audit. Controls are designed around the instruments the regulator will check. Then it stops. Obligations without an external auditor receive little attention. The organization regulates what is inspected and leaves the rest to chance. 2. Compliance means meeting the regulator In these organizations, compliance is defined as meeting the obligations set by external bodies. That definition is narrower than the one most of them claim to follow. ISO 37301 defines compliance as meeting all of the organization's compliance obligations, both mandatory and voluntary. Customer commitments, internal policies, safety goals, sustainability pledges and promises made to communities are all compliance obligations. When compliance is limited to the external regulator, these become optional. This is where obligation debt accumulates. 3. The organization resists obligations it expects others to keep Some organizations carry a culture that pushes back on external regulation. Leaders speak of red tape and regulatory burden. Obligations from outside are treated as something to minimize, negotiate or delay. The same organizations expect employees, suppliers and contractors to meet the obligations the organization imposes. Policies are to be followed. Targets are to be met. Commitments are to be kept. People notice the conflict. When an organization treats obligations from outside as negotiable, its people learn that obligations are negotiable. A culture that resists obligation will struggle to keep its own promises. 4. Governance is expected to regulate, but it is not operational Every organization is expected to regulate itself from outcomes down to means. Governance sets direction and decides what the organization commits to. Programs build the capability to deliver those commitments. Systems keep operations stable. Processes do the work. In many organizations this exists on paper. Policies are approved. The board receives reports. The structure is described in the management system manual. What is missing is the operational capacity to regulate. Governance receives information and has little ability to act on it. 5. Compliance for the regulator builds nothing for the organization That system does not build the apparatus the organization needs to regulate itself. It does not build ownership of obligations at governance. It does not build programs that develop capability. It does not build systems that keep variation within limits. It does not build promises that people choose to keep. Over time, the organization becomes dependent on the external regulator because it has no other regulator. External regulators were never designed for that role. Their instruments are minimal by necessity. Following OSHA 1910.119, ISO 9001, or license to operate rules meets the minimum a regulator can specify and audit. The obligation to be safe extends well beyond that minimum. The duty of care stays with the organization The duty of care belongs to the organization. It always has and always will. No regulator, standard or auditor can carry it on the organization's behalf. Meeting that duty requires the organization to own all of its obligations and translate them into promises across governance, programs, systems and processes. Governance has to act as the top-level regulator. External regulators then become one source of obligations among many, and the outermost check on whether the organization's own regulation is working. A question for this week Many organizations may lack the capacity to regulate themselves, never mind those that come from external regulatory bodies. That deserves honest reflection. Here is the question I am leaving with you this week: if the external regulator disappeared tomorrow, what in your organization would still be regulated? About the Author Raimund (Ray) Laqua, P.Eng., PMP, is the Founder and Principal Consultant of Lean Compliance Consulting, Inc. He defined the practice of Lean Compliance, which helps organizations in highly regulated, high-risk industries meet their obligations by operationalizing them into promises they have the capability to keep. Ray is one of the first licensed software/digital engineers in Canada. He chairs the Digital Engineering Committee for Engineers for the Profession (E4P), serves on OSPE's AI in Engineering Task Force, and advocates nationally for Professional Digital Engineering licensure. Learn more at leancompliance.ca.

For the last few years, the question most people have asked about AI is whether it works. Does it give accurate answers? Does it save time? Does it deliver a return on investment? These are reasonable questions. They are also incomplete. There is a deeper question that deserves our attention. How do organizations that adopt AI remain viable? I have been reflecting on this question while revisiting an article I wrote on Cybernetic Control. That article was written for risk and compliance. Its principles speak directly to what organizations face as they adopt AI. What Viable Means Most people hear the word viable and think of a system that works. A viable business makes money. A viable product meets a need. A viable plan can be carried out. Stafford Beer gave the word a stronger meaning. For Beer, a viable system is one capable of maintaining its existence in a changing environment. It senses what is happening. It adapts. It regulates itself and stays within acceptable limits as conditions change. It continues to achieve its purpose over time. A system can work today and fail tomorrow when conditions shift. Viability is the capacity to keep working as the world changes. Viability is very close to governance. Governance exists to keep an organization on mission, meeting its obligations, and capable of adapting to what comes. It sets direction, assigns authority, and regulates the organization so that it stays between the lines. Beer made this connection explicit in his Viable System Model. The functions that monitor performance, look outward to the future, and define identity and purpose are the functions of governance. To ask whether an organization is viable is to ask whether it is well governed. The question of AI viability is a question of governance. The Organization Is the System Governance applies to the organization as a whole, and AI is part of that whole. AI is deployed within an organization, governed by it, and accountable through it. The organization defines its purpose, supplies its data, integrates it into processes, and answers for its outcomes. An AI model may perform well in testing. Once deployed, it becomes part of a larger system that includes people, processes, technology, and obligations to stakeholders. Its behaviour affects customers, employees, environment, and the public. The question of viability belongs to the organization. When AI becomes part of how an organization operates, does the organization remain capable of meeting its obligations and achieving its mission? The Law Behind Viability Ross Ashby gave us the law behind viability. His Law of Requisite Variety states that only variety can absorb variety. A control system must have at least as much variety as the system it seeks to regulate. In Cybernetic Control, I described four principles that follow from this law: When the variety of the environment exceeds the capacity of a system, the environment will dominate. The larger the variety of actions available to a control system, the larger the variety it is able to compensate. A control system can only regulate what its channels of communication allow it to see and act on. The response time of the control system must meet or exceed the speed of change. These principles explain why some controls are effective and others are not. They apply to any organization that must stay between the lines on its way to mission success. AI Adds Variety and Uncertainty AI adds enormous variety to the organization. It creates variety in what it outputs and in how it acts within the business. Together, these create significant uncertainty. Traditional software are deterministic. The same input produces the same output. Its behaviour can be specified, tested, and verified. Consider what AI outputs. Its outputs are probabilistic. Its behaviour can change with context, with data, and over time. Its reasoning is often opaque, even to those who build it. Consider how AI acts. It acts in more ways than the systems it replaces. It writes, recommends, decides, and executes. It can choose among many paths to reach a goal, including paths no one anticipated. Agentic AI chains these actions together across tools and systems on the organization's behalf at machine speed. Every new way of acting is new variety the organization must regulate. This uncertainty enters at every point AI touches: decisions, processes, customer interactions, and operations. This deserves deep reflection. Governance controls are mostly designed to regulate variety coming from the environment, such as market shifts, regulatory changes, and operational upsets. With AI, the organization imports uncertainty into its own operations. The source of variety is now inside the walls. Four Questions Ashby's principles raise four questions for every organization using AI. Does the uncertainty AI creates exceed our capacity to contend with it? Ashby tells us that when variety exceeds a system's capacity, the variety will dominate. Outcomes are then determined by what AI does, and the organization loses control of its own operations. Do our controls have the variety to absorb the uncertainty AI brings? Many controls were designed for deterministic systems with predictable failure modes. They may lack the range of responses needed for systems that behave in unexpected ways. Do we have the channels to see what AI is doing across the organization? A control system cannot regulate what it cannot observe. Many organizations do not know where AI is being used, let alone how it is behaving. Do our controls respond as fast as AI acts? Governance cycles often run quarterly or annually. Audits look back. Agentic AI decides and acts in seconds. The Limits of Feedback Most organizations rely on feedback control. We measure outputs, find deviations, and take corrective action. Management systems, standards, and regulations are built around this loop. As I noted in Cybernetic Control, feedback has a significant weakness. It requires outputs to be measured first. For risk and compliance objectives, this is often too slow and too late, particularly with respect to safety. With AI, this weakness grows. By the time a deviation is measured, an AI system may have made thousands of decisions. An agent may have taken actions that cannot be undone. Harm may already have reached customers or the public. This is why feed-forward control matters. Feed-forward control anticipates deviation and acts to prevent it before it happens. It shapes conditions, constrains behaviour, and designs out failure modes in advance. It is central to engineering practice, and it is what organizations need as AI becomes part of their operations. Restoring Balance Beer offered two ways to achieve requisite variety. We can attenuate the variety entering the system. We can amplify the variety of the system that regulates it. For organizations using AI, attenuation means reducing uncertainty at its source. This includes limiting where AI is used, bounding the authority of AI agents, and defining the operating envelope within which AI is permitted to act. Amplification means increasing the organization's capacity to regulate. This includes building competence in people, establishing channels that make AI behaviour visible, creating controls that respond at the speed of AI, and strengthening the structures that keep the organization aligned with its obligations. Viable organizations do both. They reduce the uncertainty they take on, and they increase their capacity to contend with the uncertainty that remains. A Question Worth Asking Many organizations are adopting AI as fast as they can. They measure success by whether it works. That is understandable. It is also a narrow measure. An organization that works today may not be viable tomorrow. Viability depends on whether the organization's capacity to regulate keeps pace with the uncertainty it takes on. Ashby's law offers no shortcuts. Variety must be matched by variety. I find myself returning to the same question. Alongside asking whether AI works, we need to ask whether our organizations can remain viable with it. This is a question every leader can ask of their own organization. As we adopt AI, how will we remain viable? Lean Compliance can help you answer this question. Our Forward Assurance program helps organizations operationalize AI governance so they stay between the lines, ahead of risk, and on mission as they adopt AI. Reach out to learn how Forward Assurance can help your organization remain viable.

Are your risk and compliance controls capable to keep you between lines? The purpose of risk and compliance is to keep companies operating between the lines so that they do not fall in a ditch on their way to mission success. To ensure that this does not happen risk and management controls are put in place to act as guardrails (protect against loss) as well as to drive processes and practices towards targeted outcomes in response to stakeholder obligations. Stakeholders include: customers, suppliers, shareholders, employees, government, and the public at large. Requirements (mandatory) and commitments (voluntary) are derived from obligations contained within internal policies, guidelines and code of conduct; regulations and standards; contracts, and product and service specifications. Obligations include: conformance, performance, achievement, and outcome based specifications. Traditional approaches (1950-1970s) to organizational design are based on the notion of (1) "Organizations as Systems" comprised of: general systems theory and contingency theory, and (2) "Hard Systems Thinking" comprised of operations research, systems analysis, systems engineering and cybernetics. In the field of cybernetics (the science of communication and control in both machines and living things), there are two models of the organization: management cybernetics and organizational cybernetics. Management Cybernetics treats the organization as a machine or an organism. It is congruent with the philosophy of hard systems thinking. Organizational Cybernetics treats the organization as a viable system that manages complexity. It moves beyond mechanistic and organismic thinking and makes full use of the concept of variety (Stafford Beer). The concept of controls comes from these theories of systems. The most common form of a control process is the feedback control loop used to apply corrective actions in response to system output deviations from target values. The control loop serves to keep the system between acceptable operating limits (ex. constraints, performance levels, etc). Cybernetic Control Loop We can use organizational cybernetics, specifically the Law of Requisite variety developed by Ross Ashby, to help understand what is required for a control loop to be effective. When the variety or complexity of the environment exceeds the capacity of a system the environment will dominate The larger the variety of actions available to a control system, the larger the variety it is able to compensate The capacity of the control system cannot exceed the capacity as a channel of communication The response time of the control system must meet or exceed the speed of change These principles provide important insights to improving the effectiveness of feedback control loops specified by many standards and regulatory bodies and used in the majority of management systems. There is one significant weakness of the feedback control loop which is that it requires outputs to be measured first. When it comes to risk and compliance objectives measuring outputs using a feedback-management-control is often too slow and too late specifically with respect to safety. In this case it is better to eliminate the possibility of deviation before it happens. This requires the use of feed-forward cybernetic control which will be the topic of a future article.

As organizations plan for 2027, many are deciding what work AI agents will take on next year. Successful businesses take ownership of their obligations and make commitments to meet them. These commitments are promises that must be kept. That is the lens worth bringing to AI: how can AI agents help us keep the promises we have made? Obligations and promises Over the last year in our Elevate Compliance Huddles, we have walked through the Operationalized Obligation model, which is based on Promise Theory. It describes how obligations become promises. Operationalized Obligations - Promise Theory An obligation begins with an intention. Once imposed, it creates uncertainty about how and whether it will be met. A promise answers that uncertainty. It states what will be done and how it will be done, and the promise owner commits to doing the right work, the right way, to achieve the right results. That commitment is what brings certainty. Operational compliance is the work between the obligation and the promise. It is where promises are kept, obligations are fulfilled, and evidence of compliance is produced. Each side of the model has its own work: Obligation owners manage what is required through rules, practices, targets, and outcomes. They audit and validate that obligations are being met. Promise owners keep their promises through processes, systems, programs, and governance. They assess and verify that those promises are being kept. When we ask an agent to help A promise owner can be a person or a machine. People make promises through their commitments. A machine makes promises through its design, and it can only keep the promises it was designed to keep. When we ask an AI agent to help, we are transferring responsibility for keeping part of a promise we have made. Accountability stays with the obligation owner, who answers for the work the agent does and the results it achieves. The left side of the model remains with them: knowing what was intended and validating that obligations are being met. Before an agent is given a promise to keep, the questions are the same ones we would ask of anyone we rely on: Does it have the knowledge, know-how, and skills the work requires? Does it have the capacity to keep the promise every time it is asked, under the conditions it will actually face? An agent with the right capability and capacity extends what the business can deliver, and knowing whether it has them is where the work begins. Principles for AI adoption All of this points to a more fundamental question: what principles are we applying to AI adoption? Most AI adoption is not engineered. It proceeds without the management, compliance, safety, and other principles we apply to the rest of the business. The Operationalized Obligation model points to principles that are relevant here: Ownership. Every obligation must have an owner who is accountable for meeting it. Promises by design. A machine makes promises through its design, so its design must reflect the commitments the business has made. Retained accountability. Responsibility may be transferred to an agent. Accountability must remain with the obligation owner. Capability before transfer. No agent should be asked to keep a promise until its capability and capacity have been established. Verification and validation. Promises must be verified as kept, and obligations validated as met. Looking ahead to 2027 As the year ahead takes shape, these questions are worth asking: What principles are guiding your adoption of AI? Which of your commitments could AI agents help you keep? How will you know those agents are capable of keeping them? If you are working through these questions too, I would love to hear from you. Raimund Laqua, PMP, P.Eng. Founder, Principal Consultant Lean Compliance Consulting, Inc. Engineering Trust in the Intelligence Age

Digital Depot of Transformation Digital Transformation – The Home Depot of Computing Walking into a building construction store like Home Depot can be overwhelming. There are so many items to choose from and if you are like me you often don't know what you are looking for. If you are a builder or contractor most of the items will make sense and be familiar to you. However, what is more important, you will know what to do with them when you take them home. This experience is similar to companies who are deciding what to do with digital technologies. It can be just as overwhelming as walking into Home Depot. What is important to realize is that this experience is not a new one. When I first started consulting over 25 years ago a popular trope was this: Let’s say you can have ERP for free and have it installed today (back in the day this would take 12 -18 months) then what will you do with all that technology? The answer given was usually, "We don't really know. Everyone is using ERP and we thought we should get one too." Well then, why are you focusing on technology when you don’t know what it is you want to accomplish?" It is remarkable that we find ourselves now able to access instantly and usually for free (to start) any software you might need for your business. But this still leaves us with the same question, "what are you going to do with all that technology?" This is where many companies find themselves with respect to digital transformation. Based on what you read you might conclude that everyone is doing digital transformation and you should too. If you find yourself thinking this you are in good company. More Items for Your Shopping Cart Everything as a Service (XAAS) is a gaining mind share among the digital community. This is a progression of what has been going on for a while manifested in the form of: Software as a Service (SAAS) Platform as a Service (PAAS) Infrastructure as a Service (IAAS) And many others. The concept has been invented by computer and business architects alike to turn delivery of everything into a service. In fact, digital components are themselves delivered as a micro-services constituting what some are calling the programmable business framework. For those that remember the days of CORBA (common object request broker architecture) for the enterprise this is the same idea but for everyone. The premise is that you can build whatever you want by accessing ready-made capabilities available in real-time, on-demand, and almost for free. The hope is that someone will use these services to build something great. The question is who and what is this going to be? The Loss of Strategic Computing and Information Services When Computing and Information Technology came on the scene each system needed to be championed and sponsored by a business function that needed the capability. Funding for such an endeavor required justification based on achieving a ROI against specific business outcomes. Sound familiar? However, over time, the connection between the business and IT was severed. This happened as computing switched from mainframes to minis to servers and finally to personal computers. Today you would add mobile devices to this progression. The transition of ownership changed along with these advances from the company, to departments, and to individual users. Computing did not all move to the end users as a significant amount computing still resides in back end data servers and today in the cloud. However, what did happen was the removal of the middle layer of management both in terms of managerial accountability and IT resources that supported them. This part of the organization is where sponsors, champions and the resources to build out projects once resided. During the time of this transition, IT also became more standardized which made it easier for it to be supplied as a commodity by external vendors instead of by internal resources. The role of IT soon turned into one that selects and manages suppliers of commodity components: networks, hardware, software, and systems. Today, it is not uncommon for companies to prefer pre-built application suites rather than individual applications or capabilities. However, when you consider IT as a commodity you are no longer considering it as strategic to your mission. With the loss of champions, sponsors, and resources, IT is left with a mandate to provide only company-wide systems (platforms) served now by the cloud. The remainder is left, not to functional groups as it once had, but to individual users. Without middle management there is very little capacity left to support strategic or competitive differentiation in terms of the use of computing and information services. This lack of strategic intent is a significant obstacle for digital transformation and creates the greatest risk to companies wanting to survive digital disruption. The Return of Strategic Computing and Information Services? Eli Goldrattt, the creator of Theory of Constraints, suggests that for technology to deliver benefits it must remove a limitation that you have that is holding you back from achieving your outcomes. Your limitations are unique to your business although they may be shared by others at some level. The business has always been the ones to build out new capabilities that were needed to meet their objectives. In earlier days you would buy separate hardware, commercial of the shelf software (COTS), and integrate them together. This was done in the context of a business function that needed new capabilities that in turn would generate improved outcomes. This did result in more silos than we wanted, but that is what enterprise architecture frameworks were supposed to solve and in most cases never did. Today we find ourselves with a shopping cart full of commodity capabilities at every level of the computing and information stack available as micro services all the way to application suites. As an aside, the only way that vendors can distinguish themselves is by creating a new way to do something that we already could. Sure it is shinier, perhaps faster, maybe better in some marginal way, but none of it is tied to your specific requirements or problems you need to solve, unless your requirements are so low as to match only basic functional levels. If you want something that meets your higher standards then you need to build it yourself. You will never find your solution in the cloud because there is not enough demand for your specific set of requirements. What you will find instead are the components and capabilities that you need to build your solutions. Think power tools, drywall, lumber, nails and screws, if that helps. If you are like most people these sit in your garage or basement and collect dust. And this brings us to the crux of digital transformation – it is about building a future not just buying technology. But who will do this? Who in your organization will champion the cause? And who will answer the question, what will we do with all that technology? A Call for Leadership We need to see the return of strategic computing and information services. Leadership at the middle level has been removed and replaced in most companies by technologies in the form of management systems and applications. No wonder we find many management functions calling out for more leadership. Technology is necessary but not a sufficient condition for success. Leadership needs to point the way forward and champion the cause. Leaders need to aim at something higher if they want more than basic improvements driven by cost reduction. This will require that top level management stand in the gap where middle management once stood. Without this kind of leadership, companies end up with users heading to their favorite Digital Depot and doing their own DIY projects. Some of that is already happening, and some of this is good. However, where this leads to is even more silos of computing at the individual level using software they can get for free that will run out in 90 days. If you thought aligning functional groups to strategic initiatives was challenging doing this at the individual level is even more. Whether you have a flattened organization or not, you still need leadership. You need it more than ever if you want to build your future rather than accepting the disruption that is coming your way. Digital technologies offer possibilities that did not exist before. However, you will need to answer the same question that we asked 25 years ago and is as relevant today: What will you do with all that technology?