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',
    },
];