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

Feature Specification: apps/website Public Content Architecture & Messaging

Feature Branch: 404-public-content-messaging

Created: 2026-05-22

Status: Draft

Input: User description: "Create Spec 404 for apps/website Public Content Architecture & Messaging before the later homepage layout rhythm and visual productization spec."

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

• Problem: The current public website has a safe foundation, but its copy still reads like a conservative theme adaptation rather than a clear Tenantial product narrative.
• Today's failure: Visitors can miss the product category, see repeated claims across sections, or infer unsupported proof, billing, or live-tenant behavior from provisional public copy.
• User-visible improvement: Public visitors can understand Tenantial as evidence-first governance for Microsoft tenant configuration, follow the homepage story, and see consistent conservative CTAs and trust language.
• Smallest enterprise-capable version: Rewrite and normalize public website copy, headings, CTA labels, route metadata, FAQ/trust/pricing language, and claim-safety wording across the core public routes without changing the website foundation.
• Explicit non-goals: No website rebuild, no broad visual redesign, no new design system, no backend workflows, no login/signup/billing/checkout/newsletter behavior, no Microsoft Graph behavior, and no changes to apps/platform.
• Permanent complexity imported: No persisted models, services, enums, runtime workflows, or product capability layers. The durable complexity is limited to sharper public messaging rules and route-level content ownership.
• Why now: Layout polish should follow stable content; otherwise spacing and visual hierarchy would be optimized around copy that may still change.
• Why not local: The issue crosses homepage, product, pricing, trust, contact, docs navigation, metadata, footer, and CTA language, so isolated copy fixes would keep the narrative fragmented.
• Approval class: Core Enterprise.
• Red flags triggered: Public claim-safety risk; cross-route messaging consistency risk. No persistence, taxonomy, or runtime behavior red flags.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 2 | Produktnähe: 2 | Wiederverwendung: 1 | Gesamt: 11/12
• Decision: approve.

Spec Scope Fields (mandatory)

• Scope: Public website content surfaces in apps/website.
• Primary Routes: /, /platform, /pricing, /trust, /contact, exposed docs routes, public navigation, FAQ surfaces, footer, and route metadata.
• 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 explanation pages.

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: N/A - no canonical tenant or workspace view is introduced.
• Explicit entitlement checks preventing cross-tenant leakage: N/A - no tenant data, entitlement 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 only.
• Interaction class(es): public navigation, CTA labels, route metadata, FAQ copy, footer copy, and page-level product messaging.
• Systems touched: apps/website public routes, shared website copy/components where already used, sitemap/robots-adjacent public route visibility if affected by navigation exposure.
• Existing pattern(s) to extend: The current ScrewFast-derived public website structure and Spec 402/403 route model.
• Shared contract / presenter / builder / renderer to reuse: Existing website content/component organization; no new shared runtime contract.
• Why the existing shared path is sufficient or insufficient: The existing website substrate is sufficient for public content updates, but the current copy does not yet provide a stable Tenantial messaging architecture.
• Allowed deviation and why: Bounded copy and metadata changes are allowed. Broad layout redesign and new design-system work are deferred to Spec 405.
• Consistency impact: CTA wording, proof-safe trust language, product category language, and static/demo preview framing must stay aligned across all public pages.
• Review focus: Reviewers must verify that copy changes do not create parallel brand claims, fake proof, unsupported workflows, 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, notification, queue, or link semantics are 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?: no.
• Boundary classification: N/A.
• Seams affected: Public website wording about Microsoft tenant governance only.
• Neutral platform terms preserved or introduced: Governance, evidence, findings, drift, restore planning, auditability, exceptions, reviews, evaluation, and rollout.
• Provider-specific semantics retained and why: Microsoft tenant configuration remains part of the public product category, but public copy must not imply live provider access, Microsoft endorsement, or Microsoft Graph execution by the website.
• Why this does not deepen provider coupling accidentally: The feature changes public positioning, not provider contracts, product runtime, tenant data handling, or platform-core taxonomies.
• Follow-up path: Spec 405 may use the stabilized copy for visual rhythm and product preview polish.

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

N/A - no operator-facing platform surface changes. 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 buyers do not yet get a crisp product story, and claim-sensitive pages still need stronger content discipline before layout work.
• Existing structure is insufficient because: Specs 402 and 403 established the website foundation and launch-readiness guardrails, but they did not finalize public messaging hierarchy, CTA language, or proof-safe page-level copy.
• Narrowest correct implementation: Update public website copy, route metadata, CTA labels, FAQ/trust/pricing wording, and exposed docs/navigation content only.
• Ownership cost: Future public website changes must preserve the same claim-safety and CTA consistency rules.
• Alternative intentionally rejected: Starting with homepage spacing and visual productization was rejected because content determines which sections, headings, CTAs, and product previews need visual priority.
• Release truth: Current-release public website truth; not future-only preparation.

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, route metadata, navigation/CTA wording, and claim safety; build and smoke checks prove the public output still renders and routes correctly.
• New or expanded test families: none required by this specification.
• Fixture / helper cost impact: none.
• Heavy-family visibility / justification: none.
• Special surface test profile: N/A.
• Standard-native relief or required special coverage: Public website build, smoke, residue, CTA, and scope checks are sufficient.
• Reviewer handoff: Reviewers must confirm content quality, conservative claims, intentional CTAs, route safety, and that apps/platform remains untouched.
• 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; git diff --check; git status --short -- apps/platform.

Depends On

• Spec 402 - apps/website ScrewFast Website Rebuild
• Spec 403 - apps/website Public Website Launch Readiness

Scope

This spec is strictly local to apps/website.

It focuses on public website content architecture, messaging hierarchy, CTA language, page-level copy, route metadata, and claim safety.

It does not redesign the website layout. It does not rebuild the ScrewFast-derived foundation. It does not recreate apps/website.

Important Scope Clarification

In this feature, the word "platform" refers only to the public website route /platform inside apps/website.

It does not refer to the Laravel/Filament application in apps/platform.

apps/platform is completely out of scope:

• do not modify it
• do not import from it
• do not inspect it as a content source
• do not run Laravel, Filament, Livewire, Blade, migrations, policies, providers, jobs, queues, database, tenant/workspace, RBAC, or Microsoft Graph code
• only verify through git status --short -- apps/platform that it remains untouched

Goal

Establish a clear, conservative, enterprise-ready public messaging system for Tenantial before visual layout polish.

The website should communicate:

• what Tenantial is
• who it is for
• which Microsoft tenant governance problems it addresses
• why evidence-first governance matters
• how backup, restore, drift, findings, exceptions, auditability, and reviews fit together
• what a visitor should do next

The content should be strong enough that a later layout-rhythm spec can optimize around stable section intent instead of placeholder copy.

Non-Goals

This spec does not:

• change the ScrewFast-derived foundation
• rebuild or recreate apps/website
• perform broad visual redesign
• introduce a new design system
• add backend forms, auth, billing, newsletter, login, checkout, account creation, or self-serve subscription behavior
• add new product runtime capabilities
• introduce Microsoft Graph calls
• claim integrations or certifications that are not verified
• add customer logos, testimonials, or "trusted by" claims
• touch apps/platform
• change Filament, Livewire, Laravel, Blade, providers, policies, migrations, jobs, queues, database, tenant isolation, workspace behavior, RBAC, or AuditLog behavior

Problem

Spec 402 created the correct website foundation, and Spec 403 made the public website safer for launch. However, the current homepage and public pages still feel like a theme adaptation with conservative placeholder copy. The messaging is directionally correct but not yet sharp enough for an enterprise SaaS buyer.

Current issues:

• Hero messaging is long and visually heavy.
• The homepage repeats similar concepts without a clear content hierarchy.
• Product previews do not yet map to a crisp narrative.
• Pricing/evaluation language feels provisional.
• FAQ answers are safe but not yet strong.
• Trust language is conservative but could better explain what is and is not claimed.
• CTA labels need consistent buyer intent.
• The website does not yet fully express the difference between Tenantial as governance-of-record and a helpdesk/device-action tool.

Content Positioning Principles

Public copy must follow these principles:

1. Governance-of-record, not helpdesk: Tenantial should be positioned as a governance, evidence, review, audit, backup/restore, and drift-control product for Microsoft tenant configuration.
2. Evidence-first: The core message is not simply "backup Intune." It is "make tenant configuration changes reviewable, attributable, and recoverable through evidence."
3. Operator-safe: Public copy must avoid implying blind automation, automatic restore success, or uncontrolled live tenant action.
4. Enterprise calm: Copy should be precise, restrained, and credible. Avoid hype, inflated AI language, fake urgency, and unsupported security/compliance promises.
5. Public website only: Marketing language may explain product intent, but must not imply that the public website itself connects to Microsoft tenants, runs Graph calls, or shows live tenant data.
6. No fake proof: No customer logos, testimonials, certifications, Microsoft endorsements, uptime guarantees, compliance guarantees, or recovery guarantees unless verified proof is supplied.

User Scenarios & Testing (mandatory)

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

A first-time visitor opens the homepage and understands that Tenantial is an evidence-first governance product for Microsoft tenant configuration.

Why this priority: If visitors cannot quickly categorize the product, layout polish will not fix the website.

Independent Test: Read the hero and first two homepage sections without relying on visuals.

Acceptance Scenarios:

1. Given a visitor opens /, When they read the hero, Then they can identify Tenantial as a governance/evidence product for Microsoft tenant configuration.
2. Given they read the first two sections, When they summarize the product, Then they mention at least three of: backup, restore, drift, findings, evidence, audit trail, exceptions, reviews.
3. Given they compare Tenantial to a helpdesk or device-action product, When reading the page, Then they understand Tenantial is not positioned as a helpdesk/device-action surface.

---

User Story 2 - Follow A Clear Website Narrative (Priority: P1)

A buyer scrolls the homepage and sees a deliberate narrative from problem to model to capability to evaluation.

Why this priority: A strong homepage needs a content sequence, not just independent sections.

Independent Test: Read homepage section headings and subheadings in order.

Acceptance Scenarios:

1. Given a visitor scans headings only, When they move from hero to footer, Then the section sequence tells a coherent story.
2. Given a visitor reads body copy, When moving through sections, Then each section adds new meaning instead of repeating the same claims.
3. Given a CTA appears, When read in context, Then it matches the visitor's likely decision stage.

---

User Story 3 - Explain The Public Product Model On /platform (Priority: P1)

A visitor opens /platform and understands Tenantial's product model in more detail.

Why this priority: The /platform route is the main product explanation page and should hold deeper messaging than the homepage.

Independent Test: Read /platform copy without using admin/platform code as a source.

Acceptance Scenarios:

1. Given a visitor opens /platform, When they read the page, Then backup, restore, drift, findings, evidence, auditability, exceptions, and reviews are explained as one operating model.
2. Given product-like previews are present, When copy references them, Then they are described as illustrative/static.
3. Given the page mentions Microsoft tenants, When reviewed, Then it remains public product positioning and does not imply website runtime provider access.

---

User Story 4 - Present Conservative Evaluation And Pricing Language (Priority: P2)

A buyer reads /pricing and homepage evaluation copy and understands that commercial packaging is scoped and contact-led.

Why this priority: Pricing language is a trust-sensitive surface.

Independent Test: Read pricing/evaluation copy and verify it avoids unsupported billing and entitlement claims.

Acceptance Scenarios:

1. Given pricing is not finalized as self-serve billing, When /pricing renders, Then it does not claim checkout, subscription activation, instant onboarding, or fixed plan entitlements.
2. Given evaluation packages are shown, When reviewed, Then they are framed as scoped conversations or rollout options.
3. Given CTAs appear in pricing sections, When clicked, Then they route to /contact or another intentional page.

---

User Story 5 - Build Trust Without Fake Proof (Priority: P2)

A security-conscious buyer reads trust/legal/FAQ copy and sees clear, conservative trust positioning.

Why this priority: Tenantial's buyer will care about governance and evidence. Trust copy must be honest and precise.

Independent Test: Read /trust, FAQ, legal-adjacent copy, and footer statements.

Acceptance Scenarios:

1. Given no verified certification proof exists, When trust copy is reviewed, Then it avoids SOC 2, ISO, Microsoft endorsement, compliance guarantee, uptime guarantee, and recovery guarantee claims.
2. Given no customer proof exists, When social-proof areas render, Then they avoid fake logos, testimonials, and "trusted by" claims.
3. Given the public website mentions evidence, When reviewed, Then it does not imply that public pages expose live tenant data or real customer evidence.

---

User Story 6 - Normalize CTA Language (Priority: P3)

A visitor sees consistent CTA language across homepage, platform, pricing, trust, docs, and footer.

Why this priority: CTA inconsistency makes the site feel unfinished.

Independent Test: List all visible CTA labels and target URLs.

Acceptance Scenarios:

1. Given CTAs appear across pages, When labels are compared, Then the primary action language is consistent.
2. Given secondary CTAs appear, When clicked, Then they route to explanatory pages or anchors.
3. Given a CTA implies a workflow, When reviewed, Then the workflow is actually available or the CTA is reworded.

Edge Cases

• If a strong marketing phrase risks unsupported claims, prefer conservative wording.
• If a page is not ready for detailed content, use restrained intentional placeholder copy or hide it from navigation.
• If docs content is exposed, it must not imply product behavior not yet supported.
• If product screenshots/previews show values, they must be framed as illustrative/static.
• If the public website mentions Microsoft, it must not imply Microsoft endorsement.
• If public copy mentions restore, it must avoid guaranteed recovery language.
• If copy mentions audit/compliance, it must avoid guaranteed compliance language.
• If copy mentions security, it must avoid certification or assurance claims unless verified.
• If CTA text references "walkthrough", "demo", or "contact", the target must be intentional and not imply automated scheduling unless implemented.
• If old ScrewFast/source copy remains only in non-public attribution or internal files, it is not a content blocker unless it is emitted into public output.

Requirements (mandatory)

Assumptions

• Spec 402 and Spec 403 are complete.
• apps/website is ScrewFast-derived and currently builds.
• The public website domain is tenantial.com.
• No verified customer proof, certification proof, Microsoft partnership proof, or billing model has been supplied.
• No backend form submission, scheduling, login, newsletter, or self-serve purchase workflow exists in website scope.
• Tenantial's intended public positioning is evidence-first governance for Microsoft tenant configuration.
• Tenantial is not positioned as a helpdesk, device-action, or live remediation product.
• apps/platform is out of scope and must remain untouched.

Functional Requirements

Scope

• FR-001: The implementation MUST remain scoped to apps/website.
• FR-002: The implementation MUST NOT touch apps/platform.
• FR-003: The implementation MUST NOT recreate apps/website.
• FR-004: The implementation MUST NOT replace the ScrewFast-derived foundation.
• FR-005: The implementation MUST focus on public content, messaging, metadata, CTA labels, and claim safety.
• FR-006: Layout and visual changes SHOULD be limited to what is necessary to support content clarity.

Messaging Architecture

• FR-007: The homepage MUST have a clear messaging hierarchy from hero to final CTA.
• FR-008: Homepage section headings MUST tell a coherent story when read in order.
• FR-009: Homepage sections MUST avoid unnecessary repetition.
• FR-010: The product MUST be positioned as evidence-first governance for Microsoft tenant configuration.
• FR-011: The product MUST NOT be positioned as a helpdesk, device-action, or blind automation tool.

Product Capability Copy

• FR-012: Public copy MUST explain backup, restore, drift detection, findings, evidence, auditability, exceptions, and reviews.
• FR-013: Restore copy MUST avoid guaranteed recovery or automatic success language.
• FR-014: Drift/finding copy MUST emphasize reviewability and operator decision-making rather than automatic remediation.
• FR-015: Evidence/audit copy MUST avoid claiming legal sufficiency, certification, or guaranteed compliance.
• FR-016: Every public product-like preview or status-like preview value MUST be framed as static, demo, or illustrative content and MUST NOT imply live tenant data.

Page-Level Content

• FR-017: / MUST contain finalized homepage copy suitable for layout polish.
• FR-018: /platform MUST contain deeper product-model copy than the homepage.
• FR-019: /pricing MUST use conservative evaluation/scoped rollout language.
• FR-020: /trust MUST use proof-safe trust language.
• FR-021: /contact MUST set realistic expectations about the contact/demo process.
• FR-022: Docs routes exposed in navigation MUST contain intentional Tenantial-specific content or be hidden from navigation.

CTA Language

• FR-023: Primary CTA language SHOULD be consistent across the site.
• FR-024: Secondary CTA language SHOULD clearly indicate informational navigation.
• FR-025: CTAs MUST resolve to intentional routes or anchors.
• FR-026: CTAs MUST NOT imply unavailable workflow such as login, signup, checkout, account creation, instant provisioning, or automated scheduling.

Trust And Claim Safety

• FR-027: Public copy MUST NOT include fake customer logos, fake testimonials, or unsupported "trusted by" claims.
• FR-028: Public copy MUST NOT claim SOC 2, ISO, Microsoft endorsement, guaranteed uptime, guaranteed recovery, or guaranteed compliance unless verified proof is supplied.
• FR-029: Public copy MUST NOT expose ScrewFast, construction, hardware, manufacturing, template, TenantAtlas, TenantPilot, or TenantCTRL as public brand residue.
• FR-030: Public copy MUST NOT imply the public website connects to a live Microsoft tenant.
• FR-031: Public copy MUST NOT imply the public website displays real tenant data.

Metadata

• FR-032: Core public route titles and descriptions MUST reflect the revised messaging.
• FR-033: Metadata MUST remain Tenantial-specific and residue-free.
• FR-034: Sitemap and robots behavior from Spec 403 MUST remain intact.

Validation

• FR-035: Build validation MUST pass with corepack pnpm build:website.
• FR-036: Public smoke validation MUST pass with WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke.
• FR-037: Whitespace/conflict validation MUST pass with git diff --check.
• FR-038: Scope validation MUST confirm git status --short -- apps/platform is empty.
• FR-039: Implementation summary MUST list changed pages, CTA labels, claim-safety decisions, validation results, and any content follow-ups.

Success Criteria (mandatory)

• SC-001: A reviewer can summarize Tenantial's product category from the homepage hero and first two sections in one sentence without using implementation notes.
• SC-002: Homepage headings read as a coherent narrative from problem to product model to evaluation when copied into a plain-text outline.
• SC-003: /platform explains the product model more deeply than the homepage and covers backup, restore, drift, findings, evidence, auditability, exceptions, and reviews as one operating model.
• SC-004: Public copy includes backup, restore, drift, findings, evidence, auditability, exceptions, and reviews without unsupported recovery, compliance, certification, or endorsement guarantees.
• SC-005: Pricing/evaluation language is conservative and contact-led, with 0 claims of checkout, instant subscription activation, self-serve billing, or fixed unsupported entitlements.
• SC-006: Trust copy contains 0 unsupported certifications, endorsements, customer-proof claims, uptime guarantees, recovery guarantees, or compliance guarantees.
• SC-007: 100% of visible CTA labels use the normalized buyer-intent language defined by this feature, and 100% of CTA targets resolve to intentional routes or anchors.
• SC-008: 0 public href="#" placeholders remain.
• SC-009: 0 forbidden public residue terms appear in visible copy or metadata.
• SC-010: corepack pnpm build:website passes.
• SC-011: WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke passes.
• SC-012: git diff --check passes.
• SC-013: git status --short -- apps/platform returns empty.

Implementation Notes For Planning

Planning should preserve the following sequence:

• Start with a read-only content audit of visible headings, body copy, CTA labels, metadata titles, metadata descriptions, FAQ answers, and footer statements across core public routes.
• Define the homepage narrative before rewriting section copy.
• Define /platform as the deeper public product-model explanation.
• Normalize primary and secondary CTA language before changing individual labels.
• Keep claim-safety wording conservative for restore, audit, compliance, trust, and pricing.
• Review exposed docs routes and either update them with intentional Tenantial-specific content or hide them from public navigation.
• Preserve sitemap, robots, redirect, and noindex behavior established by Spec 403 unless a website-scope correction is explicitly required.
• Confirm apps/platform remains untouched during close-out.

Suggested Validation Commands

corepack pnpm build:website
WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke
git diff --check
git status --short -- apps/platform

Reviewer Notes

Reviewers should evaluate content quality before requesting spacing or layout refinements.

The review should answer:

1. Is the product category clear?
2. Is the homepage narrative coherent?
3. Does /platform explain the product model better than the homepage?
4. Are restore, audit, trust, pricing, and evidence claims conservative?
5. Are CTA labels consistent and honest?
6. Is the public website still free of unsupported claims and residue?
7. Is apps/platform untouched?

Follow-Up

After this spec, the next likely spec is:

• Spec 405 - apps/website Homepage Layout Rhythm & Visual Productization

Spec 405 should use the stabilized content from this spec as the basis for spacing, section rhythm, preview sizing, and visual polish.