## 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
139 lines
5.9 KiB
Markdown
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.
|