AWA–CORE

A structured web application platform
AWA–CORE is a structured web application platform for building, operating, and extending websites, applications, APIs, and services from governed structured state.
AWA defines and governs what the system is. CORE provides the reusable application capabilities from which installations are built. The Kernel owns the common request and execution foundation beneath both.
Together, they provide a disciplined environment in which application structure, content, configuration, authority, presentation, and behavior remain explicit, inspectable, and portable.
AWA–CORE is not a CMS layered on top of a framework. It is not a collection of plugins connected through conventions. It is an integrated platform in which the same structured state can serve websites, applications, administration interfaces, APIs, automation, integrations, scheduled operations, and other system capabilities.

Why AWA–CORE Exists

Conventional web systems tend to divide the same application across separate layers.
Data lives in one place. Business logic lives somewhere else. Rendering develops its own interpretation of that data. Administration becomes another system. APIs reproduce application logic again. Integrations introduce another representation. Automation adds another.
Over time, each layer develops its own assumptions about what the application is.
AWA–CORE starts from a different premise:
The system should have one explicit, governed understanding of its own structure and state.
Different consumers may present or manipulate that state differently, but they should not need to independently redefine it.
This reduces duplication, limits architectural drift, and makes the system easier to inspect, extend, automate, migrate, and reason about.

Structured State

Structured state is fundamental to AWA–CORE.
Pages, collections, schemas, menus, configuration, application state, permissions, content, and other system definitions can be represented explicitly rather than being buried throughout executable code.
JSON is a primary representation within AWA–CORE, but JSON itself is not the architecture.
The larger principle is:
Code defines capabilities. Structured state defines the installation.
AWA and CORE provide governed structure and reusable capabilities on a common Kernel foundation. An installation determines how those capabilities are assembled, configured, populated, presented, and governed.
This separation allows substantial differences between websites and applications without requiring each installation to become its own fork of the platform.
Structured state is intended to remain readable by humans, applications, automation, development tools, and AI systems.
The Architecture
At its simplest, AWA–CORE can be understood as five layers:
Installation / Application
The particular website, application, service, tenant, or product being operated.
AWA
Defines and governs the structure of the system: pages, collections, forms, applications, users, configuration, presentation, extensions, and administrative state.
CORE
Provides reusable services, domain behavior, handlers, components, rendering capabilities, and other application-level functionality.
Kernel
Owns the common request lifecycle, routing, security boundaries, runtime context, and dispatch beneath both AWA and CORE.
HTTP
The common delivery boundary through which websites, applications, APIs, files, integrations, and other network consumers interact with the runtime.
The same architecture can therefore support different forms of delivery without requiring separate application stacks for each one.
Kernel
The Kernel is the common runtime foundation beneath AWA and CORE.
It owns the fundamental request lifecycle, routing, security boundaries, runtime context, and dispatch required before a request belongs to either AWA or an application capability provided through CORE.
The Kernel is deliberately independent of both. AWA uses it. CORE uses it. Neither defines it.
This separation keeps the lowest-level runtime behavior stable and shared while allowing AWA and CORE to evolve according to their different responsibilities.
The governing principle remains:
Every request belongs to the Kernel before it belongs to AWA, CORE, or the application.
CORE
CORE provides the reusable application capabilities from which AWA–CORE installations are built.
CORE is organized around three primary forms of reusable functionality: Components, Libraries, and Services.
Components are the primary means by which CORE is extended. A Component packages a coherent application capability and may provide the handlers, resolvers, filters, templates, blocks, dynamic blocks, scheduled or cron behavior, and other resources required for that capability. Components use only the mechanisms they need; none of these individual elements is required simply because something is a Component.
Libraries provide reusable code and shared functionality that does not need to operate as a complete Component.
Services provide shared application operations that can be used across Components and other parts of the platform.
This structure allows functionality to be added to CORE as a defined capability rather than patched into the runtime or duplicated across installations.
The Kernel provides the execution foundation. CORE provides the reusable functionality that runs on it.
AWA
AWA is the structural, administrative, and authoring environment of the platform.
AWA is organized around three primary forms of functionality: Mods, Libraries, and Services.
Mods are the primary means by which AWA is extended. A Mod packages a coherent AWA capability and participates in the common AWA environment without requiring changes to AWA itself.
Libraries provide reusable AWA code and shared functionality that does not need to operate as a complete Mod.
Services provide shared operations that can be used across Mods and other parts of AWA.
Through these mechanisms and AWA’s foundational capabilities, AWA provides and governs functionality such as Pages, Collections, Forms, menus, Events, Tasks, updates, tenancy, installation configuration, and other administrative and authoring functionality.
AWA also provides the environment through which Applications are installed and managed.
Components extend CORE. Mods extend AWA.
Applications
Applications are installable units of functionality within AWA–CORE.
An Application may consist of a single Mod or multiple Mods, a single Component or multiple Components, or a combination of Mods and Components, depending on what the Application needs to provide.
Components supply reusable CORE functionality. Mods supply AWA functionality. An Application can package either or both into one installable capability.
Applications are installed and managed through AWA and operate within the installation’s existing Kernel runtime, authentication and authority environment, structured state, configuration, and application context.
An Application may operate within AWA, provide its own dedicated interface, or operate as an installable web application or PWA where appropriate.
Applications package functionality without requiring a separate architecture.
Authentication
Authentication is a foundational AWA capability rather than an installable Mod.
Auth establishes identity and authenticated session context and can serve both System Users, who operate and administer AWA–CORE, and Application Users, who interact with applications built on the platform.
Authentication is separate from user administration and authorization. It establishes identity; the surrounding user, application, authority, and tenant context determines what that identity represents and what it is permitted to access or do.
System Users are users of the AWA–CORE system itself, such as administrators, editors, staff, developers, and operators.
Application Users are users of applications built on AWA–CORE, such as customers, members, clients, subscribers, or other application-specific participants.
Tenants should not be presented as a third user type. A Tenant is a governed organizational/application context within which application functionality, data, configuration, and Application Users may be scoped.
Auth establishes who you are. Authority determines what you may do. Tenant context can determine where and in whose context you do it.
Themes
Themes provide the presentation layer of an AWA–CORE installation independently of AWA and CORE functionality.
A Theme defines the visual presentation of an installation while consuming the structured output produced by the platform.
AWA can govern aspects of page structure and layout, but the Theme itself remains an independent presentation concern rather than belonging to AWA or CORE.
This separation allows presentation to change without redefining the installation’s structured state or underlying application functionality.
Structure and functionality can remain stable while presentation changes independently.

Extensibility Without Patching

AWA–CORE is designed to be extended without modifying the platform indiscriminately.
Extend by design, not by patch.
Different kinds of extension have different responsibilities.
The Kernel provides the common request and execution foundation.
Components extend CORE with reusable application capabilities.
Mods extend AWA with structural, administrative, and authoring capabilities.
Applications package one or more Components, one or more Mods, or a combination of both, and are installed and managed through AWA.
Themes remain an independent presentation concern.
Libraries and Services provide reusable functionality within CORE and AWA as appropriate.
Installation data and configuration determine how these capabilities are assembled for a particular installation.
Private or installation-specific functionality can coexist with reusable platform functionality without requiring the upstream platform to become installation-specific.
The objective is not to eliminate custom development. It is to give custom development a defined place to live.

pantaServ — Serve Everything

AWA–CORE follows a broader runtime principle called pantaServ:
Anything that can be delivered through HTTP can be served through one disciplined runtime.
A webpage, application screen, API response, collection record, administrative operation, generated document, file, PWA endpoint, integration, or machine-facing resource does not require an entirely separate architectural universe.
Each is a different expression of a governed system responding through HTTP.
This allows AWA–CORE installations to evolve from websites into applications and services without abandoning the architecture that originally created them.

Websites Are Only One Expression

AWA–CORE can operate conventional websites, but it is not limited to them.
The same underlying architecture can support:
  • Public websites
  • Content-driven sites
  • Administrative systems
  • Business applications
  • Progressive Web Apps
  • Multi-tenant applications
  • Product and catalogue systems
  • Project and workflow systems
  • APIs
  • External integrations
  • Automation
  • AI-assisted operations
Not every installation uses every capability.
The purpose of the architecture is to allow those capabilities to coexist when they are required without turning the installation into a collection of disconnected systems.
Scheduled Operations
AWA–CORE is not limited to work initiated by a browser or HTTP request.
Its scheduled execution system allows applications and platform services to perform governed operations automatically through cron, including recurring processing, synchronization, maintenance, notifications, publishing, cleanup, update-related operations, and other installation-defined jobs.
Scheduled operations use the same platform capabilities and structured state as interactive operations. Work can therefore occur when required by time or system policy rather than requiring a user or external request to initiate it.
HTTP can initiate work. Time can initiate work too.
Integrations
AWA–CORE is designed to participate in larger systems rather than treating external services as isolated add-ons.
Integrations can bring external data and services into an installation, expose platform capabilities to external systems, synchronize state, and connect application behavior to APIs and other service boundaries.
External information can be normalized into governed AWA–CORE structures so imported or synchronized data can participate in the same Collections, Pages, Applications, authority, automation, and presentation mechanisms as information created within the installation.
Integrations extend the system without requiring external data or services to become a separate architectural silo.
Authority and Governance
AWA–CORE treats authority as part of the architecture rather than an afterthought added independently by each feature.
Authentication establishes authenticated identity and session context.
Authority determines what an authenticated identity is permitted to access or do.
AWA defines and governs authority policy, while the Kernel provides the common security and request boundaries through which requests are admitted and dispatched.
Applications, components, routes, data operations, and administrative capabilities operate within that authority model.
Tenant context may further scope where and in whose context that authority applies.
Installation-specific policy can then define narrower rules without replacing the common security architecture.
This becomes particularly important when the same installation serves public users, authenticated customers, staff, administrators, applications, APIs, automation, and external services.
Tenants and Installation Context
AWA–CORE can support installations in which different customers, organizations, projects, or operational contexts share platform capabilities while retaining governed separation.
Tenant context can determine available functionality, data visibility, applications, configuration, and other installation behavior.
Tenancy is therefore not simply a visual grouping mechanism. It participates in application authority and runtime behavior.
This allows the same platform to support both single-purpose installations and more complex multi-tenant systems.
Updates, Verification, and Releases
AWA–CORE is developed from a canonical upstream platform and distributed to individual installations through controlled, versioned releases.
Updates are a built-in platform capability rather than an informal process of copying changed files between installations.
The update system tracks installed packages and versions, evaluates available changes, plans updates, and applies them while preserving the distinction between shared platform code and installation-specific state.
Platform changes are supported by revision history, built-in tests, and Sanity verification so development, deployment, troubleshooting, and update operations can be checked against known system expectations.
This allows the upstream platform to continue evolving while installations retain their own data, configuration, presentation, extensions, and private functionality.
An AWA–CORE installation is designed to be maintained and upgraded, not abandoned at the version on which it was first built.
Built to Be Inspectable
AWA–CORE favors explicit architecture over hidden behavior.
Its structure should be understandable not only by the developers who originally created an installation, but also by future developers, administrators, automation systems, development agents, and AI systems asked to analyze it.
Schemas should describe data.
Configuration should describe configuration.
Authority should be explicit.
Extensions should identify their responsibilities.
Runtime behavior should follow predictable paths.
Documentation should describe the architecture that actually exists.
The result is a system intended to be reasoned about rather than merely operated.
Documentation
AWA–CORE documentation is published openly in machine-readable and human-readable formats.
Architectural documentation covers the platform itself as well as major subsystems including the Kernel, CORE, AWA, Pages, Collections, Forms, Applications, Components, Mods, Themes, Tenancy, APIs, security, releases, and other platform capabilities.
Markdown source documentation is made directly available so developers and AI systems can inspect the technical material without depending exclusively on presentation-oriented webpages.
The documentation is intended to make a practical question answerable:
Can AWA–CORE support this application, and how would that application fit into its architecture?
AWA–CORE
AWA defines and governs what the system is.
CORE provides reusable application capabilities.
The Kernel owns the common request and execution foundation.
pantaServ allows that system to serve everything.
One governed architecture, expressed through websites, applications, APIs, services, and whatever comes next.