Glossary
Terms I use when describing platform work. These may or may not be formal industry definitions. In either case, they are the working meanings behind this site and the ZaveStudios platform practice.
boundaries
The places where responsibility, authority, data, identity, runtime state, or network access changes hands.
Why it matters: Clear boundaries let workload teams and platform operators understand what they own, what they can change, what they inherit, and where escalation belongs.
Examples:
- A workload team owns application behavior, while the platform owns build and deployment mechanics.
- A network path crosses an account or gateway boundary where another team owns the next control.
- A data boundary separates tenant state, shared platform state, and operational telemetry.
References:
certificate trust
The runtime trust path created by certificates, issuers, service identity, and encryption expectations.
Why it matters: Certificate problems often look like application or network failures, but the real issue may be expired trust, the wrong issuer, missing mTLS configuration, or a certificate that does not match the route being used.
Examples:
- cert-manager issues the certificate, but the ingress or service mesh expects a different issuer or secret.
- mTLS is required between services, but one side does not trust the certificate chain presented by the other.
- A route is reachable, but clients fail because DNS, certificate SANs, and ingress configuration do not describe the same endpoint.
References:
contracts
Small, explicit interfaces where a workload declares what it needs and the platform supplies the repeatable mechanics around delivery, policy, identity, runtime, observability, and service integration.
Why it matters: Contracts reduce variance. They let teams express intent without redesigning the platform path for every workload.
Examples:
- A workload declares runtime, exposure, delivery behavior, and capability needs.
- Shared workflows validate the contract before build or promotion.
- The platform owns the mechanics behind the contract instead of pushing those decisions into every workload repository.
References:
control plane
The part of a platform that declares, authorizes, reconciles, or governs behavior. In this site, the term can refer to Kubernetes, GitOps, Terraform, IAM/SSO, policy, delivery, certificate, or network control layers depending on context.
Why it matters: Control planes are where platform intent becomes enforceable behavior. If their state, ownership, or authority is unclear, teams lose the ability to understand and safely change the system.
Examples:
- Kubernetes controllers reconcile declared workload state into runtime behavior.
- GitOps stores desired runtime state and becomes the reviewable path for deployment changes.
- IAM, SSO, policy, certificate, and network control layers decide which actions, identities, routes, and trust paths are allowed.
References:
default path
The supported path that is easier, safer, and more reviewable than creating a custom platform route for each workload.
Why it matters: The platform creates leverage when the secure path is the normal path. If teams must invent delivery, identity, policy, networking, and observability each time, the platform is not doing its job.
Examples:
- A workload declares intent through a small contract and inherits validation, build, promotion, policy, and runtime expectations.
- GitOps represents desired runtime state instead of each team changing cluster resources manually.
- Standard controls apply through the platform path instead of being rediscovered during review.
References:
failed handoff
A boundary where responsibility, state, or context moves from one layer, team, or process to another, but the receiving side cannot safely continue because something is missing, stale, unclear, or misaligned.
Why it matters: Platform problems often appear as component failures, but the useful signal is frequently in the transition between components or owners.
Examples:
- Terraform renames an IAM role, but Kubernetes workload identity still expects the old role.
- CI builds an image, but promotion or deployment does not know which digest or runtime state to consume.
- Security flags a finding, but ownership between the workload team, platform baseline, and Landing Zone controls is unclear.
References:
formation phase
The stage where a platform is still proving its surface area, contract model, operating model, supported paths, and automation boundaries before treating them as stable product interfaces.
Why it matters: Formation phase makes maturity explicit. It lets the platform show real work without pretending that onboarding, self-service, documentation, and automation are already fully productized.
Examples:
- A contract exists, but the team is still learning which fields belong in the stable interface.
- Manual validation remains acceptable while the platform is proving which behavior should later become automation.
- Docs and operating rules are being refined so the supported path becomes easier to consume by someone other than the platform owner.
References:
network pathing
The route traffic is expected to take across cloud, cluster, service, and boundary layers.
Why it matters: A platform can look correctly configured while traffic still fails because the intended path crosses the wrong endpoint, gateway, route table, ingress, policy, or trust boundary.
Examples:
- A workload reaches a cloud service through a VPC endpoint instead of public internet egress.
- Traffic crosses a transit gateway, internet gateway, NAT gateway, or internal gateway depending on the account and network boundary.
- An ingress route works in one environment but fails in another because DNS, certificates, service routing, or network policy do not match.
References:
operating model
The ownership and execution model around the platform: who owns what, how work enters the system, what is self-service, what requires approval, how changes are validated, and where escalation goes.
Why it matters: A platform is not just infrastructure. The technical architecture and the human execution path have to agree, or every important change becomes a negotiation.
Examples:
- A workload team owns application behavior, while the platform owns delivery mechanics, policy controls, and runtime registration.
- A security finding is handled differently depending on whether it belongs to the workload, platform baseline, or a shared infrastructure control.
- A platform operator knows whether the next move belongs in GitOps, Terraform, the IdP, a ticket, or an escalation path.
References:
operating rules
The explicit rules that describe how the platform should be changed, reviewed, supported, escalated, and documented.
Why it matters: Operating rules keep platform behavior from living only in the memory of the last person who debugged it.
Examples:
- Breaking changes require a reviewable path and a documented handoff.
- Manual changes are treated as exceptions unless they are captured back into the governed state.
- A recurring failure mode becomes a documented validation step or clearer ownership boundary.
References:
workload delivery
The governed path from source change to running workload, including validation, build, security checks, artifact promotion, desired state, deployment, and runtime verification.
Why it matters: Delivery is where platform intent becomes operational reality. The path has to be predictable enough for workload teams and supportable enough for platform operators.
Examples:
- A repository change runs shared validation and build behavior before promotion.
- An image digest is promoted into GitOps-managed runtime state.
- Policy, identity, and observability expectations are handled as part of the delivery path, not added later.
References:
workload identity
The path that lets a running workload prove who it is and receive only the permissions it needs to call platform, cloud, or data services.
Why it matters: In regulated platforms, identity is part of the runtime contract. A workload should not inherit broad credentials or depend on unclear manual secret handling.
Examples:
- A Kubernetes service account maps to an AWS role through IRSA or Pod Identity.
- A pod can call one cloud service because its trust relationship and policy allow that path, but it cannot use unrelated permissions.
- A renamed IAM role breaks workspace launch behavior because the runtime identity layer still expects the old shape.
References: