On Fri, Apr 10, 2015 at 12:25 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: Yep. This is exactly what Envers does. Currently, I have Envers using org.hibernate.boot.spi.AdditionalJaxbMappingProducer for this purpose. That was a transitory fix since Envers already build DOM (represeting the hbm.xml of the entities they want to add) and because I did not want to waste cycles atm rewriting all of Envers bootstrapping to "be more correct" and generate model classes directly. We could start to develop the more correct approach for you to use. Basically you would generate org.hibernate.mapping model instances yourself and have them added to the "metadata sources". Either way, you'd also be interested in looking at their "flush cycle hooks" as you would probably have similar requirements. Bonus brownies if we could figure out a way to mark these as This does not exist today. Blocking them from being used in associations would be very detrimental to Envers if we were ever to expose this generically. But your other 2 points would work wonderfully with Envers too. We can add that for post-5.0 if you wish. I don't see it as critical. As far as querying, I'd suggest marking these are not allowing implicit polymorphism (are they returned, e.g., from a query like `from java.lang.Object`?). If you do go this route, this is pretty easy now in 5.0. You'd simply obtain the Database from the Metadata (preferrably while building, so specifically from the org.hibernate.boot.spi.InFlightMetadataCollector). drives schema export, update, etc.