TenantAtlas/apps/website/src/content/pages/trust.ts
Ahmed Darrazi 27d520b4aa
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m10s
feat: implement website core pages IA
2026-04-19 12:16:45 +02:00

85 lines
3.9 KiB
TypeScript

import type {
CalloutContent,
HeroContent,
PageSeo,
TrustPrincipleContent,
} from '@/types/site';
export const trustSeo: PageSeo = {
title: 'TenantAtlas | Trust',
description:
'TenantAtlas uses the Trust surface to explain tenant isolation, access boundaries, operating discipline, and the limits of public claims in one explicit place.',
path: '/trust',
};
export const trustHero: HeroContent = {
eyebrow: 'Canonical trust surface',
title: 'Review the trust posture in the language of operator safeguards, access boundaries, and explicit limits.',
description:
'The Trust page exists so public claims about isolation, hosting, update discipline, and safer change handling have one bounded supporting surface instead of leaking across product copy.',
primaryCta: {
href: '/contact',
label: 'Start the working session',
},
secondaryCta: {
href: '/imprint',
label: 'Read the imprint',
variant: 'secondary',
},
highlights: [
'Tenant isolation, access handling, and safer restore posture are explained directly.',
'Public claims stay narrower than internal ambition or future certification plans.',
'Trust still routes to a human conversation instead of becoming a dead-end policy wall.',
],
};
export const trustPrinciples: TrustPrincipleContent[] = [
{
title: 'Tenant isolation is a product boundary, not a marketing adjective.',
description:
'The public trust story should make it clear that tenant-scoped truth, access, and workflow boundaries are deliberate product rules, not hand-wavy positioning language.',
note: 'Isolation must stay attributable.',
},
{
title: 'Sensitive access remains bounded, reviewable, and purpose-specific.',
description:
'The product depends on Microsoft tenant-facing access where governance work requires it, but the public site should explain those boundaries without pretending the website itself is part of that runtime path.',
note: 'Bound the trust story carefully.',
},
{
title: 'Restore and other high-risk actions are framed around preview and confirmation.',
description:
'Safer changes come from validation, selective scope, and explicit confirmation rather than from confidence theater about one-click remediation.',
note: 'Safer execution is part of credibility.',
},
{
title: 'Operating discipline matters as much as storage or hosting claims.',
description:
'Change history, evidence linkage, review posture, and update discipline all contribute to whether a serious buyer can trust the product story.',
note: 'Trust includes how the team operates.',
},
];
export const trustNotes: CalloutContent[] = [
{
eyebrow: 'Hosting and residency claims',
title: 'Hosting-region or residency language must stay qualified and current.',
description:
'If the product makes a public claim about where data or workloads run, the Trust page should explain the scope, boundary, and any conditions instead of leaving the claim unbounded.',
tone: 'accent',
},
{
eyebrow: 'Update discipline',
title: 'Operational rigor needs a public explanation even before formal certifications exist.',
description:
'A serious trust page should explain update posture, review expectations, and how the product treats risky changes without falling back on empty compliance theater.',
},
{
eyebrow: 'What we will not imply',
title: 'No absolute legal-compliance claims and no vague “fully automated governance” language.',
description:
'Trust weakens quickly when a public page substitutes slogans for the real controls and workflows a buyer will later inspect.',
tone: 'subtle',
},
];