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

Feature Specification: Public Website Positioning & Content Architecture

Feature Branch: 404-public-content-messaging

Created: 2026-05-25

Status: Draft

Input: User description: "Reposition the public Tenantial website from an Intune-only or backup-tool impression toward Policy Governance for Microsoft 365 and modern cloud environments, with Microsoft 365 first positioning, provider-extensible direction, an Observe-to-Audit operating model, and strict public claim discipline."

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: The public website still risks framing Tenantial as an Intune backup utility, a narrow Microsoft admin tool, or generic SaaS copy instead of the intended governance-of-record platform.
• Today's failure: Visitors can leave with the wrong category, miss the governance operating model, or infer unsupported provider, compliance, trust, or automation claims from incomplete positioning.
• User-visible improvement: Public visitors can understand Tenantial as a policy governance platform, see Microsoft 365 as the first focus without collapsing the story to Intune, and follow a clear evidence-review-decision narrative.
• Smallest enterprise-capable version: Refresh public website copy hierarchy, terminology, metadata, navigation labels, CTA language, and claim guardrails inside apps/website only, without changing platform runtime behavior.
• Explicit non-goals: No apps/platform changes, no shared auth or API coupling, no CMS, no provider implementation work, no detailed legal or trust proofs, no fake social proof, no fake certifications, and no website-wide visual-system rewrite beyond what content hierarchy requires.
• Permanent complexity imported: No persisted models, services, enums, or runtime workflows. The durable complexity is limited to public positioning rules, provider-claim guardrails, trust-claim guardrails, and route-level content architecture.
• Why now: Launch-readiness and later visual productization depend on a stable public narrative; polishing layout first would optimize around the wrong product story.
• Why not local: The mispositioning spans hero copy, operating-model sections, capability framing, navigation, metadata, trust language, CTA labels, and supporting route hierarchy.
• Approval class: Core Enterprise.
• Red flags triggered: Public category ambiguity; provider-claim risk; compliance/trust overclaim risk; narrow Intune-only framing risk.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 1 | Gesamt: 11/12
• Decision: approve.

Spec Scope Fields (mandatory)

• Scope: workspace.
• Primary Routes: /, /platform, /pricing, /trust, /contact, exposed docs navigation, public metadata, public CTA surfaces, and any shared marketing copy/configuration that drives those routes.
• Data Ownership: No tenant-owned or workspace-owned records are created, changed, or read. This is public website content only.
• RBAC: Not applicable. The affected surfaces are public marketing and product-positioning pages.

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: N/A - no tenant-context or canonical platform view is introduced.
• Explicit entitlement checks preventing cross-tenant leakage: N/A - no tenant data, workspace data, or authenticated platform state is involved.

Cross-Cutting / Shared Pattern Reuse (mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write N/A - no shared interaction family touched)

• Cross-cutting feature?: yes, within public website content surfaces.
• Interaction class(es): public navigation, homepage section hierarchy, CTA labels, capability cards, trust teaser language, route metadata, and public route discovery.
• Systems touched: apps/website pages, shared marketing content/configuration, route metadata, public navigation/footer surfaces, and any public docs route exposure.
• Existing pattern(s) to extend: The public website foundation from Specs 400-403 and the current shared content/layout organization inside apps/website.
• Shared contract / presenter / builder / renderer to reuse: Existing website route and content composition; no new runtime contract is required.
• Why the existing shared path is sufficient or insufficient: The current website substrate is sufficient to carry the revised narrative, but its public copy hierarchy is not yet aligned to the intended product category or claim discipline.
• Allowed deviation and why: Bounded copy, metadata, navigation, and content-hierarchy updates are allowed. Broad redesign, trust-surface expansion, and provider-taxonomy expansion are deferred follow-up work.
• Consistency impact: Product category language, Microsoft-first wording, provider-extensible wording, operating-model labels, trust-safe wording, and CTA intent must remain aligned across public routes.
• Review focus: Reviewers must verify that no page reintroduces Intune-only framing, unsupported provider claims, unsupported compliance claims, fake proof, placeholder links, or apps/platform coupling.

OperationRun UX Impact (mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an OperationRun; otherwise write N/A - no OperationRun start or link semantics touched)

N/A - no OperationRun start, completion, queue, notification, or deep-link behavior is touched.

Provider Boundary / Platform Core Check (mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write N/A - no shared provider/platform boundary touched)

• Shared provider/platform boundary touched?: yes, at public positioning and vocabulary level only.
• Boundary classification: mixed public-positioning vocabulary; no runtime provider seam changes.
• Seams affected: Public category language, Microsoft-first wording, provider-extensible wording, current-versus-future provider/domain labels, and homepage capability framing.
• Neutral platform terms preserved or introduced: Policy governance, cloud policy governance, managed environment, provider connection, policy evidence, drift detection, findings, exceptions, accepted risks, review packs, decision summary, audit trail, controlled recovery, and provider readiness.
• Provider-specific semantics retained and why: Microsoft 365 remains the first public focus because that is the current product truth. Intune may be described only as one Microsoft 365 policy domain. Google, AWS, and other providers remain future direction only.
• Why this does not deepen provider coupling accidentally: The feature changes public positioning only. It does not change provider contracts, platform-core taxonomies, provider runtime logic, or supported-integration truth.
• Follow-up path: A later public provider/domain taxonomy feature can expand current-versus-planned labeling without changing this positioning baseline.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

N/A - no operator-facing platform surface is changed. This feature changes public website content surfaces only.

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing decision surface is added or materially changed.

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing detail or status surface is added or materially changed.

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing list, detail, queue, audit, config, or report surface is added or materially changed.

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing page or workflow is added or materially refactored.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no.
• New persisted entity/table/artifact?: no.
• New abstraction?: no.
• New enum/state/reason family?: no.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: Public evaluators, MSPs, and internal IT teams do not yet get a stable product category or governance operating model from the website.
• Existing structure is insufficient because: Specs 400-403 established website foundation and launch safety, but they did not finalize a public positioning architecture for policy governance, provider posture, or safe trust language.
• Narrowest correct implementation: Rework public copy, hierarchy, navigation, metadata, terminology, and claim guardrails in apps/website only.
• Ownership cost: Future public pages and website edits must preserve the same positioning contract, provider posture, and trust-safe wording.
• Alternative intentionally rejected: Broad visual redesign and detailed trust/legal expansion were rejected because they would deepen scope before the public narrative is stable.
• Release truth: Current-release public positioning truth, with later follow-up work for detailed trust, provider taxonomy, and use-case expansion.

Compatibility posture

This feature assumes a pre-production public website content environment.

Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.

Canonical replacement is preferred over preservation.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Browser/static public website validation.
• Validation lane(s): fast-feedback and public smoke.
• Why this classification and these lanes are sufficient: The feature changes public content, metadata, navigation, CTA wording, and claim discipline; website build, smoke, and targeted static claim scans are the narrowest proof that the public output remains correct.
• New or expanded test families: none required beyond existing website validation and targeted static content scans.
• Fixture / helper cost impact: none.
• Heavy-family visibility / justification: none.
• Special surface test profile: N/A.
• Standard-native relief or required special coverage: Homepage desktop/mobile review, public route smoke, placeholder-link scan, claim scan, and apps/platform untouched confirmation are sufficient.
• Reviewer handoff: Reviewers must confirm product category clarity, operating-model visibility, provider-safe wording, trust-safe wording, honest navigation/CTAs, and zero apps/platform drift.
• Budget / baseline / trend impact: none expected.
• Escalation needed: none.
• Active feature PR close-out entry: Smoke Coverage.
• Planned validation commands: corepack pnpm build:website; WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke; grep -RIn -e 'href="#"' -e 'Intune Management Tool' -e 'Intune backup tool' -e 'DSGVO compliant' -e 'GDPR compliant' -e 'ISO certified' -e 'Google supported' -e 'AWS supported' -e 'automatic restore' -e 'autonomous remediation' -e 'neutral SaaS visual' -e 'lorem ipsum' apps/website/src apps/website/public 2>/dev/null || true; git diff --check; git status --short -- apps/platform.

User Scenarios & Testing (mandatory)

User Story 1 - Recognize The Right Product Category (Priority: P1)

A first-time visitor opens the homepage and understands that Tenantial is a policy governance platform for Microsoft 365 and modern cloud environments, not an Intune-only utility.

Why this priority: If the product category is wrong, every later page and CTA inherits the wrong expectation.

Independent Test: Read the hero and the next section on the homepage without relying on internal product knowledge.

Acceptance Scenarios:

1. Given a visitor opens /, When they read the hero and supporting line, Then they can describe Tenantial as policy governance rather than an Intune backup or helpdesk tool.
2. Given a visitor reads the first screen and adjacent positioning copy, When they summarize the product, Then they mention Microsoft 365 first focus and evidence-based governance.
3. Given Intune appears in the copy, When the visitor reads the surrounding text, Then Intune is understood as one policy domain rather than the full product category.

---

User Story 2 - Follow The Governance Operating Model (Priority: P1)

A buyer scrolls the homepage and understands how observed state becomes evidence, detection, review, decision, and audit trail.

Why this priority: The operating model is the clearest way to explain the product without reducing it to a feature list.

Independent Test: Read homepage section titles and core section summaries in order from top to bottom.

Acceptance Scenarios:

1. Given a visitor scans the homepage, When they reach the operating-model section, Then they can identify the flow from observed state to audit trail.
2. Given the capability section is visible, When the visitor reads the cards, Then the story focuses on evidence, drift, reviews, controlled recovery, provider readiness, and decision traceability rather than raw feature enumeration.
3. Given the visitor compares the operating-model section with the hero, When they continue down the page, Then each section adds new meaning instead of repeating the same claim.

---

User Story 3 - Evaluate Provider Posture And Boundaries Safely (Priority: P2)

A security-conscious evaluator can see Microsoft 365 as the current focus, provider extensibility as future-safe direction, and clear boundaries about what the product is not.

Why this priority: Provider posture and boundary language strongly influence trust, scope expectations, and commercial qualification.

Independent Test: Read the homepage and the primary supporting product page without referencing implementation notes.

Acceptance Scenarios:

1. Given a visitor reads the Microsoft-first section, When they review provider/domain examples, Then current focus and future direction are clearly separated.
2. Given the visitor reads boundary language, When they compare Tenantial to an admin center, helpdesk, PSA, or blind automation tool, Then those categories are clearly rejected.
3. Given a visitor looks for Google, AWS, or other non-Microsoft provider claims, When they review the page, Then they find only architecture-direction or provider-extensible wording, not live-support claims.

---

User Story 4 - Trust The Site Without False Assurance (Priority: P2)

A DACH or enterprise evaluator reads the trust teaser, metadata, and CTA surfaces and sees conservative, honest claims.

Why this priority: The website must invite evaluation without overpromising compliance, hosting, or automation.

Independent Test: Review hero copy, trust teaser, supporting sections, metadata, navigation links, and CTAs on primary public routes.

Acceptance Scenarios:

1. Given no verified legal or certification proof is provided, When trust-related copy is reviewed, Then it avoids claims about German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, or zero customer data storage.
2. Given public CTAs and navigation are present, When a visitor interacts with them, Then every visible link resolves to a real route or intentional page state and no href="#" placeholders remain.
3. Given restore, remediation, and automation language appears, When the copy is reviewed, Then it speaks about controlled recovery and approval-ready follow-up rather than autonomous remediation or automatic restore.

Edge Cases

• If provider-extensible wording appears near provider examples, it must not imply that Google, AWS, or other providers are live today.
• If Intune is named in the hero, capability copy, or domain examples, it must remain one policy domain and not become the umbrella category.
• If trust or DACH language is added, it must stop at auditability, evidence, review trail, role-based access, or evaluation readiness unless verified legal claims exist.
• If a navigation label suggests a page that does not exist or is not ready, the route must be omitted or replaced with an intentional limited page that matches current website conventions.
• If the site mixes German and English copy, the mix must be intentional and not look like mockup residue.
• If supporting routes mention roadmap domains, the copy must clearly label them as planned or architecture direction.
• If metadata compresses the message, it must still preserve policy-governance positioning and avoid Intune-only framing.
• If previews, screenshots, or status-like content appear, they must not imply live customer/provider data unless explicitly verified.

Requirements (mandatory)

Assumptions

• Specs 400-403 provide the current public website foundation and launch-readiness baseline.
• apps/website is the only application scope for this feature.
• The workspace contracts that matter to the website remain the root script names, website package name @tenantatlas/website, WEBSITE_PORT, and apps/* pnpm workspace convention.
• No verified Google, AWS, or other non-Microsoft provider support has been supplied as current product truth.
• No verified claim exists yet for German hosting, DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, or "no customer data stored" messaging.
• Detailed DACH trust, Datenschutz, hosting, legal, and security evidence belongs to a later trust-focused feature rather than this positioning feature.
• apps/platform is out of scope and must remain untouched.

Functional Requirements

Scope And Workspace Contracts

• FR-001: The implementation MUST remain scoped to apps/website and directly related website workspace-contract files only.
• FR-002: The implementation MUST NOT modify apps/platform runtime, routes, auth, database, Filament, Livewire, or provider code.
• FR-003: The implementation MUST NOT add platform API calls, shared auth/session coupling, database dependencies, or route dependencies from the public website to apps/platform.
• FR-004: The implementation MUST preserve the root package script names, website package name @tenantatlas/website, WEBSITE_PORT convention, and apps/* pnpm workspace contract.
• FR-005: Before execution, the implementation MUST verify current repo truth for root scripts, website scripts, and website source structure instead of assuming a fixed file layout.
• FR-006: The feature MUST NOT introduce a CMS, fake placeholder pages, fake customer proof, fake certifications, or fake trust artifacts.

Positioning Contract

• FR-007: The public website MUST position Tenantial primarily as a Policy Governance Platform or an equivalent cloud policy governance phrasing.
• FR-008: The public website MUST NOT primarily position Tenantial as an Intune backup tool, Intune management tool, Microsoft admin center replacement, helpdesk, PSA platform, compliance certification platform, or autonomous remediation platform.
• FR-009: Homepage and metadata copy MUST communicate Microsoft 365 as the first product focus.
• FR-010: Intune MAY appear in public copy only as one Microsoft 365 policy domain, not as the product category.
• FR-011: Public copy MAY describe the product as provider-extensible by design or future-ready beyond a single admin center.
• FR-012: Public copy MUST NOT present Google, AWS, or other non-Microsoft providers as live supported integrations unless verified current product truth exists.

Provider Posture Rules

• Microsoft 365 is the current public product focus.
• Intune is one Microsoft 365 policy domain.
• Entra or Conditional Access may be described as Microsoft 365 governance domains only when consistent with current website truth.
• SharePoint, OneDrive sharing, enterprise apps, service principals, Google, AWS, and other providers may appear only as roadmap or architecture-direction language when they are not current product truth.

Homepage Content Architecture

• FR-013: The homepage MUST explain what Tenantial governs and why evidence-based governance matters.
• FR-014: The homepage hero MUST communicate policy governance, Microsoft 365 first focus, and provider-extensible direction in one screen.
• FR-015: The homepage MUST include a trust teaser or equivalent light trust surface that speaks about auditability, evidence history, role-based access, review trail, or DACH evaluation readiness without overclaiming legal or certification status.
• FR-016: The homepage MUST include an operating-model section that covers observed state, evidence, detection, review, decision, and audit trail.
• FR-017: The homepage MUST shift capability framing away from narrow Intune feature language and toward policy evidence, drift/change detection, governance reviews, controlled recovery, provider readiness, and decision traceability.
• FR-018: The homepage MUST include a Microsoft 365 first section or equivalent explanation that is concrete without collapsing the product into Intune-only positioning.
• FR-019: The homepage MUST include concise audience messaging for MSPs and internal IT teams or an equivalent audience split that matches public commercial intent.
• FR-020: The homepage MUST include clear boundary language that Tenantial is a governance and evidence layer, not an admin-center clone, not blind automation, and not a helpdesk or PSA replacement.
• FR-021: The homepage MUST end with concrete CTA language tied to real destinations or deliberate in-page navigation.

Supporting Route And Navigation Requirements

• FR-022: Supporting public routes such as /platform, /pricing, /trust, /contact, and exposed docs navigation MUST reinforce the same positioning contract as the homepage.
• FR-023: If public navigation labels are adjusted, they MUST use honest labels such as Platform, Use Cases, Trust, Docs, Pricing, and Contact, or equivalent labels that match available route truth.
• FR-024: Navigation and CTA surfaces MUST NOT contain href="#" placeholders or production-looking links to content that does not exist.
• FR-025: If a route does not exist or lacks real content, it MUST be omitted from navigation or represented with an intentionally limited page consistent with current website conventions.
• FR-026: /platform or the primary supporting product route MUST explain the governance model more deeply than the homepage while remaining clearly public and non-runtime-coupled.

Metadata And Terminology

• FR-027: Homepage metadata MUST position Tenantial as policy governance for Microsoft 365 and avoid Intune-only framing.
• FR-028: Public metadata and visible copy MUST stay aligned on policy governance, evidence, review, decision, and auditability rather than raw feature lists.
• FR-029: Preferred public terminology MUST emphasize policy governance, managed environments, provider connections, policy evidence, drift detection, findings, exceptions, accepted risks, decision summaries, audit trail, controlled recovery, and provider readiness or equivalent governance language.
• FR-030: Restore terminology MUST prefer controlled recovery, restore readiness, or recovery planning over blind rollback or guaranteed restore language.
• FR-031: Public copy MUST remain consistent in route language and avoid accidental English/German mockup residue.

Claim Guardrails

• FR-032: Public copy MUST NOT claim Google support, AWS support, multi-cloud support today, provider-agnostic execution today, or provider-agnostic restore unless verified.
• FR-033: Public copy MUST NOT claim DSGVO/GDPR compliance, AVV/TOM availability, ISO/BSI/NIS2 certification, German hosting, Microsoft endorsement, or "no customer data stored" unless verified.
• FR-034: Public copy MUST NOT claim autonomous remediation, automatic restore, self-healing, or approval-free automation.
• FR-035: Public copy MUST NOT include fake customer logos, fake testimonials, fake compliance badges, lorem ipsum, neutral-SaaS residue, or other placeholder artifacts in emitted public output.
• FR-036: If roadmap or architecture-direction language is used, it MUST be clearly separated from currently available product focus.

Validation And Reporting

• FR-037: The implementation MUST use only scripts that actually exist in the workspace root or apps/website/package.json.
• FR-038: Validation MUST include a website build check using the existing workspace scripts.
• FR-039: Validation MUST include a website smoke or browser check if local preview/test support exists.
• FR-040: Validation MUST include a static scan for placeholder links and forbidden public claims in website source and committed public output when applicable.
• FR-041: Completion reporting MUST document changed public surfaces, commands run, pass/fail results, deferred follow-up work, and confirmation that apps/platform remained untouched.

Success Criteria (mandatory)

• SC-001: A reviewer can describe Tenantial from the homepage hero and next section as a policy governance platform for Microsoft 365 without calling it an Intune-only or backup-only tool.
• SC-002: Homepage copy presents a clear six-step governance narrative from observed state to audit trail that a reviewer can list in order from the rendered page.
• SC-003: Intune appears only as one example domain in homepage/supporting copy and does not appear as the primary product category in visible headings or metadata.
• SC-004: Provider-extensible language appears without any unverified live-support claim for Google, AWS, or other non-Microsoft providers.
• SC-005: Trust-related public copy contains zero unverified claims about German hosting, DSGVO/GDPR compliance, AVV/TOM availability, certifications, or autonomous remediation/recovery.
• SC-006: Navigation and CTA surfaces contain zero placeholder destinations, and every visible CTA leads to a concrete next step or real route.
• SC-007: MSP/internal IT/governance-evaluator messaging is visible on the public site without reducing the target audience to endpoint administrators alone.
• SC-008: Homepage metadata and primary supporting routes consistently reinforce policy-governance positioning, Microsoft 365 first focus, and evidence/review language.
• SC-009: No apps/platform files are modified as part of the feature.
• SC-010: Public website validation completes successfully, or any failure is explicitly documented as pre-existing.