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

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:

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.