Seven products, one shared declarative domain.

It's the combination most projects start from: you describe the domain, the backend runs it and the interfaces generate from the same declaration. It's enough for complete business applications — jobs, matters, shipments, procedures — and for customer- or citizen-facing portals.

Orchestration isn't needed until you want something to act on data autonomously. Many projects stay here for a long time, and that's fine: AI makes sense once the domain is well described, not before.

Added when a natural-language request needs to become an action rather than an answer. The step isn't an integration: the orchestrator reads the capability registry the backend already produces, so it knows what exists and what is permitted without anyone restating it.

The path that works best is gradual: first read-only on operational questions, which carries zero risk and exposes the limits of the domain description; then low-impact actions with human confirmation; then the rest.

These aren't runtime components but tools that act earlier: gathering process knowledge in a structured way, and turning existing documentation into a blueprint to review.

They're needed in projects where understanding the domain is the long part — typically modernising historic systems and large organisations with unwritten processes. In a small, well-understood project they add little, and it's right to know that.