SEARCH

Why Governance Starts with Obligations, Not Decisions "Requisite Authority — the decision-making capacity necessary for an obligation owner to fulfil their obligation." Scroll through any governance-focused discussion on LinkedIn right now and you'll find a recurring theme: organizations need decision authority at the point of execution. The argument is intuitive. Operations move fast. People closest to the action can't wait for three levels of sign-off. Therefore, push decision-making authority as close to the action as possible. It's a reasonable operational principle. But it isn't governance. It's operational efficiency using governance language. What Decision Authority Gets Right The focus on decision authority didn't come from nowhere. Decades of governance literature — COBIT, RACI, corporate governance theory, and more recently the AI governance frameworks from NIST and ISO — have centred on clarifying who can authorize what. This solves a real problem. In large organizations, ambiguity about decision rights creates paralysis, duplication, and unaccountable action. Clarifying those rights genuinely fixes things. But this literature solves a structural  problem, not a purposive  one. It answers "who decides" without first answering "in service of what commitment." In stable environments where the obligations are implicit and obvious — where everyone already knows what we're trying to achieve and just needs clear lanes — that works fine. The obligations are the water the fish don't notice. Where It Breaks Down Consider the range of obligations that any regulated organization must fulfil: safety obligations to workers and the public, security obligations to protect people and assets, sustainability commitments to communities and future generations, quality obligations to customers, ethical obligations to stakeholders, and legal obligations to regulators and the courts. Each of these represents a promise — sometimes mandated, sometimes voluntary — that someone in the organization owns and is accountable for keeping. Now ask: does the person who owns the safety obligation have the authority to stop a production run when conditions are unsafe? Does the person who owns the environmental commitment have the standing to redirect capital toward emission reductions? Does the person accountable for data privacy have the power to override a product decision that compromises it? In every case, the governance question isn't whether someone has decision authority in the abstract. It's whether the obligation owner has the specific  authority needed to keep their promise. When decision authority is allocated without reference to obligations, organizations end up with a familiar pathology: the safety manager has a title but not the authority to halt operations; the compliance officer can write reports but not block a non-conforming shipment; the sustainability lead can set targets but not direct spending. Decision authority exists, but it isn't matched to the obligations it's supposed to serve. The decisions are all authorized, documented, and reviewed — and the promise is still broken. From Decisions to Obligations The alternative isn't to abandon decision authority. It's to recognize that decision authority is derived , not foundational. The foundation is obligation ownership. An obligation owner isn't just someone with decision rights. They are someone who has made or inherited a promise — to a regulator, a customer, a stakeholder, the public — and who is accountable for its fulfilment across time. Decision authority is one capability they need. But they also need visibility into whether the obligation is being met, the capacity to intervene when it isn't, and the organizational standing to allocate resources toward keeping the promise. Decision-centric governance asks: "Who gets to decide what?" Obligation-centric governance asks: "Who owns the obligation, and what must be true for that obligation to be kept?" Decisions become instruments in service of obligations, not the primary object of governance. Requisite Authority Elliott Jaques' work on Requisite Organization offers a rigorous foundation for this shift. Jaques argued that organizational structure should be designed around the time horizon of accountability, not around functions or decision speed. Each level in his model exists because there is a qualitatively different kind of work to be done — work defined by the complexity and time span of the obligations attached to it. In Jaques' framework, decision authority isn't a freestanding thing you allocate for efficiency. It's a consequence of the accountability structure . You have decision authority because you are accountable for a certain scope of work over a certain time horizon, and you need that authority to fulfil that accountability. Strip away the accountability and the decision authority has no justification. This gives us a better term than "decision authority." What governance actually requires is requisite authority  — the decision-making capacity necessary for an obligation owner to fulfil their obligation. The word "requisite" does the critical work. It immediately implies that something else defines what's needed. Authority isn't self-justifying. It exists because an obligation demands it. The Diagnostic Question Requisite authority also gives us a diagnostic that decision authority alone cannot provide: Is the authority matched to the obligation? Too little authority relative to the obligation and you have an Operability Gap — the obligation owner made or inherited a promise but doesn't have the means to keep it. Too much authority without corresponding obligation ownership and you have unaccountable power — decisions being made by people or systems that bear no accountability for the commitments those decisions affect. Both are governance failures. But only the obligation-first framing reveals them as such. The decision-authority crowd can't ask "is this enough?" because they have no reference point for enough. Enough for what? For speed? For efficiency? Those are operational questions. "Requisite to the obligation" is a governance answer. What This Means for AI When an AI agent operates autonomously, it exercises decision authority without being situated in a requisite structure. There is no one above it carrying the longer-horizon obligation. No one tracing the link from the agent's micro-decisions back to the promise that justified those decisions in the first place. The consensus — "push decision authority to the point of execution" — is essentially flattening organizational accountability into a single layer. It optimizes for speed of action at the cost of accountability for commitments. Jaques would recognize this as the pathology he spent his career diagnosing: decisions being made at a level of complexity that the role wasn't designed to carry. The governance design question for AI isn't "where should decision authority live." It's "where do obligations live, who owns them, and what authority do those owners need to fulfil them?" That's a fundamentally different starting point, and it produces a fundamentally different governance architecture. The Bottom Line Decision authority is a necessary governance mechanism but an insufficient governance foundation. The foundation is obligation ownership. Decision authority is derived from it, allocated in service of it, and meaningless without it. The people arguing for decision authority at the point of execution aren't wrong. They're standing on a floor without knowing what's underneath it. Requisite authority — authority matched to the obligation it serves — is what's underneath.

Up until now, we created, stored, and moved data to where it was needed to drive our businesses. This was the world of Information Technology (IT) — and the foundation of Enterprise Architecture. That era is ending. AI has already absorbed virtually all the unstructured data available in the world. Large language models didn't just process that data — they internalized it. Now we need to build AI for the business — harnessing operational data, engaging the system of record, and deploying autonomous agents to do what could not be done before. Enterprise Architecture will no longer be designed to manage information. It will be designed to create and harness the power of artificial intelligence. This is the shift from Information Technology to Intelligence Technology — from IT to I²T. And it demands a new kind of compliance — not procedural, but operational. Real-time, adaptive, and capable of regulating AI at the speed AI operates. ⚡ Is your compliance ready for intelligence technology? Let's find out. Take our Compliance Capability Assessment and see where you stand before the shift leaves you behind.

As a lean compliance leader, your role is pivotal in upholding integrity and ensuring adherence to regulations and internal obligations while maximizing efficiency. To truly excel, it's essential to find purpose in your work and become a driving force for positive change within your organization. By embracing essential habits inspired by the principles of lean compliance, you can uncover your purpose and make a meaningful impact. 7 Habits of Successful Lean Compliance Leaders Habit 1: Be Proactive To find purpose, take initiative and embrace a proactive mindset. Seek out opportunities to improve compliance processes, eliminate waste, and drive efficiency. Embrace challenges and be a catalyst for positive change. By taking ownership and staying ahead of the curve, you become an influential leader in shaping lean compliance. Habit 2: Begin with the End in Mind Envision the impact you want to make as a lean compliance leader. Reflect on the broader purpose behind compliance and how it aligns with organizational goals. Keep your ultimate purpose in mind as you guide decisions and inspire others to work towards a shared vision of lean compliance excellence. Habit 3: Prioritize Value-Adding Activities Effective time management is key for lean compliance leaders seeking purpose. Focus on tasks that contribute value to the compliance process and eliminate non-value-added activities. Delegate responsibilities when necessary to free up time for strategic thinking and driving meaningful change. Habit 4: Foster Collaborative Partnerships Finding purpose as a lean compliance leader involves building strong relationships based on trust and collaboration. Seek partnerships with different departments, including operations and quality assurance, to streamline compliance efforts. By fostering collaborative relationships, you create a culture of shared purpose and maximize the effectiveness of lean compliance initiatives. Habit 5: Listen and Understand Listening is crucial for finding purpose in lean compliance. Take the time to understand the needs and perspectives of stakeholders, including employees, customers, and regulators. Empathize with their challenges and seek solutions that benefit everyone. By actively listening, you build trust, enhance communication, and unlock innovative solutions. Habit 6: Drive Continuous Improvement Embrace the lean principle of continuous improvement to discover purpose. Encourage a culture of learning and experimentation within your compliance team. Continuously seek ways to optimize processes, enhance efficiency, and reduce waste. By striving for continuous improvement, you demonstrate your commitment to purposeful lean compliance. Habit 7: Foster a Learning Culture As a lean compliance leader, prioritize personal and professional growth. Invest in your own development by seeking knowledge and staying updated on compliance trends. Encourage your team members to do the same, fostering a culture of learning. By continuously learning and growing, you can lead with confidence and inspire others to excel. Discovering Your Purpose Let me challenge you with this exercise to help you discover your purpose. Close your eyes and imagine that you have retired from your compliance leadership role. Imagine people at your retirement party giving speeches about you. What would you like to hear from them, your colleagues, customers, suppliers, and others you worked with over the years? Listen to what they are saying in your mind and write it down. Let that be your guide. Discovering purpose as a lean compliance leader is an ongoing journey that involves embracing essential habits inspired by the principles of lean compliance. By being proactive, envisioning the end goal, prioritizing value-added activities, fostering collaboration, listening and understanding, driving continuous improvement, and fostering a learning culture, you can unlock your purpose and become a transformative force within your organization. Embrace these habits, nurture your personal growth, and make a lasting difference as a purpose-driven lean compliance leader.

This is a summary of my presentation made recently on the topic of Lean Logistics which you can download below. Lean Logistics: Improving the Probability of Mission Success Using Lean Introduction I am Raimund Laqua, Founder, and Chief Compliance Engineer at Lean Compliance. Today, I'm excited to delve into the realm of Lean Logistics and the profound impact that LEAN has on managing uncertainty within the value chain. Join me as we explore the intricacies of risk, the power of Lean principles, and the integration of value chain analysis to improve the probability of mission success. Charting a Path Amid Uncertainty Throughout my career across a diverse number of North American industries, I've supported risk and compliance goals—ranging from safety and security to sustainability and regulatory compliance. However, the unifying thread across all these endeavours is the pervasive presence of uncertainty. In our journey today, I will explore how the principles of LEAN extend beyond efficiency and play a pivotal role in risk management, particularly in the context of Lean Logistics. A Mission to Confront Risk Let's start by acknowledging that risk is an inherent aspect of logistics. Whether transporting goods, managing inventory, or coordinating processes, the logistics landscape abounds with potential pitfalls. Recent global events, such as the COVID-19 pandemic and the Suez Canal disruption, have underscored the vulnerability of supply chains. This realization underscores the urgency of not just understanding risk but actively mitigating it. The Foundation: Value Chain Analysis Value Chain Analysis To grasp the interplay between risk, logistics, and LEAN, we must first comprehend the value chain. This conceptual framework, popularized by Michael Porter, dissects an organization's activities into primary and support functions, unveiling how each contributes to value creation. At its core, the value chain represents the journey from raw materials to the final product, with logistics serving as a critical link. The Quintessential Role of Logistics Logistics isn't just a function or a process; it's the heartbeat of the value chain. It orchestrates the intricate dance of transporting goods, managing inventory, and optimizing processes to ensure that products reach consumers efficiently. Within the value chain, logistics is tasked with achieving the "Seven Rights of Fulfillment": The Right Product To the Right Customer A the Right Time At the Right Place In the Right Condition In the Right Quantity At the Right Cost LEAN: Unveiling a Deeper Purpose While LEAN is renowned for its ability to streamline processes and eliminate waste, its value goes beyond efficiency. LEAN's core principles offer a comprehensive toolkit to tackle the most significant waste of all—risk. In the following sections, we'll explore how LEAN's principles align with the value chain analysis to empower organizations to thrive in the face of uncertainty. Risk, Uncertainty, and LEAN: A Complex Interplay Waste Is The Result Of Risk At the heart of our exploration is the intrinsic connection between risk, uncertainty, and LEAN. Uncertainty is the breeding ground for risk, and risk, in turn, is the catalyst for waste. When risk materializes, waste is generated—defects, excess processing, overproduction, waiting, inventory, transportation, motion, and underutilized talent. The challenge, therefore, lies in effectively contending with uncertainty to minimize waste. LEAN's Dual Approach: Margins and Risk Management LEAN offers a twofold strategy to address uncertainty: bolstering margins and risk management. By optimizing processes and reducing inefficiencies, LEAN enhances margins manifested as extra resources, time, and capacity. These act as a cushion against unforeseen challenges. Furthermore, integrating risk management tools, such as the bowtie analysis, empowers organizations to proactively buy down risk, ensuring the value chain's resilience. Navigating from Uncertainty to Certainty Improving the Probability of Mission Success Using Lean Our journey through the nexus of LEAN Logistics, value chain analysis, and risk management unveils a path to rise above the effects of uncertainty: Engage LEAN principles to amplify margins to create the opportunity to contend with uncertainty and risk Use margin to identify uncertainties using a total value chain analysis Use margin to evaluate and buy-down reducible risk using bow-tie analysis and risk management Use margin to cushion the effects of irreducible and residual risk. This creates a virtuous cycle of resiliency. The more you buy-down risk, the less waste is created, which creates greater margins to buy-down even more risk. Improving the Probability of Mission Success In conclusion, LEAN isn't just a means to improve efficiencies — it's a strategy that empowers organizations to navigate complexity and uncertainty with assurance. By combining value chain analysis, LEAN principles, and risk management tools, businesses can create a future that thrives amidst uncertainty. LEAN helps you improve the probability of success and decrease the probability of failure. Download the PowerPoint slides here:

In recent years many in the compliance industry have observed a shift in regulation from prescriptive to performance and outcome-based designs. What we are seeing is only the beginning of a trickle down effect emerging from regulatory reform over the last few decades across regulatory jurisdictions and across the world. During this time an increasing number of regulatory bodies have started to modernized the function of regulation, its processes and practices, and how regulation itself is regulated (meta-regulation). Most of this transformation has centered around the adoption of risk-based: strategies, operations, and tactics. There are many reasons for why this is happening. However, what is perhaps more important is that it is happening bringing with it continued changes for those who operate under regulation and to the role of compliance. In this article we will take a look at: Why is this happening? What is risk-based regulation? Regulatory models What might it mean to be a risk-based regulator? The regulation of regulators What this all means Why Is This Happening? Risk regulation is a relatively recent phenomenon and is an expression of what many social scientists call a "risk society." This is defined as a society in which there is an orientation to the future and a belief that we can control and manage risk. Some have said this is a shift from believing in fate to an "aspiration to control" future events. In many ways present-day changes to regulation can be seen as an outworking of this belief that risks can be anticipated and controlled. It is this notion that has invaded the public but also private sectors. The anticipation and control of risks affects the traditional notion of regulation. Dr. Malcolm K. Sparrow, a leading expert in the regulatory field, suggests that this change to risk-based approaches is a necessary manifestation when one considers the coverage of the problem space itself. Traditional regulation has focused on protecting public safety by means of delivering prescriptive obligations, compliance and enforcement functions primarily seen through a legal lens. This legal focus often results in many "paper violations" that are not necessarily harmful to the public. However, many of the risks that do affect the public are in the domain of legal and permissive behaviors which require a different approach than enforcement and strict compliance. The question that regulatory agencies are asking themselves is not which of these domains to focus on but rather how should resources be divided between them. They understand that to better protect (or create) public safety they will need to extend their focus to include illegal and harmful things. This shift requires that definitions exist for what "harm" means. Harms are similar to the notion of "hazards". They are complex, multi-dimensional problems that have the potential to negatively impact the public or the environment. The identification and solving of harms requires different skills, capacity, and organizational culture than what may exist within an agency and therefore will require the need for a transformational change. Perhaps, the most significant change in dealing with "harms" will be the introduction of risk management capabilities. What is Risk-based Regulation? At a high level, risk-based regulation, is a set of guiding principles to rationalize the regulatory process[3]. It does this by prioritizing regulatory actions based on an assessment of the risk to the achievement of its objectives. Risk-based regulation is more than the technical implementation of risk assessment and risk management techniques. These practices are used in conjunction with and part of the development of an agency's risk-based operating framework regarding its functions and processes. One of the appealing benefits of risk-based regulation is that is helps to address institutional risk; the threat of not achieving objectives by the regulatory agency. This is accomplished not only by an analysis of economic costs and benefits, but also the concepts of uncertainties and impacts [3]. This provides, among other things, an integrated decision making framework applicable to all levels of risk and organization. For a risk-based regime it is desirable to regulate all firms according to their particular risk, instead of simply prioritizing the supervision of the riskiest ones. Julia Black (London school of Economics), discusses and presents a remedy concerning the problems with ignoring the lowest risks and only focusing on high-risk firms. Black also makes the following reflections regarding risk-based regulation[3]: the danger of focusing more on diagnosis than cure; the importance of organizational culture in implementing risk based regulation; risk based frameworks can create risks; the danger of inappropriate reliance on firms’ internal controls is reduced but not removed in risk based approaches; (see models below) in making it clear what issues are not regulatory priorities, risk based regulation can have a potentially contentious political message. Changes driven by a "risk society" and modernization will continue to impact regulatory regimes. One of the ways is how risk itself is delegated between regulators and the organizations that are under regulation. Regulatory Models Malcolm Sparrow suggests that to better understand the way that risk-based regulation might manifest itself we can consider how three broad elements of risk management: risk identification, risk analysis and design, and risk implementation, might be delegated between regulators and the regulated industry: According to Sparrow, the traditional model for regulators is "Model 1." This is where government retains responsibility of risk identification, analyzing them, and developing (or selecting) an intervention design. This model produces prescriptive regulation typified by inspectors showing up with a tape measure to see how close you are to specified limits. In recognition of the diversity in the regulatory industry (along with levels of trust and assurance) regulators will allow firms greater flexibility (Model 2) in terms of the means by which risk is controlled. This creates "ends-based" instruments often referred to "performance-based" or "outcome-based" regulation. Large companies in highly technical industries may be delegated all three risk elements in the form of self-regulation (Model 3). This does not mean that the regulator has no responsibilities but may be in the form of "light-touch" regulation (this is different than right-touch regulation discussed below). Finally, Model 4, is a variant of the previous model where the companies under regulation are too small to afford or do not want to build out comprehensive risk-control systems on their own. They also do not want to be burdened with "going back" to "Model 1" and under the tutelage of prescriptive regulation. Instead, they form an industry association made up of representative members who will take on the self-regulation function. What Might It Mean To Be A "Risk-based Regulator?" A risk-based regulator will look different from those that focus only on enforcement and compliance. They will utilize the full set of regulatory instruments as needed to address the risks within their scope. Sparrow suggests that risk-based regulators will: Focus on the "Expert" rather than the "Legal" model of regulation Focus more on identifying and reducing "bads" (risk/harms), less on defining and promoting "goods" Practice "Regulatory Craftsmanship" (utilizing a broader range of tools, organized around specific tasks) Master organizational methods (less program-centric, more problem-centric) Fit different regulatory structures to different classes of risk (structural versatility) Use risk-mitigation as the foundation for partnerships Understand types of risk that pose special challenges These characteristics apply to all of Sparrow's regulatory models along with private sector risk management functions. The Regulation of Regulators In cases of self-regulation the idea of meta-regulation becomes necessary. There are two kinds of meta frameworks which often get confused: Light-touch regulation and Right-touch regulation. Light Touch This form of regulation refers to policy strategies that rely on private markets more than regulation. The light-touch narrative in a sense is the story about the Internet's regulatory journey. In many ways it is a policy of non-regulation. The primary role of government is to monitor the management of risk by the private sector and be prepared to adopt a different regulatory model if and when necessary. Right Touch Right-touch has its roots in the regulation of professional organizations. This form of regulation concerns itself with setting up the conditions by which self-regulatory bodies conduct themselves with respect to their responsibilities related to public safety or public interest. Right-touch regulation is in the formative stage and differs in its implementation. However, a common purpose of the right-touch approach is to strike the right balance between regulatory force and effective impact on risk. The UK Professional Standards Association (2015) defines six principles of the right-touch approach : Proportionate : regulators should only intervene when necessary. Remedies should be appropriate to the risk posed, and costs identified and minimized Consistent : rules and standards must be joined up and implemented fairly Targeted : regulation should be focused on the problem, and minimize side effects Transparent : regulators should be open, and keep regulations simple and user friendly Accountable : regulators must be able to justify decisions, and be subject to public scrutiny Agile : regulation must look forward and be able to adapt to anticipate change. The right-touch approach has been adopted by many professional associations and serves as an example for a "common-sense" manifesto for risk-based regulation across all sectors. What This All Means Regulatory bodies fundamentally exist to contend with public risk. Historically, the primary way that this has been done is by creating obligations, verification of compliance, and enforcement. However, this has now changed and will continue to do so as more regulatory agencies adopt risk-based approaches to their functions, processes, and specific problems they are responsible to address. This will drive continued change for those under regulation and specifically the role of compliance: The regulatory transformation currently underway has already created a change in how regulation and standards are designed and more change is expected. This will have continued impacts on organizations under regulation foremost of which will be for them to have clear objectives along with the capability to identify, analyze and implement effective risk controls. Regulatory agencies may offer the private sector unique insights into how a risk-based operating framework perform. As the sole purpose of a regulatory agency is to effect public risk they will have non-competing opportunities to develop risk management excellence. The concept of uncertainty and risk will continue to evolve and harmonize across risk disciplines. This will help to advance risk excellence to the benefit of both the public and private sector. Compliance will also evolve to become for those under regulation a " risk-based operational system " to meet obligations ex. Obligation Management System (OMS). Governance within both the public and private sector may benefit from further developments in meta-regulation with respect to internal policies, and voluntary obligations. References: [1] Dr. Malcolm K. Sparrow, "The Regulatory Craft – Controlling Risks, Solving Problems, and Managing Compliance" [2] Dr. Malcolm K. Sparrow, "The Character of Harms – Operational Challenges in the Control" [3] Julia Black, "The Development of Risk Based Regulation in the Financial Services: Canada, UK and Australia", 2004 [4] UK Professional Standards Association, "Right-touch Regulation", 2015

For compliance to succeed you must manage your obligations, but more importantly you need to keep your promises. This requires several things working together to produce the outcome of compliance: better safety, security, sustainability, quality, lower risk, and ultimately better stakeholder trust. ISO 37301: Performance-based Standard for Compliance Management Systems ISO 37301 can help you achieve those outcomes. But only if you intend to keep your promises. Otherwise, it will just be another standard among others that add more work, cost and deliver few benefits. ISO 37301 is not a rule-based standard like many of the others. ISO 37301 is performance-based which makes it ideal for performance and outcome-based obligations, and where compliance failure means mission failure. In this webinar, I help you understand what ISO 37301 is all about, how it works, and how to use it to keep all your promises. By doing so you will realize more than just incremental improvements. You will experience transformational benefits that compound year over year. We offer an on-line certificate program based on this webinar along with additional resources to help you use ISO 37301 to achieve compliance success.

Ensuring that organizational obligations and policies are effectively deployed and upheld is a critical task. This is where Hoshin Kanri, a Lean practice, comes into play. Hoshin Kanri offers a structured approach to operationalize obligations across organizations, providing a roadmap to align objectives, ensure accountability, and drive continuous improvement. In this blog post, we will delve into the framework of policy deployment using Hoshin Kanri, shedding light on its key components and how it helps organizations steer towards better outcomes. The Framework: Policy Deployment using Hoshin Kanri Integrative Framework to Operationalize Obligations At its core, policy deployment using Hoshin Kanri is about translating high-level organizational goals and policies into actionable plans that permeate throughout the organization. This framework can be summarized as follows: Define Obligations and Promises : The journey begins by defining organizational obligations and high-level policies. These policies provide guiding principles that align the organization with its strategic direction. Promises are more specific commitments derived from the policies, essentially breaking down the high-level goals into tangible objectives. Policy Deployment Plans (PDPs): Once policies and promises are established, they are captured in Policy Deployment Plans (PDPs). These plans serve as roadmaps, outlining the specific actions, responsibilities, and timelines required to meet the promises. Each PDP is a detailed action plan that brings clarity to the path forward. Negotiation : The negotiation phase is where the rubber meets the road. PDPs are not handed down from the top; instead, they are negotiated with those responsible and accountable for their execution. This negotiation process is known as "Catch-ball." It encourages open dialogue and collaboration, breaking down silos and ensuring everyone is on the same page. Alignment, Accountability, and Assurance Policy deployment using Hoshin Kanri is a powerful framework because it helps drive alignment, accountability, and assurance across the organization: The 3 A's of an Effective Compliance Program Alignment : The process aligns every individual and team with the organization's policies and objectives, creating a shared sense of purpose. Accountability : Through the negotiation and Catch-ball process, clear responsibilities are assigned, leaving no room for ambiguity. This enhances accountability at all levels of the organization. Assurance : By monitoring both quantitative and qualitative aspects, the organization gains assurance that it is not only meeting its targets but also advancing its long-term obligations and outcomes. Two Primary Loops: Quantitative and Qualitative Regulation In policy deployment using Hoshin Kanri, there are two primary loops that guide the process: Meeting Objectives (Quantitative Regulation - Compliance 1) : This loop focuses on quantitative regulation, ensuring that the organization is meeting its numerical targets and objectives. It involves tracking key performance indicators (KPIs) and metrics to measure progress towards the promises made in the PDPs. Meeting Obligations and Advancing Outcomes (Qualitative Regulation - Compliance 2): While meeting numerical targets is crucial, qualitative aspects are equally important. This loop emphasizes qualitative regulation, ensuring that obligations are met and outcomes are advanced. It involves assessing the impact of policies on the organization's culture, values, and long-term sustainability – it measures effectiveness. A Proactive and Integrative Program What emerges from policy deployment using Hoshin Kanri is an integrative and proactive program. It's not merely about meeting immediate goals but about strategically advancing the organization towards better outcomes. It's a dynamic process that encourages continuous improvement and adaptability in a rapidly changing environment. Building a policy deployment program using Hoshin Kanri requires a structured approach: Leadership Commitment : Start by securing commitment from top leadership. Without their buy-in, it's challenging to drive such a comprehensive change. Education and Training : Provide training and education on Hoshin Kanri principles and methodologies to all levels of the organization. Policy Development : Develop clear and concise organizational policies that align with your strategic direction and organizational obligations. Promise Identification : Identify specific commitments derived from these policies, ensuring they are actionable and measurable. Policy Deployment Plans : Create detailed PDPs that outline responsibilities, timelines, and metrics for each promise. Catch-ball Process : Implement the Catch-ball process to negotiate and refine the PDPs with those responsible and accountable. Monitoring and Feedback : Continuously monitor progress using KPIs and gather feedback to make necessary adjustments. Continuous Improvement : Encourage a culture of continuous improvement, where the organization learns from its successes and failures. Policy deployment using Hoshin Kanri is a robust framework for operationalizing obligations across organizations. It not only ensures alignment, accountability, and assurance but also drives organizations towards better outcomes. By following the structured approach outlined in this blog post, you can build a proactive and integrative program that transforms your organization's policies into tangible objectives, making a meaningful impact on its success and sustainability.

In this blog post we walk through the approach developed by Marissa Kephart in collaboration with Lean Compliance to define a golden thread of assurance for an environmental program. In this post we look at the use of a Dependency (or Design) Structure Matrix (DSM) to better understand the interactions of The12 Environmental Pillars (download them here ), which interactions are essential, and which ones contribute the most to overall program effectiveness. This information will help determine which should be part of the golden thread. In Part 2, we will consider the use of a balanced scorecard to monitor the golden thread and provide insights for decision makers on how to improve overall program performance. What is a Golden Thread? The 12 Environmental Pillars To provide assurance that environmental obligations will be met, an environmental program must perform such that its outcomes are continuously advanced towards the overall goal of community sustainability. This outcome is created by the product of the interaction of 12 environmental pillars. A “golden” thread that runs through the pillars of an environmental program – Environmental Golden Thread – can serve to provide assurance that essential capabilities exist and are operational. It can also provide traceability and transparency for retrospective and prospective analysis, ensuring the integrity of the environmental program and all its systems and processes. Using an Environmental Golden Thread can also provide leadership and management with valuable insights to help make better decisions associated with environmental obligations, commitments, and investments. Additionally, this thread will enable better coordination and alignment of effort across an organization in support of overall program objectives. What is a DSM? A Dependency Structure Matrix (DSM) is a tool used to represents a system and its components to better understand critical dependencies. A DSM models system elements and their corresponding information exchange, interactions, and relationship in a compact visualization to highlight the important dependencies. Dependancy Structure Matrix An environmental program will include many aspects which can be modelled using a DSM. We have used it here to model the 12 environmental pillars which need to be advanced simultaneously towards the goal of community sustainability. Since program outcomes are a product of system interactions, using a DSM will help to better understand how to manage environmental pillars collectively to achieve program objectives. In the process, this understanding will contribute to the development of an environmental golden environmental thread - the mechanism to provide program assurance. The following baseline DSM was created based on an original ordering of the 12 pillars: Baseline DSM Analyzing Adjacency Within a system there can be various types of relationships between elements. As shown below, a relationship can either be sequential, coupled or parallel. The latter was not considered since it represents no interaction between elements. In a sequential relationship, element A influences B, as shown in the diagram below. This gives an idea of which elements to focus on before others for increased program output. There also exists adjacency relationships which are called, "coupled". This is where the flow of influence or information is intertwined: element A influences B and element B influences A, as shown below. DSM Relationships The performance of an environment program is helped by knowing which program pillars have sequential and parallel adjacency with other pillars. This will help determine which pillars depend on another and how this might impact how they are managed. Sequential Adjacency For sequential relationships, two pillars within the DSM are intertwined where pillar A influences pillar B. As pillars are more like streams rather than static assets not all of pillar A may be necessary before Pillar B. What is important is that Pillar B needs something from Pillar A to be effective. Knowing the type of relationship provides visibility as to which pillars need upfront planning and should be prioritized. This planning may help uncover other dependencies that have secondary influences. Within the Environmental Golden Thread DSM, there exists many adjacency relations between pillars. Most of these relationships are sequential where A reinforces B, fostering an increased output for B with the presence of A. For example, the following pillars are sequential relationship in the Environmental Golden Thread model: Carbon Neutrality / Circular Economy Environmental Stewardship / Community Sustainability Environmental Stewardship / Circular Economy Active and Green Transportation / Environmental Health and Safety Climate Change Risk and Adaptation* / Adaptive Management for Service Reliability Infrastructure Resilience / Climate Change Risk and Adaptation * The bolded pillars in the above list indicate which dependencies are primary and can be sequentially prioritized within the coupled relationship, since the Environmental Golden Thread model is built with a combination of primary and secondary dependencies. Coupled Adjacency Coupled relationships are seen where two dependencies are located directly across the DSM’s diagonal from each other, where A must exist to get B and B must exist to get A. As such, the coupled relationships in the model show the critical areas of focus in the system. For example, the following pillars are coupled: Circular Economy / Zero waste Greenhouse Gas Emission Reductions / Carbon Neutrality Climate Change Risk and Adaptation / Environmental Health and Safety Environmental Health and Safety / Environmental Stewardship · Adaptive Management for Service Reliability / Infrastructure Resilience Coupling is even more vital to the health of the overall system. Coupled dependencies' proximity to the diagonal axis of the DSM indicates their role in connecting the pillars of the Environmental Golden Thread. Additionally, since all coupled relationships within the model include both primary and secondary dependencies, the primary dependencies should be prioritized over the secondary ones in the coupled relationship. However, due to their tightly coupled nature, the performance of the primary dependency may affect the performance of the secondary dependency, and vice versa. Dependency Rank Ordering The total number of dependencies in either the vertical or horizontal rows of the DSM give insights into which program pillars should be managed more carefully and with a higher priority. Pillars that are high on both lists indicate that they should be of high priority, whereas the lower ones serve to connect-the-dots together, effectively keeping the critical chain intact. This analysis is dependent on the organization’s interest in either primary or secondary dependencies, or both, as the figures below show that multiple combinations of priority can be determined dependent on individual priority of system dependencies and pillars. Vertical Dependency Rank Order Marks going down a single pillar’s column in the DSM indicate how many outputs that pillar has, as well as which of the other pillars that pillar is dependent on. Knowing which pillars have the most vertical marks, or dependencies, gives an idea as to how many and which pillars are necessary to achieve the objectives of the individual pillar and the system. As such, this gives an idea as to the pillar’s overall dependence on the other 11 pillars within the system model. The total number of dependencies in each pillar’s vertical row were then counted and ranked by the total number of dependencies, as well as the primary and secondary on an individual level, as follows: Based on total number of dependencies (primary + secondary): 1) Food Security 2) Zero Waste 3) Environmental Stewardship 4) Active and Green Transportation 5) Circular Economy 6) Infrastructure Resilience 7) Adaptive Management for Service Reliability 8) Environmental Health and Safety 9) Climate Change Risk and Adaptation 10) Carbon Neutrality 11) Community Sustainability 12) Greenhouse Gas Emission Reductions Based on the number of primary dependencies: 1) Food Security 2) Climate Change Risk and Adaptation 3) Environmental Health and Safety 4) Zero Waste 5) Environmental Stewardship 6) Active and Green Transportation 7) Circular Economy 8) Infrastructure Resilience 9) Adaptive Management for Service Reliability 10) Carbon Neutrality 11) Community Sustainability 12) Greenhouse Gas Emission Reductions Based on the number of secondary dependencies: 1) Zero Waste 2) Environmental Stewardship 3) Food Security 4) Active and Green Transportation 5) Circular Economy 6) Infrastructure Resilience 7) Adaptive Management for Service Reliability 8) Carbon Neutrality 9) Environmental Health and Safety 10) Climate Change Risk and Adaptation 11) Community Sustainability 12) Greenhouse Gas Emission Reductions The figure below shows that the pillars “Climate Change Risk and Adaptation”, “Environmental Health and Safety”, and “Food Security” have the most primary dependence on other pillars in the model. This demonstrates that to achieve these pillars, the other pillars that they are dependent on must be started first to support the other. This analysis is dependent on the organization's interest in either primary or secondary dependencies, or both, as the figure below shows that multiple combinations of priority can be determined dependent on individual priority of system dependencies and pillars. Vertical Dependency Rank Order Horizontal Dependency Rank Order Marks going across a single horizontal row of the DSM represent dependencies flowing to pillars that are necessary to achieve the objective of the pillar corresponding to that row. The more dependencies each pillar has in their row indicates that it is more connected to the other pillars of the system model, therefore it should be prioritized over pillars of lower dependency counts. These horizontal dependencies show which pillar has the most inputs, or how many other pillars the pillar row supports, as well as its overall contribution to the program model. The total number of dependencies in each pillar’s horizontal row were then counted and ranked by the total number of dependencies, as well as the primary and secondary on an individual level, as follows: Based on total number of dependencies (primary + secondary): 1) Environmental Health and Safety 2) Carbon Neutrality 3) Community Sustainability 4) Adaptive Management for Service Reliability 5) Climate Change Risk and Adaptation 6) Circular Economy 7) Active and Green Transportation 8) Food Security 9) Infrastructure Resilience 10) Greenhouse Gas Emission Reductions 11) Environmental Stewardship 12) Zero Waste Based on the number of primary dependencies: 1) Environmental Health and Safety 2) Adaptive Management for Service Reliability 3) Climate Change Risk and Adaptation 4) Active and Green Transportation 5) Carbon Neutrality 6) Circular Economy 7) Food Security 8) Infrastructure Resilience 9) Greenhouse Gas Emission Reductions 10) Environmental Stewardship 11) Zero Waste 12) Community Sustainability Based on the number of secondary dependencies: 1) Community Sustainability 2) Environmental Health and Safety 3) Carbon Neutrality 4) Adaptive Management for Service Reliability 5) Climate Change Risk and Adaptation 6) Circular Economy 7) Food Security 8) Infrastructure Resilience 9) Greenhouse Gas Emission Reductions 10) Environmental Stewardship 11) Active and Green Transportation 12) Zero Waste The figure below shows that the pillars “Active and Green Transportation”, “Environmental Health and Safety”, “Adaptive Management for Service Reliability”, and “Climate Change Risk and Adaptation” critically contribute the most to other pillars in the model. This demonstrates that achieving the objectives of these pillars subsequently supports the rest of the pillars, since the other pillars are highly dependent on them. Horizontal Dependency Rank Order Primary versus Secondary Dependencies Without the existence of the secondary dependencies in the system model, the program would still be intact; however, there would be less opportunity for further improvements of user’s environmental obligations. As can be seen in the DSM, most of the secondary dependencies are located well outside the diagonal region, as well as the two pillar grouping areas (as indicated by the black outlines). This indicates that as the dependency locations travel further from the diagonal, the less they critically support the “Golden Thread”, instead offering additional reinforcements to the model. However, there are several exceptions where the secondary dependencies are located adjacent to the DSM's diagonal where the presence of these dependencies adds a layer of depth to the system that allows organizations the option to tailor the model to their unique needs and to understand the possible combinations of the pillar inter-dependencies more fully. The secondary dependencies, if considered by an organization, connect the loose ends of the primary dependencies, and necessitate organization's to implement a more holistic approach to the Environmental Golden Thread through systems thinking and active management techniques. Off-axis Primary Dependencies In the final partitioned DSM, several primary dependencies were observed that did not directly follow the line of the diagonal axis, including: Climate Change Risk and Adaptation to Adaptive Management for Service Reliability Active and Green Transportation to Community Sustainability Food Security to Environmental Health and Safety Infrastructure Resilience to Climate Change Risk and Adaptation Such dependencies remain primary, despite their location in the DSM, since they serve as connectors between the different subgroups in the DSM. For example, the dependency between the pillars “Climate Change Risk and Adaptation” and “Adaptive Management for Service Reliability” connects the subgroup of three pillars together from the main Golden Thread loop. Similarly, the dependency connecting “Active and Green Transportation” and “Community Sustainability” is located far from the diagonal axis; however, the presence of this connection is vital to the structure of the model since it connects the main upper loop to the lower loop of the model (see dependency map below). Overall, these off-axis primary dependencies portray locations of possible redundancy in the pillar dependencies, without them the program still functions; however, the critical chain among the 12 pillars is weakened. Partioned DSM DSM Insights There are a number of insights that we be derived from using a DSM on the 12 program pillars: Pillars with 'X's directly adjacent to the diagonal form primary dependencies with corresponding pillar. Pillars with 'X's farther away from the diagonal form secondary dependencies and provide further areas of contribution to the program. Pillars with tightly coupled adjacency should be planned together Pillars with sequential adjacency should be planned in order of their dependency Pillars should exploit dependencies to reinforce and amplify pillar performance Pillars with the greater number of 'X's vertically require more inputs Pillars with the greater number of 'X's horizontally generate more outputs Connecting each pillar together using this information will create a golden thread that ensures each pillar performance is combined to maximize overall program effectiveness. This will save costs, realize outcomes sooner, and create a virtuous cycle of improvement over time. In Part 2, we will combine this analysis with a balanced scorecard to provide a mechanism to monitor pillar and program performance to help decision makers know how best to invest and make improvements.

Golden Thread of Assurance for Compliance An important role of compliance is keeping organizations operating between the lines and ahead of risk. And when it comes to risk many will provide a long list that you might consider. Some of these will indeed require attention and careful deliberation. However, there will always be uncertainty when pursuing mission success. There will always be a list of risks to handle. What’s better is knowing how to meet obligations and deliver stakeholder commitments in the presence of uncertainty. This is why compliance should consider operational aspects when planning their compliance efforts.These are the capabilities necessary for compliance to be successful in the presence of uncertainty. A measure of compliance success is when compliance is fit for purpose, capable of meeting all obligations, and perhaps most importantly, capable of realizing the benefits that come from being in compliance: better safety, security, sustainability, quality, regulatory, and ultimately stakeholder trust. The following are essential compliance capabilities as viewed through an operational lens. These define the operational requirements for an effective compliance program: Obligation Management Promise Fulfillment Value Chain Integration Organizational Alignment Compliance Operability When operating together these form a golden thread of assurance to provide the necessary confidence for compliance success. Let's take a look at each one, starting with obligations. 1. Obligation Management Compliance must manage obligations Many organizations have compliance management systems. However, very few manage obligations. You may have a management system for quality, environmental, safety, security and so on. These manage the “practice” of compliance but do not necessarily obligations themselves. For that you need a compliance program. ISO 37301 is a recent standard you can use that has the basics for such program. It elevates compliance by providing a system to manage compliance performance. ISO 37301 includes a concept of operations diagram that illustrates the various functions, behaviours, and interactions that need to be considered and continuously improved over time. This is a good start for organizations beyond the basics of what common management systems provide. We need to remember that we don't need compliance management we need managed obligations. 2. Promise Fulfillment Compliance must operationalize obligations. Organizations may track their obligations but seldom do they keep track of their promises which makes them difficult to keep. Promises are the operational side of obligations. In fact, promises are operationalized obligations. They define the commitments we make to meet our obligations. Promises describe the how while obligations describe the what . Obligation and Promises If obligations are the requirements, promises are the specifications that tell us what we need to achieve compliance. While managing obligations is a level up for many organizations, managing promises is what makes them effective at it. To meet obligations, organizations need to learn and practice how to keep their promises. 3. Value Chain Integration Compliance must be an integral part of the value chain For compliance to be successful obligations must be operationalized which means compliance must be an integral to the value chain. The following adaptation of Michael Porter's value chain helps illustrate why this is important: Total Value Chain At the basic level companies desire to advance profit and better margins. However, organizations will also have other outcomes promised to their stakeholders. Ensuring these outcomes requires programs to operational obligations. These programs (or what we call certainty programs) translate obligations into value chain commitments (or promises) that contribute to meeting targets or advancing outcome associated with safety, security, sustainability, quality, and so on. This kind of integration is known as internal regulation – regulating towards better outcomes, not only better margins. This is not a project that is done once and forgotten. Value Chain Integration is a continuous process that aligns organizational values with operational objectives. 4. Organizational Alignment Compliance must bridge the gap between what's above and what's below There is a line that runs through an organization that separates the difference between: upper management and lower management. Organizational Barrier This organizational barrier creates a gap between: those who are accountable and those that are responsible programs that change state, and systems that resist change to maintain state obligations that define compliance requirements and promises that specify our commitments the ends and the means the benefits and the cost our long term vision and our short term mission Now, there used to be something called middle management to do the translation between what is above and what is below because they all speak different languages. This layer has been mostly gutted in recent years to flatten organizational structures. What does this mean for compliance? If you want an effective compliance program, that program must now include managing change, and negotiation of this barrier. Failure to do this will result in compliance failure. You could say that operationalizing obligations depends on how well you negotiate this barrier. Compliance must find a way to align these two worlds. 5. Compliance Operability Compliance must be operational For compliance to be successful it must be operational. It must be fit for purpose, able to meet obligations, and capable of realizing the benefits of compliance. To understand this better we developed the following compliance operational model: Compliance Operational Model This model comprises what's needed to continuously deliver on promises to maintain a state of compliance: Operational Governance - sets the destination - the desired outcomes, the goals that we want to achieve. Operational Programs - what governance uses to steer towards outcomes (the controller of the subsystems) Operational Subsystems - implement controls (which are processes) to ensure that objectives are consistently met Operational Processes - do the work of compliance Feed-back and Feed-forward processes along with improvement loops for conformance, performance, and effectiveness. These are all continuous functions, behaviours, and interactions not yearly activities or tasks. When operational they will achieve what we call Minimal Viable Compliance (MVC) - the minimum performance necessary to start realizing benefits. MVC is not achieved at the end of a 5-step maturity model, but right at the start. Why is that important? Because, compliance failure means mission failure.

At a fundamental level compliance programs protect the value stream from threats that hinder the creation of value. Each program contributes to keeping the value chain safe from various risk including: quality risk, occupational safety risk, security risk, and so on. These programs are socio-technical in nature in that they recognize the interaction between people and technology often across multiple levels of organization. Rasmussen's Risk Management Framework (also known as Rasmussen's ladder) provides useful insights when it comes to understanding risk across social-technical boundaries to achieve safety objectives along with other risk objectives. Rasmussen originally developed his approach as part of a proactive risk management strategy, however, its primary application has been as an accident analysis tool (ACCIMAPS) for complex socio-technical systems. Rasmussen's Risk Management Framework This framework has its roots in systems thinking based on the notion that accidents are hidden in normal operations and do not need special causes. This is similar to Safety II (Holnagel, 2017), and Deming's work that defects are caused by normal causes (natural variation). Rasumussen's model and others since represent a growing trend away from "root causes" or you might say "special causes" for systemic failures. Rasmussen' suggests the following system boundaries by which to map structure, components and their interactions: Rasmussen's Risk Management Framework The structure of Rasmussen's Risk Management Framework considers six levels: Government - where laws and regulations are developed; Regulatory - where industry standards are developed based on laws and regulations; Company - where company policies and procedures based on industry standards govern work processes; Management - where company policies and procedures are implemented; Staff - representing the activities and characteristics of workers performing the processes; and Work - representing the equipment and environment by which work happens Vertical integration is required for the system to function safely. This means that decisions made at the higher levels should propagate down the hierarchy as information flows upwards. The interaction and dependencies across levels are critical to ensure that intended safeguards protect system states. Threats to safety result from a loss of control caused by inadequate vertical integration across levels, not just from deficiencies at any one level. Nancy's Leveson [2] provides an example of how this can be used to model safety control: Nancy Leveson - Hierarchical Model of Safety Control Framework Predictions Rasmussen's Risk Management Framework makes a series of predictions[1] in relation to performance and safety in complex socio-technical systems: Safety is an emergent property of a complex socio-technical system. They are impacted by the decisions of all of the actors – politicians, managers, safety officers and work planners – not just the front-line workers alone. Threats to safety are usually caused by multiple contributing factors , not just a single catastrophic decision or action. Threats to safety usually result from a lack of vertical integration (i.e. mismatches) across levels of a complex socio-technical system, not just from deficiencies at any one level alone. The lack of vertical integration is caused, in part, by a lack of feedback across levels of a complex socio-technical system. Actors at each level cannot see how their decisions interact with those made by actors at other levels, so the threats to safety are far from obvious before an incident. Work practices in a complex socio-technical system are not static . They will migrate over time under the influence of a cost gradient driven (see Drift to Failure below) by financial pressures in an aggressive competitive environment and under the influence of an effort gradient driven by the psychological pressure to follow the path of least resistance. The migration of work practices can occur at multiple levels of a complex socio-technical system, not just one level alone. Migration of work practices causes the system’s defenses to degrade and erode gradually over time. Accidents are induced by a combination of this systematically induced migration in work practices and a triggering event, not by an unusual action or an entirely new, one-time threat to safety. Drift to Failure Rasmussen also identified a phenomenon which he called, "drift to danger." systemic migration of organizational behavior toward accident under the influence of pressure toward cost-effectiveness in an aggressive, competing environment Rasmussen's Migration Model - Transport Canada - Jim McMenemy, Safety Intelligence Project Rasmussen's migration model represents constraints (i.e. economic, workload, safety) which create the following possibilities: If the system reduces output too much, it will fail economically and be shut down If the system workload increases too far, the burden on works and equipment will be too great If the system moves in the direction of increasing risk, accidents will occur In essence, accidents occur when the system's activity crosses the boundaries into unacceptable safety. Application Rasmussen's Risk Management Framework provides a good representation of the real world and has been used to better understand safety risk in dynamic, social-technical systems. Accimaps[3] which are derived from Rasmussen's framework provide a generic and flexible approach since they do not use predefined taxonomies of hazards or failures across the various levels. Accipmaps have been used in aviation, defense, oil&gas, risk management, public health, patient safety, and environmental studies. Rasmussen's framework also provides the means to better understand how to achieve other risk objectives such as quality, resilience, reputation, financial, and trust. References: [1] A.L. Cassano-Piche, K.J. Vicente and G.A. Jamieson, "A test of Rasmussen’s risk management framework in the food safety domain: BSE in the UK", 2009, Theoretical Issues in Ergonomics Science [2] Nancy G. Leveson, "Rasmussen’s Legacy: A Paradigm Change in Engineering for Safety", 2015, [3] Justen Debrincat, "Assessing Organizational Factors in Aircraft Accidents using a Hybrid Reason and AcciMap Model", 2012, RMIT University

Raimund Laqua, P.Eng., PMP For decades, the system of record has been the gravitational centre of the enterprise. Your ERP, your CRM, your quality management system — whatever the acronym, the function was the same. One place where the authoritative version of the truth lives. Every audit trail starts there. Every compliance obligation traces back to it. Machines have always done part of the work inside these systems — workflows, automated triggers, batch processing. But that work was governed, designed, and built by humans. Every automated step was deliberately engineered into a known path. The system of record captured the work because the work was designed to flow through it. And when governance was working, the how mattered as much as the what — the work reflected the organization's values, its commitments, and its obligations. But what happens when autonomous agents do the work? The Shift AI assistants are already embedded in the platforms organizations use — Microsoft's Copilot across Dynamics 365, SAP's Joule, Salesforce Einstein. Today, a person still asks the question and still decides what to do with the answer. But the vendors aren't stopping there. They're explicitly moving from "system of record" to "system of intelligence." The system no longer waits for people to analyse data. It acts. That's not an assistant — that's an agent with authority. And it changes everything about where the source of truth lives. It's important not to confuse this with the workflow automation we've had for decades. A workflow is a deterministic path — designed by humans, with each step predefined, each decision point mapped, and the system of record baked into the sequence. The workflow writes to the system because the system is part of the track it runs on. An autonomous agent doesn't follow a track. It receives an objective, assesses the situation, decides what to consult, coordinates with other agents, takes action, and moves on. It may take a different path every time depending on what it finds. The system of record isn't part of that path unless someone engineered it to be. No human is watching each decision. No human can — not at the speed and scale agents operate. Now ask the question: where is the system of record in that workflow? And more importantly — is the work being done in a way that upholds what the organization stands for? The Problem Work was done. But were the promises kept? Not just "did the agent complete the task" — but did it fulfill the organization's actual commitments? The right output can only be produced the right way. Did it uphold the values behind those commitments — the safety, the quality, the duty of care that the organization promised its regulators, its customers, and its stakeholders? If nobody engineered the agent to track that, the question may not even be answerable. When agents coordinate with other agents to deliver on a shared promise, it gets worse. The source of truth isn't a system anymore. It's distributed across agent interactions that may be ephemeral. The source of truth didn't move to a new system. It dissolved into a process. Whose Promises Is the Agent Keeping? Here's what I think cuts to the heart of it: when we say an agent "works," we usually mean it completes the task and stays within its guardrails. Those are the developer's promises. The promises your organization has made are different. Promises to comply with governance policies. Promises to produce auditable evidence. Promises to fulfill obligations in a way that reflects your values — not just efficiently, but ethically, safely, and transparently. Right now, there's no mechanism in most agent architectures to translate those organizational promises into agent-level operational commitments. The agent doesn't know what you promised the regulator. It doesn't know what your values require. It knows what its developer built it to do. The agent is keeping the developer's promises. Nobody has engineered it to keep yours. Can Agents Follow Governance Policy? This raises a harder question: can autonomous agents follow governance policies at all? Not the way humans do. An agent can follow instructions and be constrained by guardrails. But governance requires understanding intent, interpreting context, and exercising judgment about edge cases the policy didn't anticipate. Agents don't do that. They optimize toward objectives within whatever constraints they were given. If the constraint was well-engineered, the behaviour looks like compliance. If it wasn't, the behaviour looks confident and wrong. There's a deeper problem. Any codified rule will eventually be inadequate because the agent optimizes around the measurable parts and erodes the unmeasurable intent. The letter of the policy gets followed. The spirit gets lost. Not through malice — through the physics of optimization. So agents can fulfill obligations that have been engineered into their architecture. They cannot interpret governance policies the way a competent professional would. And they cannot uphold organizational values unless those values have been translated into operational commitments they're designed to keep. The Humans in the Loop The human in the loop is not only the person reviewing the agent's output after the fact. You can't verify what you can't see. An important human in the loop is the engineer who designs the agent to do the right thing before it's deployed. The accountability is front-loaded into the architecture, or it doesn't exist at all. Governance policy can't be an external constraint layered on after the fact. It has to be engineered into what the agent is — because the right output can only be produced the right way, and the right way has to be built in. The Promise Architecture I've been thinking about this through Mark Burgess's Promise Theory. The core insight: you can only make promises about your own behaviour. An obligation imposed from outside isn't a promise until you've assessed it, determined what you can genuinely commit to, and declared that commitment. Most agent architectures work on an imposition model — do this task, follow these rules. For work that matters, that's not enough. The agent needs to receive the obligation, assess whether it can fulfill it, declare what it can commit to, and fulfill that commitment while producing evidence that the promises were kept — because the right output can only come from a process that upholds the organization's commitments and values. That's what I've been calling a Promise Agent. Policy isn't a reference document the agent consults — it's an operational capability the agent possesses. A fire suppression system doesn't "consult" the fire code. The requirements are engineered into its design. The system embodies the obligation. Delivery matters as much as the declaration. In a human workflow, the person doing the work is also the person creating the record. In an agentic workflow, that coupling breaks. This is why promise delivery can't just mean the agent produced an output. The right output can only be produced the right way — and the agent must demonstrate that the path it took was consistent with what the organization committed to. In Burgess's framework, delivery is continuous — the agent evaluates whether it can still keep delivering, and signals when that capability is compromised. The Golden Thread So where does the source of truth actually live? In the human model, it lives in the system of record. One place, one version, one truth. In the agentic model, that's no longer sufficient. The source of truth lives in the promise architecture — the traceable relationship between four things: the obligation (what the organization committed to), the promise (what the agent declared it could deliver), the delivery (how the agent fulfilled it and whether it did so in a way consistent with the organization's values), and the evidence (the demonstrable record that all three are connected and consistent). What connects these four elements is the golden thread of assurance — the unbroken, traceable line that runs from commitment through promise through delivery through evidence. In a human workflow, the golden thread runs through the system of record. In an agentic workflow, it has to run through the promise architecture — and the system of record becomes where that thread is anchored and made auditable. If the thread breaks at any point, assurance is lost. And any of these elements without a connection to the organization's values is compliance without purpose — the letter without the spirit. The system of record doesn't disappear. But its role shifts from being the source of truth to being the registry of truth — the place where the golden thread is anchored, where the organization can demonstrate that its agents are keeping its promises in a way that upholds its values. Most current systems of record weren't designed for that. They were designed for humans filling in forms. A Design Problem I'm not arguing that the system of record is dead or that fully autonomous agent workflows are the norm yet. But the building blocks are being assembled — in the platforms, in the vendor roadmaps, and in the architectural decisions organizations are making right now. The concern is that the decisions being made today are creating an architecture where agents do work without a golden thread connecting what they did to what the organization promised — and to the values behind those promises. Where nobody can demonstrate that the right output was produced the right way. That's not a technology failure. It's a design failure. And design failures are preventable. If you're deploying AI agents in a regulated environment, the question I'd encourage you to ask is not "what can the AI do?" but "will the AI do it in a way that keeps our promises and upholds our values?" If you don't have a clear answer, you have a design problem that's worth solving now — before it becomes a compliance problem you have to explain later. Raimund (Ray) Laqua, P.Eng., PMP, is a computer engineer and the founder of Lean Compliance Consulting. With over 30 years of experience across regulated industries — oil & gas, pharmaceuticals, medical devices, aerospace, nuclear, and financial services — he developed the Lean Compliance methodology grounded in Promise Theory, cybernetic regulation, and total value chain analysis. Ray is Chair of the AI Committee for Engineers for the Profession (E4P), sits on ISO's ESG working group, serves on OSPE's AI in Engineering committee, and advocates for federal Digital Engineering licensing in Canada. He writes regularly at leancompliance.ca .

The Future of Compliance - Digital Threads In response to the Grenfell Tower Fire, the UK government recently 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 to improve compliance. 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 t o 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 when 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