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`.