# 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

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.