This seems to be the perfect use case for implementing a simple rules engine.

In your case, the rules are just "validation rules". Each rule needs to contain the code for the validation (which may throw an exception when the constraint is violated), as well as the documentation of the specific rule. That would allow you

• to execute the rules during validation in your application

• run a custom documentation generator tool which extracts the docs from the rule objects and includes them into a summary

In case you are implementing and maintaining the rules in code (and not in some DSL), this can be pretty simple and straightforward to implement. Something along the lines of (using C# like pseudo code):

  class ValidationRule
  {
        public abstract void Execute();   // throws an exception when rule is violated
        public abstract string Description();  
  }

  class RoofTileCheck
  {
       public RoofTileCheck(Roof roof)
       {
           this.roof=roof;
       }
       public override void Execute()
       {
           if(roof.HasTiles && roof.Hooktype==null)
                throw new ValidationException("Roof has tiles but no hook type");
       }
       public override string Description()
       {
            return "If your roof has tiles, you need to specify a roof hook type";
       }
  }

If all of your 250 rules need different code, this would end up in 250 different classes, but I guess in reality there will probably fewer of them, since some of them can probably be implemented using the same class, just with different constructor parameters.

Finally, you need a factory for instantiating the rule objects for your main application's rule execution loop, and another one for your documentation generator. Maybe it is the same factory if you have a 1:1 correspondence between the specific rules in your application and the docs, and a different one if some rules will only be required as some representatives in the docs.

Of course, this is just a rough guideline and you may need to flesh out a lot of details here, but I gues you got the idea.

This seems to be the perfect use case for implementing a simple rules engine.

In your case, the rules are just "validation rules". Each rule needs to contain the code for the validation (which may throw an exception when the constraint is violated), as well as the documentation of the specific rule. That would allow you

• to execute the rules during validation in your application

• ro create a custom documentation generator tool which extracts the docs from the rule objects and includes them into a summary

In case you are implementing and maintaining the rules in code (and not in some DSL), this can be pretty simple and straightforward to implement. Something along the lines of (using C# like pseudo code):

  class ValidationRule
  {
        public abstract void Execute();   // throws an exception when rule is violated
        public abstract string Description();  
  }

  class RoofTileCheck
  {
       // roof can be null in case only the description is required
       public RoofTileCheck(Roof roof)
       {
           this.roof=roof;
       }
       public override void Execute()
       {
           if(roof.HasTiles && roof.Hooktype==Hooktype.None)
                throw new ValidationException($"Roof {roof.ID} has tiles but no hook type");
       }
       public override string Description()
       {
            return "If your roof has tiles, you need to specify a roof hook type";
       }
  }

If all of your 250 rules need different code, this would end up in 250 different classes, but I guess in reality there will probably fewer of them, since some of them can probably be implemented using the same class, just with different constructor parameters.

Finally, you need a factory for instantiating the rule objects for your main application's rule execution loop, and another one for your documentation generator. Maybe it is the same factory if you have a 1:1 correspondence between the specific rules in your application and the docs, and a different one if some rules will only be required as some representatives in the docs.

Of course, this is just a rough guideline and you may need to flesh out a lot of details here, but I gues you got the idea.