Documentation

Build on a deterministic infrastructure runtime.

Architecture references, API contracts, and module development guides for teams building high-trust products on top of Altason.

Documents

Sections

Primary Audience

Systems builders

Platform

Using the platform (builders)

Projects, modules, core module selection, and publishing workflows.

Reference

This guide describes how builders use the platform day-to-day.

Create a project (slug becomes its subdomain on the project-site host).
Project status:
- draft: not publicly available
- live: available to end-users
- archived: disabled

Modules are enabled per project from:

Builder Marketplace (/modules → open module details → enable per project)
Inside a project, via Project Modules navigation (preferred operational flow)

Enabling a module attaches its capabilities to that project:

Each project must have one core module.

Why:

Landing page (/) uses core module template
Site shell can adapt layout rules based on the core module
Authenticated end-user area is template-defined (for example /portal, /courses, /products)

Storage:

Content/publishing is module-owned:

Project owners manage public landing content from Project settings → Landing Page.

Generic fields: headline, subheadline, CTA.
Template-specific fields: per-section visibility and copy controls defined by the active template.
Example (AI SaaS): hero badge text + visibility and hero stats visibility are configurable directly in landing settings.

End-user login is provided by end-user-auth.
Authenticated post-login area is provided by template + module site routes.

End-user session cookie: project_session
End-user pages must resolve project context via resolveProjectContext() (handles cache misses)

/dashboard is now a compatibility redirect.
Do not build new module features around dashboard aggregation.

If legacy projects still use dashboard section descriptors, treat them as transitional only.