Advanced Workflows
How to use AI generation, framework copying, and Human Performance Indicator mapping when managing competency frameworks at scale.
Overview
Most framework work is straightforward: create, structure, assign, review, publish. The advanced workflows exist for the moments when that simple route is not quite enough. Sometimes you need a fast first draft. Sometimes you need to reuse an existing framework rather than start again. Sometimes the challenge is not writing at all, but translating one organisation's Human Performance Indicator (HPI) logic into another's.
That is where the more advanced tools come in.
Generate
Use AI to create a structured first draft from guided context inputs.
Copy
Reuse an existing framework when the role or structure is already close enough.
Map
Translate competencies into another organisation's Human Performance Indicator structure without flattening the logic.
Generating a framework with AI
AI generation is most useful when you want momentum rather than a finished answer. The flow asks for context about the organisation, the role or framework focus, and some writing preferences such as language variant and sentence length. From that, WeMatter can generate a structured draft that gives you something concrete to react to.
That reaction step is the important part. AI can help you escape the blank page, surface patterns quickly, and suggest wording you may want to keep or refine. It should not be treated as the last editorial step.
Treat AI output as a draft, not a verdict
Review HPI fit, duplication, specificity, tone, and publishing readiness before using an AI-generated framework in live workflows.
AI generation tends to work best when the role family is clear, the organisation's context is known, and you mainly need help turning that context into structured statements. It is less useful when the role is very specialised, politically sensitive, or already supported by a mature framework that only needs careful refinement.
Copying within the same organisation
Copying a framework within the same organisation is the cleanest reuse pattern. Because the source and target live inside the same HPI structure, the framework logic does not need to be translated. You are reusing a shape that already fits the local model.
This can be a strong option when you want to create a variant, preserve most of an existing capability pattern, or move faster than a full rebuild would allow. Even so, it is worth resisting the temptation to duplicate and publish in one move. A copied framework still benefits from a quick editorial pass so the name, description, and competency set clearly belong to the new use case.
Copying to another organisation
Cross-organisation copying is where things become more interesting. The source framework may be good, but the target organisation may group capability in a different way. Similar HPI names do not always mean identical intent, and a clean-looking copy can still introduce confusion if the underlying structure is misaligned.
For that reason, the flow asks you to choose a target organisation, inspect the source HPI areas, and decide how they should map into the target structure. Only the competencies with a valid home in the target model should come across.
Reading HPI mapping properly
HPI mapping is not only a mechanical step. It is a judgement call about meaning. You are deciding whether one organisational category is a sensible equivalent of another, and whether the competency statements still make sense once they land there.
Sometimes the answer is yes. Sometimes a source HPI has no convincing target equivalent and should be left unmapped. That is not failure. It is often the sign of a healthy governance decision.
What matters is that copied competencies arrive in a place where they still make sense, rather than being forced into a category simply to preserve volume.
When the target organisation has no HPI structure yet
If the target organisation has no HPI areas configured, cross-organisation copy usually is not the right next step. The better move is to establish the target HPI structure first, then return to the framework copy once there is somewhere valid for competencies to land.
Without that structure, the copy process may be technically blocked, but even if it were not, it would still be conceptually weak. Frameworks gain their shape from HPI. Without HPI, the framework has lost the organising logic that makes it useful.
Reviewing the result after copying or generating
However the draft was created, the same editorial questions still apply. Does the name help people recognise what this framework is for? Does the competency set feel repetitive or sharp? Is HPI coverage credible? Are the visibility and ownership settings right for the people who now need to interact with it?
The important point is that advanced workflows accelerate production, not judgement. Human review is still what turns a draft into a dependable framework.
A sensible governance mindset
Reuse is powerful when the underlying capability model is genuinely similar. It is less helpful when it hides difference. If the target role, organisation, or HPI intent is materially different, starting fresh may be the more honest and more efficient route.
The same principle applies to publishing. A copied or generated framework should not feel automatically trustworthy just because it came from something that was already live elsewhere. It still needs to earn its place in the new context.
The downstream rules do not change
Whether a framework was written manually, generated with AI, or copied from elsewhere, WeMatter still treats it by the same downstream rules. It must be fit for live use before it can support scorecard launch. And if it is assigned to a person, it can still become part of the later context used in goal generation.
The creation method may change. The standard it needs to meet does not.
Last updated on