# Data Model: DACH Trust, Datenschutz & Security Website Surface

This feature introduces no persisted runtime entities. The model below describes the editorial and route-level content structures the website implementation must express.

## Entity: Trust Page Content

- **Purpose**: The canonical public trust surface for a locale.
- **Fields**:
  - `locale`: `de` or `en`
  - `route`: public route path such as `/trust` or `/en/trust`
  - `pageTitle`: localized metadata title
  - `metaDescription`: localized metadata description
  - `heroTitle`
  - `heroSummary`
  - `primaryHandoff`: real route or `mailto:` destination for trust/security follow-up
  - `topics`: ordered list of trust topics
  - `claimStatusLegend`: allowed status vocabulary exposed on the page
- **Relationships**:
  - has many `TrustTopic`
  - has many `TrustCallToAction`
- **Validation rules**:
  - must exist in both supported locales
  - must expose a real primary handoff or omit the CTA
  - must not contain placeholder links or forbidden trust claims

## Entity: Trust Topic

- **Purpose**: A single trust subject displayed on the public trust page.
- **Fields**:
  - `slug`: stable editorial identifier such as `hosting-posture` or `provider-permissions`
  - `title`
  - `summary`
  - `detailPoints`: ordered explanatory bullets or paragraphs
  - `claimStatus`: one of the allowed public statuses
  - `verificationNote`: optional editorial note when a hard claim is actually documented
  - `requestPath`: optional real route or `mailto:` for further information
  - `audience`: buyer, technical reviewer, procurement/privacy reviewer, or shared
  - `order`
- **Relationships**:
  - may include many `DataCategory`
  - may include many `DocumentReadinessItem`
  - may include one `PermissionPosture`
- **Validation rules**:
  - `claimStatus` must be one of the six allowed values
  - `requestPath` is required when the visible CTA promises a request action
  - any hard factual claim requires a `verificationNote`
  - topics must stay public-safe and must not require runtime product data

## Entity: Claim Status

- **Purpose**: Bounded editorial vocabulary that separates current fact from request-based or planned trust material.
- **Allowed values**:
  - `documented`
  - `on-request`
  - `in-preparation`
  - `planned`
  - `not-claimed`
  - `not-applicable`
- **Validation rules**:
  - no other public status labels are allowed unless the wording is a clear locale equivalent
  - `documented` cannot be used for a hard claim without a traceable verification note
- **Editorial state transitions**:
  - `planned` -> `in-preparation`
  - `in-preparation` -> `on-request`
  - `in-preparation` -> `documented`
  - any status -> `not-claimed` when the claim is intentionally removed
  - any status -> `not-applicable` when the topic no longer belongs on the public page

## Entity: Data Category

- **Purpose**: Public explanation of a type of data Tenantial may handle for governance or support reasons.
- **Fields**:
  - `slug`
  - `title`
  - `description`
  - `purpose`
  - `dataBoundary`: governance metadata, provider metadata, evidence, review artifact, audit context, or support/diagnostic context
  - `rawPayloadHandling`: minimized, contextual, or request-only explanation
  - `avoidanceNote`: optional note for data the product does not aim to store unnecessarily
- **Validation rules**:
  - descriptions must explain why the category exists, not just name it
  - categories must avoid absolute “no personal data” or “no customer data” claims unless verified

## Entity: Permission Posture

- **Purpose**: Public explanation of why provider access is needed and how read/write access differ.
- **Fields**:
  - `provider`: for this feature, Microsoft 365 / Microsoft Graph
  - `capabilityArea`: inventory, evidence, review preparation, drift detection, recovery preparation, or similar
  - `accessClass`: `read-oriented`, `write-oriented`, or `mixed`
  - `whyNeeded`
  - `leastPrivilegeNote`
  - `auditabilityNote`
  - `detailDocLink`: optional future route if detailed public docs later exist
- **Validation rules**:
  - exact permission names are optional
  - if exact permission names are published later, they require a verification source and last-reviewed context
  - the text must preserve provider-specific detail as provider-owned, not platform-core truth

## Entity: Document Readiness Item

- **Purpose**: Public statement about the availability of AVV/DPA, TOM, subprocessors, or related trust materials.
- **Fields**:
  - `documentType`
  - `claimStatus`
  - `availabilitySummary`
  - `requestPath`: optional
  - `verificationNote`: optional
- **Validation rules**:
  - no fake file URL or download action may be attached
  - `on-request` requires a real request destination
  - `documented` requires a real artifact or documented public proof path

## Entity: Trust Call To Action

- **Purpose**: A real public action that moves the evaluator from public trust copy to a valid next step.
- **Fields**:
  - `label`
  - `href`
  - `kind`: `internal-route` or `mailto`
  - `purpose`: contact, request documents, ask security/privacy question, or book walkthrough
  - `locale`
- **Validation rules**:
  - `href` must not be `#` or empty
  - if `kind` is `internal-route`, the route must exist in the public site
  - if `kind` is `mailto`, the mailbox must be real and verified

## Relationship Summary

- `Trust Page Content` owns the ordered trust surface for one locale.
- Each `Trust Topic` describes one trust subject and may carry a `Claim Status`, `Document Readiness Item`, `Permission Posture`, or `Data Category` list.
- `Trust Call To Action` entries connect the trust page and homepage teaser to real destinations only.

## Implementation Notes

- This is an editorial content model, not a database or backend model.
- The likely source of truth remains `apps/website/src/data_files/site-copy.ts` plus page composition inside `TrustPage.astro` and `HomePage.astro`.
- No persisted entity, runtime enum, or platform abstraction is justified by this feature.