TenantAtlas/specs/404-public-content-messaging/research.md

Phase 0 Research: Public Website Positioning & Content Architecture

Decision: Keep the existing Astro website foundation and shared copy architecture

Rationale: The active website is already a standalone Astro app at /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website with Starlight docs, locale-aware route mirrors, shared page components, centralized route copy in src/data_files/site-copy.ts, and Playwright smoke coverage. Spec 404 is a positioning and content-architecture pass, not a rebuild.

Alternatives considered:

• Rebuild the public website foundation: rejected by scope and unnecessary after Specs 400-403.
• Introduce a new content framework or CMS: rejected because this feature needs narrative clarity, not another authoring layer.
• Use apps/platform as a content source: rejected because the public /platform route is static website positioning and apps/platform is explicitly out of scope.

Decision: Treat public route behavior, messaging claims, CTAs, and metadata as the contract

Rationale: The feature introduces no API endpoints or runtime entities. The behavior that matters is expressed through public routes, visible copy, navigation/footer exposure, metadata, docs exposure, CTA targets, and emitted static output.

Alternatives considered:

• Generate OpenAPI or GraphQL contracts: rejected because the public website exposes no feature API.
• Model messaging states as persisted product data: rejected because it would create unnecessary taxonomy or persistence.
• Leave behavior implicit in review comments: rejected because the later implementation and smoke updates need stable, explicit rules.

Decision: Use a homepage operating model instead of an Intune-first feature list

Rationale: The homepage needs to explain the product through an operating model that runs from observed state to evidence, detection, review, decision, and audit trail. That structure supports the intended category better than a narrow feature list or backup-tool framing.

Alternatives considered:

• Keep the existing feature-list emphasis: rejected because it allows the product to collapse back to an Intune-only or backup-only impression.
• Lead with pricing or generic SaaS value claims: rejected because category clarity and trust-safe positioning must come first.
• Defer narrative changes until visual polish: rejected because later layout decisions should follow stable section intent.

Decision: Make /platform the deeper governance-model page and keep /product as the redirect alias

Rationale: The current route structure already redirects /product to /platform. The deeper explanation of the governance model should therefore live on /platform and explain Microsoft 365 first focus, evidence workflows, drift/finding review, controlled recovery, and auditability as one public model.

Alternatives considered:

• Maintain two competing product explanation pages: rejected because it would fragment the public story.
• Mirror homepage copy on /platform: rejected because the route should go deeper than the homepage.
• Reference internal admin implementation details: rejected because the public route must not imply Laravel/Filament/Livewire/runtime coupling.

Decision: Keep Microsoft 365 as the first focus and bound provider-extensible claims explicitly

Rationale: The current product truth supports Microsoft 365-first positioning. The website may say the platform is provider-extensible by design, but current-route copy must keep Google, AWS, and other providers in future/architecture-direction territory only.

Alternatives considered:

• Present the product as Intune-only: rejected because it narrows the intended category too far.
• Present the product as broadly provider-agnostic today: rejected because current support truth does not justify it.
• Avoid provider posture entirely: rejected because the spec requires safe provider-extensible framing.

Decision: Build trust through restrained claims and explicit boundaries

Rationale: No verified German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, Microsoft endorsement, or no-customer-data claim has been supplied. The trust posture should therefore speak about auditability, evidence history, review trails, role-based access, and DACH evaluation readiness without crossing into false assurance.

Alternatives considered:

• Use aspirational trust claims to sound enterprise-ready: rejected because it creates legal and commercial risk.
• Remove trust language entirely: rejected because evaluators still need a clear, honest trust posture.
• Hide boundaries and hope later trust pages fix them: rejected because public pages need safe wording now.

Decision: Reuse the current smoke suite and augment it with claim scans rather than inventing new test families

Rationale: The existing Playwright smoke helpers already validate rendered routes, placeholder-link bans, forbidden public residue, metadata, redirects, mobile navigation, keyboard reachability, and overflow. Those checks, plus a targeted static grep scan for newly forbidden terms, are the narrowest sufficient validation.

Alternatives considered:

• Run Laravel/Pest/Filament tests: rejected because this feature does not touch apps/platform.
• Add a new website-only test framework: rejected because the current smoke suite already covers the needed route and claim surfaces.
• Rely only on manual copy review: rejected because emitted output, links, and metadata also need executable proof.

Decision: Keep docs and locale mirrors intentional and in sync with the positioning contract

Rationale: The public website exposes docs routes under both the default locale and /en/... mirrors, and both route families are driven by shared content/copy organization. Public docs and locale mirrors therefore need the same claim discipline and route-intent review as the core marketing pages.

Alternatives considered:

• Treat docs exposure as separate from positioning: rejected because public docs influence buyer understanding and indexing.
• Update only German default routes: rejected because /en/... pages share the same positioning responsibility.
• Hide all docs routes temporarily: rejected unless specific routes are found to be unready during implementation.

Current Source Observations

• Core marketing routes in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages are thin wrappers around shared components in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/pages.
• Navigation labels, CTA labels, page titles, and page descriptions are centralized in /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/data_files/site-copy.ts.
• Metadata flows through /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/layouts/MainLayout.astro and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/components/Meta.astro.
• Locale routing is mirrored under /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/pages/en using shared component and copy sources.
• Starlight docs content lives under /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/docs and is publicly rendered.
• Existing smoke coverage lives under /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/tests/smoke and already includes forbidden public pattern detection, placeholder-link detection, metadata checks, and mobile/keyboard/overflow checks.
• Placeholder collections still exist under /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/blog, /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/insights, and /Users/ahmeddarrazi/Documents/projects/wt-website/apps/website/src/content/products; public exposure must remain intentional and route-safe.