Definition
An MLE is the smallest bundled unit that still retains logical sense and context when considered across business, design, and development perspectives.
It is not simply the smallest technical artifact, UI part, or backlog item. It is the smallest unit that can still be understood as meaningful in its own context.
Why it was needed
Software work is fragmented into requirements, stories, screens, components, APIs, functions, schemas, tests, and operational processes. Each is useful, but none alone necessarily represents a complete, meaningful unit of the product.
The MLE lens asks what is smallest but still meaningful inside a discipline, and what is smallest but still meaningful when relevant disciplines are considered together.
It prevents both feature buckets that are too broad to explain or govern, and fragments such as a component, endpoint, or field that are too small to retain their purpose.
Early cross-discipline framing
| Discipline | Example MLE |
|---|---|
| UX/UI | User Story |
| Data modelling | Bounded Context |
| Frontend | Element Component |
| Backend | Use Case |
These examples demonstrate the observation that every relevant level has its own minimum logical element. They do not imply a universal one-to-one mapping across disciplines.
From MLE to Capability MLE
The next question was the MLE of a complete software ability. The answer is a Capability MLE: the smallest complete, contextually meaningful ability that produces a meaningful outcome.
Request a moving quote is illustrative: it can be understood, invoked, implemented, tested, and composed independently. Arbitrary implementation pieces lose its purpose context; broadening it into all quote management creates a vague feature bucket.
Why this leads to a CRD
Minimum Logical Element principle
↓
Capability MLE
smallest complete meaningful ability
↓
Capability Requirements Document (CRD)
canonical requirements specification for that ability
↓
Interaction Contract MLEs
smallest executable behaviours
↓
Operational Capability Documentation
current realizationsA CRD does not replace a PRD. A PRD can describe a product or application and link to multiple CRDs. A CRD can also stand independently in a reusable Capability Inventory.
What MLE contributes
- A CRD is not a broad product area or undifferentiated feature request.
- A CRD is not a wrapper around one endpoint, screen, component, or function.
- A CRD carries purpose, boundaries, requirements, contracts, and unknowns—enough context to remain meaningful across realizations.
That is why CRD can become common ground for people, agents, applications, and developers without being tied to one technology or current implementation.
Source and status
This background is derived from Valto Loikkanen’s original Tools of EcosystemOS — TechStack for Ecosystem Orchestration material and subsequent CRD development. It is conceptual background, not a claim that the discipline examples are universal or final.