Principles & Architecture Decisions

Twelve testable principles, sixteen fully-argued ADRs (proposed), six honestly-open decisions, and the exception mechanics.

Status honesty: every ADR below is proposed — ratification, amendment or rejection happens at Phase 0 (runbook P0, step 4). They are complete decision records so the organization inherits analyzed options, not blank pages. The identity of vendors/providers is never decided here (A-08); ADRs decide shapes, the organization selects products against the integration catalog's criteria.

1 · Architecture principles

Principles are written to be testable in review: each is phrased so a design either conforms or needs an exception (RB-20). Source sections S3/S29 supply the themes; the testable phrasing is this package's proposal.

ID	Principle	Source
PR-01	Business outcome first Every initiative traces to a named business objective; architecture work that cannot name its outcome does not proceed.	S2, S6
PR-02	Security and privacy by design Controls are designed into components and flows (deny by default, least privilege, complete mediation) - never appended after the fact.	S25
PR-03	Data is owned and governed Every dataset and data product has a domain owner, classification and lifecycle; ungoverned data is a finding, not a norm.	S19
PR-04	APIs and events are managed products Interfaces have owners, contracts, versions, SLOs and deprecation paths - they are products, not project artifacts.	S16, S20
PR-05	Reuse before duplication Platform capabilities (identity, integration, data, observability) are consumed, not rebuilt; duplication requires an approved exception.	S3, S9
PR-06	Automate repeatable controls Guardrails that can be code are code (policy-as-code, pipelines, GitOps); manual review is reserved for judgment calls.	S33, S46
PR-07	Design for operability and recovery A component is not done until it is observable, on-call-owned, capacity-planned and restorable with evidence.	S36-S38
PR-08	Cloud-smart, not cloud-only Workload placement follows requirements (data gravity, latency, cost, residency) - not slogans in either direction.	S3, S22
PR-09	The simplest architecture that meets the quality attributes Complexity (microservices, mesh, multi-region, agents) must be justified by measured or explicitly stated requirements.	S47, S49
PR-10	Vendor choices follow logical requirements Capabilities are designed vendor-neutrally; products are selected against documented criteria and remain replaceable where economic.	S18
PR-11	AI actions are bounded, observable, reversible and accountable Every AI/agent action has an allowlisted scope, an audit trail, a rollback path and a human accountable for it.	S41, S42
PR-12	Exceptions are explicit, risk-accepted, time-limited and reviewed Deviations from standards carry an owner, a compensating control and an expiry date - silent drift is not an option.	S45, S46

2 · Architecture Decision Records

ID	Title	Status	Review
ADR-01	Cloud-smart hybrid strategy during modernization	proposed	2027-01-24
ADR-02	Single primary cloud provider	proposed	2027-07-24
ADR-03	Multi-cloud requires documented justification	proposed	2027-07-24
ADR-04	Managed Kubernetes for the service core; PaaS/serverless as the escape valve; VMs as transitional rehost landing	proposed	2027-01-24
ADR-05	Domain-first incremental extraction; modular monolith as the default for new medium applications	proposed	2027-07-24
ADR-06	Single edge API gateway with full API management lifecycle	proposed	2027-07-24
ADR-07	Event streaming backbone AND work queues - selected by semantics, not fashion	proposed	2027-07-24
ADR-08	Lakehouse-primary analytics estate with data-product (mesh) operating model; SQL warehouse only on trigger	proposed	2027-07-24
ADR-09	Separate workforce IdP and CIAM; PAM + IGA from wave 0	proposed	2027-07-24
ADR-10	Central secrets service, KMS-owned keys, automated certificates, workload identity everywhere	proposed	2027-07-24
ADR-11	OpenTelemetry-first observability with consolidated platform	proposed	2027-07-24
ADR-12	Golden-path CI/CD with GitOps delivery and supply-chain gates	proposed	2027-01-24
ADR-13	Hosted foundation models first, via the AI gateway; self-managed serving only on trigger	proposed	2027-01-24
ADR-14	Agentic AI enters production only through the tool-registry + HITL + kill-switch control set	proposed	2026-10-24
ADR-15	Multi-AZ baseline resilience; immutable backup + isolated cyber vault; multi-region deferred to OD-01	proposed	2026-10-24
ADR-16	FinOps: mandatory tagging, showback first, unit economics per product	proposed	2027-01-24

ADR-01 · Cloud-smart hybrid strategy during modernization

Status / date: proposed · 2026-07-24 · review 2027-01-24
Decision owner: Enterprise architecture + cloud foundation
Context: The source guide (S22-S23) describes hybrid coexistence as the modernization reality: legacy core on-premises while new capabilities are cloud-native. No org-specific constraints are known (OQ-01/02).
Requirements: Support strangler-pattern coexistence; private connectivity; consistent identity/policy across environments; exit path from on-prem.

Options considered

A) Cloud-first big-bang migration
B) Hybrid coexistence with deliberate drawdown (chosen)
C) Indefinite dual-estate hybrid

Decision: Adopt hybrid as a TRANSITION posture: cloud is the default for new/modernized workloads; on-prem persists only for the legacy core and shrinks per wave with explicit exit criteria.
Rationale: B matches the incremental-modernization theme of the source (S56) and avoids big-bang risk; C institutionalizes dual-run cost (risk R-01).
Consequences: Dual-run costs and hybrid networking complexity are accepted for the transition window; every on-prem residual after wave 2 requires an explicit decision.
Security impact: Consistent identity and logging must span both estates from wave 0 or investigations fragment.
Cost impact: Dual-run is the main cost driver; tracked as a FinOps line item with a drawdown curve.
Operational impact: Two operating models during transition; mitigated by extending platform tooling (observability, backup) across both.
Reversibility: Medium - posture can be re-weighted per wave; sunk connectivity costs are modest.
Evidence: Wave exit reports showing on-prem footprint reduction; connectivity utilization trends

ADR-02 · Single primary cloud provider

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Executive steering + cloud foundation
Context: The source is provider-neutral throughout. Provider choice requires org input (contracts, skills, region needs - OQ-10); what CAN be decided architecturally is the number of strategic providers.
Requirements: Deep managed-service leverage; one landing-zone/guardrail implementation; one skills curve; FinOps commitment leverage.

Options considered

A) One primary provider (chosen)
B) Two providers with workload split
C) Provider-agnostic abstraction layer everywhere

Decision: Standardize on ONE primary provider (identity of the provider = organization selection against documented criteria in the integration catalog). Secondary providers only via ADR-03 justification.
Rationale: Splitting early doubles platform build cost and halves commitment leverage; abstraction layers (C) tax every workload to hedge a rare event (S49 anti-pattern: over-engineering).
Consequences: All landing-zone, policy and platform investment concentrates on one provider; exit costs grow over time and are consciously accepted and reviewed.
Security impact: Single-provider guardrails are simpler to verify; concentration risk assessed in the risk register (R-09).
Cost impact: Commitment discounts and focused platform team offset lock-in premium; egress/exit cost reviewed annually.
Operational impact: One operating model, one on-call skill set.
Reversibility: Low-to-medium - portability preserved at the data layer (open formats, ADR-08) where it is cheap.
Evidence: Provider selection scorecard (org-completed); annual lock-in/exit review

ADR-03 · Multi-cloud requires documented justification

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Architecture review board
Context: S22 presents multi-cloud as common practice; the prompt requires documented justification before recommending it. Resilience-motivated multi-cloud is frequently cost without benefit.
Requirements: Prevent resilience theater; allow genuinely justified secondary-provider use (sovereign/service-unique/M&A cases).

Options considered

A) Multi-cloud by default for resilience
B) Single provider, exceptions with justification (chosen)
C) Prohibit second providers entirely

Decision: Multi-cloud deployments require an approved exception documenting: the requirement no primary-provider service meets, the full duplicated platform cost, and the operating ownership.
Rationale: Cross-cloud failover of stateful systems is rarely achievable at reasonable cost (state, consistency, split-brain - see scalability principles); most claimed benefits dissolve under that analysis. C is too rigid for M&A/service-unique realities.
Consequences: Exception path exists; each exception carries duplicated-control cost explicitly.
Security impact: Avoids silent duplication of the security stack per cloud.
Cost impact: Avoids 1.5-2x platform cost of dual estates.
Operational impact: Ops complexity contained to justified exceptions.
Reversibility: High - this is a governance rule, changeable by ARB.
Evidence: Exception register showing zero unjustified second-cloud deployments

ADR-04 · Managed Kubernetes for the service core; PaaS/serverless as the escape valve; VMs as transitional rehost landing

Status / date: proposed · 2026-07-24 · review 2027-01-24
Decision owner: Platform engineering + ARB
Context: S31-S32 cover microservices/containers/K8s; the prompt requires K8s be justified, not assumed. Illustrative estate: ~10-15 services, event consumers, AI runtime - enough to amortize a cluster platform IF a capable platform team exists (assumption A-04).
Requirements: Run heterogeneous service workloads with strong isolation, GitOps delivery, admission-time supply-chain enforcement; avoid forcing K8s onto trivial workloads.

Options considered

A) Managed K8s for everything
B) PaaS-only estate
C) Managed K8s core + PaaS escape valve + transitional VMs (chosen)
D) Serverless-first

Decision: C: domain services, BFFs, integration and AI runtimes on managed multi-AZ Kubernetes; scheduled jobs, low-traffic apps and event glue on managed PaaS/serverless; rehosted legacy on hardened VMs with forward dispositions.
Rationale: The service count and admission-control/supply-chain requirements justify K8s (criteria documented, per prompt); B caps platform control (admission policies, mesh-identity options); D forces re-architecture of everything at once.
Consequences: Platform team must staff K8s expertise (risk R-13); PaaS variance in golden paths accepted and templated.
Security impact: Admission control becomes the supply-chain enforcement point (C-SC-02); cluster misconfig is a top risk - CSPM coverage mandatory.
Cost impact: Cluster baseline cost amortizes across services; per-workload PaaS pricing wins below ~3-5 services per team (rule-of-thumb placeholder, validate with FinOps data).
Operational impact: One deployment model for the core estate; HPA/autoscaler capacity per runbook RB-18.
Reversibility: Medium - PaaS escape valve means individual workloads can move without re-platforming the estate.
Evidence: Assumption A-04 validation (team capacity); quarterly platform cost-per-service report

ADR-05 · Domain-first incremental extraction; modular monolith as the default for new medium applications

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Enterprise architecture + domain teams
Context: S31, S52, S56: the source consistently favors incremental, domain-driven decomposition over big-bang microservices. The prompt requires explicit modular-monolith vs microservices criteria.
Requirements: Extract legacy capabilities safely; avoid a distributed monolith; give teams a default that matches their operational maturity.

Options considered

A) Microservices-first for everything
B) Keep the monolith, API-enable only
C) Modular-monolith default + criteria-based extraction (chosen)

Decision: New medium-complexity applications start as modular monoliths with enforced internal boundaries. A module becomes a service only when it meets extraction criteria: independent scaling need, divergent change cadence, distinct data ownership, team ownership boundary, or independent failure isolation requirement.
Rationale: A creates operational load ahead of team maturity (S49 anti-pattern); B leaves the agility problem unsolved. C matches source S56 and the strangler roadmap.
Consequences: Some modules will be extracted later at refactoring cost - accepted as the price of learning real boundaries.
Security impact: Fewer network hops = smaller attack surface initially; extraction adds mTLS/workload-identity requirements per service.
Cost impact: Fewer runtime components early; extraction cost budgeted per wave.
Operational impact: On-call surface grows with each extraction; each must arrive with SLOs and runbooks (PR-07).
Reversibility: High for new apps (internal boundaries preserved); extraction decisions themselves are one-way once consumers exist.
Evidence: Extraction-criteria checklist applied per candidate; distributed-monolith review in wave retrospectives

ADR-06 · Single edge API gateway with full API management lifecycle

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Integration platform + API governance
Context: S16, S53: API-first enterprise with managed lifecycle. Baseline has point-to-point sprawl (S49, S57).
Requirements: One mediated ingress for API traffic; API products with versioning, portal, subscriptions, analytics; partner-grade exposure.

Options considered

A) Per-team gateways
B) One edge gateway + APIM lifecycle (chosen)
C) Service mesh ingress only, no APIM

Decision: All external and cross-domain API traffic passes one governed gateway tier managed through an APIM control plane with a developer portal; internal same-domain calls may bypass (documented boundary).
Rationale: Per-team gateways (A) recreate point-to-point sprawl one level up; C loses product lifecycle, portal and partner onboarding capabilities.
Consequences: The gateway tier is a critical dependency: multi-AZ, aggressive SLOs, and a tested bypass-for-degradation stance for internal traffic.
Security impact: Central PEP for C-APP-01/03; single audit point for API traffic.
Cost impact: Gateway/APIM licensing scales with traffic - unit cost watched by FinOps.
Operational impact: API governance gets an enforcement point; deprecation policy becomes executable.
Reversibility: Medium - gateway products are swappable behind stable API contracts, at migration-project cost.
Evidence: API inventory coverage %; rogue-endpoint scans (should trend to zero)

ADR-07 · Event streaming backbone AND work queues - selected by semantics, not fashion

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Integration platform + API governance
Context: S20 (EDA), S57. Order/fulfillment/notification fan-out plus analytics feeds justify a durable log; command-style work (invoice generation) fits queues better.
Requirements: At-least-once delivery with replay for facts; load-leveled work distribution for commands; schema governance; DLQ discipline.

Options considered

A) Streaming platform for everything
B) Queues only
C) Streaming for facts + queues for work (chosen)

Decision: Domain FACTS (order lifecycle, customer changes, partner documents) publish to the streaming backbone with registry-governed schemas; WORK COMMANDS use queues with competing consumers. A one-page decision tree ships in the integration catalog.
Rationale: A forces log semantics onto work distribution (awkward acking, rebalancing pain); B loses replay and analytics feeds that justify the backbone (fan-out documented in rels).
Consequences: Two messaging technologies to operate - accepted; conventions and golden-path templates keep usage consistent.
Security impact: Broker ACLs via workload identity both sides; PII minimized in events (C-INT-01..03).
Cost impact: Streaming clusters/capacity are a real cost - consumer-lag-driven right-sizing per FinOps review.
Operational impact: DLQ/replay runbooks (RB-10) mandatory before a team's first consumer ships.
Reversibility: Medium - protocol-compatible managed services exist; schema registry is the real coupling.
Evidence: Semantics-misuse findings in integration reviews; DLQ drill records

ADR-08 · Lakehouse-primary analytics estate with data-product (mesh) operating model; SQL warehouse only on trigger

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Data platform + data governance council
Context: S19, S40, S58. The prompt demands a clear mesh/fabric/lakehouse distinction: LAKEHOUSE = storage/compute architecture; DATA MESH = domain-ownership operating model; DATA FABRIC = metadata-driven integration tooling claim, treated with caution here.
Requirements: One governed analytical estate; domain-owned data products with contracts; BI + ML + AI consumption; no dual-estate drift.

Options considered

A) Traditional warehouse-centric EDW
B) Lakehouse-primary + mesh operating model (chosen)
C) Full mesh with per-domain infrastructure autonomy
D) 'Data fabric' product suite

Decision: Single lakehouse (raw/validated/curated/serving zones) as the physical estate; domain-owned data products as the operating model; central platform team runs shared infrastructure. A dedicated SQL warehouse is added ONLY if measured serving performance/cost triggers documented here fire.
Rationale: B captures mesh's ownership benefits without C's infrastructure fragmentation (unaffordable at assumed org scale); D buys a promise the catalog+pipeline stack already delivers; A recreates the baseline bottleneck.
Consequences: Zone promotion gates become the quality control point; serving-layer performance is the watched risk (trigger: sustained BI SLO misses or unit-cost regression -> evaluate warehouse).
Security impact: Zone-scoped access and column masking enforced from catalog classification (C-DP-01/03).
Cost impact: Storage-compute separation controls cost; per-domain showback via FinOps tagging.
Operational impact: Platform team owns infra; domains own products and their quality pager (C-OPS-01 applied to data).
Reversibility: Medium - open table formats preserve data portability; semantic/dashboard layers are the sticky part.
Evidence: BI SLO attainment; product freshness SLOs; trigger-metric dashboard for the warehouse decision

ADR-09 · Separate workforce IdP and CIAM; PAM + IGA from wave 0

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Security engineering
Context: S25 (zero trust, identity-driven). Workforce and customer identity have different threat models, scale and lifecycle.
Requirements: Phishing-resistant workforce auth; consumer-scale external auth with consent; JIT privilege; automated JML.

Options considered

A) One IdP for all populations
B) Separate workforce IdP + CIAM (chosen)

Decision: Workforce identity on the enterprise IdP (SSO/MFA/conditional access/SCIM); customers and partners on CIAM (risk-based MFA, consent, federation). PAM for privileged access and IGA for lifecycle start in wave 0, not later.
Rationale: Blast-radius separation: consumer credential-stuffing waves must not touch workforce auth; licensing/scale models differ anyway.
Consequences: Two identity systems to govern - accepted; PDP policy model kept logically unified (sec-pdp).
Security impact: Foundational to the entire zero-trust model (C-ID-01..05).
Cost impact: CIAM per-MAU pricing watched; workforce per-user predictable.
Operational impact: JML automation removes the perennial orphan-account audit finding.
Reversibility: Low - migrations between IdPs are painful; choose deliberately (org selection per catalog criteria).
Evidence: MFA coverage, JML latency, orphan-account scans, access-review completion

ADR-10 · Central secrets service, KMS-owned keys, automated certificates, workload identity everywhere

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: Security engineering + platform
Context: S25, S33. Baseline anti-pattern: static credentials scattered in configs (S49 implied).
Requirements: Eliminate static secrets; owned encryption keys with rotation; no cert-expiry outages; short-lived workload credentials.

Options considered

A) Per-team secret stores
B) Central secrets + KMS + PKI automation + workload identity (chosen)

Decision: One secrets service (delegated namespaces), KMS/HSM-backed key hierarchy with documented ownership, ACME-style automated certificate issuance/renewal, and platform-issued workload identities replacing service accounts.
Rationale: Secret sprawl (A) is unauditable; workload identity removes the largest class of credential theft targets.
Consequences: Vault availability becomes tier-1 (its outage blocks deploys/starts) - HA + break-glass documented.
Security impact: Directly implements C-ID-04, C-DP-02; certificate monitoring closes a classic outage class.
Cost impact: Modest platform cost vs incident cost avoided.
Operational impact: Rotation runbook RB-06 becomes routine instead of heroics.
Reversibility: Medium - migration off static secrets is incremental with a scanner-driven burn-down.
Evidence: Static-secret count trend to zero; cert-expiry incident count zero; rotation logs

ADR-11 · OpenTelemetry-first observability with consolidated platform

Status / date: proposed · 2026-07-24 · review 2027-07-24
Decision owner: SRE + platform engineering
Context: S37. Baseline: fragmented per-team monitoring implied by S49/S57 anti-patterns.
Requirements: Vendor-neutral instrumentation; three signals + events correlated by propagated ids; SLOs with owners; telemetry cost control.

Options considered

A) Vendor-native agents everywhere
B) OTel instrumentation -> consolidated backend (chosen)

Decision: All new services instrument via OpenTelemetry SDKs/collectors with enterprise semantic conventions; one consolidated observability backend (org-selected per catalog); AIOps evaluated only after hygiene is proven (see ops-aiops note).
Rationale: OTel keeps backend choice reversible (the expensive part is instrumentation, not storage); vendor-native lock at the SDK layer is the costliest lock-in in observability.
Consequences: Collector layer adds an operated component; it is also the redaction/sampling control point - worth it.
Security impact: Telemetry redaction at collector protects log privacy (supports C-OPS-01 and privacy overlay).
Cost impact: Sampling + retention tiers are THE cost lever; ingest cost reviewed monthly by FinOps.
Operational impact: One query surface for incident response; service maps from real traces.
Reversibility: High at backend layer (OTel portability); low at convention layer once adopted.
Evidence: Instrumentation coverage %; MTTR trend; telemetry cost per service

ADR-12 · Golden-path CI/CD with GitOps delivery and supply-chain gates

Status / date: proposed · 2026-07-24 · review 2027-01-24
Decision owner: Platform engineering + security
Context: S33-S34. Supply-chain controls (SBOM, signing, provenance) required by the prompt's security section.
Requirements: Fast paved-road delivery; enforced scanning/signing; separation of duties; reproducible environments.

Options considered

A) Team-owned bespoke pipelines
B) Golden-path templates + GitOps + admission verification (chosen)

Decision: Standard pipeline templates (build->test->scan->SBOM->sign->attest->deploy via GitOps) with policy gates; clusters admit only signed, attested artifacts from the trusted registry; production changes only via reconciled Git state.
Rationale: Bespoke pipelines (A) make every security improvement an N-team negotiation; templates make it a version bump.
Consequences: Template rigidity risk - explicit escape hatches with expiring exceptions (PR-12).
Security impact: Implements C-SC-01..04, C-CLD-02 at the strongest layer (admission), not by convention.
Cost impact: Runner/registry costs modest; blocked-release friction is the real (accepted) cost.
Operational impact: Emergency-release path (RB-14) rehearsed so gates never force cowboy deploys.
Reversibility: High - templates evolve centrally.
Evidence: DORA metrics; gate-bypass audit (zero unapproved); attestation coverage

ADR-13 · Hosted foundation models first, via the AI gateway; self-managed serving only on trigger

Status / date: proposed · 2026-07-24 · review 2027-01-24
Decision owner: AI platform + AI governance council
Context: S41-S42 describe AI/GenAI adoption without hosting specifics. Hosting posture drives cost, risk and residency.
Requirements: Fast capability access; data-use terms verified; cost metering; option for residency/latency/cost-driven self-hosting.

Options considered

A) Self-host open-weight models first
B) Hosted-first via gateway, self-managed on trigger (chosen)
C) Per-team free choice

Decision: Consume provider-hosted models through the AI gateway (allowlist, quotas, logging). Stand up self-managed serving ONLY when a documented trigger fires: residency/sovereignty requirement (OQ-02), sustained unit-cost crossover at volume, latency floor, or fine-tuned-model ownership needs.
Rationale: A front-loads GPU capex and MLOps burden before value is proven; C forfeits governance and metering (C-AI-01).
Consequences: Provider dependency accepted and mitigated by gateway-level fallback routing across allowlisted providers.
Security impact: Data-processing terms review is a selection criterion; prompts/responses logged with redaction.
Cost impact: Token spend is metered per consumer from day one (C-AI-06); crossover analysis is a standing FinOps item.
Operational impact: No GPU fleet to run until a trigger fires.
Reversibility: High - gateway abstraction keeps provider switching a config change for compatible capabilities.
Evidence: Gateway metering reports; trigger-metric dashboard; provider-terms review records

ADR-14 · Agentic AI enters production only through the tool-registry + HITL + kill-switch control set

Status / date: proposed · 2026-07-24 · review 2026-10-24
Decision owner: AI governance council
Context: S42 envisions autonomous enterprises; the prompt mandates bounded, observable, reversible, accountable AI actions and forbids broad default permissions.
Requirements: Allow agent value (workflow automation, assisted operations) without unbounded blast radius.

Options considered

A) Agents with broad service accounts, iterate later
B) Graduated autonomy behind tool registry, HITL, kill switch (chosen)
C) Prohibit agentic AI

Decision: Agents act only via allowlisted, least-privilege tools with transaction limits; actions above governance thresholds require human approval; every action is audited; a rehearsed kill switch (RB-12) disables scopes instantly. Autonomy levels are granted per use case by the AI governance council, starting at assist/recommend.
Rationale: A is how agent incidents happen (R-06); C forfeits the source's S42 opportunity thesis entirely.
Consequences: Slower agent rollout than vendor demos promise - accepted deliberately.
Security impact: Implements C-AI-04/05; prompt-injection red-teaming (C-AI-02) is a release gate for agent-facing surfaces.
Cost impact: HITL adds human latency cost on gated actions - the point, not a bug.
Operational impact: New operational surface (agent incidents) gets runbooks + on-call ownership before production.
Reversibility: High - autonomy levels are policy, adjustable per evidence.
Evidence: Tool-grant register; approval audit trail; kill-switch drill evidence; agent incident reviews

ADR-15 · Multi-AZ baseline resilience; immutable backup + isolated cyber vault; multi-region deferred to OD-01

Status / date: proposed · 2026-07-24 · review 2026-10-24
Decision owner: SRE + executive steering
Context: S38. No BIA exists yet (A-07); the prompt forbids inventing recovery numbers or claiming multi-region without addressing state/cost.
Requirements: Survive AZ loss for critical tiers; survive ransomware including backup-credential compromise; make the region question an explicit, costed decision.

Options considered

A) Active-active multi-region now
B) Multi-AZ + immutable backup + cyber vault now; region posture decided by OD-01 after BIA (chosen)

Decision: All T1/T2 services multi-AZ (C-RES-04); policy-driven backups with immutability windows and scheduled restore tests (C-RES-01); delayed immutable replication to an isolated vault (C-RES-02). Multi-region posture (pilot-light/warm/active-active/none) is decided in OD-01 once the BIA prices downtime.
Rationale: A without a BIA buys unquantified benefit at maximal cost and ignores state/consistency/split-brain complexity the prompt explicitly flags.
Consequences: A regional event before OD-01 resolves would find the org on backups + rebuild - stated honestly as the interim posture.
Security impact: Vault isolation assumes primary credential compromise - separate admin realm enforced.
Cost impact: Multi-AZ premium accepted; multi-region premium deferred until priced against BIA impact numbers.
Operational impact: DR rehearsals per tier produce timed evidence against placeholder bands until real objectives exist.
Reversibility: High - posture upgrades are additive.
Evidence: Restore/DR test evidence; BIA completion; OD-01 decision record

ADR-16 · FinOps: mandatory tagging, showback first, unit economics per product

Status / date: proposed · 2026-07-24 · review 2027-01-24
Decision owner: FinOps practice + executive steering
Context: S39. Allocation is impossible without tagging; chargeback before culture exists breeds gaming.
Requirements: Full allocation of cloud + AI spend; budgets/anomaly detection; unit-economics visibility; commitment management.

Options considered

A) Chargeback immediately
B) Showback first, chargeback as an explicit later decision (chosen; OD-04)
C) Central untagged pool

Decision: Ownership/cost-center tags enforced at deploy by policy-as-code (untagged = undeployable); product-level showback dashboards from wave 0; budgets + anomaly alerts per product; commitment purchases follow utilization evidence; AI token spend allocated per consumer via gateway metering.
Rationale: Tag-at-deploy is the only reliable allocation mechanism; showback builds the accountability muscle chargeback later formalizes (OD-04).
Consequences: Some shared costs (platform, security) allocated by driver keys - method published to avoid disputes.
Security impact: Cost anomaly detection doubles as a crypto-mining/compromise detective control.
Cost impact: FinOps tooling cost is small against the waste it exposes (S39 premise).
Operational impact: Monthly FinOps review (gov-finops) with published actions.
Reversibility: High.
Evidence: Tag coverage %; allocation coverage %; anomaly MTTR; commitment utilization

3 · Open decisions

These cannot be responsibly decided without organization input — deciding them by assumption would violate the package's honesty rules. Each carries the inputs that unlock it.

ID	Title	Owner	Due
OD-01	Multi-region DR posture	Executive steering + SRE	End of Phase 2 (target architecture sign-off)
OD-02	Dedicated SQL warehouse adoption	Data platform + gov-data	Wave 2 review
OD-03	Workflow platform realization	ARB + domain teams	Phase 5 start
OD-04	Showback to chargeback transition	Executive steering + FinOps	Wave 2 FinOps review
OD-05	Edge computing adoption	ARB	Wave 3 planning
OD-06	Service mesh adoption	Platform engineering + security	Wave 2 review