ahmido
c261b1c632
## Summary - tighten homepage messaging, hero support copy, trust teaser flow, and CTA routing for the website public-content rollout - align shared website copy, smoke expectations, and spec 404 artifacts with the latest messaging pass - replace the previously closed PR for `404-public-content-messaging` ## Commits - `44d27395` feat(website): tighten homepage messaging and trust flow - `1ddbd28b` feat(website): refine public content messaging rollout ## Validation - `git diff --check` ## Notes - local Playwright MCP output remains untracked and was not included Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #398
146 lines
7.5 KiB
Markdown
146 lines
7.5 KiB
Markdown
# Data Model: Public Website Positioning & Content Architecture
|
|
|
|
This feature introduces no database tables, product runtime models, persisted entities, enums, status families, provider contracts, or shared product taxonomy.
|
|
|
|
The records below are planning and validation concepts for static website artifacts only.
|
|
|
|
## Public Positioning Surface
|
|
|
|
Represents one intentional public route, docs route, navigation/footer surface, or shared metadata surface affected by the positioning pass.
|
|
|
|
**Fields**
|
|
|
|
- `surfaceId`: stable identifier such as `homepage`, `platform`, `pricing`, `trust`, `contact`, `docs-intro`, `footer`, or `site-meta`
|
|
- `path`: public route path when the surface maps to a URL
|
|
- `locale`: default German, English mirror, shared, or locale-neutral
|
|
- `sourceArea`: shared copy file, route wrapper, page component, docs content, metadata component, navigation/footer component, or smoke expectation
|
|
- `audienceIntent`: first-time visitor, MSP evaluator, internal IT evaluator, governance reviewer, or site maintainer
|
|
- `surfaceRole`: hero, operating model, capability section, provider posture, trust teaser, boundary section, CTA surface, docs surface, or route metadata
|
|
- `status`: needs audit, needs rewrite, accepted, hidden from navigation, or removed
|
|
|
|
**Validation Rules**
|
|
|
|
- Every exposed core public route must have intentional Tenantial-specific content.
|
|
- Homepage surfaces must support policy-governance category clarity and an operating-model narrative.
|
|
- `/platform` must explain the governance model more deeply than the homepage.
|
|
- No positioning surface may import, reference, or depend on `apps/platform`.
|
|
|
|
## Messaging Claim
|
|
|
|
Represents visible copy or metadata that could create a product, provider, trust, pricing, legal, proof, or workflow claim.
|
|
|
|
**Fields**
|
|
|
|
- `surfaceId`: related public positioning surface
|
|
- `claimText`: reviewed phrase or summary of the phrase
|
|
- `claimCategory`: product category, provider posture, trust, pricing, restore, automation, compliance, endorsement, social proof, preview framing, or workflow expectation
|
|
- `proofStatus`: verified, conservative positioning, architecture direction, illustrative/static, unsupported, or remove
|
|
- `riskLevel`: low, medium, high
|
|
- `requiredAction`: keep, rewrite, remove, hide, or verify proof
|
|
|
|
**Validation Rules**
|
|
|
|
- Unsupported provider, certification, compliance, hosting, endorsement, and customer-proof claims must be removed or rewritten.
|
|
- Restore and automation language must avoid autonomous remediation or guaranteed recovery.
|
|
- Trust language must stop at evaluation readiness, auditability, evidence history, review trails, and role-based access unless proof exists.
|
|
- Public copy must not imply that the website connects to or displays live provider/customer data.
|
|
|
|
## Provider Posture Entry
|
|
|
|
Represents one provider or policy-domain reference that may appear in public copy.
|
|
|
|
**Fields**
|
|
|
|
- `providerOrDomain`: Microsoft 365, Intune, Entra, Conditional Access, SharePoint, OneDrive sharing, Enterprise Apps, Service Principals, Google Workspace, AWS, or other domain wording
|
|
- `publicStatus`: current focus, example domain, roadmap domain, architecture direction, or disallowed claim
|
|
- `allowedLabel`: Microsoft 365 first, one policy domain, planned, roadmap domain, architecture direction, or omit
|
|
- `guardrail`: exact wording or implication that must be avoided
|
|
- `relatedSurfaces`: homepage, platform, docs, metadata, trust, or pricing surfaces where the reference appears
|
|
|
|
**Validation Rules**
|
|
|
|
- Microsoft 365 is the current public focus.
|
|
- Intune may appear only as one Microsoft 365 policy domain.
|
|
- Non-Microsoft providers may appear only as architecture direction or future direction when not verified.
|
|
- Public wording must not imply current live support where none exists.
|
|
|
|
## Operating Model Step
|
|
|
|
Represents one step in the public governance operating model.
|
|
|
|
**Fields**
|
|
|
|
- `stepId`: observe, evidence, detect, review, decide, audit
|
|
- `displayLabel`: localized section label for the step
|
|
- `goal`: what the step explains to a visitor
|
|
- `supportingConcepts`: evidence, findings, drift, exceptions, accepted risks, next actions, or audit trail elements
|
|
- `relatedSurfaces`: homepage, platform, docs, or metadata summaries where the step appears
|
|
|
|
**Validation Rules**
|
|
|
|
- The homepage operating model must contain a complete sequence from observed state to audit trail.
|
|
- Step labels must remain understandable to public evaluators and not degrade into implementation vocabulary.
|
|
- Each step must add meaning rather than repeat the prior step.
|
|
|
|
## CTA Intent
|
|
|
|
Represents a visible CTA, navigation item, footer link, or docs/action link.
|
|
|
|
**Fields**
|
|
|
|
- `label`: visible link or CTA text
|
|
- `sourceSurface`: route, shared component, footer, docs nav, or metadata-adjacent surface where the CTA appears
|
|
- `target`: route, anchor, static asset, `mailto:` link, or legitimate external URL
|
|
- `intentFamily`: primary contact/demo, secondary product explanation, trust review, docs review, pricing/evaluation, or navigation
|
|
- `workflowImplied`: walkthrough request, contact request, product education, trust review, pricing discussion, docs review, login, signup, checkout, account creation, self-serve billing, or automated scheduling
|
|
- `supported`: yes or no
|
|
|
|
**Validation Rules**
|
|
|
|
- Public CTAs must resolve to intentional targets and must not use `href="#"`.
|
|
- CTA labels must not imply unavailable login, signup, checkout, account creation, self-serve billing, or automated scheduling workflows.
|
|
- Primary CTA language should remain consistent across core public routes.
|
|
|
|
## Route Metadata
|
|
|
|
Represents public route title, description, canonical, and search/social-facing metadata.
|
|
|
|
**Fields**
|
|
|
|
- `path`: public route path
|
|
- `title`: route-specific page title
|
|
- `description`: route-specific page description
|
|
- `canonicalPolicy`: canonical self, localized alternate, redirect-only, or hidden
|
|
- `socialSummary`: Open Graph/Twitter-facing summary
|
|
- `positioningStatus`: aligned, needs rewrite, or blocked
|
|
- `claimStatus`: conservative, needs rewrite, or blocked
|
|
|
|
**Validation Rules**
|
|
|
|
- Core public route metadata must reinforce policy-governance positioning and Microsoft 365 first focus.
|
|
- Metadata must remain Tenantial-specific and residue-free.
|
|
- Metadata must avoid unsupported provider, compliance, trust, or automation claims.
|
|
- Sitemap and robots behavior from the launch-readiness baseline must remain intact unless a website-scope correction is required.
|
|
|
|
## Relationships
|
|
|
|
- A `Public Positioning Surface` may contain many `Messaging Claim`, `Provider Posture Entry`, `Operating Model Step`, `CTA Intent`, and `Route Metadata` review points.
|
|
- A `Provider Posture Entry` may appear on multiple public positioning surfaces, but each appearance must preserve the same current-versus-future public status.
|
|
- An `Operating Model Step` may appear on the homepage, `/platform`, and docs surfaces, with the homepage carrying concise explanation and `/platform` carrying deeper detail.
|
|
- A `CTA Intent` belongs to one source surface and targets one intentional route, anchor, asset, or legitimate external URL.
|
|
- `Route Metadata` belongs to one public route and must be reviewed alongside the visible copy for that same route.
|
|
|
|
## State Transitions
|
|
|
|
No product runtime state transitions are introduced.
|
|
|
|
Implementation review may move planning concepts through this non-product workflow:
|
|
|
|
```text
|
|
identified -> audited -> rewritten -> validated
|
|
identified -> hidden-from-navigation -> validated
|
|
identified -> removed -> validated
|
|
```
|
|
|
|
These are task/review states only and must not become product runtime status families.
|