Reference Document · The Autonomous Enterprise · 2026
Architecture Decision Records: Every Decision Recorded.
Every Alternative Documented.
Each record states the context, the decision, the alternatives considered, and the consequences. Module-specific decisions are documented in full on each pillar's own module page, where that page exists — Quote-to-Cash and the governance crown today, with Procure-to-Pay and Supply Chain's own decisions pending.
Group 01
Core Platform — Foundation decisions, Phase A through Phase D.
ADR numbers are sequential by decision date, not grouped by category — ADR-005 (phased adoption) was decided after ADR-001–004 but belongs to Go-to-Market, not Core Platform. It appears in Group 02, below.
ADR-001GCP across all four pillars — augmentation, not replacement
The Platform's pillars address domains outside existing CRM/ERP boundaries. Salesforce and SAP remain systems of record across every pillar. Integration is additive. No decommissioning of existing investments. This decision eliminates the most common enterprise AI adoption failure mode: the system migration risk.
Alternative considered: Replace existing CRM/ERP systems with AE-native equivalents. Rejected: eliminates ClaraVis's existing system investments and introduces unacceptable migration risk.
Documented: Page 03 ADM Phase A · Referenced: Page 08 GTM — adoption risk
ADR-002Firestore for agent state and HITL audit over Cloud Spanner or BigQuery
Firestore is the platform standard for agent state machines and the HITL audit store, mandated across all pillars. Spanner's global distribution is not required for a single-region EU deployment. Firestore's document model maps naturally to agent state and HITL event schemas.
Alternative considered: Cloud Spanner for global consistency guarantees. Rejected: global distribution not required for a single-region EU deployment; added cost and complexity not justified.
Documented: Page 03 Phase D
ADR-003SHAP TreeExplainer over LIME for the XAI explanation layer
SHAP is the mandated explanation method across every pillar's ML models. It provides consistent, theoretically grounded feature attribution across tree-based and neural models. LIME's local approximations introduce instability on repeated calls — unacceptable for an immutable audit record.
Alternative considered: LIME for local interpretability. Rejected: instability on repeated calls is incompatible with an immutable, deterministic audit record.
Documented: Page 03 Phase D
ADR-004Pub/Sub as the integration event bus over direct HTTP inter-service calls
All cross-system and cross-pillar events publish to Pub/Sub before consumption — the standard that makes the platform's event fabric coherent. Direct synchronous calls between systems create tight coupling and make event replay for audit purposes impossible.
Alternative considered: Direct HTTP calls between services. Rejected: creates tight coupling and makes event replay for audit purposes impossible.
Documented: Page 03 Phase D
ADR-006Ariba and SAP IBP as systems of record — augmentation, not replacement
Ariba remains the system of record for sourcing, RFx, and purchase order data across four regional instances. SAP IBP remains the system of record for demand planning. The AE does not maintain a parallel procurement or planning system — it reads from and writes back to both via the same augment-not-replace pattern established for Salesforce (ADR-001) and Firestore-mediated agent state (ADR-002). This is the Procure-to-Pay and Supply Chain equivalent of ADR-001's commercial-side decision.
Alternative considered: A parallel AE-native procurement or demand-planning store. Rejected: duplicates an existing system of record, fragments supplier and forecast data across two sources of truth, and reintroduces the migration risk ADR-001 specifically avoids on the commercial side.
Documented: Page 03 Phase C, §5 · Referenced: Page 02, AR-13 · C-08
Group 02
Go-to-Market — Adoption strategy, Phase GTM Design.
ADR-005Phased adoption (H1/H2/H3) over big-bang full-suite deployment
ClaraVis has a hard regulatory deadline (Q2 2026 EU AI Act review), limited internal change management capacity, three complex legacy system integrations (Salesforce, SAP, Ariba), and 12 stakeholders with different adoption readiness levels. Full suite deployment in a single programme would require all of these to be addressed simultaneously. H1 delivers compliance infrastructure before the review. H2 delivers core business modules. H3 delivers the full suite. Each horizon is independently valuable — ClaraVis can pause after H1 or H2 and retain the value already delivered.
Alternative considered: Full AE suite as a single programme. Rejected: EU Act deadline cannot wait; change management load across 12 stakeholders is untenable; no partial value if programme stalls.
Documented: Page 08 GTM Strategy
Group 03
Module-Specific Decisions — Each documented on its module page.
Current scope covers Quote-to-Cash and the governance crown modules in full. Procure-to-Pay and Supply Chain's own module-specific ADRs — the Sourcing Agent's RFx pattern, the 3-Way Match tolerance-band logic, DemandIQ's model selection, SupplierSentinel's scoring methodology, and others — are pending as those pillars' own design documentation matures. This index does not pretend to record decisions it hasn't yet been given; a module with no ADR here has not been audited as ADR-complete.
ADR-SA01Turn-11 escalation boundary for CCAI Sales Agent
5 turns is insufficient for BANT + CPQ. 20 turns is poor sales experience. 11 is the boundary where BANT is complete, BOM is configured, pricing is presented, and the AE enters at the natural handoff point where technical discussion begins.
M-01 CCAI Sales Agent — ADR-SA01
ADR-SA02Salesforce Opportunity created at turn 6, not at HITL-01 escalation
The AE's first action after reading the briefing is to open Salesforce. If the Opportunity doesn't exist, the AE wastes 30–90 seconds creating it — exactly the administrative task the agent eliminates.
M-01 CCAI Sales Agent — ADR-SA02
ADR-CG01Two-pass architecture (Document AI → Gemini) for ContractGuard
Gemini-only extraction is unstructured, expensive per clause, and breaks on unusual contract formats. Document AI provides deterministic structured extraction; Gemini provides semantic reasoning over the full document. Each pass does what it is optimised for.
M-02 ContractGuard — ADR-CG01
ADR-CG02Vertex AI Vector Store over BigQuery vector search for ContractGuard precedents
BigQuery VECTOR_SEARCH has no ANN index — latency degrades as corpus grows. Vertex AI Vector Store uses ANN and returns top-k in under 100ms. First-class integration with Feature Store and Gemini embedding API.
M-02 ContractGuard — ADR-CG02
ADR-R01SAP write requires hitl_id as a mandatory function parameter
Application-level checks can be bypassed by a bug or future code change. The SAP write guard is in the function signature, not in conditional logic. A developer cannot accidentally remove the HITL requirement without explicitly changing the function signature.
M-03 RevRec AI — ADR-R01
ADR-R02HITL-04 required for every RevRec AI classification — no confidence threshold exception
EU AI Act Annex III does not distinguish by confidence level. Auto-approving high-confidence classifications removes the feedback loop that builds Finance Controller trust and produces training signal from overrides.
M-03 RevRec AI — ADR-R02
ADR-FR01Streaming Pub/Sub scoring over scheduled BigQuery batch for FinRisk Sentinel
A 15-minute batch window is unacceptable for a 1-hour HITL SLA. The streaming architecture detects and alerts within 18 seconds of a payment event. BigQuery SQL cannot call a Vertex AI endpoint synchronously.
M-04 FinRisk Sentinel — ADR-FR01
ADR-FR02Dual-reviewer HITL-08 over single-reviewer for high-severity financial alerts
Separation of duties for financial fraud alerts. EU AI Act Article 14 requires oversight proportionate to the risk. Matches the four-eyes principle already applied to financial authorisations above a threshold at ClaraVis. Optimistic lock handles concurrent decisions correctly.
M-04 FinRisk Sentinel — ADR-FR02
ADR-AQ01GKE Autopilot for batch RUL over Cloud Run for Asset IQ
Cloud Run max timeout 60 minutes — insufficient margin for a 45-minute batch job. RUL job requires GPU (A100) which GKE Autopilot provisions natively. Per-pod billing is optimal for one long infrequent job; Cloud Run per-request billing is optimal for many short frequent requests.
M-05 Asset IQ — ADR-AQ01
ADR-AQ02Unified Pub/Sub schema over per-region API adapters for Asset IQ ingestion
Cross-regional fleet analytics (HITL-07) require a single BigQuery query across all regions — impossible without a common schema. Data Governance (M-08) enforces the unified schema at the ingestion gate. The unified schema makes ADR-AQ02 enforceable at runtime, not just as a design convention.
M-05 Asset IQ — ADR-AQ02 · M-08 Data Governance
ADR-GO01±6 hour deferral window for GreenOps carbon-aware scheduling
±1h rarely spans a low-carbon trough. ±24h affects model freshness. Analysis of 90 days of europe-west3 Carbon Footprint API data: low-carbon window occurs within 6 hours 73% of the time. 6-hour deferral on a weekly retraining job = 0.4% interval increase — statistically indistinguishable from normal variation.
M-06 GreenOps — ADR-GO01
ADR-GO02GCP Carbon Footprint API over third-party APIs (Electricity Maps, WattTime) for GreenOps
Third-party APIs require outbound internet calls — a VPC-SC network egress path that requires CISO approval. GCP's API is available within the perimeter. Consistent with GCP billing carbon reporting, ensuring internal CSRD reporting consistency.
M-06 GreenOps — ADR-GO02
ADR-DG01TFX ExampleValidator over custom JSON schema validation for Data Governance
TFX is stateful — it detects distributional drift, not just structural violations. Integrates natively with Vertex AI Pipelines ensuring same schema enforced at training and serving. Great Expectations integration produces living data quality documentation satisfying EU AI Act Article 11.
M-08 Data Governance — ADR-DG01
ADR-DG02Quarantine-then-review over reject-on-arrival for schema violations in Data Governance
Sensor data cannot be re-sent — Pub/Sub delivery window is finite. A schema violation often indicates a legitimate upstream system update, not corrupted data. Quarantine preserves the raw record for reprocessing once the mapping is confirmed. Reject-on-arrival causes permanent data loss.
M-08 Data Governance — ADR-DG02
ADR-SD01Looker Studio over custom React dashboard for Strategy Dashboard
Native BigQuery connector, GCP IAM integration, no separate backend or authentication layer. Correct for the executive audience who consume dashboards in meetings, not in the developer console. Custom React UX investment is better spent on HITL interfaces where UX directly affects operational decisions.
M-07 Strategy Dashboard — ADR-SD01
ADR-SD02Materialised BigQuery views over live queries for Strategy Dashboard
Live queries compete with operational writes for BigQuery slots. Per-panel refresh cadences (5min to 1h) match actual freshness requirements — fleet panel does not need 5-minute refreshes. Materialised view definitions are the auditable specification of what the dashboard shows.
M-07 Strategy Dashboard — ADR-SD02