TenantAtlas/specs/404-public-content-messaging/data-model.md

Data Model: apps/website Public Content Architecture & Messaging

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 Content Surface

Represents an intentional public page, docs page, navigation area, footer area, FAQ area, or metadata surface affected by this content architecture pass.

Fields

• surfaceId: stable human-readable identifier, such as homepage, platform, pricing, trust, contact, docs-intro, or footer
• path: public URL path when the surface maps to a route
• locale: German default, English mirror, shared, or locale-neutral
• sourceArea: page, shared data file, component, docs content, metadata, navigation, footer, or smoke expectation
• audienceIntent: first-time visitor, buyer evaluator, security-conscious reviewer, or site owner/reviewer
• sectionRole: category definition, problem framing, operating model, capability explanation, evaluation, trust, FAQ, legal-adjacent, or closing CTA
• readiness: needs audit, needs rewrite, accepted, or hidden from navigation

Validation Rules

• Every exposed core public page must have intentional Tenantial-specific content.
• Homepage surfaces must support a coherent narrative from product category to evaluation.
• /platform surfaces must explain the public product model more deeply than the homepage.
• Surfaces must not import, reference, or depend on apps/platform.

Messaging Claim

Represents visible copy or metadata that could create a product, trust, pricing, legal, proof, or workflow claim.

Fields

• surfaceId: related public content surface
• claimText: reviewed phrase or summary of the phrase
• claimCategory: product positioning, trust, pricing, restore, audit, compliance, Microsoft relationship, social proof, preview framing, or workflow expectation
• proofStatus: verified, conservative positioning, illustrative/static, unsupported, or remove
• riskLevel: low, medium, high
• requiredAction: keep, rewrite, remove, hide, or verify proof

Validation Rules

• Unsupported SOC 2, ISO, Microsoft endorsement, compliance guarantee, recovery guarantee, uptime guarantee, and customer-proof claims must be removed or rewritten.
• Restore language must avoid guaranteed recovery or automatic success.
• Audit/evidence language must avoid legal sufficiency, certification, and guaranteed compliance.
• Public copy must not imply that the website connects to or displays live Microsoft tenant data.

CTA Intent

Represents a visible CTA, navigation item, footer link, docs link, or form-like public action.

Fields

• label: visible CTA or link text
• sourceSurface: page, component, footer, docs nav, or metadata-adjacent content area where the CTA appears
• target: route, anchor, static asset, mailto link, or legitimate external URL
• intentFamily: primary contact/demo, secondary product explanation, pricing evaluation, trust/legal review, docs review, or navigation
• workflowImplied: contact request, product education, pricing discussion, trust review, docs review, login, signup, checkout, subscription, account creation, automated scheduling, or backend submission
• supported: yes or no

Validation Rules

• Public CTAs must resolve to intentional routes or anchors.
• Public CTAs must not use href="#".
• CTAs must not imply unavailable login, signup, checkout, account creation, instant provisioning, self-serve billing, automated scheduling, or guaranteed backend submission workflows.
• Primary action language should remain consistent across pages.

Product Capability Narrative

Represents one Tenantial capability concept that must be explained safely in public copy.

Fields

• capability: backup, restore, drift, findings, evidence, auditability, exceptions, reviews, or restore planning
• homepageRole: category proof, short capability mention, or omitted
• platformRole: detailed operating-model explanation, static preview explanation, or related capability
• claimBoundary: words or implications to avoid
• relatedSurfaces: public pages or docs surfaces where the capability appears

Validation Rules

• Homepage copy must mention enough capabilities for product category clarity without repeating the same claims across sections.
• /platform must explain the capabilities as one operating model.
• Drift and finding copy must emphasize reviewability and operator decision-making instead of automatic remediation.
• Capability language must remain public positioning, not runtime guarantee.

Static Preview Reference

Represents product-like static/demo content shown or referenced on public pages.

Fields

• surfaceId: related route or component
• previewName: human-readable preview name
• framingCopy: text that identifies the preview as static, illustrative, or demo where needed
• capabilityShown: backup, restore, drift, findings, evidence, auditability, exceptions, reviews, or related product positioning
• dataProvenance: static/demo only
• claimRisk: whether the preview could imply live tenant data, real customer evidence, or active provider integration

Validation Rules

• Preview content must not imply live tenant data.
• Preview status-like values must not become shared product taxonomy.
• Preview copy must not rely on color alone for meaning where status-like information is shown.
• Preview wording must avoid internal Laravel/Filament implementation details.

Route Metadata

Represents public route title, description, canonical, social, and search-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
• residueStatus: clean, needs review, or blocked
• claimStatus: conservative, needs rewrite, or blocked

Validation Rules

• Core public route titles and descriptions must reflect the revised messaging.
• Metadata must remain Tenantial-specific and residue-free.
• Metadata must avoid unsupported claims just like visible page copy.
• Sitemap and robots behavior from Spec 403 must remain intact unless explicitly corrected within website scope.

Relationships

• A Public Content Surface may contain many Messaging Claim, CTA Intent, Product Capability Narrative, Static Preview Reference, and Route Metadata review points.
• A CTA Intent belongs to one source surface and targets one intentional route, anchor, static asset, or legitimate external URL.
• A Product Capability Narrative may appear on multiple public content surfaces, with the homepage carrying concise positioning and /platform carrying deeper explanation.
• Route Metadata belongs to one public route and must be reviewed with the visible copy for the same route.

State Transitions

No product runtime state transitions are introduced.

Implementation review may move planning concepts through this non-product workflow:

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.