ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
website-dev
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

5.9 KiB
Raw Permalink Blame History

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.