Architecture Constraints

This section describes the fundamental boundaries and technical requirements that Framework M must adhere to.

2.1 Technical Constraints

Category	Requirement	Constraint
Language	Python 3.12+	Only async Python is supported.
Composition	Typed DI	All components must be wired through the DI Container + Wiring.
Contracts	Protocols	Components must depend only on Protocols (Interfaces) for infrastructure concerns.

2.2 Core Philosophy

1. Only async Python and DI wiring are irreplaceable: Every other part of the system—from the database to the event bus—must be replaceable, extended, or composed via standardized Protocols.
2. Open-Closed Principle: The framework's core contracts (Protocols) are closed for modification but open for extension via third-party adapters (adapters for NATS, Kafka, Redis, etc.) and entrypoints.
3. Zero-Cliff Future: No architectural design should lead to a "cliff" where a developer is forced to rewrite the entire application for common scaling or technology shifts (e.g., swapping a SQL database for a high-performance engine like TigerBeetle).

2.3 Operating Constraints

• Stateless by Default: All components must be designed for stateless execution across distributed environments (e.g., Kubernetes).
• Metadata-Driven: All business entities (DocTypes) must be defined as metadata (Pydantic-based), enabling cross-tooling between Frontend, Backend, and CLI.