The requirements layer of the TOGAF ADM. Every architectural decision in the six design phases traces back to a documented requirement on this page. This is the single source of truth for what the Autonomous Seller is designed to achieve for ClaraVis.
ClaraVis runs Salesforce as the system of record for its commercial operations. Salesforce Einstein provides capable AI within that boundary. The first question any CTO or enterprise architect asks is: why build on GCP when Einstein exists? The answer is architectural, not commercial.
A composite of real regulated-industry enterprise patterns. Every requirement, constraint, and architectural decision on this page is grounded in the specific operational context of a medical imaging OEM operating under EU AI Act, FDA 21 CFR 820, and ISO 13485 simultaneously.
An enterprise architecture that satisfies the CTO's infrastructure requirements but cannot answer the Compliance Officer's audit question will not be adopted. Each stakeholder below has a primary concern, a specific question the AS must answer for them, and a set of modules that address their domain directly.
| AS Module | S-01 CTO |
S-02 CCO |
S-03 CFO |
S-04 VP Sales |
S-05 VP Clinical |
S-06 VP Field |
S-07 Gen. Counsel |
S-08 Ent. Arch. |
S-09 CISO |
|---|---|---|---|---|---|---|---|---|---|
| CCAI Sales Agent | I | C | I | A | C | I | I | R | C |
| ContractGuard | I | A | C | C | I | I | A | R | C |
| RevRec AI | I | A | A | I | I | I | C | R | C |
| Asset IQ | C | C | A | I | C | A | I | R | C |
The TOGAF ADM Phase B input. Understanding where process latency and architectural debt accumulate in the current state is the prerequisite for designing the To-Be architecture. The As-Is diagrams below establish the baseline. The To-Be value stream shows how the AS closes the gap.
Every requirement below is traceable to a stakeholder concern, a regulatory obligation, or a business pain point identified in the preceding sections. The Raised By column links each requirement to the stakeholder register above. Prioritised using MoSCoW — Must Have requirements are architectural constraints on the AS design.
| ID | Requirement | Description | MoSCoW | AS Module | Raised By |
|---|---|---|---|---|---|
BR-01 | Quote-to-Cash cycle acceleration | The end-to-end Q2C cycle — from Opportunity creation to revenue posting in SAP — must be orchestrated with defined SLAs per transition and an immutable audit record at every handoff. The current 47-day average is the primary commercial pain point for VP Sales. | Must | CCAI Sales Agent · ContractGuard · RevRec AI | S-04 · S-03 |
BR-02 | EU AI Act compliance for 3 production models | All three existing ML models — revenue recognition, asset failure, contract risk — must be brought into EU AI Act Annex III compliance. This requires SHAP explanations per inference, documented HITL checkpoints, and a versioned risk management system before the next compliance review. | Must | RevRec AI · Asset IQ · ContractGuard · XAI Layer | S-02 · S-01 |
BR-03 | Unified asset telemetry and predictive maintenance | The six regional asset telemetry systems must feed a single streaming pipeline enabling fleet-level RUL prediction and unit-level anomaly detection. The warranty reserve over-provision is a direct consequence of the inability to model failure probability at scale. | Must | Asset IQ · Pub/Sub Pipeline | S-06 · S-03 |
BR-04 | ASC 606 revenue recognition automation | Lease vs sale classification and performance obligation identification must be handled by an ML model trained on ClaraVis's contract portfolio, with every classification producing a SHAP explanation and routing through a Finance Controller HITL checkpoint before posting to SAP. | Must | RevRec AI · SAP Integration | S-03 · S-02 |
BR-05 | Contract clause intelligence and risk scoring | Every inbound contract must be analysed at clause level — liability caps, indemnification, governing law, IP ownership — with non-standard terms flagged to Legal with a risk score, precedent references, and a draft counter-position before any countersigning event. | Must | ContractGuard | S-07 · S-04 |
BR-06 | Data sovereignty — no data leaves EU boundary | All PII, PHI, device configuration data, and commercially sensitive contract data must remain within the EU GCP region boundary. This is a hard constraint from the CISO and a GDPR requirement. Enforcement must be architectural — VPC-SC — not policy-based. | Must | Layer 04 Infrastructure · VPC-SC | S-09 · S-02 |
BR-07 | CCAI Sales Agent for inbound MRI inquiries | An intelligent sales agent must handle the first stages of an inbound MRI inquiry autonomously — qualification, clinical configuration fit, pricing estimate — and escalate to a Senior AE with a full briefing document when commercial terms are required. Autonomy boundary specified in HITL spec. | Should | CCAI Sales Agent · Salesforce Integration | S-04 · S-05 |
| ID | Requirement | Description | MoSCoW | Regulatory Basis | Raised By |
|---|---|---|---|---|---|
AR-01 | SHAP explanation per ML inference | Every ML model inference that informs a business decision must produce a SHAP explanation identifying the top contributing features, their directional effect, and the model confidence score. The explanation must be written to the audit log before any downstream action executes. | Must | EU AI Act Art. 13 & 14 | S-02 · S-08 |
AR-02 | HITL checkpoint as formal state machine node | Every high-risk decision must route through a named human approver via a formal HITL state — with defined entry condition, presentation contract, decision interface (approve/reject/escalate), timeout behaviour, and immutable audit record. HITL is a first-class architectural component, not a process note. | Must | EU AI Act Art. 14 | S-02 · S-03 · S-07 |
AR-03 | Immutable audit trail for all agent actions | Every agent action — tool call, state transition, HITL event, model inference — must be written to an immutable audit store (Firestore) before the action is considered complete. The audit record must be queryable but not modifiable. Deletion requires a separate access-controlled process with its own audit trail. | Must | EU AI Act Art. 12 · ISO 13485 | S-02 · S-09 |
AR-04 | Salesforce as system of record — AS augments | The AS reads from and writes back to Salesforce via Developer Edition REST API. Salesforce remains the source of truth for commercial data. The AS does not maintain a parallel CRM. Any data written to Salesforce by the AS is tagged with the agent action ID that produced it (ADR-001, ADR-002). | Must | ADR-001 · ADR-002 | S-01 · S-08 |
AR-05 | Model Cards for every ML model | Every model in production must have a Model Card documenting intended use, training data summary, evaluation metrics, known limitations, bias analysis, and the HITL checkpoint specification. Model Cards are versioned alongside the model in Vertex AI Model Registry and reviewed as part of the promotion gate. | Must | EU AI Act Art. 11 · Google Model Cards | S-02 · S-08 |
AR-06 | VPC-SC perimeter for data sovereignty | All data processing must occur within a VPC-SC perimeter configured to prevent data exfiltration outside the EU GCP region. The perimeter is enforced at the infrastructure layer via Terraform — it is not a network policy that can be overridden by application configuration. | Must | GDPR · EU DPDP · BR-06 | S-09 · S-02 |
AR-07 | CMEK encryption — ClaraVis key custody | All data at rest and in transit must be encrypted using Customer-Managed Encryption Keys via Cloud KMS. ClaraVis retains key custody — Google cannot access encrypted data without ClaraVis key authorisation. Key rotation policy: 90 days. | Must | ISO 27001 · GDPR | S-09 · S-03 |
AR-08 | ASC 606 rules as write-path constraints | Revenue recognition classification rules must be encoded as write-path constraints in the data model — applied at transaction time, before any posting. Recognition logic is not a reporting layer applied after the fact. Every transaction is tagged with the performance obligation it satisfies at the time of writing. | Must | ASC 606 · IFRS 15 · BR-04 | S-03 · S-02 |
AR-09 | Device History Record atomic write | Every MRI device shipment event must write simultaneously to the Salesforce Order, the SAP logistics record, and the ISO 13485 Device History Record — in a single atomic transaction. Partial writes are not acceptable. The DHR must be created before the shipment is considered confirmed. | Must | FDA 21 CFR 820 · ISO 13485 | S-01 · S-08 |
AR-10 | ADR documentation for every significant decision | Every significant architectural decision must be documented as an Architecture Decision Record with status, context, decision, alternatives considered, and consequences. ADRs are version-controlled in the repository and linked from the relevant module page. | Must | TOGAF ADM · Portfolio Standard | S-08 · S-01 |
AR-11 | Pub/Sub event fabric as the integration bus | All cross-system events — asset telemetry, Salesforce opportunity updates, SAP posting confirmations — must be published to a Pub/Sub topic before downstream systems consume them. This decouples producers from consumers, enables replay for audit purposes, and provides the foundation for the streaming ML feature pipeline. | Should | Architecture Principle · BR-03 | S-08 · S-01 |
AR-12 | Drift detection and automated retraining trigger | Every model in production must have a Vertex AI monitoring job configured to detect data drift and concept drift against a baseline. Drift beyond a defined threshold must trigger an alert, generate a retraining recommendation, and route to the ML Engineer HITL checkpoint before any automated retraining executes. | Should | EU AI Act Art. 9 · MLOps Standard | S-08 · S-02 |
| ID | Constraint | Description & Impact on Design | MoSCoW | Source | Raised By |
|---|---|---|---|---|---|
C-01 | Zero additional software licensing cost | The AS portfolio is a demonstration system built on free-tier and open-source components. No paid API subscriptions, no commercial data connectors, no licensed dataset providers. Salesforce Developer Edition (free, permanent) is the only external dependency. All GCP services will operate within the free tier or GCP credits until the build phase begins. | Must | Portfolio Constraint | Portfolio |
C-02 | Salesforce Developer Edition as integration pattern | Salesforce integration uses Developer Edition REST API only — no Enterprise or Unlimited Edition features, no paid connectors, no ISV AppExchange dependencies. The integration pattern must be demonstrable on a free Developer Edition org with sample data. Schema is Salesforce standard objects only (ADR-001). | Must | ADR-001 · C-01 | S-08 · C-01 |
C-03 | SAP integration via middleware abstraction | Direct SAP API integration is not implemented in the portfolio demo (SAP license cost). The AS design shows the integration architecture — BAPI/RFC via middleware, or BTP event mesh — and the demo uses a BigQuery table seeded with SAP-schema data to represent the ERP layer. The architecture is correct; the live integration is deferred to the client engagement phase. | Must | C-01 · ADR-002 | S-08 · C-01 |
C-04 | EU data residency — GCP europe-west3 (Frankfurt) | All GCP resources must be provisioned in europe-west3 (Frankfurt) or europe-west4 (Netherlands) only. No multi-region configurations that include non-EU endpoints. This is enforced via Terraform variable and Organisation Policy constraint — not configurable at the application layer. | Must | GDPR · BR-06 · AR-06 | S-09 · S-02 |
C-05 | MVP-plus build standard | Each module is built to demonstrate one complete end-to-end flow — sufficient to impress a hiring manager or enterprise architect in a live demo. Production hardening (multi-region failover, 99.99% SLA engineering, load testing) is out of scope for the portfolio phase. Architecture is designed for production; the implementation is scoped for demonstration. | Must | Portfolio Scope | Portfolio |
C-06 | Existing Salesforce and SAP investments preserved | The AS does not replace Salesforce or SAP. Both systems remain in place and the AS augments them. Any design decision that requires replacing either system is out of scope. The AS is the orchestration and intelligence layer — the systems of record stay (ADR-002). | Must | ADR-002 · BR-06 | S-01 · S-03 |
C-07 | SAFe delivery governance — light touch | The AS modules map to Agile Release Trains consistent with SAFe 6.0 principles. Full Program Board and PI Planning artifacts are documented at the architectural level (Page 04) but are not operationally executed for the portfolio build. The SAFe mapping demonstrates delivery governance understanding; it is not a live programme management process. | Could | SAFe Page 04 | S-08 · S-01 |
The AI Readiness Assessment is the input to the TOGAF Architecture Vision. It defines the starting position across five dimensions and frames the gap the AS is designed to close. Scored 1–5. Findings are actionable, not evaluative.
Each use case is a specific, demonstrable capability the AS delivers for ClaraVis. Every card includes the EU AI Act risk classification and the specific architectural constraint the AS satisfies to meet it.
Observable architectural outcomes — not percentage projections. Each criterion is measurable at the system level and traceable to a specific requirement. These are the acceptance criteria the AS must satisfy before any module is considered production-ready.
This document is the input to TOGAF Phase A — Architecture Vision. Every diagram, decision record, and architecture component in the pages that follow traces back to a requirement, constraint, or stakeholder concern documented here.