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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
After the BIA prices downtime per service tier: none / pilot-light / warm standby / active-active - and in which region pair (residency-dependent, OQ-02)?
Owner
Executive steering + SRE
Due
End of Phase 2 (target architecture sign-off)
Related
ADR-15, C-RES-03, C-RES-04
Inputs needed before deciding
BIA impact numbers (P1)
Residency constraints (OQ-02)
Priced options per posture from cloud foundation
OD-02 · Dedicated SQL warehouse adoption OPEN
Question
Do lakehouse serving SLO misses or unit-cost regressions (triggers in ADR-08) justify a dedicated warehouse tier?
Owner
Data platform + gov-data
Due
Wave 2 review
Related
ADR-08
Inputs needed before deciding
6 months of BI SLO + cost telemetry after lakehouse MVP
OD-03 · Workflow platform realization OPEN
Question
Realize workflow/case management as BPM product, iPaaS orchestration, or ITSM-platform workflows (svc-workflow is 'optional' pending this)?
Owner
ARB + domain teams
Due
Phase 5 start
Related
cap-order-fulfillment, vs-request-to-resolve
Inputs needed before deciding
Case-type inventory (P1)
Volume/complexity profile (OQ-04)
License landscape (OQ-10)
OD-04 · Showback to chargeback transition OPEN
Question
When (if ever) does showback become chargeback, and at what granularity?
Owner
Executive steering + FinOps
Due
Wave 2 FinOps review
Related
ADR-16
Inputs needed before deciding
2+ quarters of showback adoption evidence
OD-05 · Edge computing adoption OPEN
Question
Does a concrete edge use case (latency floor, disconnected operation, local data processing) with an owner and NFRs exist? Source S50 mentions edge only as an emerging theme.
Owner
ARB
Due
Wave 3 planning
Related
edge-sites
Inputs needed before deciding
Use-case brief with measured latency/disconnection requirements (OQ-12)
OD-06 · Service mesh adoption OPEN
Question
Adopt a service mesh for mTLS/traffic policy, or continue with platform workload identity + network policy? Mesh adds real operational weight (S31 mentions mesh; PR-09 demands justification).
Owner
Platform engineering + security
Due
Wave 2 review
Related
sec-workload-id, ADR-04
Inputs needed before deciding
Count of services needing L7 policy beyond gateway
mTLS coverage gaps measured
platform team capacity check (A-04)
4 · Exception process
Deviations follow runbook RB-20: precise standard cited, compensating control,
named owner, expiry date, risk-tiered approval, automated expiry flagging, quarterly hygiene review. Exception clusters are treated
as evidence that the standard may be wrong — they feed the standards lifecycle rather than being renewed silently (PR-12).