A-Concept Runtime Composition: Features as Extension Points, Not Implementations

The Assumption Most OOP Codebases Are Built On

Every developer trained in object-oriented programming has internalized the same mental model: entities own their behavior. A User object has a save() method. A PaymentService has a processPayment() method. The behavior is attached directly to the class, and the class, not the broader system, is the unit of abstraction.

This worked well in single-process applications where the entire system shared one runtime. The User.save() method had exactly one implementation, defined once on the class, executed everywhere it was called. The mental model and the runtime model were the same.

Distributed systems quietly broke this assumption a decade ago. The moment a User exists simultaneously on a Google integration service, a database service, and a frontend application, the question "what does User.save() mean?" has three different answers, and the OOP model has no clean way to express that. The industry workaround has been to fragment the abstraction: UserDTO here, UserEntity there, UserModel on the third service, with mapping code linking them at every boundary.

A-Concept does not work around the assumption. It replaces it.

The A-Concept Model, in Five Primitives

A-Concept's runtime model is built on five composable primitives. Each has a precise role, and together they describe what every piece of software is, what it does, and how it relates to everything else.

A-Entity: owns the contract

An entity declares the features it participates in, but does not implement them. A User entity says "I have a load feature and a save feature." It does not say what loading or saving means. The entity is a contract, not an implementation.

A-Feature: declares an extension point

A feature is a named, typed extension point declared on an entity. User.save is a feature: a place where some component, somewhere in the system, will provide a real implementation. The feature definition specifies the contract (input, output, constraints). It does not specify the behavior.

A-Component: provides the behavior

A component is a unit of implementation that attaches to one or more feature extension points. A DatabaseUserRepository component attaches to User.save and provides the database persistence logic. A GoogleUserAdapter component attaches to the same feature and provides OAuth-backed loading. Components are adapters; they declare what capabilities they extend.

A-Container: chooses which components exist

A container is a runnable unit (a server, a worker, a frontend bundle) that declares which components participate in it. The server-side container chooses DatabaseUserRepository. The frontend container chooses ApiUserAdapter. The same feature on the same entity behaves differently in each container because the container chose different implementations.

A-Concept: orchestrates the runtime

A concept is the top-level composition that determines which containers exist and how they relate. A single project is one concept. The concept defines the system as a whole; the containers define the runtime topology; the components define the behavior; the features define the contracts; the entities define the domain.

What This Looks Like When You Write It Down

The model becomes clearer with a concrete example. Consider a File entity that needs to behave one way on the client (calling an API) and another way on the server (writing to disk):

// The entity declares its contract. No behavior here.
entity('File') {
    feature('save file') { ref:save }
    feature('load file') { ref:load }
}

// Server-side container picks the disk-based implementation.
container('server') {
    component(ref:diskFileRepository)
    fragment(ref:serverStorage)
    realize(ref:save) { using(ref:diskFileRepository) }
    realize(ref:load) { using(ref:diskFileRepository) }
}

// Client-side container picks the API-based implementation.
container('client') {
    component(ref:apiFileAdapter)
    realize(ref:save) { using(ref:apiFileAdapter) }
    realize(ref:load) { using(ref:apiFileAdapter) }
}

The File entity exists once. The features (save, load) exist once. What varies between client and server is purely which component is in scope to realize the feature, and that variation is explicit, declared, and reviewable.

From the calling code's perspective, this is completely transparent. file.save() works on the client (calling the API) and on the server (writing to disk) without the caller knowing or caring which implementation is active. The behavior is determined by the runtime composition, by which container the call happens in, not by branching in the calling code.

Why This Matters More Than It Looks

The runtime composition model delivers three properties that distributed-system architects spend years trying to achieve with conventional frameworks.

Property architects want	Conventional OOP / DI	A-Concept runtime composition
One shared entity library	Fragments into UserDTO, UserEntity, UserModel with mapping code at every boundary	One entity, one contract, one serialization format. Behavior varies; structure does not
Behavior split across units	Tangled into a single class or hidden behind implicit aspect-oriented magic	Serialization, validation, audit, and persistence components attach to one feature, explicit and typed
Same code across runtimes	Requires runtime branching inside the calling code	user.save() runs in a server, worker, frontend, or CLI; the container picks the implementation

Why This Model Is Better for AI Code Generation

Beyond the distributed-systems benefits, the runtime composition model produces a property that turns out to be unexpectedly valuable for AI-assisted development. When an AI tool is asked to extend a feature (to add a new stage to a save pipeline, to provide a new implementation of a load feature, to introduce a new component), it operates against an explicit, typed, scoped extension surface.

The AI does not have to infer where to attach the new behavior. The architecture tells it. The feature is the extension point. The container is the scope. The component is the unit of attachment. The contract is the entity. Generation becomes a structurally constrained operation rather than a free-form code-completion exercise.

This is why A-Concept and AIS work together as deeply as they do. AIS is the language for declaring the architecture. A-Concept is the runtime that the architecture maps onto. The two are co-designed: AIS does not just describe arbitrary architecture; it describes A-Concept compositions, which means the AI generation step can be deterministic rather than probabilistic.

The Mental Shift Required

Adopting A-Concept asks engineers to make one precise shift in how they think about composition: stop asking "what does this class do?" and start asking "what feature does this entity participate in, and which component provides the behavior?"

In conventional OOP, the typical reflex when adding new behavior is to find the relevant class and add a method to it. In A-Concept, the reflex is different: identify which feature this behavior contributes to (or declare a new feature), identify which component is attaching the implementation (or write a new component), and let the container composition wire them together.

The result is code that is, paradoxically, easier to navigate and easier to modify. Behavior is concentrated in components that have one job. Entities stay clean (they hold contracts, not implementations). Containers are the visible map of which behaviors exist in which runtime; the documentation is the composition itself.

Where This Model Came From, and Where It Is Going

A-Concept did not emerge from a research lab. It emerged from five million lines of production code across two years of building real systems, hitting the limits of conventional frameworks, and progressively isolating the composition primitives that mattered. The five primitives, concept, container, component, feature, and entity, are the irreducible set that fell out of the work.

What the model unlocks, beyond its distributed-systems benefits, is a clean substrate for AI-driven development. When the architecture is composed of typed, scoped, declared primitives, AI tools can generate implementation against it deterministically. The model is what makes AIS, the executable architecture language, viable as a generation target rather than just a documentation format.

For senior architects evaluating the model: the closest analogy is not OOP, not DDD, and not microservices patterns. It is closer to dependency injection taken to its structural conclusion, combined with aspect-oriented composition made first-class. The result is more flexible than OOP, more explicit than DI, and more typed than AOP.

Conclusion

The biggest discovery in the A-Concept design process was not a new pattern. It was that the patterns most distributed-system codebases struggle with, namely entity duplication, behavior fragmentation, runtime branching, and AI generation that produces structurally wrong code, all share a single root cause: the assumption that behavior belongs to entities.

Once behavior is treated as a separately-composed extension to entity contracts, all of these problems become structurally addressable. The composition model gives architects a precise vocabulary, distributed systems a clean topology, and AI tools a deterministic generation surface: three benefits from one design decision.

A-Concept is an open-source framework available as an npm package under the Apache 2.0 license. AIS provides the executable architecture language that targets A-Concept runtimes. ADAAS works with engineering teams evaluating the model for greenfield systems and progressive adoption in existing codebases.