A title does not explain the work
I would hesitate to approve a role described only as “AI specialist.” I cannot tell from that title whether the person will develop models, evaluate suppliers, govern data, support users or authorize consequential decisions. I want the institution to describe the work it needs done and the responsibility attached to it. Otherwise, an apparently precise classification may rest on an unresolved organizational question.
I distinguish the identity of a position from the identity of its current holder. A position should remain intelligible when a person leaves, when reporting lines change or when a new system alters part of the work. I would describe its purpose, expected outputs, responsibilities, authority and essential requirements together. A code can then refer to that account; I would not expect the code to substitute for it.
The questions I want to make explicit
I use a hypothetical pair of identical titles to test this distinction. One data analyst prepares routine reports under supervision; another defines an institutional measurement method and is accountable for its interpretation. I would not assume that the same title implies the same responsibility, seniority or qualification needs. I would ask which decisions each position owns and what evidence justifies the requirements attached to those decisions.
I also want requirements to be contestable. If a role requires an advanced degree, I want to understand the work that makes that requirement necessary and whether another form of evidence could demonstrate the same capability. I would resist inferring a requirement simply because similar advertisements include it. My concern is that unexplained requirements can become exclusion rules whose organizational purpose nobody can clearly defend.
Where I would put AI
I see a useful role for AI in exposing omissions, comparing descriptions and proposing interpretations for review. I would require the system to distinguish user-provided facts from suggestions and to identify the information still missing. I want an authorized person to decide what becomes part of the position record. A fluent recommendation should make the review easier; it should not make the source of authority harder to see.
I connect this argument to MIYAR, the workforce architecture and position-management prototype developed with Ahmad Raza Khan. I regard a prototype as a way to make an institutional design discussion concrete. I would evaluate an implementation through reviewable definitions, traceable revisions and the quality of the decisions it supports. I would need evidence from actual use before claiming that it improves hiring, productivity or workforce planning.
Meaning must survive revision
My test for a mature position system is simple: can a reviewer explain why a role exists, how its requirements were chosen, who approved them and what changed since the previous version? I would keep the record compact enough to maintain, with review triggered by meaningful changes in the work. I believe an institution gains control when it can revise its definitions deliberately and explain the consequences of those revisions to the people affected.