Ecosystem / Ecosystem guide
Three Layers, One Workflow: OS, Platform, and Framework
A good business tool needs a place to work, an interface that makes the work clear, and a system that carries it out. Semitexa gives those three jobs distinct names.
Three layers, three questions
Think about a person reviewing an approval. They need to find the task, understand the details, and submit a decision. It is tempting to call all of that “the app.” Separating the responsibilities makes it easier to design the experience and to reason about the code behind it.
OS: where work has a home
Semitexa OS is the experience layer. Its job is the shape of a working day: how someone finds their projects, changes focus, and keeps context while moving between tools. A useful OS decision might be whether an approval is visible beside the project it belongs to, or how the workspace helps someone return to an unfinished task.
That is a product question before it is a component question. A polished button cannot repair a workflow that leaves people lost. The OS site presents this operating surface as a product vision; the layer map describes the intended responsibility, not a claim that every possible workflow is already shipped end to end.
Platform: how the work is presented
Semitexa Platform is the interface layer: reusable fields, data views, product shells, and interaction patterns. If the same kind of approval appears in several products, this layer is where the visual grammar should remain consistent. The Platform showcase demonstrates server-owned rendering, components, deferred regions, and live updates.
Reusability is useful only when it clarifies the task. A field should make its label, help, validation, and state legible. A data view should make scanning and acting on a row predictable. Platform supplies that common language while each product keeps its own purpose.
Framework: how the decision runs
Semitexa Framework is the execution layer. In its typed PHP flow, a payload describes an incoming request, a handler makes the application decision, and a resource returns the result. Server-rendered pages, events, tenancy, and long-running work can share that explicit architecture.
For an approval, application code still has to check who may act, apply the business rule, store the result, and decide whether an event should follow. A reusable interface does not make that decision for the server. The Framework site lets you inspect working routes and demos when you want to see how the underlying request and response fit together.
One workflow, three decisions
Imagine an approval inbox. This is an illustrative feature, not a claim that a shared inbox is already deployed across all three sites.
- Experience: place the inbox where a person can find it in the context of their project, and make the next action obvious.
- Interface: show the request in a readable data view, present the decision with a consistent control, and explain any validation error.
- Execution: accept the action through a typed route, check permission and state in application logic, then return the updated result or publish follow-up work.
The boundaries help when a feature changes. If people cannot find the inbox, revisit the experience. If every inbox looks different, revisit the interface. If the action can be applied twice or by the wrong person, revisit execution. The separation turns a vague “the app feels wrong” into a question a team can answer.
Where to start exploring
Begin with the layer that matches your question. Explore the OS vision to see the working environment, the Platform showcase for reusable interface patterns, and the Framework installation guide when you are ready to trace or build the PHP flow. These sites currently show different parts of the ecosystem; the three-layer map gives them a shared design vocabulary.