# 0001: Four-layer platform boundary

- Status: Accepted
- Date: 2026-07-12

## Context

Ekklesia must remain understandable and independently extensible after many backend capabilities
and user experiences have been added. A conventional feature monolith or UI-bearing plugin model
would couple business behavior to a particular presentation framework.

## Decision

> **Partial correction — see [ADR 0021](0021-modules-as-hostable-products.md).**
> The rule below that a module exposes "data and behavior only" and that "every renderer and UI
> concern belongs to a surface" was superseded by ADR 0021: a module may own its own UI and ship it
> as part of an independently versioned product, hostable by Ekklesia and, later, by a standalone
> host. The four ownership layers themselves, Core's feature-agnostic role, the prohibition on Core
> importing a module, and every other boundary in this ADR remain accepted and unchanged — Core
> still owns the containing application shell and all platform policy. This section is left as
> originally accepted, as the historical record.


Adopt four explicit ownership layers: Core orchestration, backend Modules, presentation Surfaces,
and declarative Surface Builder configuration. Begin as a modular monolith. Modules expose data
and behavior only; every renderer and UI concern belongs to a surface.

## Alternatives

- A conventional feature monolith was rejected because boundaries degrade as features grow.
- UI-bearing plugins were rejected because they bind capabilities to frameworks and visual design.
- Initial microservices were rejected because distribution adds failure modes before contracts
  have been proven.

## Consequences

Stable contracts, SDK ports, generated composition, and automated boundary checks are required.
Some integrations take more deliberate service or event design, but modules and surfaces remain
independently replaceable.

## Migration implications

Future boundary violations must move behind public contracts before the affected package can be
treated as independently installable or upgradeable.