One platform family. Explicit boundaries.#
Matrix combines an application framework with independent services for application launch, workflow execution and a common inbox. Build your domain logic in code. Compose only the modules and service integrations that your application needs.
| Component | Start with this question | Read next |
|---|---|---|
| Matrix Core and modules | How do I compose a business application and enforce its policies? | Core architecture |
| Portal and identity | How do users discover applications and enter their own authenticated sessions? | Portal integration |
| Workflow | Who owns process progress, service operations and human decisions? | Workflow architecture |
| Messages | How do events and tasks become actionable items in a shared inbox? | Inbox and actions |
| Infrastructure | How do approved releases use shared identity, transport and data services? | Infrastructure boundaries |
Follow an implementation path#
- Define the business journey. Name the actors, data owners, allowed operations and expected failure behavior. Select a bounded first use case.
- Choose and pin the capability baseline. Check the actual package and template versions before taking a code example into a Consumer. A new source feature is not automatically in a published package.
- Compose the application. Add API and Web modules, typed adapters and server-side policies. Integrate Portal, Workflow or Messages where the requirement calls for them.
- Verify the contract. Exercise allowed and denied behavior, uncertain outcomes and recovery. Preserve the evidence with the selected release.
- Deploy and operate. Use a reviewed installation plan, separate runtime and migration authority, and verify the resulting installation.
The capability map connects these decisions to the detailed guides. The source document index gives a summary of every engineering reference used by this site.
Why Matrix exists#
As artificial intelligence models continue to evolve, companies are increasingly shifting the development of custom-tailored software solutions to their internal teams.
We support this transition by providing an opinionated development platform, tools, and engineering expertise that help organizations manage the uncertainty of probabilistic AI-driven development while ensuring security, consistency, and verifiable software quality.
Read implementation status correctly#
Documented describes an architecture or integration contract in the reviewed source. Release-dependent means that package publication, installed versions or integration acceptance affect availability. Planned identifies a design direction that should not be treated as an implemented capability.
The guides preserve the distinction between source implementation, a published artifact, application adoption and an accepted installation. They do not turn local test evidence into a production capacity or availability claim. Start with the architecture, then use the component guide for the exact ownership and verification boundary.