TenantAtlas/specs/405-dach-trust-datenschutz-security-website-surface/data-model.md
ahmido 714b910734 405: DACH Trust, Datenschutz & Security Website Surface (#400)
## Summary
- add a dedicated public trust, privacy, and security surface for DACH evaluation
- expand homepage trust discoverability and localized trust handoff copy
- add and update smoke coverage plus Spec Kit artifacts for feature 405

## Validation
- corepack pnpm --dir apps/website build
- WEBSITE_PORT=4322 corepack pnpm exec playwright test tests/smoke/public-routes.spec.ts tests/smoke/interaction.spec.ts

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #400
2026-05-26 00:11:27 +00:00

139 lines
5.9 KiB
Markdown

# 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.