When to call me

Decision triggers and protocol for requesting external architectural judgment. Formal, minimal, and outcome‑oriented.

Decision triggers

• Surface‑level success but runtime‑layer inconsistency across entry paths.
• Tenant variance emerging during rollout; behavior diverges across customers.
• Stability degrades 12–18 months after go‑live.
• Decision impasse around trust, routing, identity, or lifecycle control.
• Remediation implies changes to subdomains, destinations, roles, or tenant routing.
• Ownership drift across domains; no single team can issue a decision.

What you probably do not need me for

• Staffing on implementation or delivery tickets.
• Low‑level troubleshooting with clear ownership already established.
• Generic advisory without a concrete architectural decision to make.

What to send

Send a structured summary including:

1. Landscape — S/4 + BTP runtime(s) + identity surfaces
2. Observable runtime divergence — what works where; what fails where
3. Timeline — go‑live, rollout, and recent changes
4. Stakeholder ownership — who holds what today
5. The decision that cannot converge

What happens next

I confirm whether the situation matches a boundary failure pattern. If appropriate, we proceed with a fixed‑scope triage or audit defined in writing — no sales motions. Where executive‑level convergence is required, the Executive Boundary Verdict defines final jurisdiction.

For the model behind this assessment, see the Boundary Model. For essays, see Insights.