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.

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.

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.

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

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:

1. Enterprise procurement.
2. Freight orchestration.
3. Hospital robotics.
4. Employment decision systems.
5. Third-party banking AI.
6. Clinical decision support.

Adversarial Testing Results

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.