Skip to content

Tend system design

Tend is a governed application lifecycle plane for AI-built internal apps, running on CNCF infrastructure inside the customer's own boundary. Business power users describe an app; an AI builder writes it; Tend makes it safe to run — not by reviewing the generated code, but by enforcing a runtime contract that every app must live under: declared data scopes, a generated network perimeter, a signed evidence chain from prompt to production, a named owner, and an expiry date.

The AI builder is deliberately replaceable. The governed runtime and lifecycle plane is the product.

flowchart LR
    U[Business power user] -->|describes an app| B[AI builder]
    B -->|commits code| G[Git]
    G -->|build + attest| P[Pipeline]
    P -->|signed artifact| T[Tend governed runtime]
    T -->|evidence, ownership,\ncost, lifecycle| E[Answerable estate]

How this documentation is organized

This site follows the Diátaxis framework. Pick the section that matches what you need right now:

  • :material-school: Tutorials

    Learning-oriented. Bring up the platform and take one app from prompt to governed production, step by step.

  • :material-format-list-checks: How-to guides

    Task-oriented. Recipes for concrete jobs: onboard an app, change data scopes, verify an attestation, respond to a cost suspension.

  • :material-book-open-variant: Reference

    Information-oriented. The App CRD schema, service APIs, the policy baseline, CI gates — precise and complete.

  • :material-lightbulb-on: Explanation

    Understanding-oriented. The architecture in C4 views, the governance model, the evidence chain, and why the system is shaped this way.

  • :material-scale-balance: ADRs

    Architecture Decision Records — every significant decision, with the alternatives that were rejected and why.

The system in one paragraph

An App custom resource is the single source of truth for every app (Principle IV). The Tend operator reconciles it into a namespace with a generated Cilium network perimeter (egress only to the platform's two gateways and Keycloak's token endpoint), ResourceQuotas, and Argo CD delivery. A Kyverno admission baseline defaults governance fields at creation and refuses non-compliant workloads. The inference gateway is the builder's only way to reach a model; the data gateway is an app's only way to reach data, enforcing declared scopes per request and logging every access for the app's lifetime. Builds run in Tekton, and Tekton Chains signs in-toto/SLSA attestations with cosign, stored beside the image in Harbor; unattested images are refused at admission in every environment the platform governs — sandbox included. "Governed" is a precise condition and not a figure of speech: the admission policy selects on the tendtech.io/app namespace label that the operator applies to every workload namespace it creates, so a namespace without that label is not selected by the policy and an unsigned image is admitted there. The label is what makes the gate apply. The evidence index assembles each app's full history — prompts, models, tests, approvals, deployments, data access — into one queryable record.

Where to start

You are… Start here
New to Tend entirely System context (C4 L1), then the first-app tutorial
Evaluating the architecture Containers (C4 L2) and the ADR log
Operating the platform How-to guides
Auditing / compliance The evidence chain and querying evidence

Sources of truth

This site describes the system. The binding governance baseline is the constitution (.specify/memory/constitution.md), and the canonical product brief is docs/{problem,requirements,design}.md in the repository. On conflict, those win.