After associating a control objective to relevant entity types, the compliance lead expects control records on those entities. Which architecture behavior produces them?
Select an answer to reveal the explanation.
Short Explanation
Associate the recipe (control objective) to the kitchens (entity types), then generation bakes a cake (control) in each kitchen. That's item generation—not Discovery scanning ports for policy text.
Full Explanation
Item generation creates control instances on entities when control objectives are associated to entity types or specific entities. That architecture behavior is what produces owned control records after association for city compliance teams—not manual recreation of every control text inside incident records, a knowledge article that lists the control objective once, or a Discovery schedule that invents controls from open ports. Generation connects definition-level content to entity-level work so managers receive testable obligations in IRM. Incidents are operational tickets, not the compliance content model. Knowledge articles inform people but do not generate owned controls. Discovery finds infrastructure facts; it does not author GRC control instances from port data. Exam caveat: association without successful generation—or without scope and ownership—still leaves owners with nothing to test; verify generation jobs and results. Operational check: associate a control objective to a pilot entity type, run item generation, confirm controls appear on in-scope municipal entities with owners, and sample one attestation path end to end. Document generation prerequisites in the city's compliance runbook so 'we associated it' is never mistaken for 'controls exist,' and monitor generation failures after content pack updates.