A documented standard is not an applied standard
Most organizations already have standards written down somewhere — a wiki page, an architecture doc, a security guide. Documentation is necessary, but it isn't sufficient: a documented standard can still be ignored under deadline pressure, misunderstood by someone new, or simply out of date by the time anyone reads it again.
Vertro's governance model moves standards along a deliberate path: documented, then defaulted into the Golden Path, then validated, then enforced, then measured. Each stage is a real step, not a formality — jumping straight to enforcement before anyone's validated it against real workloads is how governance programs create outages instead of trust.
Guardrails and Golden Paths do different jobs
Golden Path
Creates correct configuration by default. A developer onboarding through it gets the right namespace pattern, the right identity model, the right resource limits — without deciding any of it themselves.
Guardrail (Policy)
Prevents unacceptable configuration from being admitted, including from outside the Golden Path — a manual change, a fork, a request that skipped the standard process.
Vertro treats these as complementary, not interchangeable. A policy engine with no good defaults just blocks bad configuration after someone's already hit the wall. A Golden Path with no enforcement behind it is a suggestion, not a standard. Using both is what makes "the easy path is the correct path" actually true.
Policy content stays yours to define
Vertro can install and configure Policy Controller, Google Cloud's managed implementation of Gatekeeper for Kubernetes admission governance, but installing the engine isn't the same as defining your organization's rules. Your platform and security teams decide which constraints apply, at what strictness, and where exceptions are permitted. Vertro delivers that policy content declaratively through Git and Config Sync.
Resource governance without per-Application guesswork
Every Application Environment receives ResourceQuota and LimitRange settings from approved platform defaults rather than requiring developers to choose CPU and memory values independently. Required ownership, cost-center, and Environment labels can also be generated consistently to support governance and reporting.
Exceptions designed to stay visible, not invisible
Some Applications genuinely need something outside the standard. Vertro's exception model is designed around a requester, a reason, an approver, a scope, and an expiration where practical — rather than a one-off change nobody remembers approving eighteen months later — so exceptions are meant to stay visible instead of becoming permanent by accident. The exception path is intentionally not designed to be easier than the standard path; if it were, it would quietly become the new standard.
Frequently asked questions
Is a guardrail the same thing as a Golden Path?
No. A Golden Path creates correct configuration by default. A guardrail (policy) prevents unacceptable configuration from being admitted even if something outside the Golden Path tries to introduce it. Vertro uses both — generating good defaults and enforcing boundaries around them — rather than relying on either alone.
Does Vertro install a policy engine, or does it define our policies for us?
Vertro can install and configure the policy engine, such as Policy Controller. The actual policy content — which rules apply, at what strictness — is defined by your platform and security teams. An installed policy engine with no organization-specific rules doesn't enforce anything on its own.
Can policy rules be reviewed the same way infrastructure changes are?
Yes. Policy content is managed declaratively through Git and delivered through Config Sync, the same reconciliation model used for other platform-owned Kubernetes configuration — giving policy changes the same versioning, review, and rollback as everything else Vertro generates.
How does Vertro handle resource quotas across many Applications?
Quotas and limits are generated from approved platform defaults rather than configured per Application by hand — so every Application Environment gets predictable resource governance without a developer needing to pick the right numbers themselves.
Who is accountable when a policy exception is granted?
Vertro's exception model is designed around a requester, a reason, an approver, and a scope, with an expiration where practical, so an exception doesn't quietly become a permanent, undocumented configuration.