ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
website-dev
TenantAtlas/specs/401-tenantial-platform-page/data-model.md
ahmido 2000c17f33 feat: transition website product page to platform (#391) 
## Summary
- rename the website product page to `/platform`
- add a redirect from `/product` to `/platform` and update navigation/content links
- refresh footer/layout metadata and align smoke tests with the new route
- add spec artifacts for 401-tenantial-platform-page

## Testing
- not run in this step

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #391
2026-05-19 21:34:31 +00:00

7.0 KiB
Raw Permalink Blame History

Data Model: Tenantial Platform Page

This feature uses static public website content only. The "entities" below are content models and route contracts, not database tables or persisted application records.

Platform Page

Purpose: Canonical public route that explains Tenantial's evidence-first governance platform.

Fields:

  • path: /platform
  • canonicalPath: /platform
  • title: Tenantial Platform page title
  • description: SEO description covering backup, restore, drift detection, findings, evidence, audit trails, exceptions, and reviews
  • hero: Platform Hero content
  • operatingModelSteps: ordered list of Operating Model Steps
  • capabilities: list of Capability items
  • governanceLoop: Governance Loop content
  • truthLayers: optional list of Truth Layer items
  • operatorWorkflows: optional list of Operator Workflow items
  • platformBoundary: Platform Boundary content
  • finalCta: CTA content

Validation rules:

  • path must be /platform.
  • Page must have exactly one primary heading.
  • Metadata must use Tenantial branding and must not contain stale public brand/template terms.
  • Page must not depend on tenant data, customer data, platform APIs, auth state, Microsoft Graph, or backend fetches.
  • Page must include required sections from the spec: hero, operating model overview, capability grid, governance loop, platform boundaries, final CTA, and footer.

Relationships:

  • Links from homepage secondary CTA.
  • Links from header Platform navigation.
  • Links from footer Platform navigation.
  • May be reached from /product only through redirect compatibility.

State transitions: N/A - static route content.

Platform Hero

Purpose: First viewport explanation of what Tenantial is and why the visitor is on this page.

Fields:

  • eyebrow: "TENANTIAL PLATFORM" or equivalent
  • headline: product-specific governance headline
  • description: backup, drift, findings, evidence, audit trail, and reviews in one operating loop
  • primaryCta: "Book a demo" linking to the current intentional conversion route
  • secondaryCta: "See the governance loop" linking to the relevant page section
  • visual: large static dashboard/product preview

Validation rules:

  • Must be understandable in the first viewport.
  • Must use a split layout where the product preview is the dominant visual anchor.
  • Must not duplicate homepage hero copy exactly.
  • Must not imply live tenant data.
  • Must keep "Book a demo" primary.

Relationships:

  • References Governance Loop via secondary CTA.
  • Uses Platform Page metadata and shell.

State transitions: N/A.

Operating Model Step

Purpose: Explain the operator-led governance sequence.

Fields:

  • label: step name
  • description: plain-language explanation
  • order: numeric display order

Required ordered values:

  1. Snapshot
  2. Drift
  3. Finding
  4. Review
  5. Evidence
  6. Audit trail

Validation rules:

  • Steps must render as a compact connected sequence on desktop.
  • Steps must stack or simplify on mobile.
  • Copy must avoid implying automatic remediation.

Relationships:

  • Supports Platform Hero and Governance Loop.

State transitions: N/A.

Capability

Purpose: Describe a core Tenantial platform capability in a grouped section with one larger primary block and smaller supporting cards.

Fields:

  • title: capability name
  • description: concise public explanation
  • icon: optional decorative icon identifier

Required values:

  • Backup & Restore
  • Drift Detection
  • Findings
  • Evidence
  • Audit Trail
  • Exceptions
  • Governance Reviews

Validation rules:

  • One primary Backup & Restore block and 6 supporting capability cards should render.
  • Descriptions must not claim guaranteed compliance, guaranteed recovery, full automation, zero drift, or real-time coverage.
  • Icons are decorative unless explicitly labelled.

Relationships:

  • Belongs to Platform Page capability grid.

State transitions: N/A.

Governance Loop

Purpose: Show how configuration change becomes reviewable evidence.

Fields:

  • headline: section heading
  • description: public explanation of why context and evidence matter
  • steps: ordered loop labels

Required loop labels:

  • Source of truth
  • Snapshot
  • Diff
  • Finding
  • Exception
  • Review
  • Evidence
  • Audit trail

Validation rules:

  • Must be shown as a connected visual diagram, not only a text grid.
  • Must make operator review explicit.
  • Must make evidence preservation explicit.
  • Must make auditability explicit.
  • Must not imply live remediation or device actions.

Relationships:

  • Referenced by Platform Hero secondary CTA.
  • Connects Operating Model Steps and Capability items.

State transitions: N/A.

Truth Layer

Purpose: Explain that different forms of product truth are not collapsed into one misleading status.

Fields:

  • title: layer name
  • description: plain-language explanation

Expected values:

  • Execution Truth
  • Artifact Truth
  • Backup Truth
  • Recovery Evidence
  • Operator Next Action

Validation rules:

  • Must be understandable to IT leaders and operators.
  • Must avoid claiming perfect knowledge of all external systems.
  • Must not create a runtime status taxonomy.

Relationships:

  • Optional section on Platform Page.

State transitions: N/A.

Operator Workflow

Purpose: Help target audiences recognize how they would use the platform.

Fields:

  • audience: target audience label
  • description: short workflow statement

Expected audiences:

  • MSP Operator
  • Enterprise IT
  • Security Reviewer
  • Compliance / Audit Stakeholder

Validation rules:

  • Copy must be short and conservative.
  • Must not include fake logos, named customer claims, or unverified proof.

Relationships:

  • Optional section on Platform Page.

State transitions: N/A.

Platform Boundary

Purpose: Prevent misunderstanding of Tenantial's role.

Fields:

  • headline: boundary statement
  • description: what Tenantial is designed for and what it is not replacing

Validation rules:

  • Must clarify governance of record and recovery context.
  • Must state that Tenantial does not take actions on the customer's behalf, does not manage devices, does not replace ITSM/SIEM/ticketing/Microsoft admin centers, and supports reviewable decisions.
  • Must remain sales-friendly and not hostile.

Relationships:

  • Required section on Platform Page.

State transitions: N/A.

Product Compatibility Route

Purpose: Keep existing /product route reachable without exposing stale or conflicting public content.

Fields:

  • path: /product
  • canonicalPath: /platform
  • behavior: redirect to /platform
  • sitemap: excluded when treated as compatibility

Validation rules:

  • Must not expose inconsistent or stale public product copy.
  • Must not render equivalent page content at /product.
  • Must not remain the primary Platform navigation target.
  • Must be covered by smoke tests if retained.

Relationships:

  • Compatibility route for historical links.
  • Canonical route is Platform Page.

State transitions: N/A.