Skip to content

Boundary tiers

Tend's core promise is sovereignty: nothing an app is made of or touches — prompts, generated code, application data, model inputs and outputs, telemetry — leaves the customer-controlled boundary. What "the boundary" means for model inference is configurable per installation as a tier. Everything else (platform, data, delivery) is customer-controlled under Tier 1, and is designed to be under Tier 2.

Tier 2 is reserved and has never been exercised

Only Tier 1 has ever run. Tier 2 is a reserved value in the App CRD — operator/api/v1alpha1/app_types.go defines it as "reserved; not exercised this slice" — and no vLLM-class serving exists anywhere in the platform's deployment, tooling or services. Every statement about Tier 2 on this page is a design intent, not an observed property, and is written in the conditional for that reason.

Tier 1 — cloud-private (default)

Model inference uses private managed endpoints inside the customer's own cloud tenancy and region — the class of service Vertex AI, Bedrock and Azure OpenAI belong to, though only Vertex AI on GCP is implemented today — with provider training on customer prompts disabled and response caching disabled, recorded field by field in deploy/inference/tier1-posture.yaml.

Retention is not fully disabled

Provider-side retention for abuse monitoring still applies. The posture record carries abuseLogging: not-requested: the exemption is a manual request to the provider and has not been filed. Note also what the verifier can and cannot do — the training, transport and abuse-logging fields have no live API to query, so they are operator attestations in a reviewable file, not measurements.

flowchart LR
    subgraph boundary["Customer boundary (tenancy + region)"]
        B[AI builder] --> IG[Inference gateway]
        subgraph cloud["Customer's cloud tenancy"]
            EP[Private managed\nmodel endpoint]
        end
        IG --> EP
    end
    X[Public model APIs]
    IG -. "no route" .-> X
    style X stroke-dasharray: 5 5

Tier 1 trades a tier-dependent model-endpoint jurisdiction for managed model quality and zero model-ops. The sovereignty claim is scoped honestly: platform and data jurisdiction is customer-controlled; the model endpoint's jurisdiction follows the cloud provider agreement. It must not be marketed as blanket "no foreign jurisdiction".

Honest scoping extends to the network path. "Private managed endpoints" means a tenancy-private managed service — the model serves the customer's own cloud project, with training disabled — the same sense in which Bedrock or Azure OpenAI qualify. It is a statement about tenancy and data handling, not about transport.

Transport to the endpoint is TLS over the public internet, and the Tier-1 Posture Record (deploy/inference/tier1-posture.yaml) states this explicitly — transport: public-internet-tls — so the claim stays honestly scoped. Read that value as scoped to what the record scopes it to: it describes transport from the local development cluster, and no cloud overlay patches it. The GCP-hosted demo environment changes how the gateway authenticates (native GKE workload identity instead of the local cluster's uploaded JWKS) and not how it reaches the endpoint, though its node subnet has Private Google Access enabled, so its path is at least as private as the record claims. Private network transport (GCP Private Service Connect) is a hardening step, not a Tier-1 requirement, and it is not configured.

The posture record carries its own verifiedAt timestamp, written by hack/gcp-inference-up.sh --verify on a successful run against the live project. Read that field, not this page, for how recently the record was checked: this paragraph describes what the file asserts, not when it was last proven.

Tier 2 — self-hosted (reserved; not exercised)

Tier 2 is the design for fully self-hosted inference: all inference would run on customer-operated infrastructure with no external model calls — vLLM-class serving inside the cluster estate — giving jurisdictional control over the model endpoint as well as the platform, at the cost of operating model serving and accepting open-weight model quality.

None of that has been built or run. Tier 2 exists as an enum value the App CRD accepts, and as an accepted value of the inference gateway's tier setting that changes nothing but an audit response header. Nothing reads the App CR's tier field at all, no Tier 2 routing exists, there is no vLLM deployment or self-hosted serving configuration, and no installation has selected it. Read this section as a statement of intended design; do not read any of it as a property the product delivers today.

What is intended to be identical in both tiers

The three properties below are observed under Tier 1 and designed for Tier 2. Because Tier 2 has never run, their sameness across tiers is a design intent rather than a measured result — which is exactly the kind of claim Principle I's sovereignty-scoping clause requires be scoped rather than asserted.

  • The inference gateway is the only model path, and apps and builders never see the endpoint behind it. Under Tier 1 this is enforced today. Switching tier is intended to be a gateway configuration change, invisible to every app.
  • The network perimeter is default-deny, with cross-namespace egress only to the two platform gateways and the identity provider's token endpoint. There is no "Tier 1 egress exception" in app namespaces — only the model gateway reaches the provider endpoint. This is enforced today.
  • The evidence chain records model identity and version, so an app's provenance does not depend on the tier.

Why a gateway instead of per-app endpoints

Centralizing inference behind one gateway is what makes Principle I enforceable rather than aspirational: the perimeter can be generated as a static shape ("egress to the two gateways, the identity provider's token endpoint, DNS and the app's own namespace — nothing else") precisely because no app ever needs a bespoke network path. It also gives one place to enforce builder authentication (Keycloak OIDC — see ADR-0011) and one place to record model usage into evidence.

Operation under the managed operating model (PGT operating the platform for the customer) must not introduce any egress beyond the configured tier — the operating model changes who runs the platform, never the boundary.