The Autonomous Supply Chain / Page 04

TOGAF ADM Architecture Development Method Phases A through H

The TOGAF 10 Architecture Development Method applied to the MedDevice Industries GmbH Autonomous Supply Chain engagement. Every phase produces a living artifact traceable to a requirement. This is not a textbook summary — it is a working architecture engagement record.

TOGAF 10 · ADM 6 Architecture Principles 8 Application Modules 7 ADRs 3 Migration Horizons EU AI Act Annex III GDPR DPIA Scoped Arch Conformance Governed
The ADM applied to MedDevice Industries.
Output: Phase-by-phase artifact register · Requirements traceability

TOGAF's Architecture Development Method provides the process framework. Each phase below produces a specific artifact for the MedDevice Industries GmbH engagement. Requirements Management is not a phase — it is a continuous discipline running through all phases A through H, with a live traceability matrix binding every pain point to a principle, module, and regulatory obligation.

Prelim + RM
Principles & Req. Mgmt
Architecture principles · Continuous requirements traceability
Phase A
Architecture Vision
Vision statement · Stakeholder influence analysis · Key outcomes
Phase B
Business Architecture
Capability model with maturity · Business process changes · Pain-to-module mapping
Phase C
IS Architecture
Data architecture · Application portfolio · DPIA trigger assessment
Phase D
Technology Architecture
GCP reference stack · Security zones · Network topology · MLOps observability
Phase E
Opportunities & Solutions
Three-horizon sequencing · Dependency map · Work package rationale
Phase F
Migration Planning
Strangler Fig pattern · Governed risk register · Dependency map
Phase G
Implementation Governance
Architecture conformance gates · Compliance review board · Dispensation process
Phase H  ·  Architecture Change Management
Continuous Architecture Fitness
Change request process · Architecture update triggers (EU AI Act amendments, new GCP services, SAP version changes) · Living architecture repository
RM
Requirements Management — Continuous Traceability.
Output: Requirements Traceability Matrix · Pain-to-Principle-to-Module Mapping

Requirements Management in TOGAF is not a phase — it is the connective tissue that runs through every phase from A to H. Every discovery pain point is formally linked to an architecture principle, a functional module, and a regulatory obligation. Any architecture decision that cannot be traced to a requirement is a candidate for removal.

Traceability Contract
Every row in the matrix below constitutes a binding traceability link. A work package may not enter Horizon 2 deployment until every pain point it addresses has a corresponding requirement ID, a named architecture principle it satisfies, and a documented regulatory obligation it discharges. Untraceable requirements are escalated to the Architecture Review Board.
Requirements Traceability Matrix — Pain → Requirement → Principle → Module → Regulation
Pain ID Business Pain Req. ID Principle Module Regulatory Obligation
PAIN-01 Monthly Excel forecast cycle. No ML. Procurement trigger fully manual. FR-01, NFR-03 P-01, P-03 DemandIQ EU AI Act Art. 13 (transparency), Art. 14 (HITL)
PAIN-02 Annual supplier questionnaire. No continuous monitoring. Reactive disruption response. FR-02, FR-07 P-02, P-05 SupplierSentinel GDPR Art. 35 (DPIA), ISO 13485 §7.4
PAIN-03 Manual SAP Ariba PO creation. No inter-enterprise commerce automation. FR-03, FR-08 P-03, P-06 ProcureGuard, ContractIntelligence EU AI Act Art. 14 (HITL), CFO threshold policy
PAIN-04 23-day NCR resolution cycle across three disconnected systems. No MDR lineage. FR-04, NFR-01 P-02, P-05 QualityTrace MDR Art. 87 (vigilance), ISO 13485 §8.3
PAIN-05 Manual quarterly Scope 3 gathering. CSRD reporting retrospective and error-prone. FR-05, FR-06 P-02, P-04 ScopeTracer CSRD Art. 19a, ESRS E1, GHG Protocol Scope 3
Phase A
Architecture Vision
Output: Statement of Architecture Work · Stakeholder Influence Analysis · Key Outcomes
Architecture Vision Statement
Transform MedDevice Industries GmbH's supply chain from a reactive, spreadsheet-driven operation into an explainability-first, EU AI Act-compliant intelligent supply chain — capable of sensing disruption, deciding autonomously within defined boundaries, and satisfying MDR / CSRD / ISO 13485 / GDPR compliance by design.
34%
↓
≤12%
Forecast error rate
23 days
↓
≤5 days
NCR resolution cycle
Reactive
→
+30 days
Supplier risk advance signal
Manual quarterly
→
Real-time
CSRD Scope 3 reporting
0 of 5
→
5 of 5
EU AI Act high-risk models compliant
Architecture Vision — Stakeholder Influence & Concern Analysis
Stakeholder Role Influence Architecture Concerns Documented Objections / Risks
VP Supply Chain Primary Sponsor High Forecast accuracyOn-time deliveryInventory cost Risk: agent autonomy boundary set too conservatively, requiring excessive HITL approvals that delay procurement cycles.
CCO Compliance Sponsor High MDR Art. 87EU AI ActAudit trail completeness Objection: no AI model may enter production without a complete Model Card and conformity documentation. Veto power over Phase D delivery gates.
CPO Procurement Outcomes High PO automation scopeA2A supplier trustContract risk Risk: autonomous PO issuance must not exceed financial thresholds without HITL. Requires formal autonomy boundary document co-signed by CFO.
Quality Director MDR / NCR / CAPA Owner High NCR lineageCAPA automationVeeva Vault integrity Objection: Veeva Vault must remain the system of record for MDR. Architecture must demonstrate that event-sourced pipeline does not create two conflicting sources of truth.
CFO Financial Threshold Owner High Autonomy thresholdsROI measurementCost of non-compliance Risk: financial autonomy thresholds must be codified in the HITL framework before H2 deployment. CFO sign-off required on threshold policy document.
CISO Data Sovereignty Medium GDPR data residencyVPC-SC perimeterCMEK custody Concern: A2A inter-enterprise data exchange must not expose supplier PII or contract terms outside the VPC-SC perimeter. Requires formal network boundary sign-off.
DPO GDPR Controller Medium DPIA obligationLegal basis for processingData subject rights Objection: SupplierSentinel processing of named individual financial data (sole traders, directors) triggers GDPR Art. 35 DPIA. DPO must approve DPIA before SupplierSentinel goes to production.
Architecture Principles — the rules the design cannot break.

Six principles established before any architecture work begins. Binding constraints on every design decision that follows. Any component that violates a principle requires a formal ADR documenting the exception and its consequences.

P-01 · Explainability Before Deployment
XAI contract defined before model training begins
Every ML model is designed with its explanation contract before training begins. SHAP values are generated at inference time and written to the audit log before any downstream action executes. Post-hoc explanation is not acceptable.
Constraint: EU AI Act Annex III · MDR Article 87
P-02 · Compliance by Construction
Regulatory obligations encoded as write-path constraints
MDR, CSRD, ISO 13485, and GDPR obligations are encoded as constraints in the data model and enforced by the write path. Compliance is a structural property of every transaction, not a reporting posture applied retrospectively.
Constraint: MDR · CSRD · ISO 13485 · GDPR
P-03 · Human Oversight as Architecture
HITL is a state machine node, not a policy document
HITL checkpoints are formal states in every agent's state machine — with a defined entry condition, presentation contract, decision interface, timeout behaviour, and immutable audit record. Human oversight is designed, not assumed.
Constraint: EU AI Act Art. 14 · MDR
P-04 · GCP-Native by Design
No vendor-agnostic abstractions that sacrifice observability
No generic middleware or vendor-agnostic abstraction layers that sacrifice GCP-native observability or governance. Vertex AI, Pub/Sub, BigQuery, and Cloud Run are used with their full native feature sets, not wrapped in abstractions.
Constraint: Google Cloud Partner standards
P-05 · Event-Sourced Truth
Pub/Sub event fabric is the system of record
The Pub/Sub event fabric is the integration backbone and system of record. All modules are consumers. Every state change is an immutable event. This decouples producers from consumers and enables audit replay for MDR compliance.
Constraint: MDR Article 87 · ISO 13485
P-06 · Autonomy Bounded by Risk
Every agent has a defined autonomy boundary
Each agent has a formally specified set of actions it executes autonomously and a set that require human approval. The boundary is tied to financial and regulatory thresholds, defined before implementation, and enforced by the HITL checkpoint architecture.
Constraint: EU AI Act Art. 14 · CFO threshold policy
Phase B
Business Architecture
Output: Business Capability Map (with maturity) · Process Changes · Pain-to-Module Mapping

The Business Architecture translates the Architecture Vision into a concrete model of how MedDevice Industries GmbH's supply chain operates after the Autonomous Supply Chain is deployed. Every manual handoff is replaced by an agent-mediated state transition with a defined SLA and an immutable audit record. Capability maturity ratings reflect the as-is state — the gap drives sequencing.

Business Capability Map — Five Domains with As-Is Maturity
Demand Intelligence
Demand forecastingL1
Pipeline sensingL1
Macro signal ingestionL1
Supplier Intelligence
Risk monitoringL1
Financial health scoringL1
ESG assessmentL2
Sub-tier mappingL1
Procurement & Sourcing
PO managementL2
Contract analysisL1
A2A commerceL1
Strategic sourcingL2
Quality & Compliance
NCR managementL2
MDR traceabilityL2
CAPA managementL2
Vigilance reportingL3
Sustainability
Scope 3 monitoringL1
CSRD reportingL1
Freight analyticsL2
L1 Initial — ad-hoc, manual, no defined process
L2 Defined — process exists, partially systematic, limited automation
L3 Managed — process measured, repeatable, partial tooling
Business Process Changes — As-Is → To-Be
PAIN 01
Monthly Excel forecast cycle. No ML. No upstream demand signal. Procurement trigger fully manual.
→
DemandIQ ML ensemble with HITL checkpoint before procurement trigger. Multi-signal including Salesforce pipeline and macroeconomic features.
PAIN 02
Annual supplier questionnaire. Risk assessed once per year. No continuous monitoring. Reactive to disruption.
→
SupplierSentinel continuous real-time risk scoring. 30-day advance disruption signal. Financial filings + news stream ingestion.
PAIN 03
Manual SAP Ariba PO creation and sourcing. Contract review is ad hoc. No inter-enterprise commerce automation.
→
ProcureGuard + ContractIntelligence + A2A Commerce loop. Clause-level risk scoring. Automated PO issuance within autonomy boundary.
PAIN 04
Manual NCR trace across three disconnected systems. 23-day resolution cycle. No automated MDR lineage.
→
QualityTrace automated root cause analysis and MDR lineage. Event-sourced NCR pipeline with immutable audit trail. Target ≤5 days.
PAIN 05
Manual quarterly Scope 3 data gathering across freight and 3PL portals. CSRD reporting retrospective and error-prone.
→
ScopeTracer automated real-time CSRD reporting. BigQuery Omni in-place logistics calculation. Automated regulatory output.
Phase C
Data Architecture & Application Architecture
Output: Data Fabric Design · GDPR DPIA Assessment · Eight-Module Application Portfolio with A2A Protocol

Phase C defines what data the enterprise needs to manage and what applications manage it. The data architecture establishes GCP-native storage patterns with europe-west3 residency. A GDPR Art. 35 DPIA trigger assessment is mandatory before any module that processes personal data goes to production. The application portfolio maps all eight modules to specific GCP services, with the A2A agent protocol explicitly specified for ProcureGuard.

Data Architecture — GCP-Native Storage Fabric
Integration Backbone
Pub/Sub Event Fabric
Single Pub/Sub event fabric as the system of record for all cross-system state changes. Producers and consumers fully decoupled. Topics: demand-events supplier-events quality-events scope3-events hitl-events
Analytical Warehouse
BigQuery
Analytical data warehouse for demand signals, supplier data, quality records, and Scope 3 data. europe-west3 data residency. CMEK enforced. Datasets: demand supplier quality csrd audit
Feature Management
Vertex AI Feature Store
Features shared across all five ML models. Online and offline serving. Feature lineage tracked. Eliminates training–serving skew across DemandIQ, SupplierSentinel, InventoryOrchestrator, QualityTrace, and ScopeTracer.
Agent State & Audit
Firestore
Agent state, HITL queue, and immutable audit log. CMEK encrypted. europe-west3 residency. Every HITL event and agent action written as an immutable record. MDR Article 87 compliance requires append-only mode enforced via Firestore security rules.
Security Perimeter
VPC-SC + Data Residency
VPC Service Controls perimeter confines all supplier PII, financial data, and contract data. europe-west3 (Frankfurt) data residency for MDR + GDPR compliance. CMEK — MedDevice Industries holds keys with 90-day rotation.
Document Intelligence
GCS + Document AI
Veeva Vault batch records, supplier contracts, and quality documents ingested via GCS upload pipeline. Document AI + Gemini processing within VPC-SC perimeter. No document leaves europe-west3.
GDPR Art. 35 — DPIA Trigger Assessment
SupplierSentinel processes financial health data, credit signals, and public registry data that may reference named individuals (sole traders, named company directors). This constitutes systematic processing of personal data in an automated decision-support context, triggering a GDPR Article 35 Data Protection Impact Assessment.

DPIA requirement: DPO must approve a completed DPIA before SupplierSentinel enters production in Horizon 2. Legal basis for processing is legitimate interest (GDPR Art. 6(1)(f)) — documented in the processing register. Data minimisation enforced: only financially relevant signals are retained; named individual data is anonymised at feature extraction unless required for supplier entity resolution.
Application Architecture — Eight Modules Mapped to GCP Services
Module GCP Services Integration Points A2A / Agent Protocol
DemandIQ
 Vertex AI Pipelines Vertex AI Forecast XGBoost ARIMA Ensemble Vertex AI Feature Store SHAP at inference Salesforce pipeline events · Hospital procurement signals · Macroeconomic feature streams Internal agent. No A2A. Pub/Sub consumer/producer. HITL state machine governs procurement trigger.
SupplierSentinel
 Cloud Run Multi-factor risk classifier · Pub/Sub ingestion · Vertex AI Search Gemini for unstructured news intelligence Financial filings APIs · News stream ingestion · ESG data providers Internal agent. No A2A. Emits supplier-risk-event to Pub/Sub. ProcureGuard subscribes.
ProcureGuard
 ADK procurement agent · Cloud Run Apigee SAP Ariba REST · A2A Commerce layer for inter-enterprise PO issuance SAP Ariba REST API · Supplier A2A endpoints · HITL approval UI A2A Agent. Protocol: Google A2A over HTTPS. Capability advertisement via Agent Card (JSON-LD). Task types: RequestForQuote, PurchaseOrderIssuance, OrderAcknowledgement. Supplier-side agent must implement A2A server. Fallback: email-based PO if supplier not A2A capable.
▸ A2A inter-enterprise boundary: data does not cross VPC-SC perimeter. Only PO payload (non-PII) transmitted.
ContractIntelligence
 Gemini long-context full-corpus analysis · 1M+ token context eliminates chunking · Apigee SAP Ariba contract corpus REST · clause-level risk scoring SAP Ariba contract repository · Legal HITL queue · Firestore clause risk store Internal agent. No A2A. Outputs clause risk scores to Firestore. HITL queue surfaced in SC Command.
InventoryOrchestrator
 Vertex AI reorder/safety stock model · Pub/Sub SAP S/4HANA MRP integration · multi-site optimisation SAP S/4HANA MRP via Pub/Sub · Warehouse management systems · Demand signals from DemandIQ Internal agent. No A2A. Consumes demand-events. Emits reorder-trigger to ProcureGuard.
QualityTrace
 Pub/Sub event-sourced NCR pipeline · Apigee Veeva Vault REST · Gemini document intelligence · Firestore audit trail Veeva Vault REST API · SAP S/4HANA quality module · MDR reporting output Internal agent. No A2A. Firestore audit trail is append-only. Veeva Vault is downstream write target, not source of truth.
ScopeTracer
 BigQuery Omni logistics data in-place calculation · Pub/Sub freight/3PL ingestion · CSRD-compliant reporting output Freight portal APIs · 3PL data streams · CSRD regulatory reporting endpoints Internal agent. No A2A. BigQuery Omni queries execute at 3PL data origin. No cross-border data movement.
SC Command
 Cloud Run React dashboard · Pub/Sub real-time updates · BigQuery cross-module KPI aggregation · HITL queue display All seven modules via Pub/Sub · BigQuery analytics datasets · Firestore HITL queue No agent. Orchestration UI only. HITL decisions recorded to Firestore audit log on submission.
Phase D
Technology Architecture — GCP Reference Stack.
Output: GCP Reference Architecture · Security Zone Topology · Network Boundary Diagram · IaC Baseline · MLOps Observability

Phase D defines the full GCP technology stack. Every named service, the VPC-SC perimeter boundaries, IAM trust zones, data flow paths, and the cross-perimeter A2A traffic model. The observability layer explicitly includes Vertex AI Model Monitoring for the five high-risk AI Act models.

GCP Reference Stack — Service Layer by Layer
Compute
Cloud Run (stateless modules) GKE (stateful ADK agents)
Messaging
Pub/Sub (event fabric)
Storage
BigQuery (analytics + CSRD) BigQuery Omni (3PL in-place) Firestore (agent state + audit) GCS (document store)
AI / ML
Vertex AI Pipelines Vertex AI Feature Store Vertex AI Model Registry Vertex AI Search (Gemini) Gemini (long-context, pinned at implementation) ADK (agent orchestration)
Integration
Apigee (SAP Ariba + Veeva REST) A2A Protocol Layer (ProcureGuard)
Security
VPC-SC BeyondCorp Secret Manager IAM + Workload Identity CMEK (MedDevice key custody)
IaC
Terraform (all infrastructure versioned)
Observability
Cloud Monitoring Cloud Logging Cloud Trace Security Command Center Vertex AI Model Monitoring (drift detection) SHAP audit log (BigQuery audit dataset) Prediction distribution alerts
Network Security Zone Topology — VPC-SC Boundary Model
Security Zone Architecture · europe-west3 (Frankfurt) · MedDevice Industries GmbH GCP Project
Zone 0 · Restricted
VPC-SC Perimeter boundary. Contains: BigQuery (all datasets), Firestore (audit + agent state), Vertex AI (all services), GCS (document store). No egress permitted without explicit perimeter policy. All services accessed via Private Google Access. CMEK enforced on all data at rest. Supplier PII, financial data, and contract corpus remain within this boundary at all times.
Zone 1 · Internal Service Mesh
GKE cluster (ADK agents) + Cloud Run (stateless modules). Internal service-to-service communication via Workload Identity. No public IPs. Pub/Sub consumers authenticated via service account with least-privilege IAM. BeyondCorp enforces zero-trust for human operator access to HITL interfaces.
Zone 2 · Integration Gateway
Apigee (SAP Ariba + Veeva Vault REST). Apigee sits at the perimeter edge. All SAP and Veeva API calls are authenticated, rate-limited, and logged. Apigee transforms and validates payloads before passing into Zone 1. Supplier PII is stripped or pseudonymised at this boundary before entering Zone 0.
Zone 3 · A2A Inter-Enterprise DMZ
ProcureGuard A2A traffic only. A2A task payloads (PO issuance, RFQ, acknowledgement) are transmitted over mTLS-authenticated HTTPS to supplier A2A server endpoints. Only non-PII commercial payload is transmitted (PO number, SKU, quantity, price, delivery terms). No supplier PII, contract terms, or financial model outputs cross this boundary. A2A Agent Card discovery uses public HTTPS endpoint hosted outside VPC-SC perimeter.
Data Flow: External data sources → Zone 2 (Apigee) → Zone 1 (modules) → Zone 0 (Vertex AI / BigQuery) · A2A: Zone 1 (ProcureGuard) → Zone 3 (A2A DMZ) → Supplier A2A endpoint
Architecture Decision Records — Seven Key ADRs
ADRSC-001
Vertex AI Forecast over SAP IBP native ML
EU AI Act explainability requirements and HITL architecture require open model access. SAP IBP native ML is a black-box. SHAP values cannot be generated from IBP's proprietary forecast engine.
REJECTED ALTERNATIVES: (1) SAP IBP native ML — black-box model; SHAP extraction not possible; EU AI Act conformity not achievable. (2) Azure ML — rejected on data residency grounds; Frankfurt region parity unconfirmed at time of decision. (3) Custom TensorFlow on GKE — rejected; Vertex AI Pipelines provides MLOps scaffolding (monitoring, registry, drift detection) that would require custom build on bare GKE.
ADRSC-002
Multi-signal ensemble over single-model forecast
Salesforce pipeline signals, hospital procurement patterns, and macroeconomic features each carry independent forecast information. Ensemble reduces error from 34% to target ≤12%.
REJECTED ALTERNATIVES: (1) Single ARIMA model — insufficient signal diversity; cannot incorporate Salesforce pipeline data without custom extension. (2) Prophet (Meta) — univariate by design; would require separate models per signal with manual ensemble layer, defeating purpose. (3) XGBoost only — strong on tabular features but no native time-series structure; ensemble is superior.
ADRSC-003
Real-time Pub/Sub monitoring over batch quarterly scoring
Supplier risk events — factory incidents, financial distress signals, geopolitical disruptions — do not wait for quarterly reviews. A batch scoring cycle produces a 90-day blind spot. Real-time ingestion enables the 30-day advance signal target.
REJECTED ALTERNATIVES: (1) Quarterly batch in BigQuery — 90-day blind spot unacceptable; Horizon B disruption event (2023 supplier insolvency) would not have been detected. (2) Daily batch via Cloud Composer — reduces blind spot to 24h but still misses intraday events (news, exchange filings). Real-time Pub/Sub is the only architecture that can guarantee the 30-day advance signal SLO.
ADRSC-004
Gemini Vertex AI Search for supplier news over third-party risk vendors
Third-party risk vendors process data outside the EU. Data residency constraints (MDR + GDPR) and EU AI Act explainability requirements for high-risk models preclude sending supplier intelligence data to external vendors.
REJECTED ALTERNATIVES: (1) Dun & Bradstreet Risk Analytics — processes data in US data centres; GDPR Art. 46 transfer mechanism insufficient given MDR sensitivity. (2) Supplier.io — no GDPR-compliant EU data residency offering at time of evaluation. (3) Manual news monitoring — scales linearly with supplier count (1,400 suppliers); operationally infeasible for continuous monitoring.
ADRSC-005
Gemini long-context model over fine-tuned BERT for contract analysis
1M+ token context window eliminates document chunking. Medical device supply contracts exceed 200 pages. BERT-based approaches require chunking, which breaks cross-clause reasoning required for risk scoring.
REJECTED ALTERNATIVES: (1) Fine-tuned BERT/LegalBERT — 512 token limit requires chunking; cross-clause reasoning (e.g., indemnity clause referencing force majeure clause on p.47) is architecturally impossible. (2) GPT-4 via Azure OpenAI — data leaves EU; GDPR transfer issue; not available on GCP in europe-west3. Note: specific Gemini model version is pinned at implementation time to the current production long-context model; architecture specifies capability (≥1M token context, EU-resident) not version string.
ADRSC-006
Event-sourced NCR pipeline over direct Veeva Vault write
MDR Article 87 requires an immutable audit trail for all NCR lifecycle events. Direct Veeva Vault writes create a mutable record. The event-sourced Pub/Sub pipeline writes immutable events to Firestore before any Vault update.
REJECTED ALTERNATIVES: (1) Direct Veeva Vault write as system of record — Vault's audit log is mutable by system administrators; does not satisfy MDR Article 87 immutability requirement. (2) Custom audit database (Cloud SQL) — relational model does not natively support append-only semantics; requires custom enforcement layer; Firestore with security rules is simpler and GCP-native.
ADRSC-007
BigQuery Omni for logistics data over ETL into primary project
Freight and 3PL providers store logistics data in their own environments. ETL into the primary project introduces data quality loss and latency. BigQuery Omni calculates Scope 3 emissions in-place at the data origin.
REJECTED ALTERNATIVES: (1) ETL via Dataflow into BigQuery — data transformation loss during ETL; freight providers use inconsistent schema versions; in-place calculation avoids this entirely. (2) Direct API calls to 3PL portals — rate-limited, inconsistent SLAs, no bulk query capability; CSRD reporting requires full dataset access, not API polling. (3) Third-party carbon accounting SaaS — data leaves MedDevice control; CSRD audit requirements demand traceable calculation methodology that proprietary SaaS cannot expose.
Phase E
Opportunities & Solutions
Output: Sequencing Rationale · Three-Horizon Roadmap · Explicit Dependency Map

Phase E identifies the sequencing logic for the eighteen-month delivery roadmap. The dependency map below makes the prerequisite chain explicit — no work package in H2 or H3 begins until its named H1 prerequisites are complete. EU AI Act compliance infrastructure is a gate, not a parallel stream.

Horizon 1
Foundation & Compliance
Months 1–4
GCP foundation + VPC-SC + CMEK provisioning via Terraform
Pub/Sub event fabric established as integration backbone
SAP Ariba REST integration layer via Apigee
EU AI Act compliance infrastructure — HITL framework + XAI layer
SupplierSentinel v1 — monitoring only, no autonomous actions
Supplier master data normalisation + DPIA completion for SupplierSentinel
Horizon 2
Core Module Deployment
Months 5–10
DemandIQ ML ensemble — Vertex AI Pipelines + SHAP
QualityTrace — event-sourced NCR + Veeva Vault integration
InventoryOrchestrator — reorder model + SAP MRP integration
ProcureGuard — ADK agent + SAP Ariba PO automation
MLOps pipeline — drift detection + Vertex AI Model Monitoring
Horizon 3
Full Suite & Optimisation
Months 11–18
ContractIntelligence — Gemini long-context full-corpus analysis
ScopeTracer — BigQuery Omni + CSRD reporting
A2A Commerce full deployment — inter-enterprise PO issuance
SupplyChain Command Dashboard — cross-module KPI aggregation
EU AI Act certification readiness — all five models
Explicit Prerequisite Dependency Map — H1 Gates H2 · H2 Gates H3
VPC-SC + CMEK provisioned
→ prerequisite for →
All H2 modules (data residency required before any ML data processing)
HITL framework deployed
→ prerequisite for →
DemandIQ, ProcureGuard, QualityTrace (EU AI Act Art. 14 gate)
Supplier master data normalised
→ prerequisite for →
SupplierSentinel production + DemandIQ feature training (ML data quality gate)
DPIA approved by DPO
→ prerequisite for →
SupplierSentinel production (GDPR Art. 35 gate)
ProcureGuard v1 (SAP Ariba)
→ prerequisite for →
A2A Commerce deployment (A2A requires proven internal PO agent before inter-enterprise extension)
Vertex AI Model Monitoring live
→ prerequisite for →
EU AI Act certification readiness (post-market monitoring evidence required)
Phase F
Migration Planning
Output: Migration Approach · Governed Risk Register · Dependency Map

Phase F sequences the work packages into a migration plan. SAP S/4HANA and SAP Ariba remain systems of record. The Autonomous Supply Chain is the intelligence and orchestration layer, not a replacement. The Strangler Fig pattern governs all SAP integrations.

Migration Approach: Strangler Fig Pattern
Strangler Fig pattern for all SAP integrations. Event streams tap existing SAP data flows without replacing the core ERP. SAP S/4HANA and SAP Ariba remain fully operational throughout the migration. The Autonomous Supply Chain modules attach to the event fabric as consumers of SAP data, then progressively assume decision-making and orchestration responsibilities that were previously manual. No big-bang cutover. No SAP decommissioning required.
Risk Register — Four Key Risks (with Likelihood · Impact · Owner · Residual)
R-01 · SAP Ariba Data Harmonisation
Impact: High
Owner: Data Engineering Lead
Review: Monthly, H1
Multi-instance SAP Ariba data harmonisation complexity. Supplier master data inconsistencies across instances create downstream ML feature quality issues and training–serving skew.
Mitigation: Supplier master data normalisation in H1. Canonical supplier entity defined before any ML model training begins. Data quality gates in Pub/Sub ingestion pipeline. Schema validation SLOs enforced before H2 gates open.
Residual risk after mitigation: Medium — data quality issues in 3rd-tier suppliers may persist.
R-02 · EU AI Act Conformity Assessment
Impact: High
Owner: CCO + Architecture Lead
Review: Bi-weekly, all horizons
EU AI Act Annex III classification of five supply chain models requires conformity assessment. Incomplete documentation at go-live creates regulatory exposure and potential prohibition on deployment.
Mitigation: HITL framework + Model Cards from day one. Conformity assessment documentation built incrementally from H1. No model promoted to production without a complete Model Card. CCO has veto on any H2 deployment gate.
Residual risk after mitigation: Low — continuous documentation from H1 eliminates late-stage documentation risk.
R-03 · HITL Adoption Risk
Impact: Medium
Owner: Change Management Lead
Review: Monthly, H2 onwards
Procurement and quality staff bypassing HITL approval interfaces, routing decisions through informal channels. Undermines audit trail integrity and EU AI Act Art. 14 compliance.
Mitigation: SAFe change management programme. HITL bypass is architecturally visible and flagged in Security Command Center. Training, incentives, and enforcement mechanisms defined in Adoption Architecture (Page 08).
Residual risk after mitigation: Low-Medium — enforcement visible; culture change takes time.
R-04 · Scope 3 Data Quality
Impact: Medium
Owner: Sustainability Lead
Review: Monthly, H3
Freight and 3PL portal data quality is inconsistent. ETL-based approaches amplify data quality loss. CSRD reporting accuracy is at risk without in-place calculation.
Mitigation: BigQuery Omni in-place calculation (ADRSC-007) avoids ETL data loss. Schema validation layer at Pub/Sub ingestion. Data quality SLOs defined before CSRD reporting goes live.
Residual risk after mitigation: Low — in-place calculation eliminates primary data loss vector.
Phase G
Implementation Governance
Output: Architecture Conformance Gates · Compliance Review Board · Dispensation Process

Phase G governs the actual build against the architecture. For a medical device company under MDR and EU AI Act, Implementation Governance is not optional — it is the mechanism that ensures the architecture as built matches the architecture as designed. An Architecture Review Board (ARB) convenes at each horizon gate. Conformance is demonstrated, not assumed.

Architecture Conformance Gates — H1 → H2 → H3
H1 → H2 Gate
VPC-SC perimeter tested · CMEK key rotation verified · HITL framework signed off by CCO · Supplier master data quality SLO met · DPIA approved by DPO
H2 → H3 Gate
All H2 module Model Cards complete · Vertex AI Model Monitoring live · HITL bypass rate <2% · ProcureGuard autonomy boundary co-signed by CFO · NCR pipeline MDR Article 87 audit passed
Programme Closure Gate
EU AI Act conformity assessment submitted for all five models · A2A commerce adoption KPI >40% of POs · CSRD Scope 3 report auditor-signed · All Model Cards published to architecture repository
Dispensation Process
Any component that cannot satisfy a conformance gate raises a formal Architecture Dispensation Request (ADR-D). ARB reviews within 5 business days. Dispensations are time-bounded and carry a remediation commitment. Undispensed non-conformances block deployment.
Architecture Review Board
Governance Structure
The ARB convenes at each horizon gate and on-demand for significant change requests. Membership: Architecture Lead (chair), CCO, CISO, DPO, VP Supply Chain. Quorum: 4 of 5. All decisions recorded in the Architecture Repository.
Horizon gate sign-off authority
Dispensation request review (5-day SLA)
Technology change approval (>Tier 2)
Regulatory impact assessment trigger
Conformance Evidence
What Must Be Demonstrated
Conformance is demonstrated via evidence artifacts, not assertions. Each module must produce a Conformance Evidence Pack before promotion through a gate.
Model Card (EU AI Act Annex IV)
VPC-SC penetration test result
HITL state machine test coverage report
SHAP audit log sample (BigQuery query)
Terraform plan output (infrastructure as designed)
Phase H
Architecture Change Management
Output: Change Request Process · Architecture Update Triggers · Living Architecture Repository

Phase H ensures the architecture remains fit for purpose after programme delivery. In a regulated, AI-intensive supply chain, the architecture will need to evolve — EU AI Act amendments, new GCP services, SAP version changes, new Gemini model releases. The change management process governs how those changes are incorporated without breaking compliance or stability.

Change Request Process
Architecture Change Tiers
Change requests are tiered by impact. Tier 1 changes (documentation, minor config) are approved by Architecture Lead. Tier 2 changes (new service, integration change) require ARB review. Tier 3 changes (security zone boundary, autonomy threshold, AI model replacement) require ARB + CCO + DPO sign-off.
Tier 1 — Architecture Lead, 2-day SLA
Tier 2 — ARB, 5-day SLA, conformance re-check
Tier 3 — ARB + CCO + DPO, 10-day SLA, full conformance cycle
Planned Architecture Triggers
Known Future Change Drivers
The following events are anticipated to trigger architecture change requests during and after the programme. Each is pre-registered in the Architecture Repository.
EU AI Act implementing acts (delegated regulations, expected 2025–2026)
New Gemini long-context model version — Tier 2 change, requires Model Card update
SAP S/4HANA release upgrade — Tier 2 change, Apigee contract re-validation
CSRD delegated acts (sector-specific ESRS) — Tier 2 change, ScopeTracer schema update
A2A protocol version update (Google) — Tier 2, ProcureGuard agent contract re-test