diff --git a/hibernate-envers/src/main/java/org/hibernate/envers/query/criteria/internal/EntityTypeAuditExpression.java b/hibernate-envers/src/main/java/org/hibernate/envers/query/criteria/internal/EntityTypeAuditExpression.java
index 74d627c6cc..fc92d8591e 100644
--- a/hibernate-envers/src/main/java/org/hibernate/envers/query/criteria/internal/EntityTypeAuditExpression.java
+++ b/hibernate-envers/src/main/java/org/hibernate/envers/query/criteria/internal/EntityTypeAuditExpression.java
@@ -37,6 +37,20 @@ public class EntityTypeAuditExpression implements AuditCriterion {
 			String baseAlias,
 			QueryBuilder qb,
 			Parameters parameters) {
+		// todo: add contextual detail about query generation
+		//
+		// Take an example situation where a non-audited entity extends an audited-entity and uses the
+		// AuditEntity#entityType method with the non-audited entity.  It would stand to reason that
+		// it makes sense that we'd throw a NotAuditedException here rather than apply the restriction
+		// anyway and return no results?
+		//
+		// Knowing whether EntityTypeAuditExpression is for an association traversal or part of the
+		// entity inheritance criteria of the root entity would drive how we'd either throw an
+		// exception or be lenient and permit adding the expression without validation.
+		//
+		// For now, we're just going to allow adding the criteria without any validation because the
+		// code needs to support both traversal paths without any clear distinction.
+		//
 		String effectiveAlias = alias == null ? baseAlias : alias;
 		String effectiveEntityName = entityName;
 		if ( enversService.getEntitiesConfigurations().isVersioned( effectiveEntityName ) ) {