Context
The AI layer introduces a domain/ directory for task-aware logic (e.g., content enhancement).
There is a risk that domain logic may directly fetch CMS data (e.g., via GraphQL or database access), which would invert dependency direction and couple infrastructure to application modules.
If lib/ai becomes aware of CMS data sources, future refactoring or reuse of AI logic outside OneCMS would become difficult.
A boundary must be established between AI domain logic and CMS data access responsibilities.
Decision
AI domain logic inside src/lib/ai/domain must not:
- Fetch CMS data (GraphQL, DB, services)
- Perform database writes
- Depend on CMS modules
Instead:
- CMS modules are responsible for fetching canonical data.
- AI domain functions accept pure structured input.
- AI domain functions return validated structured output.
- CMS modules handle persistence and orchestration.
Dependency direction must remain:
module → lib/ai/domain → lib/ai/core → providers
and never the reverse.
Consequences
Enables
- Clean layering and dependency direction
- Reusable AI domain logic
- Easier testing of AI domain functions
- Isolation of infrastructure from CMS implementation details
Restricts
- AI domain cannot directly query content
- CMS modules must assemble canonical input explicitly
- No implicit data access inside AI layer
Trade-offs Accepted
- Slightly more orchestration code in CMS modules
- AI domain requires well-defined input contracts
Notes
If future AI domains require shared CMS-aware utilities, they must live outside lib/ai and be injected as data, not imported directly.