StellaOps Platform

Audience: platform engineers, architects, and module owners who need the cross-cutting picture — how the Stella Ops services fit together and which contracts they all honour.

The Platform module has two jobs. As documentation, it owns the system-wide architecture, the shared contracts (Aggregation-Only Contract, telemetry, security), and the guardrails that bind every service together. As runtime, it ships the Console backend (StellaOps.Platform.WebService) and applies only Platform-owned startup migrations. Every other deployable converges and reports its own database from its own host.

Runtime services

The Platform module ships two runnable services (in addition to its cross-cutting docs and shared libraries):

• StellaOps.Platform.WebService— the Console backend. A router-microservice (registered as serviceName: "platform") that reaches the gateway over the Valkey/Redis transport, authenticates Authority-issued bearer tokens, serves the anonymous frontend config (GET /platform/envsettings.json), owns the shared.tenants directory, and exposes aggregation/read-model, federation/NIS2 telemetry, crypto/KEK admin, and GDPR subject-access surfaces. It no longer hosts a cross-module migration face: /api/v1/admin/migrations was retired by SPRINT_20260722_026 CM-2, and each service now converges and reports its own database. See architecture.md for the full runtime, scope, and endpoint detail.
• StellaOps.Platform.Analytics— analytics models/services library consumed by the WebService analytics endpoints.

Shared libraries: StellaOps.Platform.Persistence (Platform-owned migrations plus a shrinking local/DR registry used by the explicit CLI recovery path, never as cross-service schema authority) and StellaOps.Platform.ActorIdentity.Client.

Responsibilities

• Maintain the system-wide architecture overview and integration diagrams.
• Capture Aggregation-Only Contract guidance and migration playbooks.
• Document shared services such as API gateway, tenancy, quotas, and offline posture.
• Define and maintain Platform Service API contracts and aggregation behavior.
• Coordinate platform-wide epics and compliance checklists.

Key components

• Platform architecture summary + StellaOps.Platform.WebService runtime (config composition, shared.tenants, federation/NIS2 telemetry, migration host, authorization scopes/policies, endpoint surface) in architecture.md.
• System-wide integration topology in architecture-overview.md.
• Platform Service API definition in platform-service.md; full route reference in api-reference.md and machine-readable specs under openapi/.
• Cryptography & compliance first-run defaults in cryptography-and-compliance.md; per-region routing in regional-crypto-route-matrix.md.
• Tenant-scoped endpoint classification in tenant-endpoint-classification.md; condensed reference in reference-architecture-card.md.
• Aggregation-Only Contract guidance: ../aoc/README.md (and ../aoc/architecture.md).
• High-level references: ../../ARCHITECTURE_REFERENCE.md, ../../ARCHITECTURE_OVERVIEW.md.

Integrations & dependencies

• All StellaOps services via shared contracts (AOC, telemetry, security).
• DevOps for release governance.
• Docs guild for cross-module onboarding.

Operational notes

• Module spans architecture governance and the Platform Service aggregation APIs.
• Glossaries and guardrails cross-linked across docs; keep AOC references current.
• Status mirrors: sprint file and docs/modules/platform/TASKS.md.

Backlog references

• Module task tracker: TASKS.md (in this directory).
• Active and future platform epics: sprint files under ../../implplan/SPRINT_*.md.

Implementation Status

Current Objectives

• Maintain deterministic behaviour and offline parity across releases
• Keep documentation, telemetry, and runbooks aligned with latest sprint outcomes
• Coordinate cross-cutting contracts and guardrails across all modules

Epic Milestones (cross-module coordination roadmap)

These are platform-wide coordination statuses, not the implementation state of the Platform runtime itself (see architecture.md for verified runtime detail).

• Epic 1 – AOC enforcement: authoritative guardrail docs, schemas, verifier checklists (ongoing maintenance)
• Epics 2 & 4 – Policy Engine/Studio: platform-wide governance, approvals, tenancy scopes (coordinated)
• Epic 5 – SBOM Graph Explorer: shared contracts for graph indexing and overlays (defined)
• Epics 6-11 – Cross-cutting contracts: Explorer, Lens, AI, Orchestrator, Notifications alignment (active)

Coordination Approach

• Review the module AGENTS.md before starting new work
• Sync with cross-cutting teams via sprint files in ../../implplan/SPRINT_*.md
• Update the implementation plan when scope, dependencies, or guardrails change
• Mirror status across the sprint tracker and this module’s TASKS.md

Key Documentation Assets

• architecture-overview.md— system-wide integration diagrams.
• AOC references — Aggregation-Only Contract guidance and migration playbooks.
• Offline guidance — sealed-mode deployments and air-gap operation procedures.
• Glossaries and guardrails — cross-linked across all module documentation.

Technical Notes

• Platform owns the StellaOps.Platform.WebService runtime (Console backend) and StellaOps.Platform.Analytics, plus cross-cutting docs
• Focus on architectural governance and cross-module aggregation / read-model endpoints
• The runtime fails fast when Platform:Storage:PostgresConnectionString is absent outside Testing; synthetic compatibility route groups are mapped only in Development/Testing (see architecture.md)
• Ensure discoverability of Offline Kit and AOC references from this README and architecture.md

Epic alignment

Platform keeps guardrails consistent across the suite, aligning with the Aggregation-Only Contract reference, the Policy and Policy Studio guides, the Graph / Vulnerability Explorer documentation, and the Orchestrator, Advisory AI, and Notifications implementation plans. See the Epic Milestones roadmap above for the coordination status of each cross-module epic.