Archetype

What an archetype does in an identity model

An archetype is not an access decision. It is a presentation and management layer that shapes how an identity object appears in the interface, which fields are emphasized, and what administrative behaviour is associated with that object. In layered identity designs, that separation helps keep UX intent distinct from authorization logic.

This distinction matters because object presentation can influence how operators understand ownership, lifecycle state, and operational context, without changing who is allowed to do what. In other words, an archetype can guide handling, but it should not be treated as a substitute for role assignment or policy enforcement.

How archetypes shape object behaviour and user experience

Archetypes are useful when the same underlying identity object type needs different treatment in different business or operational contexts. For example, a staff account and a service account may both be identity objects, but the interface can present them differently, with different defaults, labels, or workflow cues.

That makes archetypes a design tool for consistency. They help standardise how administrators see and manage objects, especially in environments where the identity model is broad and object types are reused across multiple processes. The result is clearer operator intent, fewer ambiguous screens, and less accidental misuse of generic forms.

Why archetypes are separate from roles and policies

The key architectural point is separation of concerns. Roles express permissions, policies express rules, and archetypes express how an object should be presented or handled. Keeping those functions distinct reduces the chance that user interface conventions are mistaken for authorization controls.

That separation also makes governance easier to reason about. If a team changes how an object is displayed or processed, it should not silently alter what the identity can access. Conversely, if access must change, that should be done through the proper authorization mechanism, not by repurposing the archetype layer.

Where archetypes fit in the identity lifecycle

Archetypes are most valuable when identity lifecycle handling depends on object context, such as onboarding, classification, review, or administrative workflow. They can help route an object to the right process, surface the right attributes, and reduce manual interpretation by operators.

Used well, they improve usability without weakening control boundaries. Used poorly, they can create the illusion that a display convention is a governance decision, which is where mistakes begin: operators may rely on visual cues instead of checking the underlying identity state, entitlement model, or policy set.

Practitioner Guidance

Governance implication: Treat the archetype as a presentation and handling construct, not as a permission source. If the object’s access, ownership, or lifecycle status changes, update the relevant roles, policies, or workflow logic separately so that interface behaviour and control behaviour do not drift apart.

What to watch for: The main failure mode is when teams embed control assumptions into a UX layer and later assume those assumptions are enforceable. Keep archetype definitions narrowly focused on how the object should be managed, and review them whenever the identity model or administrative workflow changes.

Related resources from NHI Mgmt Group

• AI deployment archetype
• AI Archetype
• Archetype-aware Security
• Deployment Archetype