An implementer creates one entity type with no table filter, so generation pulls every record from a very large table. What is wrong with that design?
Select an answer to reveal the explanation.
Short Explanation
An entity type without a filter is a fire hose aimed at your GRC database. Point at the table, yes—but add conditions like criticality or status so you get the population you meant. Unfiltered whole-table types drown the program in junk entities.
Full Explanation
An entity type should pair a source table with meaningful conditions so generation does not ingest an unfiltered whole table. An entity type with no filter is a fire hose aimed at the GRC database, drowning civic programs in low-value entities and harming performance and ownership clarity. Types are selectors, not bulk copy jobs; predicates such as criticality, status, or environment constrain the population programs actually govern. Saying entity types are not allowed to reference any table and that only manual entities are valid is false. Calling filters optional decoration that never affect which records become entities misunderstands generation. Increasing table size until performance problems disappear is not a design fix for unfiltered types. Exam caveat: source table plus meaningful conditions is the entity-type pattern. Operational check for the implementer: add durable filter conditions to the oversized type, regenerate in subprod, compare entity counts and ownership completeness before versus after, and promote only when the population matches the approved scope definition. Keep civic stakeholders aligned on the operating model, and verify platform records after each change before reporting posture to leadership. Revisit the design when CMDB classes, org structures, or program charters change.