---
type: glossary
title: Glossary
description: Terms as the Architecture Framework uses them, across framework structure, reliability, security, sovereignty, cost and the STACKIT platform.
status: draft
sidebar:
  label: "Glossary"
  order: 4
source_url: "https://framework.stackit.cloud/architecture/glossary/"
source_file: "docs/architecture/glossary.mdx"
---

Terms as this framework uses them. Where a word is used loosely in the industry, this page states
which meaning it carries here.

## Framework terms

**Pillar**: one of the seven lenses this framework applies to a workload. A pillar is a
perspective, not a partition: the same design decision is legitimately discussed under several
pillars, from different angles.

**Design principle**: the reasoning behind a pillar. Principles are not checkable and never appear
in an assessment; they exist so that you can judge when a best practice does not apply to your
situation.

**Question**, the unit a pillar is organized into, and one page: *"How do you back up data, and
how do you know you can restore it?"* Written [`REL 8`](/architecture/pillars/reliability/rel-08-backup-and-restore/). A question is not answered yes or no. It is
answered by the best practices you have established under it.

**Best practice**, a numbered, checkable instruction beneath a question, identified [`REL 8.1`](/architecture/pillars/reliability/rel-08-backup-and-restore/#rel-81-derive-the-backup-schedule-from-the-rpo-per-data-set).
This is the unit an assessment answers. Anything an assessor could not confirm or refute with
evidence appears in the design principles instead.

**Risk if not established**: what kind of damage skipping a best practice produces. **High** is a
discrete failure that arrives at once, an incident, a breach, an unrecoverable loss, a finding an
auditor writes down. **Medium** is damage that accumulates: cost, manual work, drift, a decision
nobody can reconstruct. **Low** is a missed improvement. It says what is at stake, not how much of
it you should accept, which is your organisation's decision.

**Tradeoff**: what pursuing one best practice costs the other pillars. Every best practice states
its own, including the ones that genuinely cost nothing, so that a cost you decide to pay is one
you saw first.

**Workload**, a collection of components that together deliver a business capability, deployed and
operated as a unit. The unit this framework assesses. A workload is usually smaller than "the
platform" and larger than "a service".

**Flow**, a path through the workload that delivers something a user or business process cares
about, such as "complete a checkout". Flows are ranked by business impact, and most reliability,
performance, and cost decisions follow that ranking rather than treating all components equally.

**Industry page**: how the framework applies to one vertical: the regulatory map, the sovereignty
tier default, the pillar weighting, and the statement core an assessment must account for. It adds
no best practices of its own; every demand in it points at a statement that already exists.

## Reliability

**SLO (Service Level Objective)**: the reliability target you commit to internally, expressed
against a measurable indicator. Distinct from an SLA, which is contractual, and from an SLI, which
is the raw measurement.

**RTO (Recovery Time Objective)**: how long a flow may remain unavailable after a failure before
the business consequence becomes unacceptable.

**RPO (Recovery Point Objective)**: how much recent data the business can afford to lose. RTO and
RPO are business inputs, not technical outputs; they are decided before the architecture, not
derived from it.

**Blast radius**: the extent of what stops working when one component fails. Segmentation and
redundancy are both attempts to bound it.

**Graceful degradation**: continuing to serve reduced function when a dependency fails, rather
than failing entirely.

**Health model**, the mapping from raw signals to a per-flow verdict on whether the workload is
healthy. Without one, monitoring produces alerts but not answers.

## Security

**Assume breach**, designing on the premise that an attacker is already inside the boundary, so
that internal traffic and internal identities are verified rather than trusted by location.

**Least privilege**: granting exactly the permissions a principal needs, for as long as it needs
them, and no longer.

**Principal**, any identity that can act: a human user, a service account, a workload identity.

**Data classification**: the assignment of data to sensitivity categories. Here, classification
is upstream of nearly everything: it drives encryption, key ownership, placement, retention, and
access control. See [[`SEC 3`](/architecture/pillars/security/sec-03-data-classification/)](/architecture/pillars/security/sec-03-data-classification/) and
[[`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/)](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/).

## Sovereignty & Compliance

**Digital sovereignty**, retaining effective control over your data, your ability to operate, and
your ability to leave. This framework treats it as three separable properties: data sovereignty
(where data resides and who can reach it), operational sovereignty (who can affect your ability to
run), and software sovereignty (whether you are locked to one provider's interfaces).

**Data residency**: the jurisdiction in which data physically resides. Necessary but not
sufficient for sovereignty: data can reside in Germany while remaining technically accessible from
elsewhere.

**Operator access**: the technical ability of provider personnel to access customer data. Reduced
by customer-held keys and by confidential computing, which protects data while it is being
processed rather than only at rest and in transit.

**Reversibility**, the ability to move a workload off the platform within an acceptable time and
cost. Untested reversibility is an assumption, in the same way an untested backup is.

**Subprocessor**: a third party processing data on behalf of the provider. Relevant to sovereignty
because a compliant provider with a non-compliant subprocessor is not a compliant chain.

**Shared responsibility**: the split between what the provider secures and what you secure. Most
compliance failures happen on the customer side of a boundary the customer did not know was there.

**BSI C5**, the German Federal Office for Information Security's cloud computing compliance
criteria catalogue. Type 2 additionally attests that controls were effective over a period of
operation, rather than merely present at a point in time.

## Cost and sustainability

**Cost attribution**, the ability to say which team, product, or business unit caused a given
cost. Requires the resource hierarchy and labelling to reflect ownership.

**Right-sizing**: matching provisioned capacity to measured demand. A continuous activity;
requirements drift and yesterday's correct size becomes today's waste.

**Utilization density**: how much useful work runs per unit of provisioned capacity. The primary
lever in the Sustainability pillar, and usually in Cost Optimization too.

**Demand shaping**, moving, batching, or deferring work that does not need to happen immediately,
so that peak capacity requirements fall.

## STACKIT platform terms

Definitive descriptions live in the <LinkChip href="https://docs.stackit.cloud/platform/">STACKIT documentation</LinkChip>;
these are short orientations for readers new to the platform.

**Region**: an independent geographic deployment. STACKIT operates `eu01` (Germany) and `eu02`
(Austria).

**Availability zone (AZ)**: a physically separate facility within a region with independent power,
cooling, and network. Each STACKIT region provides at least three.

**Project**: the container that holds resources and to which access and billing attach. The unit
most segmentation and cost-attribution decisions are built on.

**Resource Manager**: the service that organizes projects within an organization, and the place
where the hierarchy backing segmentation and cost attribution is defined.

**Service account**: a non-human identity used by workloads and automation.

**SKE**: STACKIT Kubernetes Engine, the managed Kubernetes service. The abbreviation is STACKIT's
own and appears throughout its documentation, so this framework uses both forms.