TenantAtlas/specs/410-public-docs-ia/spec.md

Feature Specification: Public Docs & Knowledge Base IA

Feature Branch: 410-public-docs-ia
Created: 2026-05-31
Status: Draft
Input: User description: "Create the public documentation and knowledge-base information architecture for Tenantial so the website supports evaluation, Microsoft 365 provider understanding, permissions and data access transparency, trust and data-processing review, policy evidence, drift detection, backups and recovery semantics, findings and accepted risk, review packs, known limitations, and FAQ without any apps/platform runtime changes."

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: The public website explains positioning, trust, provider scope, use cases, review story, and evaluation readiness, but it still lacks one durable documentation destination for deeper buyer, operator, security, Datenschutz, and procurement questions.
• Today's failure: Prospects must reconstruct answers across multiple marketing pages or ask manual follow-up questions about provider connections, permissions, data categories, evidence, drift, recovery boundaries, review packs, and known limitations.
• User-visible improvement: A public visitor can find one coherent documentation area that answers deeper evaluation and governance questions in bounded, claim-safe language before a demo or pilot.
• Smallest enterprise-capable version: One public docs hub with durable categories, either real child pages or one well-structured landing page depending on current website IA, plus real discovery links, metadata, FAQ, and limitations coverage.
• Explicit non-goals: No apps/platform work, no contextual in-product help, no CMS, no search backend, no authenticated docs, no API docs, no support workflow, no fake downloads, no fake permission matrix, no fake compliance claims, and no placeholder links.
• Permanent complexity imported: One bounded public docs IA, up to twelve public documentation entry points or sections, related-link maintenance across existing public pages, metadata updates, and continuing copy-governance responsibilities. No models, persistence, runtime abstractions, or product-state machinery are introduced.
• Why now: Specs 404 through 409 established the public story for positioning, trust, provider scope, use cases, review/evidence, and evaluation. The next friction point is the absence of a durable public documentation surface that makes those stories explorable and reviewable.
• Why not local: Adding a few extra blurbs to existing pages would keep technical and procurement answers fragmented and would not create one inspectable documentation destination for evaluators.
• Approval class: Core Enterprise.
• Red flags triggered: IA touch across multiple public entry points, public overclaim risk, documentation taxonomy breadth, and Microsoft 365 permission wording that could drift into unverified detail.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve.

Red Flag Defense

This spec is intentionally limited to public website information architecture and claim-safe documentation copy. It does not add runtime help systems, product logic, provider capabilities, legal downloads, or search infrastructure. The value comes from making existing public product truth explorable without pretending that undocumented or unverified capabilities already exist.

Scope

This spec defines the public documentation and knowledge-base IA for Tenantial so the website can answer deeper evaluation, governance, trust, and buyer-readiness questions in one coherent destination.

• Relevant application for later implementation: public website only
• Depends on: Spec 404 - Public Website Sales Copy & Positioning Rewrite; Spec 405 - DACH Trust, Datenschutz & Security Website Surface; Spec 406 - Provider & Policy Domain Public Taxonomy; Spec 407 - MSP & Mittelstand Use-Case Pages; Spec 408 - Customer-safe Review, Evidence & Decision Story; Spec 409 - Evaluation, Procurement & Rollout Readiness Website Surface
• Must not depend on: apps/platform runtime changes
• Primary audience: MSP operators, IT admins, Microsoft 365 admins, security reviewers, Datenschutz stakeholders, procurement teams, DACH Mittelstand buyers, and enterprise IT evaluators
• Public message: Tenantial provides a public documentation surface that explains Microsoft 365 provider context, permissions and data access thinking, policy evidence, drift, backup and recovery semantics, findings and accepted risk, review packs, evaluation readiness, and known limitations in careful public language
• Out of scope: platform help center behavior, CMS workflows, authenticated docs, search backend, AI support, support ticketing, provider runtime logic, Microsoft Graph permission execution, review-pack generation, data export, fake AVV/TOM downloads, fake permission matrices, fake screenshots implying unavailable features, root workspace contract changes, and non-website implementation work

Goals

• G1: Create one public documentation landing point that is easy to discover from the existing website.
• G2: Organize docs around durable buyer and operator questions rather than internal implementation modules.
• G3: Help security, Datenschutz, procurement, and technical evaluators understand provider access, data categories, trust boundaries, and governance concepts.
• G4: Explain evidence, drift, recovery context, findings, accepted risk, review packs, and evaluation scope in plain public language.
• G5: Keep the docs honest by avoiding fake completeness, fake downloadable artifacts, or unverified product, provider, compliance, or automation claims.
• G6: Leave space for future docs expansion such as detailed permission matrices, onboarding guides, localization, search, or versioning without requiring them now.

Non-goals

• No apps/platform changes.
• No in-product contextual help.
• No CMS or editorial backend.
• No authenticated documentation area.
• No search backend or AI assistant.
• No support ticketing or customer portal workflow.
• No API documentation.
• No Microsoft Graph runtime logic or consent flow.
• No onboarding runtime.
• No RBAC runtime changes.
• No review-pack generation or export behavior.
• No real AVV, TOM, DPA, or compliance-document download unless those assets already exist as verified public truth.
• No fake PDFs, placeholder links, fake screenshots, or href="#".
• No Google, AWS, or multi-cloud availability claims unless those providers are already verified public truth.

Spec Scope Fields (mandatory)

• Scope: N/A - public website IA outside authenticated workspace, tenant, or canonical product flows
• Primary Routes: preferred public docs family /docs; German-first alternative /dokumentation only if current site conventions already support that route style; child routes only when the current website supports nested documentation pages cleanly
• Data Ownership: no workspace-owned, tenant-owned, provider-owned, or customer-owned product data is created, changed, or persisted by this feature
• RBAC: public read-only content only; no membership, role, capability, authorization, or authenticated product behavior changes

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: N/A - no tenant-context or canonical product view is introduced
• Explicit entitlement checks preventing cross-tenant leakage: N/A - no authenticated tenant, workspace, provider, or customer data is involved

Cross-Cutting / Shared Pattern Reuse (mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write N/A - no shared interaction family touched)

• Cross-cutting feature?: yes
• Interaction class(es): public navigation, footer links, homepage or platform teasers, trust and evaluation crosslinks, docs cards or section lists, FAQ entries, and metadata
• Systems touched: current public website shell, route conventions, navigation, footer, related public pages, reusable section or card components, and metadata helpers
• Existing pattern(s) to extend: existing public page layouts, card or grid patterns, teaser conventions, link conventions, and metadata conventions
• Shared contract / presenter / builder / renderer to reuse: current website content structures and reusable public presentation components
• Why the existing shared path is sufficient or insufficient: the site already contains adjacent public story surfaces; this feature needs one coherent documentation destination inside that shell rather than a separate docs product or a new design system
• Allowed deviation and why: a dedicated docs route family is allowed when the current IA supports it because the knowledge base must be inspectable as a distinct public destination rather than scattered across unrelated marketing sections
• Consistency impact: Microsoft 365-first language, provider-connection wording, permissions and data-access boundaries, trust references, evidence and drift language, and known-limitations posture must stay aligned across docs and the existing public pages that link into them
• Review focus: verify that docs add technical clarity beyond marketing pages, all links are real, categories stay understandable, and copy does not drift into unverified provider, compliance, permissions, automation, or download claims

OperationRun UX Impact (mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an OperationRun; otherwise write N/A - no OperationRun start or link semantics touched)

• Touches OperationRun start/completion/link UX?: no
• Shared OperationRun UX contract/layer reused: N/A
• Delegated start/completion UX behaviors: N/A
• Local surface-owned behavior that remains: none
• Queued DB-notification policy: N/A
• Terminal notification path: N/A
• Exception required?: none

Provider Boundary / Platform Core Check (mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write N/A - no shared provider/platform boundary touched)

• Shared provider/platform boundary touched?: yes
• Boundary classification: mixed public vocabulary only
• Seams affected: provider-connection framing, permissions and data-access explanations, Microsoft 365-first scope language, policy evidence vocabulary, drift and recovery wording, and related trust references
• Neutral platform terms preserved or introduced: provider connection, permissions and data access, data categories, policy evidence, drift detection, review pack, accepted risk, recovery context, evaluation scope, and known limitations
• Provider-specific semantics retained and why: Microsoft 365 remains explicit because the current public scope is still Microsoft 365 governance and the docs must feel concrete for current evaluators
• Why this does not deepen provider coupling accidentally: the feature introduces no runtime provider contracts, capability registries, permission matrices, or shared product abstractions; it only explains current public scope in website copy
• Follow-up path: follow-up-spec only if later work adds verified multi-provider public truth or a detailed permission matrix

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

N/A - public website documentation surface only; no authenticated operator-facing product surface is changed.

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing product surface change.

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

N/A - public buyer-facing and evaluator-facing copy only; no operator diagnostics, support mode, or raw evidence surface is added.

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing product surface change.

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing product surface change.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: no
• New enum/state/reason family?: no
• New cross-domain UI framework/taxonomy?: no - the feature reuses the current public website shell and existing content patterns
• Current operator problem: public evaluators, security reviewers, and technical buyers still cannot self-serve deeper Tenantial questions without reconstructing answers across multiple pages or manual follow-up conversations
• Existing structure is insufficient because: the homepage, trust, provider, use-case, review, and evaluation pages answer adjacent questions, but they do not form a durable knowledge base with clear categories and bounded concept pages
• Narrowest correct implementation: one public docs hub plus either nested child pages or clearly separated landing-page sections, depending on the current website IA
• Ownership cost: public copy, metadata, and related-link accuracy must stay aligned with actual product scope, trust posture, and public route availability
• Alternative intentionally rejected: adding only incremental FAQ or teaser content to existing pages, because that would keep deeper answers fragmented and harder to review
• Release truth: current public website truth only; no runtime product promise or future abstraction is introduced

Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.

Canonical replacement is preferred over preservation.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Browser
• Validation lane(s): browser, confidence
• Why this classification and these lanes are sufficient: public website quality is proven by reachable routes, understandable documentation IA, readable desktop and mobile layouts, real navigation and footer entry points, static claim scans, and any existing website build or check commands that validate the public site
• New or expanded test families: none beyond website-only static checks and any existing public-site smoke coverage
• Fixture / helper cost impact: none
• Heavy-family visibility / justification: none
• Special surface test profile: N/A - public website surface
• Standard-native relief or required special coverage: ordinary public-site coverage only; verify docs landing reachability, child-page reachability when implemented, crosslink integrity, claim-boundary compliance, and absence of placeholder links
• Reviewer handoff: confirm only website-facing files change, no apps/platform files change, the docs route follows current IA, categories and related links are real, and copy stays bounded around permissions, trust, evidence, drift, recovery, limitations, and FAQ
• Budget / baseline / trend impact: none expected
• Escalation needed: follow-up-spec only if later work introduces search, localization, authenticated docs, downloadable trust artifacts, or detailed provider-permission matrices
• Active feature PR close-out entry: Smoke Coverage
• Planned validation commands:
  • inspect root and website package manifests before running website commands
  • run only existing website check, build, or test commands if present
  • run static scans for placeholder links, banned internal phrases, and unsupported public claims in website source and committed public assets
  • run desktop and mobile browser smoke for the docs landing page, relevant child pages, and any homepage, platform, trust, provider, review, or evaluation crosslinks if local preview is available

User Scenarios & Testing (mandatory)

User Story 1 - Evaluators Find A Coherent Docs Hub (Priority: P1)

An MSP operator, Microsoft 365 admin, or technical evaluator opens the public docs and quickly understands where to start, which concepts are documented, and where to go for provider, permissions, evidence, drift, recovery, and review questions.

Why this priority: The core value of the feature is creating one inspectable documentation destination instead of leaving deeper questions fragmented across marketing pages.

Independent Test: Can be fully tested by opening the docs landing page and confirming that the hero, category structure, and real links make the knowledge base understandable without needing other pages first.

Acceptance Scenarios:

1. Given a first-time evaluator lands on the docs area, When they scan the hero and category grid or sections, Then they understand that the docs cover evaluation, provider context, permissions and data access, trust, evidence, drift, recovery, review packs, limitations, and FAQ.
2. Given a visitor wants to start with basics, When they choose the getting-started entry point, Then they find a concise explanation of what Tenantial is, what it is not, and how to approach an initial evaluation.
3. Given a visitor enters the docs from another public page, When they arrive at the docs landing page, Then the route, page title, and categories clearly identify the destination as documentation rather than another generic marketing section.

---

User Story 2 - Security, Datenschutz, And Procurement Reviewers Get Bounded Answers (Priority: P1)

A security reviewer, Datenschutz stakeholder, or procurement contact can use the public docs to understand what kind of provider access, data-processing context, trust references, limitations, and review materials are relevant before deeper due diligence.

Why this priority: Public trust and evaluation friction often appears in review and procurement conversations rather than in product positioning alone.

Independent Test: Can be fully tested by reviewing the permissions, data-processing, trust, evaluation, limitations, and FAQ docs to confirm that they answer common review questions without overclaiming.

Acceptance Scenarios:

1. Given a security or Datenschutz stakeholder opens the docs area, When they review the permissions and data-processing topics, Then they can identify the relevant categories of questions without seeing an invented permission matrix or unverified compliance promise.
2. Given a procurement or vendor-management stakeholder looks for review readiness information, When they open the evaluation, review-pack, or FAQ pages, Then they understand which topics belong in a pilot or trust review and which artifacts depend on actual product scope.
3. Given a reviewer scans the docs for legal or security claims, When they read the trust and limitations language, Then they do not see fake certifications, fake downloads, or misleading statements about customer data, hosting, or automatic compliance.

---

User Story 3 - Technical Buyers Understand Provider, Evidence, Drift, And Recovery Concepts (Priority: P2)

A technical owner can understand how Tenantial frames Microsoft 365 provider connections, permissions and data access, policy evidence, drift detection, backup context, recovery context, findings, accepted risk, and review packs without reading internal architecture language.

Why this priority: The docs must deepen technical understanding, not just restate marketing claims.

Independent Test: Can be fully tested by opening the concept pages and confirming that each topic explains practical meaning, boundaries, and related links in buyer-friendly public language.

Acceptance Scenarios:

1. Given a technical evaluator wants to understand provider access, When they open the provider or permissions docs, Then they see careful language about scope, consent, read-oriented access, and recovery-adjacent access without an unverified full permission list.
2. Given a visitor wants to understand evidence and drift, When they open the relevant docs pages, Then they see how those concepts relate to findings, reviews, and decision support without promises of real-time detection or automatic remediation.
3. Given a visitor wants to understand backups and recovery, When they open the relevant docs page, Then they learn that recovery depends on scope, dependencies, evidence, and review context rather than a one-click rollback promise.

---

User Story 4 - Visitors Reach Docs Through Real Information Architecture (Priority: P2)

A visitor should be able to reach the docs from the public navigation, footer, homepage, platform page, trust page, evaluation page, or related concept pages wherever those entry points already exist and support a real link.

Why this priority: The documentation only reduces evaluation friction if it is discoverable from the public pages where buyers already start.

Independent Test: Can be fully tested by following every new teaser, nav link, footer link, or related link added by the feature on desktop and mobile and confirming that each destination is real.

Acceptance Scenarios:

1. Given a visitor uses a docs link from the homepage, platform, trust, evaluation, or another related public page, When they follow that link, Then they land on the docs hub or a real child page.
2. Given a visitor uses the footer or navigation to open docs, When they arrive on the destination, Then the route resolves cleanly and the docs IA is readable.
3. Given a related destination does not exist in the current site IA, When the implementation is completed, Then the missing link is omitted rather than replaced with a placeholder.

Edge Cases

• What happens when the current website does not support nested docs routes cleanly? The implementation must deliver a single real docs landing page with internal sections instead of inventing fake child links.
• What happens when some related public pages from earlier specs are missing or renamed locally? Only real routes may be linked, and the IA decision must document which crosslinks are included or omitted.
• What happens when a detailed Microsoft 365 permission matrix is not verified as public truth? The docs must describe permission thinking and readiness at a bounded level and defer exact matrices.
• What happens when trust artifacts such as AVV, DPA, or TOM are not available as public downloads? The docs may reference their status or review path, but they must not imply self-service downloads.
• What happens when the current site language strategy is German-first, English-first, or mixed? The docs route, labels, and slugs must follow the existing site convention rather than introducing a new localization foundation.
• What happens when documentation copy starts to sound like internal specs or architecture notes? Public-facing language must win over internal jargon even when the underlying concept is technically complex.

Assumptions

• The current public website can support one real documentation destination without changing root workspace contracts.
• Microsoft 365 remains the first public provider focus for current documentation scope.
• Related public pages from Specs 404 through 409 exist in some form, but any missing route may be omitted from crosslinks.
• Detailed permission matrices, downloadable trust packs, localization, search, and versioned docs are future expansions rather than required v1 scope.
• The current website has existing layout, link, and metadata conventions that the docs area should reuse rather than replace.

Requirements (mandatory)

This feature introduces no Microsoft Graph calls, no write/change product behavior, no persistence, no OperationRun flow, no RBAC mutation, and no provider runtime capability. Its only additions are bounded public documentation routes or sections, discoverability links, metadata, and claim-safe copy that translate current public product truth into a durable docs IA.

Functional Requirements

Documentation Destination And IA

• FR-001: The implementation MUST remain public-website-only and MUST NOT require apps/platform runtime changes.
• FR-002: The public website MUST provide one dedicated documentation destination for deeper evaluation and governance questions.
• FR-003: The preferred route family MUST be /docs, with /dokumentation allowed only when the existing website conventions are German-first and route-compatible.
• FR-004: The implementation MUST follow current local route conventions rather than introducing a new routing foundation.
• FR-005: The implementation MUST document whether the site supports nested docs child pages or only a single landing page with category sections.
• FR-006: The documentation IA MUST be organized around durable user questions rather than internal implementation modules.

Required Documentation Topics

• FR-007: The docs landing experience MUST expose the following topic categories: Getting Started; Microsoft 365 Provider Connection; Permissions and Data Access; Data Processing and Trust; Policy Evidence; Drift Detection; Backups, Versioning and Recovery; Findings, Exceptions and Accepted Risk; Review Packs and Decisions; Evaluation and Pilot; Known Limitations; FAQ.
• FR-008: If nested routes are supported by the current website IA, each required topic MUST have its own real public child page.
• FR-009: If nested routes are not supported without broad refactoring, the landing page MUST present the required topics as clear sections and MUST NOT advertise fake child routes.
• FR-010: The docs landing page MUST explain that the area supports evaluation, provider understanding, trust review, governance concepts, and buyer readiness.

Page And Section Content

• FR-011: The Getting Started content MUST explain what Tenantial is, what it is not, why Microsoft 365 is the first public focus, and how a first evaluation can begin.
• FR-012: The Microsoft 365 Provider Connection content MUST explain provider connection concepts, scope, consent thinking, and the difference between read-oriented and recovery-adjacent scenarios without exposing internal platform implementation.
• FR-013: The Permissions and Data Access content MUST explain why permissions are discussed, how access depends on scope, and why exact permission matrices may be documented separately when verified.
• FR-014: The Data Processing and Trust content MUST explain relevant data categories, governance metadata versus productive content, trust references, and review boundaries without making unverified privacy or compliance claims.
• FR-015: The Policy Evidence content MUST explain evidence in relation to policy state, findings, reviews, and recovery context rather than reducing the concept to screenshots.
• FR-016: The Drift Detection content MUST explain expected versus observed state, why drift matters, how drift relates to findings and review, and what drift detection does not mean.
• FR-017: The Backups, Versioning and Recovery content MUST explain versioned policy-state thinking, backup context, recovery context, limitations, and the rejection of blind-restore framing.
• FR-018: The Findings, Exceptions and Accepted Risk content MUST explain those governance concepts, their review context, and their practical meaning without implying automatic approvals or legal determinations.
• FR-019: The Review Packs and Decisions content MUST explain review-pack structure, executive summary, evidence basis, findings, accepted risks, and decision summary in customer-safe terms.
• FR-020: The Evaluation and Pilot content MUST explain how an evaluation can start, who should be involved, what scope matters, and how trust and security review fit into the path.
• FR-021: The Known Limitations content MUST state clearly what Tenantial does not replace or automate and MUST do so in a confident, non-apologetic tone.
• FR-022: The FAQ content MUST answer recurring buyer questions about scope, permissions, automation, helpdesk expectations, admin-center replacement, review packs, evidence, drift, pilot readiness, and review materials.

Claim Safety And Public Language

• FR-023: Public docs copy MUST use buyer-friendly and operator-friendly language such as documentation, provider connection, permissions and data access, policy evidence, drift detection, recovery context, findings, accepted risk, review packs, evaluation, and known limitations.
• FR-024: Public docs copy MUST NOT use internal architecture or spec jargon as primary explanatory language.
• FR-025: The documentation MUST NOT invent a complete Microsoft permission list unless that list already exists as verified public truth.
• FR-026: The documentation MUST NOT claim DSGVO compliance, ISO certification, NIS2 compliance, Germany-only hosting, absence of customer data, absence of personal data, Google support, AWS support, multi-cloud support, real-time drift, automatic remediation, automatic restore, one-click restore, immutable backups, audit guarantees, or compliance guarantees unless explicitly verified public truth exists.
• FR-027: When product scope is still bounded or route-specific, the docs MUST use careful language such as scope-dependent, review-based, customer-safe, or available when supported by product scope.
• FR-028: The docs MUST avoid fake completeness; when a topic is not fully public yet, the page or section MUST still be useful and honest about scope boundaries.

Navigation, Discovery, And Related Links

• FR-029: The docs area MUST be reachable from at least one existing public-site entry point such as navigation, footer, homepage, platform, trust, provider, review, or evaluation surfaces.
• FR-030: Every teaser, related link, CTA, nav item, and footer item added by this feature MUST resolve to a real destination; placeholder links and href="#" are forbidden.
• FR-031: Related links inside docs pages MUST point only to public routes that actually exist in the current site.
• FR-032: If the current site supports a sidebar or secondary docs navigation pattern, it MAY be used, but only if it remains simple and consistent with current conventions.

Metadata And Future Expansion

• FR-033: The docs landing page and any real child pages MUST provide page-specific titles and descriptions that match the documentation topic and avoid unsafe claims.
• FR-034: If the current website supports canonical metadata, the docs landing page and child pages MUST reuse that support.
• FR-035: The docs IA MUST leave room for future additions such as permission matrices, onboarding guides, localization, search, review-pack examples, and versioned docs without requiring those capabilities in this feature.

Verification Expectations

• FR-036: Implementation work MUST verify current local website conventions for routing, navigation, footer, metadata, reusable content structures, and language strategy before choosing the final docs IA shape.
• FR-037: Implementation work MUST run only website commands that already exist in the repository.
• FR-038: Implementation work MUST statically scan website source and any committed public output for placeholder links, banned internal phrases, and unsupported claims introduced by this feature.
• FR-039: If local preview is available, implementation work MUST browser-smoke the docs landing page, relevant child pages, and the real crosslinks added by this feature on desktop and mobile.
• FR-040: Final implementation reporting MUST state the chosen docs route, whether child pages were created, which website commands were run, and confirm that apps/platform remained untouched.

Key Entities (include if feature involves data)

• Documentation Hub: The primary public entry point for deeper Tenantial documentation, category discovery, and related public links.
• Documentation Category: A durable topic grouping such as permissions, trust, evidence, drift, recovery, or FAQ that reflects a user question rather than an internal module.
• Documentation Page: A bounded public concept page or section that explains one topic in claim-safe language and links to relevant adjacent public pages.
• FAQ Entry: A concise public answer to a recurring buyer, evaluator, or reviewer question.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: A first-time public evaluator can identify where to start and which documentation topic answers their question within 60 seconds of opening the docs landing page.
• SC-002: Each required documentation category is reachable in one click or one in-page jump from the docs landing experience.
• SC-003: Security, Datenschutz, procurement, and technical evaluators can each find at least one clearly relevant public docs path without encountering placeholder links or fake downloadable artifacts.
• SC-004: Static verification finds zero new placeholder links, banned internal phrases, or unsupported public claims introduced by this feature.
• SC-005: Desktop and mobile smoke checks confirm that the docs landing page and any real child pages remain readable and navigable.
• SC-006: The final implementation changes only website-facing files and leaves apps/platform untouched.