ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects 1 Releases Wiki Activity
platform-dev
TenantAtlas/specs/345-platform-productization-readiness-roadmap-reconciliation-gate/app-boundary-map.md
ahmido 1f3a8b5ed9 docs: platform productization readiness and roadmap reconciliation (spec 345) (#417) 
Added comprehensive documentation and planning artifacts for the platform productization readiness and roadmap reconciliation.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #417
2026-06-02 10:47:29 +00:00

2.9 KiB
Raw Permalink Blame History

App Boundary Map — Spec 345

Branch: 345-platform-productization-readiness-roadmap-reconciliation-gate
Date: 2026-06-02

Belongs in /platform

  • Internal MSP/operator control-plane work:
    • Governance Inbox and Decision Register follow-through
    • Findings, accepted-risk, and review/workflow closure
    • Provider connections, onboarding readiness, required permissions, and safe integration recovery
    • Evidence overview, review packs, stored reports, audit log, and retained-artifact truth
    • Monitoring, operations, alerts, and cross-domain indicator semantics
    • Customer-safe output preparation inside operator-managed flows
  • Practical rule:
    • customer-safe summaries may be rendered inside /platform while the operator plane is still the product of record
    • this does not make /platform the customer portal

Belongs in /customerportal

  • External customer-consumption surfaces that should consume already-stable platform outputs instead of re-implementing them:
    • customer-facing review history
    • customer-facing evidence/review-pack download center
    • external accepted-risk / acknowledgement consumption if ever moved outside the operator plane
    • branded customer document library and follow-up intake
    • any future Virtual Consultant / External Portal Guidance runtime
  • Boundary rule:
    • do not implement these inside Filament /platform
    • prepare the output contracts first in /platform, then expose them in /customerportal

Belongs in /website

  • Public marketing and acquisition work:
    • pricing
    • product pages
    • public docs or public knowledge pages
    • lead capture / waitlist / demo request
    • public trust-pack style content
  • Boundary rule:
    • no marketing/public lead-gen surface should be hidden inside the operator platform backlog

Belongs in /system

  • Platform-operator and break-glass work:
    • support-access governance and support access history
    • workspace directory / closure / commercial truth mutation surfaces
    • global ops and break-glass tooling
    • other platform-owner-only administration that should not live in tenant/workspace operator flow

Deferred (explicit)

  • /customerportal as a product line is explicitly deferred until the operator platform outputs are calmer and more stable.
  • Customer billing/self-serve portals are deferred; current commercial truth belongs in operator/system workflows.
  • External portal guidance, customer self-serve evidence history, and customer-facing workflow intake stay deferred even when customer-safe summaries already exist in /platform.
  • AI-visible customer-facing portal behavior stays deferred until a first governed runtime AI consumer exists inside the platform.

Current Boundary Judgment

  • The next spec should stay in /platform.
  • The next spec should not start /customerportal.
  • Existing customer-safe review work inside /platform should be treated as operator-managed output preparation, not as a hidden portal bootstrap.