Designing AI Governance as a System Architecture

By Jewel Darlington, Chief AI Governance Officer & Founder, Solutions by Jewel An enterprise AI agent receives approval to update a configuration in staging. During execution, it invokes a downstream service whose selected target is production. The engineering team must determine whether the resulting action falls inside the approved scope, which execution instance initiated it, and which authority can pause the workflow. The governance record must preserve the decision, the observed environment, the intervention, and the resulting state. The same governance questions arise when a model version changes during an active workflow, a downstream agent inherits a task, or a physical AI system encounters an operating condition beyond its approved environment. These situations require a shared system architecture for capability, state, authority, execution, evidence, accountability, and continuous control. SBJ AI Governance Architecture V1.0 establishes that architecture across generative AI, assistants, agentic AI, autonomous systems, and Physical AI. The public V1.0 baseline is frozen, with the published benchmark disposition VALIDATED WITH MATERIAL LIMITATIONS. Its scope, evidence, and limitations remain explicit throughout the architecture. 1. Establish the Governance Surface Enterprise AI operates through interacting models, tools, credentials, infrastructure, organizational workflows, approvals, and external dependencies. Governing these systems starts with a consistent inventory of the capabilities and conditions that determine their consequences. V1.0 defines Ten Governance Dimensions. They can coexist within a single AI system and apply across different deployment models. Governance Dimension Engineering and Governance Focus Generation Outputs created, transformed, predicted, recommended, or synthesized Assistance Human work, judgment, and decisions supported by the system Agency Goals, plans, task selection, tools, sequencing, and consequential actions Autonomy Degree of independent operation and action Environmental Interaction Digital or physical conditions the system observes, responds to, or changes Physical Actuation Movement or other effects produced through machines, devices, or infrastructure Authority Approved actions, targets, approvals, credentials, boundaries, and operating conditions Evidence Records supporting reconstruction of decisions, actions, and outcomes Accountability Ownership of authorization, supervision, intervention, and consequences Continuous Control Ongoing observation, reassessment, restriction, intervention, and governance The dimensions provide an architectural assessment surface. They direct attention to operating conditions and consequential behavior, including the relationship between an AI action and its accountable owner. 2. Represent State Across Three Independently Governed Axes The Three-Axis System State is central to V1.0: Lifecycle Stage × Authorization Status × Runtime Operational State Each axis answers a distinct operational question. Axis Governance Question Public V1.0 Illustrative State Lifecycle Stage Where is the system within its managed lifecycle? DEPLOYED Authorization Status Under which conditions does the system possess authority? AUTHORIZED WITH CONDITIONS Runtime Operational State What is the system doing operationally? PAUSED A deployed system can have a paused runtime. Its authorization can carry conditions specific to a target, environment, period, tool, approval, or action. A lifecycle record, an authorization decision, and runtime telemetry can therefore describe the same governed system from separate perspectives. Three-Axis System State — Technical Architecture Figure 1. SBJ AI Governance Architecture V1.0 — Three-Axis System State. The diagram illustrates the independently governed state dimensions and their relationships to the public architectural constructs. The state values represent an illustrative combination published in V1.0. The surrounding concepts show public architectural relationships. Detailed implementation mechanics remain within SBJ's protected architecture boundary. For architecture reviews, this creates a concrete examination: Can the organization associate current lifecycle records, authorization status, and runtime observations with a specific system and execution context? 3. Make Environment Part of the Authorization Context Environment is a first-class governance consideration in V1.0. It encompasses the conditions under which an AI system is built, deployed, and operated, along with relevant digital or physical boundaries. Consider two enterprise environments: Enterprise software operations Staging and production accounts. Tool permissions and configuration targets. Service dependencies and credentials. Approved execution windows. Organizational and operational boundaries. Physical AI Facility zones and movement constraints. Environmental operating conditions. Payload and actuation boundaries. Intervention mechanisms. Safe State conditions. A configuration change approved for staging establishes authority within the approved conditions. A proposed production action requires an authorization determination appropriate to that target and the resulting consequences. V1.0 describes the bounded set of approved operating conditions as an Authority Envelope. Depending on context, its public definition includes the actor, action, target, tool, credential, environment, timeframe, delegated authority, approvals, stop conditions, and evidence requirements. The Authority Envelope gives technical teams a recognizable subject for governance review: the scope attached to an action and the conditions relevant to its continued validity. 4. Govern Transitions and Derived Authority Operational systems move across lifecycle, environment, privilege, capability, autonomy, and consequence boundaries. V1.0 supplies two public constructs for these changes. Transition Authorization Transition Authorization governs whether a system may cross a specified boundary under approved conditions. A staging-to-production change, an expanded tool privilege, or a materially altered downstream consequence can require an updated governance determination. Derived Authorization Derived Authorization represents newly scoped authority issued following a qualifying event, state change, decision, validation, remediation, or authorized transition. The resulting authorization carries its own scope and conditions. Independent Downstream Authority addresses the authorization relevant to a downstream system, tool, or execution component. An upstream request and a downstream consequential action remain traceable through their applicable governance decisions. V1.0 places these constructs within a conceptual Operational Authorization Layer: IDENTITY ↓ GOAL ↓ CAPABILITY ↓ AUTHORITY ↓ PERMISSION ↓ ENVIRONMENT ↓ ACTION ↓ OBSERVATION ↓ EVIDENCE ↓ ACCOUNTABILITY ↓ CONTINUOUS CONTROL This sequence represents a public governance architecture. Production policy schemas, internal derivation logic, enforcement implementations, and detailed control mappings are protected SBJ architecture material. 5. Make Consequential Execution Attributable An enterprise agent can trigger several tool calls, delegate work, or involve multiple execution services. Governance-grade investigation requires traceability to the relevant Execution Instance Identity: the governed identity associated with the particular execution involved in an action. V1.0's public Decision-to-Action Authority Traceability sequence is: Authorization Decision ↓ Execution Instance Identity ↓ Authorized Execution Chain ↓ Consequential Effect ↓ Evidence This trace connects the governance determination to the execution instance, relevant downstream steps, observed consequences, and supporting records. The architecture further identifies Adverse Evidence Preservation for rejected actions, authority invalidations, exceptions, interventions, failures, and incidents. Independent Termination Authority identifies a designated authority capable of pausing, restricting, stopping, or terminating execution independently of the executing system's own decision process. Safe State supplies a defined risk-containing operating condition where applicable. These relationships are essential to executive accountability. A responsible owner needs accessible evidence about the authorization decision, the resulting execution, observed exceptions, and the effectiveness of intervention. 6. Walk Through an Enterprise Configuration-Change Example The public V1.0 architecture includes a synthetic enterprise software-change agent. The following extended example illustrates how its public constructs can be interpreted in an engineering workflow. Scenario: An agent is approved to perform a configuration update in staging. During execution, a downstream tool request identifies a production target. Event Governance Determination Evidence to Preserve Task assigned Identify the agent, designated owner, objective, and approved context Task reference, approval, accountable role Execution initiated Associate the operation with its execution instance Instance reference, observed system and environment Downstream target observed Compare the consequential action with the Authority Envelope Tool request, target observation, existing scope Boundary crossing identified Reassess the proposed target and relevant Transition Authorization Reassessment decision, applicable conditions Execution paused Record the intervention and resulting runtime state Intervention event, runtime observation, owner Continuation evaluated Establish applicable authority for any subsequent action New decision, supporting evidence, resulting status Illustrative Execution Evidence Record The following synthetic JSON record demonstrates how an engineering team might represent the observed action and governance response. { "illustrative_only": true, "system": "enterprise-config-agent", "execution_instance": "example-run-042", "goal": "apply approved staging configuration", "approved_environment": "staging", "observed_downstream_target": "production", "lifecycle_stage": "DEPLOYED", "authorization_status_at_task_start": "AUTHORIZED WITH CONDITIONS", "runtime_state_after_intervention": "PAUSED", "consequential_action_status": "withheld pending authorization review", "evidence_references": [ "example-approval-17", "example-observation-04", "example-intervention-03" ], "accountable_role": "designated change-control owner" } Implementation note: This example is an explanatory record created for this article. The published V1.0 documentation defines the governance concepts. The frozen SBJ Decision Record V2.0 specification, production authorization schemas, evidence-sufficiency rules, and enforcement mechanics have their own authoritative sources and boundaries. The workflow assumes the downstream target was observed. That assumption leads to an important assurance question: Which instrumentation detects the state change, and when does that evidence become available for authorization reassessment? 7. Position the Architecture Within Published Technical Research Independent academic work offers useful implementation context for provenance, environmental monitoring, and operational assurance. Agent Workflow Provenance Souza and colleagues' PROV-AGENT: Unified Provenance for Tracking AI Agent Interactions in Agentic Workflows (IEEE eScience, 2025) extends W3C PROV for agent interactions. The research describes capture and querying of agent-oriented provenance across heterogeneous edge, cloud, and high-performance computing workflows. It provides a relevant technical reference for the execution-lineage and evidence questions addressed by V1.0. Read PROV-AGENT. Environment-Aware Runtime Assurance Formal Analysis of AI-Based Autonomy: From Modeling to Runtime Assurance (Runtime Verification, 2021) describes VerifAI, formal modeling of AI-based autonomy and its environment, system-level testing, and runtime assurance techniques. The research illustrates the engineering relevance of monitored operational environments. Read the publication. Monitor Evaluation Unifying Evaluation of Machine Learning Safety Monitors (ISSRE, 2022) proposes three safety-oriented evaluation measures: Safety Gain: The safety improvement obtained through monitoring. Residual Hazard: The remaining safety exposure after monitoring. Availability Cost: The operational availability effects associated with monitoring and intervention. This research makes monitor effectiveness and operational tradeoffs more inspectable. Read the paper. Together, these publications reinforce the practical relevance of runtime instrumentation, provenance capture, and measurable monitoring performance. Each study evaluates its own research subject and experimental scope. SBJ V1.0's validation disposition comes from its separately documented benchmark and adversarial testing. 8. Evaluate V1.0 Against Publicly Documented AI Systems SBJ independently evaluated V1.0 against publicly documented AI systems and operating contexts associated with: Replit. Anthropic. Microsoft. Salesforce. Waymo. Google DeepMind. The benchmark evaluates the architecture's coverage of governance determinations across the selected evidence. Publicly documented material concerning those organizations provided the evidence context for the independent assessment. Benchmark Results Determination Count PASS 160 PARTIAL 24 FAIL 0 INSUFFICIENT EVIDENCE 1 Applicable determinations 185 NOT APPLICABLE 7 The applicable total comprises PASS, PARTIAL, FAIL, and INSUFFICIENT EVIDENCE determinations. Seven additional determinations were classified NOT APPLICABLE. The published benchmark reports determination counts and leaves the aggregate unscored. The insufficient-evidence finding concerned the public record available for Replit: persistent execution identity across consequential security execution and remediation chains. The evaluation also preserved the limitation concerning fully automatic post-remediation adversarial retesting. The benchmark disposition is: VALIDATED WITH MATERIAL LIMITATIONS SBJ recorded zero structural failures at the architectural-rule level within this cohort. Findings remain scoped to the public evidence and tested cases. The complete V1.0 Benchmark Summary provides the evaluation framing and independent-research disclosure. 9. Preserve Adversarial Findings and Material Limitations V1.0 also underwent Adversarial Testing Cycle 1. Testing included six architecture-directed scenarios and six independently constructed operational fact patterns involving: Enterprise procurement. Freight orchestration. Hospital robotics. Employment decision systems. Third-party banking AI. Clinical decision support. Adversarial Testing Results Outcome Result Confirmed architectural gaps 0 Structural failures 0 Architectural ambiguities identified 1 Architectural ambiguities resolved 1 V1.0 modifications 0 The resolved finding, ATC1-001 — Human-Operational-Use Drift, clarified the governance significance of changes in how organizations operationally consume, escalate, automate, or embed AI outputs. A consequential workflow change can alter the exposure associated with an AI output and trigger Transition Authorization under existing V1.0 concepts. Material Limitations The benchmark and adversarial testing preserve several material limitations for continued engineering evaluation: Authorization invalidation and reassessment-trigger semantics. Semantic legitimacy of consequential actions within technically permitted operations. Authority provenance across branching delegation chains. Execution identity and system, model, software, configuration, and environment version binding. Shared-responsibility evidence allocation across providers and organizations. Evidence completeness, integrity, retention, and adverse-evidence persistence. Observability is a specific operational dependency. An organization requires mechanisms to discover material environmental, configuration, third-party, and workflow changes in time to make governance determinations and intervene where appropriate. The V1.0 testing record preserves this detection and instrumentation boundary. The benchmark also identifies a coverage gap for autonomous, irreversible material financial transactions. That authority class requires additional direct evaluation before validation claims can be extended to it. The Adversarial Testing Cycle 1 record documents the scenarios, interpretation, and final disposition. 10. Apply the Architecture in an Enterprise Review An executive sponsor, security architect, platform engineer, and governance owner can begin with six review questions. 1. Capability and Environment Which Governance Dimensions characterize the system, and which operating conditions shape its consequences? 2. System State Where are lifecycle, authorization, and runtime conditions established and observed? 3. Authority What Authority Envelope governs the consequential action, and which changes require Transition Authorization? 4. Execution Which Execution Instance Identity connects a governance decision to a downstream execution chain? 5. Intervention Who can exercise Independent Termination Authority, and which Safe State or restriction applies? 6. Evidence and Ownership Which records preserve the decision, observations, actions, outcomes, and accountable parties? The answers establish a common architecture-review agenda spanning business ownership, engineering, security, risk, and audit. Implementation then proceeds through environment-specific technical controls, instrumentation, evidence management, independent testing, and recorded governance decisions. 11. The Executive Accountability Question Enterprise AI governance becomes operational when leadership can establish the conditions under which a consequential system action was authorized, identify the execution that produced the action, and demonstrate the authority and evidence supporting intervention. The Three-Axis System State provides a structured representation of the system's lifecycle, authorization condition, and operational state. The surrounding architectural constructs connect that state to authority boundaries, downstream execution, observable consequences, intervention capability, and accountability. For enterprise leadership, this establishes a practical decision framework for determining whether an AI system can continue operating within its approved conditions. For engineering teams, it supplies a traceable governance structure connecting system behavior to authorization, evidence, and control. The discussion I want to advance is this: When one enterprise AI agent initiates a downstream action in another environment, which execution record establishes the applicable authority, the observed context, and the accountable owner at that moment? Sources and Original Architecture Canonical SBJ Architecture and Evidence SBJ AI Governance Architecture V1.0 Public Technical Repository Architecture Overview Real-World Benchmark Summary Adversarial Testing Cycle 1 Independent Technical Research Souza et al. (2025). PROV-AGENT: Unified Provenance for Tracking AI Agent Interactions in Agentic Workflows. IEEE eScience. Formal Analysis of AI-Based Autonomy: From Modeling to Runtime Assurance (2021). Runtime Verification. Unifying Evaluation of Machine Learning Safety Monitors (2022). ISSRE. Intellectual Property and Research Scope: SBJ AI Governance Architecture V1.0 is original Solutions by Jewel architecture. Its public technical description covers architectural concepts and benchmark findings. Internal enforcement, derivation, evidence-sufficiency, and production implementation mechanics are protected. The benchmark is SBJ's independent assessment of publicly documented cases. The referenced organizations and executives are subjects of publicly available evidence used in the evaluation; the research and findings are independently attributable to Solutions by Jewel. Jewel Darlington Chief AI Governance Officer & Founder Solutions by Jewel solutionsbyjewel.com Protecting organizations in the age of AI.