This is the walkthrough into AEco's Modularization System.

AEco follows an axiomatic-oriented framework where modulars (file, axiomatics, etc) are categorized based on the type of content they represent. Everything is broken down and traced based on the axiomatics they're built off of; AEco's formatting system is the example of this Paper_Formatting_System.

What Is A Modular

A modular is any discrete unit of content in the AEco Skeleton. This includes Axiomatic Files, derivative papers, model definitions, and epistemic constructs. Every modular occupies exactly one position in the skeleton's link-tree and has exactly one parent, except for Axiomatic Files which sit at the root of their respective branch.

Modulars are not interchangeable and are not summaries of one another. Each modular contributes something that did not exist in its parent; a new definition, a derived model, a refined concept; while remaining strictly bounded by what was inherited from above.

Why Modularization

AEco spans economics, governance, epistemics, and their intersections under an AI-as-baseline assumption. Without a strict modularization system, concepts bleed into one another, definitions drift across files, and the framework loses internal consistency. Modularization enforces coherence at the file level so the skeleton remains coherent at the system level. Every concept in AEco is traceable. Every definition has a source. Every model has a lineage.

Modular Categories

Axiomatic Files:

Root-layer modulars. Contain primitive definitions, foundational models, and baseline epistemics for their domain. Self-contained by design; they do not inherit from any other modular. All files in a branch trace their lineage back to the Axiomatic File at its root. Paper_Formatting_System.

Derivative Modulars:

All non-axiomatic files. Inherit from a parent modular and contribute new conceptual work derived from that inheritance. Must declare all dependencies explicitly in their header. May extend inherited concepts only through declared refinement or derivation.

Modular Integrity

A modular is considered intact when:

• Its dependencies are fully declared in the header
• Every concept it uses is traceable to an inherited source
• Any divergence from an inherited concept is explicitly noted as a refinement or derivation.
• It contributes at least one definition, model, or derived construct not present in its parent

A modular is considered malformed when:

• Its dependency declaration is absent or incomplete
• It introduces concepts with no traceable lineage
• It duplicates a parent definition without declaring divergence
• It cites a descendant as a dependency

Malformed modulars cannot be referenced by downstream files until corrected.

Extending The Skeleton

The skeleton grows by adding new modulars at the appropriate tier and branch. Before adding a modular:

• Identify which branch and tier it belongs to
• Identify its parent modular
• Confirm all required concepts exist in the inherited tree If a required concept does not exist, trace it back to the Axiomatic File or submit an update to the relevant root before proceeding

No modular may be added without a valid parent. No concept may be introduced without a traceable lineage. The skeleton grows strictly downward and outward — never upward, never in isolation.