A golden path is the platform's easiest supported route for a common need. It creates speed through defaults, documentation, automation, and support. It is not a ban on variation. When a real need falls outside the path, the team makes the difference visible, assesses its consequences, and routes it to the right authority before implementation.
Design for momentum
A golden path should feel like a head start
A useful supported path packages decisions that teams would otherwise repeat: where an application runs, how environments are separated, where secrets live, how changes are reviewed, and where support begins. Teams move faster because common choices already have a documented, testable route.
The path earns adoption by being understandable and dependable. If teams must fight it for ordinary work, the platform has a product problem. If the path covers every imaginable case, it becomes too complex to guide anyone. The owner must optimize for the important class of applications Ember is intended to support.
- Defaults reduce decision fatigue
- Templates and automation reduce accidental variation
- Documentation makes the path learnable
- Known support routes make failures recoverable
- Feedback reveals where the path is incomplete or unnecessarily difficult
Pause with purpose
An exception is a decision, not a hidden setting
A justified exception begins with a need the supported path cannot meet. The owner describes the difference, the business reason, the affected boundaries, and the controls or operating work the difference introduces. The appropriate authority can then accept, condition, redirect, or reject it.
A workaround is different. It hides the difference in code, configuration, an account, or an informal promise. That prevents reviewers and support teams from seeing the new dependency. It also denies the platform team useful feedback about a recurring need.
- State the need before proposing the technology
- Describe exactly how the design leaves the supported pattern
- Identify new data, identity, integration, runtime, monitoring, or recovery consequences
- Name the decision authority and required evidence
- Record scope, conditions, owner, review date, and exit or adoption plan
Know the signals
Some changes alter the review boundary
Ember's current project direction identifies several kinds of change that should not be treated as routine configuration. Examples include prohibited or higher-risk data, airport operational dependency, unusual integrations or custom infrastructure, and deviations from the reference architecture.
The draft engineering standard proposes more detailed delta-review triggers, including new runtime patterns, externally exposed APIs, public unauthenticated access, new identity models, provider changes, and material changes to controls such as logging, monitoring, backup, or recovery. These are useful planning signals, but the standard is not approved. Its required Engineering, Cyber, Operations, and ARB decisions are MISSING.
- Do not assume platform review approves a specific application
- Do not assume one approved service approves every use of that service
- Escalate uncertainty before the design becomes expensive to change
- Track repeated exception requests as possible roadmap candidates
The Ember lens
Ember's confirmed provider pattern is a reference point, not blanket application approval. Render is the default application interface and runtime where appropriate, Supabase is the default database and candidate backend capability provider, Vercel mostly serves communications and documentation surfaces, and SendGrid is optional for approved notification patterns. The platform review remains pending. The detailed engineering exception and delta-review procedure is still a draft with missing approvals.
Responsibility remains
The platform owner makes the normal route clear and improves it from evidence. The application owner identifies when a real need falls outside that route and owns the business consequence. Neither role may self-approve a decision reserved for Security, Data Governance, Operations, Engineering leadership, or the ARB.
Apply it
Run the exception test
An application team wants to add a provider that is not in the Ember reference pattern because it offers a specialized feature. Decide what must happen before implementation.
- 01Write the underlying user or business need without naming the proposed provider.
- 02Compare the need with the supported path and identify the exact capability gap.
- 03List every changed boundary: data, identity, network, provider, support, monitoring, recovery, contract, or lifecycle.
- 04Name the evidence and accountable authorities needed for the difference. Do not label the exception approved until the decision is recorded.
- 05Decide whether this is a one-application exception or a recurring need the platform roadmap should investigate.
Check your understanding
Make the ideas usable
Source trace
Reviewable by design
Content owner: Wesley Almeida
Last reviewed: 2026-08-18
- Ember Learn content model and owners backlog05-projects/vibe-coding-platform/resources/learning/ember-learn-content-model-and-backlog-2026-08-11.md
- Ember platform engineering implementation standard draft05-projects/vibe-coding-platform/resources/standards/
- Ember project status, guardrails, and current review triggers05-projects/vibe-coding-platform/PROJECT.md
- CNCF Platform Engineering Maturity Model