TenantAtlas/specs/409-evaluation-procurement-rollout/data-model.md

Data Model: Evaluation, Procurement & Rollout Readiness Website Surface

This feature has no persisted data model. The entities below are static website content structures used to render a public evaluation-readiness route. They must remain content-only unless a later spec introduces runtime onboarding, procurement workflow, or legal/security document delivery truth.

Evaluation Readiness Page

Represents: The localized public page explaining how Tenantial is evaluated, piloted, reviewed, and prepared for controlled rollout.

Fields:

• locale: de or en
• pageTitle: localized metadata title
• metaDescription: localized metadata description
• heroTitle: main H1
• heroSubtitle: primary supporting paragraph
• supportingLine: short context line for demo, pilot, and trust readiness
• primaryCta: primary CTA label and route
• secondaryCta: supporting CTA label and route
• tertiaryCta: optional trust CTA label and route
• evaluationSteps: ordered evaluation-path steps
• preparationCards: checklist-style preparation cards
• pilotScenarios: typical pilot-scope cards
• stakeholderCards: buyer and reviewer roles
• securityChecklist: security/procurement review points
• accessPrinciples: Microsoft 365 access-readiness principles
• nonRequirementCards: what the first evaluation does not require
• timelineEntries: example evaluation timeline
• faqItems: buyer FAQ entries
• finalCtas: final conversion CTA set

Validation rules:

• pageTitle and metaDescription must not claim compliance certification, German hosting, automatic remediation, automatic restore, one-click restore, or unsupported providers.
• Every CTA destination must be a real route or real contact destination.
• The page must contain hero, evaluation path, preparation, pilot scenarios, stakeholders, security/procurement, Microsoft 365 access, non-requirements, timeline, FAQ, and final CTA sections.
• The page must not contain href="#".

Evaluation Path Step

Represents: One visible step in the buyer journey from first conversation to next-step decision.

Fields:

• key: stable content key
• title: visible step label
• content: buyer-facing explanation

Required rows:

• discovery-call
• product-walkthrough
• security-privacy-review
• technical-readiness-check
• focused-pilot
• review-next-step

Validation rules:

• Steps must explain buyer flow in public language, not internal runtime vocabulary.
• The sequence must make clear that Tenantial is not introduced blindly into production.

Preparation Card

Represents: One item a buyer should prepare before or during evaluation.

Fields:

• key: stable content key
• title: visible card title
• content: short preparation guidance

Required rows:

• use-case
• microsoft-365-scope
• technical-owner
• security-privacy-contact
• review-objective
• success-criteria

Validation rules:

• Cards must stay practical and organizational, not prescriptive about unverified runtime setup.
• Cards must reinforce that the evaluation can start small.

Pilot Scenario Card

Represents: One typical bounded pilot scenario.

Fields:

• key: stable content key
• title: visible card title
• content: buyer-facing description

Required rows:

• msp-customer-review
• internal-it-governance
• policy-backup-versioning
• evidence-audit-preparation
• provider-permission-readiness

Validation rules:

• Cards must describe examples, not guaranteed packaged offerings.
• Cards must not imply that every scenario is fully automated today.

Stakeholder Card

Represents: One role that should be involved in the evaluation.

Fields:

• key: stable content key
• title: visible role label
• content: what this role evaluates

Required rows:

• msp-service-owner
• msp-operator
• it-leadership
• microsoft-365-admin
• security
• datenschutz-dpo
• procurement-vendor-management

Validation rules:

• Cards must explain why the evaluation is not purely technical and not purely commercial.
• Role labels must stay buyer-facing and avoid internal architecture jargon.

Security / Procurement Checklist Item

Represents: One trust, privacy, or procurement review point.

Fields:

• key: stable content key
• title: visible item title
• content: bounded explanation of what is reviewed

Required rows:

• trust-privacy
• avv-dpa-tom
• provider-permissions
• hosting-subprocessors
• audit-retention
• commercial-fit

Validation rules:

• Items must describe status review or request-based handoff, not fake downloadable artifacts.
• Items must not imply completed legal approval where current truth is unverified.

Access Principle

Represents: One buyer-facing principle for Microsoft 365 access readiness.

Fields:

• key: stable content key
• title: visible principle title
• content: explanation of the principle

Required rows:

• read-oriented-access
• write-recovery-adjacent-access
• consent-admin-roles
• no-blind-execution

Validation rules:

• Principles must stay at scope-dependent readiness level.
• Principles must not publish an exact Microsoft Graph permission matrix unless separately verified.

Non-Requirement Card

Represents: One thing the first evaluation does not require.

Fields:

• key: stable content key
• title: visible label
• content: explanation of the boundary

Required rows:

• no-big-bang-rollout
• no-admin-center-replacement
• no-helpdesk-switch
• no-automatic-remediation
• no-fake-compliance

Validation rules:

• Cards must reduce buyer fear without weakening the trust boundary.
• Cards must not drift into dismissive or vague wording.

Timeline Entry

Represents: One example phase in the evaluation timeline.

Fields:

• key: stable content key
• title: visible phase label
• content: short explanation

Required rows:

• orientation
• technical-review
• pilot
• wrap-up-review

Validation rules:

• The set must be framed as an example timeline rather than a guaranteed delivery promise.

Buyer FAQ Item

Represents: One buyer-facing frequently asked question and answer.

Fields:

• question: visible question
• answer: direct buyer-facing answer

Required coverage:

• productive-tenant-needed
• required-permissions
• avv-tom-status
• admin-center-replacement
• helpdesk-or-psa
• automatic-changes
• provider-scope
• compliance-boundary

Validation rules:

• Answers must stay direct and cautious.
• Answers must not claim guaranteed compliance, automation, or unsupported provider coverage.

Discovery Link

Represents: A public-site entry point to the evaluation page.

Fields:

• label: visible link label
• href: localized route
• placement: homepage, platform page, trust page, use-case page, review-pack page, or footer

Validation rules:

• href must resolve to a real route.
• Links must follow the current locale strategy.
• Discovery surfaces must stay light and must not require a main-nav refactor.

Metadata Contract

Represents: The route title and description for the new public page.

Fields:

• title
• description
• canonicalPath

Validation rules:

• Metadata must mention evaluation, demo, pilot, security review, privacy questions, provider permissions, or rollout readiness safely.
• Metadata must not claim DSGVO-konform, ISO-zertifiziert, NIS2-konform, automatic remediation, automatic restore, one-click restore, Google supported, or AWS supported.