What is the Chaos MVC?
ChAoS MVC is a lightweight, modular PHP MVC framework designed around a protected Core architecture and an outward-growing application model.
The framework separates the infrastructure required to operate ChAoS MVC from the modules, themes, pages, and other functionality developed for the applications that use it.
Its development principle is simple:
Rather than continually modifying framework infrastructure to accommodate application-specific requirements, ChAoS MVC encourages developers to build functionality outward through modules and other user-space components.
The result is a PHP MVC framework intended to remain understandable, modular, and predictable as an application grows.
ChAoS MVC provides the fundamental structure expected from an MVC framework without requiring every application to inherit a large collection of features it may never use.
MVC separates an application into distinct responsibilities:
ChAoS MVC builds upon that familiar pattern while keeping application-specific functionality outside the protected framework Core.
The objective is not to make the Core responsible for every possible application feature.
The objective is to provide a stable foundation upon which those features can be built.
Modules are a fundamental part of ChAoS MVC development.
Application-specific functionality belongs in modules rather than being continually added to Core.
A typical module can own its own:
Not every module requires every directory.
A module should contain only the architecture required for the functionality it provides.
This allows a ChAoS MVC installation to grow according to the needs of the application rather than according to assumptions made by the framework.
A module may provide something small and specialized or represent a substantial application subsystem.
The architectural boundary remains the same:
The ChAoS MVC Core is treated as infrastructure.
Core responsibilities include framework-level behavior such as routing, authentication, database infrastructure, administrative dispatch, and module lifecycle authority.
Application modules use the interfaces provided by the framework without assuming ownership of those systems.
Access to Core does not constitute authorization to modify Core.
The ability to make a change does not establish authority to make that change.
When an application-specific feature is needed, the first question is therefore not:
The better question is:
If a legitimate framework capability is actually missing, that requirement can be identified and considered as framework development rather than quietly introducing an application-specific modification into Core.
This distinction helps preserve architectural stability as applications grow.
The protected Core architecture does not mean ChAoS MVC applications cannot become complex.
It means complexity has somewhere else to live.
New application functionality grows around the framework rather than continually changing the framework beneath it.
This also establishes clearer ownership.
When functionality belongs to a module, the module can own its implementation, data behavior, documentation, and lifecycle while still operating within ChAoS MVC.
Modularity does not require every module to exist in isolation.
A ChAoS MVC user module can own reusable domain functionality that is consumed by another user module.
This allows shared application capabilities to remain outside Core while still avoiding unnecessary duplication.
Conceptually:
The module that provides the capability retains ownership of its implementation.
The consuming module uses that capability without requiring the functionality to be promoted into Core merely because more than one part of the application needs it.
This allows applications to develop substantial modular systems while preserving the protected Core boundary.
ChAoS MVC favors explicit behavior over hidden lifecycle operations.
For example, database-backed modules distinguish between different operations rather than treating all database changes as the same thing.
A module can own normal operations such as:
Schema installation and updates are deliberate lifecycle operations rather than something a public page should silently trigger.
Complete removal of a module follows the established Core-controlled Nuke lifecycle.
These distinctions make authority and application state easier to understand.
A visitor opening a page should not accidentally install a database.
A GET request should not quietly destroy records.
A module should not decide that it owns framework infrastructure simply because doing so would be convenient.
The framework favors deliberate transitions.
Database-backed modules declare the database resources belonging to their lifecycle.
Module tables follow the module namespace and are declared through the module manifest.
For example:
This provides an explicit relationship between the module and the database resources it owns.
That ownership becomes particularly important when a module is removed.
The module declares what belongs to it.
Core verifies that ownership.
Core performs the final removal.
Security within ChAoS MVC is not treated solely as something added after application development.
Authority boundaries are part of the development model.
State-changing administrative operations require deliberate requests and appropriate protection.
Module-owned mutations use authenticated administrative access, POST requests, CSRF protection, explicit action selection, and validated inputs.
Views render information rather than performing database mutations.
Models own data operations.
Controllers own request behavior.
Core retains framework authority.
These boundaries are intended to make it easier to determine not merely whether something can happen, but which component is actually authorized to make it happen.
ChAoS MVC maintains a human-authoritative development model.
Artificial intelligence tools may assist development where permitted, but AI access does not establish architectural authority.
Protected framework infrastructure remains human-directed.
AI-generated or AI-modified code is expected to remain identifiable and subject to human review.
The principle is straightforward:
The developer remains responsible for understanding, reviewing, testing, and accepting the work incorporated into a ChAoS MVC project.
ChAoS MVC treats documentation as part of development rather than an optional artifact produced after development is finished.
For modules,
Development should distinguish between:
These states are deliberately not interchangeable.
Code that appears correct has not necessarily been tested.
A feature that has been implemented has not necessarily been confirmed.
Documentation provides the record necessary to preserve those distinctions.
A ChAoS MVC application can continue growing without requiring its Core to grow at the same rate.
New requirements can become modules.
Reusable domain capabilities can remain owned by foundational modules.
Presentation can be handled through themes.
Public information can be published through Pages.
Module-owned libraries can provide specialized functionality.
The framework remains the foundation underneath those systems.
This creates a simple architectural direction:
The framework provides the foundation.
The application determines what gets built upon it.
Developers do not need to be ChAoS certified before they begin learning or developing with ChAoS MVC.
They can study the framework, build projects, test their implementations, and learn its development standards.
ChAoS certification is strongly encouraged for developers who intend to contribute work to the broader ChAoS MVC ecosystem.
Certification provides a process through which a developer can demonstrate understanding of the framework, its architecture, its development standards, and its security and authority boundaries.
Forge provides the submission path between a developer's work and those review processes.
A developer can therefore begin with the most useful thing a developer can do:
Build something.
Then test it.
Document it.
Understand why it works.
And, when appropriate, submit that work through Forge.
ChAoS MVC is not built around the idea that a framework should attempt to become every application that might someday use it.
It establishes a foundation and a boundary.
The Core provides framework authority.
Modules provide application functionality.
Themes provide presentation.
Pages provide public content.
Developers build outward.
The architecture remains protected underneath them.
That is the central idea behind ChAoS MVC:
The framework separates the infrastructure required to operate ChAoS MVC from the modules, themes, pages, and other functionality developed for the applications that use it.
Its development principle is simple:
Secure the Core. Grow outwards.
Rather than continually modifying framework infrastructure to accommodate application-specific requirements, ChAoS MVC encourages developers to build functionality outward through modules and other user-space components.
The result is a PHP MVC framework intended to remain understandable, modular, and predictable as an application grows.
A Lightweight PHP MVC Framework
ChAoS MVC provides the fundamental structure expected from an MVC framework without requiring every application to inherit a large collection of features it may never use.
MVC separates an application into distinct responsibilities:
- Models manage application data and persistence operations.
- Views render information for the user.
- Controllers manage request-level behavior and coordinate application operations.
ChAoS MVC builds upon that familiar pattern while keeping application-specific functionality outside the protected framework Core.
The objective is not to make the Core responsible for every possible application feature.
The objective is to provide a stable foundation upon which those features can be built.
A Modular PHP Framework
Modules are a fundamental part of ChAoS MVC development.
Application-specific functionality belongs in modules rather than being continually added to Core.
A typical module can own its own:
user/modules/{module}/
├── controllers/
├── models/
├── views/
├── lib/
├── sql/
├── docs/
└── module.json
Not every module requires every directory.
A module should contain only the architecture required for the functionality it provides.
This allows a ChAoS MVC installation to grow according to the needs of the application rather than according to assumptions made by the framework.
A module may provide something small and specialized or represent a substantial application subsystem.
The architectural boundary remains the same:
The module owns its application behavior. Core owns framework authority.
Protected Core Architecture
The ChAoS MVC Core is treated as infrastructure.
Core responsibilities include framework-level behavior such as routing, authentication, database infrastructure, administrative dispatch, and module lifecycle authority.
Application modules use the interfaces provided by the framework without assuming ownership of those systems.
Access to Core does not constitute authorization to modify Core.
The ability to make a change does not establish authority to make that change.
When an application-specific feature is needed, the first question is therefore not:
How can Core be changed to support this?
The better question is:
How can this functionality be implemented outward from Core using the interfaces ChAoS MVC already provides?
If a legitimate framework capability is actually missing, that requirement can be identified and considered as framework development rather than quietly introducing an application-specific modification into Core.
This distinction helps preserve architectural stability as applications grow.
Secure the Core. Grow Outwards.
The protected Core architecture does not mean ChAoS MVC applications cannot become complex.
It means complexity has somewhere else to live.
Protected Core
│
├── Module
│ ├── Controller
│ ├── Model
│ ├── Views
│ └── Libraries
│
├── Module
│ └── Application Functionality
│
├── Themes
│
└── Pages
New application functionality grows around the framework rather than continually changing the framework beneath it.
This also establishes clearer ownership.
When functionality belongs to a module, the module can own its implementation, data behavior, documentation, and lifecycle while still operating within ChAoS MVC.
Modules Can Work Together
Modularity does not require every module to exist in isolation.
A ChAoS MVC user module can own reusable domain functionality that is consumed by another user module.
This allows shared application capabilities to remain outside Core while still avoiding unnecessary duplication.
Conceptually:
ChAoS MVC Core
│
├── Foundational Module
│ └── Reusable Domain Library
│
└── Consuming Module
└── Uses Foundational Module Capability
The module that provides the capability retains ownership of its implementation.
The consuming module uses that capability without requiring the functionality to be promoted into Core merely because more than one part of the application needs it.
This allows applications to develop substantial modular systems while preserving the protected Core boundary.
Explicit Application Behavior
ChAoS MVC favors explicit behavior over hidden lifecycle operations.
For example, database-backed modules distinguish between different operations rather than treating all database changes as the same thing.
A module can own normal operations such as:
- Create
- Update
- Delete
- Delete Data
- Reset Data
- Recover Data
Schema installation and updates are deliberate lifecycle operations rather than something a public page should silently trigger.
Complete removal of a module follows the established Core-controlled Nuke lifecycle.
These distinctions make authority and application state easier to understand.
A visitor opening a page should not accidentally install a database.
A GET request should not quietly destroy records.
A module should not decide that it owns framework infrastructure simply because doing so would be convenient.
The framework favors deliberate transitions.
Modules Own Their Data
Database-backed modules declare the database resources belonging to their lifecycle.
Module tables follow the module namespace and are declared through the module manifest.
For example:
{
"module": "shop",
"database_tables": [
"shop_products",
"shop_orders",
"shop_order_items"
]
}
This provides an explicit relationship between the module and the database resources it owns.
That ownership becomes particularly important when a module is removed.
The module declares what belongs to it.
Core verifies that ownership.
Core performs the final removal.
Security Boundaries Are Part of Development
Security within ChAoS MVC is not treated solely as something added after application development.
Authority boundaries are part of the development model.
State-changing administrative operations require deliberate requests and appropriate protection.
Module-owned mutations use authenticated administrative access, POST requests, CSRF protection, explicit action selection, and validated inputs.
Views render information rather than performing database mutations.
Models own data operations.
Controllers own request behavior.
Core retains framework authority.
These boundaries are intended to make it easier to determine not merely whether something can happen, but which component is actually authorized to make it happen.
Human-Directed Development
ChAoS MVC maintains a human-authoritative development model.
Artificial intelligence tools may assist development where permitted, but AI access does not establish architectural authority.
Protected framework infrastructure remains human-directed.
AI-generated or AI-modified code is expected to remain identifiable and subject to human review.
The principle is straightforward:
AI tools are assistants, not architects.
The developer remains responsible for understanding, reviewing, testing, and accepting the work incorporated into a ChAoS MVC project.
Documentation Is Part of the Architecture
ChAoS MVC treats documentation as part of development rather than an optional artifact produced after development is finished.
For modules,
docs/CHANGELOG.md serves as a lifecycle record.Development should distinguish between:
- Designed behavior.
- Implemented behavior.
- Tested behavior.
- Confirmed behavior.
These states are deliberately not interchangeable.
Code that appears correct has not necessarily been tested.
A feature that has been implemented has not necessarily been confirmed.
Documentation provides the record necessary to preserve those distinctions.
Development Beyond Core
A ChAoS MVC application can continue growing without requiring its Core to grow at the same rate.
New requirements can become modules.
Reusable domain capabilities can remain owned by foundational modules.
Presentation can be handled through themes.
Public information can be published through Pages.
Module-owned libraries can provide specialized functionality.
The framework remains the foundation underneath those systems.
This creates a simple architectural direction:
Framework Infrastructure
↓
Stable Core Interfaces
↓
Application Modules
↓
Domain Functionality
↓
Application
The framework provides the foundation.
The application determines what gets built upon it.
Developing for ChAoS MVC
Developers do not need to be ChAoS certified before they begin learning or developing with ChAoS MVC.
They can study the framework, build projects, test their implementations, and learn its development standards.
ChAoS certification is strongly encouraged for developers who intend to contribute work to the broader ChAoS MVC ecosystem.
Certification provides a process through which a developer can demonstrate understanding of the framework, its architecture, its development standards, and its security and authority boundaries.
Forge provides the submission path between a developer's work and those review processes.
A developer can therefore begin with the most useful thing a developer can do:
Build something.
Then test it.
Document it.
Understand why it works.
And, when appropriate, submit that work through Forge.
Why ChAoS MVC?
ChAoS MVC is not built around the idea that a framework should attempt to become every application that might someday use it.
It establishes a foundation and a boundary.
The Core provides framework authority.
Modules provide application functionality.
Themes provide presentation.
Pages provide public content.
Developers build outward.
The architecture remains protected underneath them.
That is the central idea behind ChAoS MVC:
Secure the Core. Grow outwards.