Platform Architecture
Summary
This thread explains LKCI as a composable operational platform. It focuses on layers, monorepo posture, one database with explicit responsibilities, and the platform map.
Reader Question
What architectural shape makes the platform composable across data, services, jobs, integrations, UI surfaces, and human repair?
Surface Or Workflow
The reader enters through the static site and starts with the platform map, layers, and monorepo posture. This thread is the architecture spine for that path.
Lifecycle
The story starts with platform principles, moves through layers and monorepo composition, explains conceptual data boundaries, and then links to operations and service-boundary pages.
Child Threads
- Platform Journey: parent reader path.
- Platform Map: entry map.
- Platform Layers: layered architecture.
- Monorepo As Operational Platform: repo-as-platform framing.
Implementation Boundaries
The page uses only public-reviewed strategy and architecture pages. It does not expose internal route, job, package, or operational inventory.
Tradeoffs
This architecture page omits many implementation details. That keeps the external story useful for readers who do not have the codebase open.
Visual
The current visual is a public-reviewed graph neighborhood. The intended visual is a public architecture map showing layers, services, jobs, review surfaces, and public export filtering.
Source Evidence
docs/public/platform-journey-strategy.mddocs/engineering/start/platform-map.mddocs/engineering/architecture/platform-layers.mddocs/engineering/architecture/monorepo-as-operational-platform.mddocs/engineering/architecture/one-database-many-responsibilities.md