Platform

The shared platform layer is what allows psi* to package multiple modules without turning the product into a set of disconnected tools.

Core platform ideas

Authoring and published runtime are different concerns

psi* distinguishes between private working-state authoring and the published runtime experience. That matters because operators should be able to shape flows and pages intentionally without editing live production by accident.

The operator shell is part of the product model

Threads, workflow-triggering actions, and review posture are treated as real operating surfaces. They are not just prompt wrappers around isolated APIs.

Workflow execution is durable

The public product pages sit on top of an execution model that expects jobs, approvals, and workflow state to survive beyond one browser tab or one assistant response.

Data and read models are shaped for staged work

The platform is built for multi-stage operating paths. That means data context is expected to move from intake, to routing, to readiness, to outbound review rather than living in one flat table of prompts.

Why this matters in the public site

The product pages intentionally keep the story lighter than the internal system map, but they still need a credible shared foundation. This platform page is where the public docs explain that foundation without requiring every reader to learn the internal route registry.

Current emphasis

The first public version focuses on the product modules and the workflow they create:

Lead Intake
Campaign Manager
Outbound

The broader platform story exists to explain how those modules stay coherent as one operating system.