About AXIOMS
Who we are, why this specification exists, and how Cells turn architecture into evidence.
AXIOMS Community
Architects, engineers and tools working together on a living standard.
AXIOMS is being built by a small but stubbornly obsessive community: human architects, long–time practitioners, and the software tools (including AI systems) that help us reason about complexity.
The initial draft of the specification was authored and edited by Enrique Regis Pascalin Romo, a senior software architect with decades of experience in large-scale systems. Around that work we are assembling what we call the AXIOMS Community: people and tools committed to turning architecture from opinion and fashion into contracts and evidence.
- We have seen the “sea of frameworks” up close. Microservices vs monoliths, Hexagonal vs Clean, DDD vs “just ship it” – often treated as religions instead of choices.
- We believe architecture needs a unit, not a trend. AXIOMS defines the Cell as that unit and insists that every interaction is explicitly contracted and testable.
- We refuse architecture without proof. If there is no fitness function, no CTK scenario, and no telemetry to back it, we treat the claim as a hypothesis, not as architecture.
Our goal with AXIOMS and GSSATO is simple to state and hard to achieve: provide a technology-agnostic, evidence-driven, certifiable architecture standard that any team, in any stack, can adopt without joining a particular “school of thought”.
Core Axioms (A1–A31)
GSSATO Dimensions
Runtime Planes (Data, Control, Knowledge)
Conformance Test Kit (CTK)
AXIOMS in One Page
A contract- and evidence-driven meta-architecture for modern systems: Cells, planes, contracts, fitness functions and conformance tooling, all described by a normative specification.
Conceptual Model
AXIOMS defines a clear set of primitives:
- Cells as the fundamental architectural and deployment unit.
- Planes (Data, Control, Knowledge) to reason about runtime concerns.
- Contracts (RPC, events, policy, observability) as the only way Cells interact.
- Fitness Functions to turn architectural intent into executable checks.
These primitives host and organize existing styles: microservices, modular monoliths, Hexagonal, Clean, DDD and others become coordinates inside the model, not competing religions.
Normative Specification
AXIOMS is a written standard, not just a pattern catalog. The specification provides:
- Axioms A1–A31 written as MUST/SHOULD rules for Cells.
- Guidance on contracts, evolution rules and Cell anatomy.
- Language Profiles to map code quality and tooling expectations per stack.
- Conformance levels (Base / Hardened) for incremental adoption.
The long-term goal is formal recognition as an industry-grade standard suitable for ISO/ANSI-style certification.
Evidence & Conformance
Architecture is considered incomplete without evidence. AXIOMS builds verification in:
- Fitness functions express architectural invariants as tests.
- Conformance Test Kit (CTK) scans code, contracts and telemetry.
- CI/CD reference pipeline runs AXIOMS checks continuously.
- Knowledge artifacts document what each Cell claims to be and prove.
Instead of “diagrams + faith”, teams get reproducible, machine-checked reports about their architecture.
The Cell
A self-contained, polymorphic unit that can host any serious architectural style while still obeying the same contracts and evidence rules.
The unit that replaces “service”, “module” and “microservice” debates.
In AXIOMS, a Cell is the smallest unit of architecture that matters. It is at the same time a logical concept and a deployable artifact: one clear responsibility, bounded surfaces, internal structure, contracts and knowledge all shipped together.
- Polymorphic Internals. Inside a Cell you can choose Hexagonal, Clean, layered, event-sourced, DDD-heavy or minimalistic approaches. AXIOMS does not dictate the style – it constrains the edges.
- Strictly Bounded Surfaces. All interaction goes through explicit, versioned contracts (RPC, events, policy, observability). No hidden database sharing, no “just call this class in another module”.
- Evidence Included. Each Cell ships with tests, fitness functions, specs, manuals and telemetry definitions so that its behavior can be verified in isolation and in the wider system.
- Topology-agnostic. Collections of Cells can form modular monoliths, classic microservice meshes, serverless graphs or hybrids. The unit does not change; only the topology does.
In the AXIOMS specification you will find a full Cell Anatomy section: surfaces, state machine, modules, error taxonomy, concurrency and backpressure – all described so that Cells are predictable, evolvable and observable.
What AXIOMS Focuses On
The specification is intentionally narrow in syntax but deep in concern: clear boundaries, verifiable qualities, and long-term sustainability of complex systems.
GSSATO + AXIOMS
Classification meets construction: GSSATO describes the architectural universe; AXIOMS tells you how to build inside it with contracts and evidence.
From “What exists?” to “What must be true?”
GSSATO 2025 is our taxonomy of software architecture: five dimensions (Knowledge, Structural, Epistemological, Process, Quality) that describe how a system is conceived, built and evolves. It is a diagnostic lens – a way to classify any style, framework or methodology without taking sides.
AXIOMS sits on top of that taxonomy as a construction framework. It does not just name dimensions; it defines axioms that Cells must obey and provides a Conformance Test Kit to verify them. Where GSSATO gives you coordinates, AXIOMS gives you blueprints and instruments.
Dimensions as Metadata
Each Cell can declare its position in the GSSATO dimensions (for example, D2: topology, D3: principles, D5: quality attributes) as part of its knowledge artifacts.
Axioms as Guarantees
AXIOMS A1–A31 transform those coordinates into rules: isolation, explicit contracts, observability, zero-trust security, evolution constraints and more, all testable by CTK scenarios and fitness functions.
One Ring, Many Styles
DDD, Hexagonal, Clean, event-driven, CQRS, serverless – instead of competing dogmas, they become reusable patterns that Cells can adopt while still remaining AXIOMS-compliant and measurable.
How to Get Involved
AXIOMS is an open technical specification. You can read, critique, implement and extend it – or simply use it as a lens to design your next system more deliberately.
Read the Specification
Start with the AXIOMS Architecture Specification draft and the GSSATO 2025 guide. They describe the concepts, axioms and reference structures in detail.
Apply It to a System
Model your existing system as Cells, identify contracts, define fitness functions and connect them to your CI/CD. AXIOMS is most useful when it meets real-world constraints.
Contribute Feedback
Share issues, critiques and proposals through the AXIOMS repositories and community channels. The standard evolves as we gather more evidence from real implementations.