Architecture v0.1

SVTV Architecture Blueprint

A concise draft of the SVTV Studios and SVTV Platform ecosystem: what belongs to the studio, what belongs to the platform, and how applications, projects, knowledge systems, infrastructure, and shared services relate.

Version
1.0 Draft
Status
Draft
Owner
SVTV Studios
Last Architectural Review
2026-06-27

Blueprint draft

SVTV Platform contains Applications, Projects, Knowledge, Infrastructure, and Shared Services

  1. Vision

    • SVTV Studios should grow as a connected creative and technical ecosystem, not as a pile of unrelated tools.
    • The architecture favors small, useful foundations that can mature into durable studio systems over time.

  2. The Studio

    • SVTV Studios is the parent studio, company, and creative identity. It owns the brand, the long-term direction, and the standards for how work is produced.
    • The studio is broader than any one application, project, encyclopedia, or platform surface.

  3. The Platform

    • SVTV Platform is the private internal operating environment for studio tools, planning, project support, and shared technical systems.
    • The platform contains Applications, Projects, Shared Services, Infrastructure, and Knowledge systems. It supports studio work; it is not the public studio website.

  4. Hub

    • Hub is the launcher and train station for the SVTV Platform. Hub is not the destination; Hub helps users find the correct internal destination.
    • Hub now has its own internal entry point at hub.svtvstudios.com while still opening the SVTV Platform Hub route at /.
    • Its job is orientation, routing, and quick access to applications, projects, knowledge systems, and operational areas.

  5. Architecture

    • Architecture is the blueprint and engineering planning area for SVTV systems. It records the intended shape of the studio ecosystem before individual tools expand.
    • Architecture should stay practical: decisions, boundaries, relationships, and operating principles matter more than ceremony.

  6. Infrastructure

    • Infrastructure is the technical foundation: GitHub, DigitalOcean, Caddy, PM2, GitHub Actions, DNS, deployment, recovery, and related operational pieces.
    • Current routing keeps svtvstudios.com as the public static Studio Website, hub.svtvstudios.com as the internal Hub entry point, and glde.svtvstudios.com as the internal GLDE entry point.
    • The infrastructure goal is reproducibility. A lost or replaced server should be recoverable from documented steps and versioned assets.

  7. Internal Domain Boundary

    • Any subdomain of svtvstudios.com is considered an internal SVTV Studios platform area.
    • Public-facing experiences exist only beneath the primary domain, using paths like svtvstudios.com/... when public surfaces expand.
    • Internal applications should assume authenticated studio use. Future authentication should protect all subdomains.
    • Internal applications should never be architected as public websites.

  8. Applications

    • Applications are internal tools and modules that help SVTV Studios operate, such as GLDE, Hub, Architecture, Asset Library, MCP, Build Dashboard, Analytics, and future studio utilities.
    • Applications and Projects are peers inside the SVTV Platform, not a parent-child chain. A single application may support many projects.

  9. Projects

    • Projects are creative productions and products made by SVTV Studios, such as Gridiron Life, NTBTS, future games, and other public-facing works.
    • A project may use many applications for planning, documentation, assets, analytics, publishing, or production support.

  10. Knowledge

    • Knowledge systems are encyclopedias, documentation systems, references, and structured records. They often live where Projects and Applications meet.
    • GLDE is the Gridiron Life Development Encyclopedia: the first internal application and knowledge system within the SVTV Platform. GLDE supports the Gridiron Life Project; it is not the parent platform itself.

  11. Shared Services

    • Shared Services are cross-application systems that may eventually include auth, users, search, assets, MCP, permissions, logging, notifications, and backups.
    • These services should be introduced only when multiple applications or projects genuinely need them.

  12. Design Principles

    • Interfaces should feel clear, calm, and useful. Internal tools should prioritize orientation, readability, and repeatable workflows.
    • Public-facing studio surfaces may be more atmospheric, but operational surfaces should stay focused and easy to scan.

  13. Engineering Principles

    • Build small, working foundations before adding abstractions. Prefer clear boundaries, readable code, and deployable increments.
    • Preserve existing routes and behavior unless the architecture intentionally changes them.

  14. Studio Principles

    • The platform should protect the studio history, creative context, and production memory behind SVTV work.
    • Tools should make the studio more capable without turning every idea into unnecessary process.

  15. Relationships

    • SVTV Studios owns the SVTV Platform. The SVTV Platform contains Applications, Projects, Shared Services, Infrastructure, and Knowledge systems.
    • Applications are internal tools. Projects are creative productions and products. A Project may use many Applications, and an Application may support many Projects.
    • Knowledge often lives where Projects and Applications meet. GLDE is both an Application and the Knowledge system for the Gridiron Life Project.

  16. Roadmap

    • Near term: stabilize the Studio Website, GLDE, Hub, Architecture, and deployment foundations.
    • Next: add clearer application boundaries, authentication, persistent storage, asset organization, and shared services as real needs emerge.

  17. Version History

    • 1.0 Draft establishes the first written blueprint for the SVTV Studios / SVTV Platform ecosystem.
    • Phase 2.7 documents Hub as its own internal subdomain without changing the PM2 process topology.
    • Phase 3.2 adds the Internal Domain Boundary as permanent architectural guidance for internal platform subdomains.
    • Future versions should record meaningful architectural shifts, not routine implementation details.