The person who knows the industry builds the layer. Not an engineer learning it.

Two things compound in this company, on different clocks.

Inside one institution, understanding accumulates with every meeting. Their decisions, their reasoning, connected and returned when it matters. That is the customer's value and it belongs to them.

Across an industry, something else accumulates. The vocabulary. The decision structures. The conditions that recur in every institution of that kind and in none of another. That is ours, and the next institution inherits it on day one.

It is metadata, not code. A domain layer is a vocabulary, a set of relationships, a process model and a library of conditions worth detecting - written by someone who knows the industry, not implemented by someone learning it. If adding an industry requires changing the platform, we have built it wrong.

We hold ourselves to a number. Pack coverage: the share of a new client's needs the existing layer already meets. If it rises across engagements, this is a platform. If it stays flat, it is a consultancy with good documentation.

What the work actually is: find five conditions that are true across institutions in your industry, invisible today, and that would change a decision if someone saw them. Then work backwards to the vocabulary needed to express them. Start with the patterns, not the ontology - vocabulary first produces a data model; patterns first produce a detection system.