How to Define a New Hire Role Charter with an AI Company Brain

Give a new hire a role charter that says, for each outcome, what they decide, what they only recommend and who approves, because a job description cannot answer the first real decision. We recommend two features that most charters lack. A decision right that steps up on a date when the hire passes a practical test, instead of full authority assumed on day one. And a pick-list answer when the assistant cannot tell which outcome a question belongs to, instead of a guess. The company brain serves the confirmed charter with its source and never infers authority from a job title or an org chart.

Why a job description stops short

CIPD's job design factsheet defines job design as the process of establishing employees' roles and responsibilities, meant to optimise work processes while also creating good quality jobs. A job description is the recruiting output of that process. Work starts at a finer grain, where a new hire has to know which result they own, which decisions are theirs, which need approval and where the current procedure lives. Without those, the first real decision goes wrong in one of three ways: two people assume the other owns an outcome, the hire waits for approval they already had authority to give, or the hire acts alone where a legal, security, finance or customer owner had to approve.

The charter record

Treat the charter as structured knowledge with a readable page, not a paragraph in an offer letter. Each responsibility carries enough data to answer a work question safely:

charter_id: customer-operations-manager-v3
employee_id: worker-1842
role_family: customer_operations
version: 3
effective_from: 2026-09-03
review_due_at: 2026-10-03
manager_id: worker-0911
outcomes:
  - outcome_id: renewal-risk-review
    expected_result: Renewal risks have an owner and next action before forecast review.
    evidence_source: /knowledge/renewal-risk-process
    decision_right: recommend
    decision_right_after_verification: decide
    after_verification_scope: non-strategic accounts
    approval_owner: revenue-director
    consulted_teams:
      - customer_success
      - finance
    escalation_route: revenue-operations-help
    verification_task: Route one synthetic renewal-risk case.
status: confirmed
confirmed_by:
  - worker-1842
  - worker-0911

Keep the fields operational. expected_result is an observable outcome, not a loose activity such as "support renewals". evidence_source points to the maintained process or policy that governs the work. decision_right comes from a small controlled vocabulary: decide, recommend, execute, review or observe. consulted_teams records required input without turning every colleague into an approver, and escalation_route is a queue or help channel that survives one person's leave. Link supporting procedures instead of pasting them in, so a process update leaves no duplicate instructions behind, and keep the first charter to five to eight outcomes a hire can confirm and test.

Resolve the manager from a directory and treat the answer carefully. Microsoft's List manager API returns the user or organizational contact assigned as the manager, and returns 404 Not Found when no manager is assigned. A 404 is an unresolved approver and the charter stays unconfirmed. A contact is not a person who can confirm anything. Either way, the manager link is one input, because it establishes neither the approval owners nor the process owners in the charter.

Step the right up on a date

We recommend that every decision right carries two values: the one the hire holds now and the one the role carries once the verification task is passed and the manager records it. In the example above, the hire recommends renewal-risk responses and the Revenue Director approves them, and after the verification case the hire decides for non-strategic accounts and still recommends for strategic ones. The charter marks which value is current, and the assistant quotes only the current one. A hire given full authority on day one acts alone where an approver should have seen the case, and a hire kept at "recommend" indefinitely waits for approvals they should be giving. A dated step avoids both and gives the manager a concrete reason to run the test in the first month.

Build it before the hire starts, confirm it in week one

Start from the approved job description, team goals, process pages, service ownership records and delegation rules, and ask the manager and one or two people who depend on the role which decisions routinely cross team boundaries. If the manager cannot point to an approved source or an accountable owner for an expectation, record an unresolved item, and never let the company brain turn a repeated chat opinion into policy. Convert activities into outcomes: "attend customer meetings" is an activity, and "customer risks are recorded with an owner and due date within one business day" is an outcome the hire can inspect.

Layer the charter the way GitLab's onboarding handbook layers its onboarding issue, which has a main section for every team member with department and role-specific tasks below it, some of them linking to a supplemental template. Maintain the company-wide outcomes, such as security, expenses and conduct, once, and keep a short addendum for each role family. Name the decision right for each outcome and add conditions where authority changes by amount, customer tier, region or data sensitivity. "Owns with support" forces every hire to interpret the boundary again.

In the first week, the manager walks through each outcome and the hire explains the decision boundary in their own words, flagging unclear wording, missing sources and conflicting expectations. Confirmation means both people reviewed a specific version. It is not a blanket acknowledgment that every expectation is fair or permanent. Record unresolved items with owners and due dates, and keep the affected boundary restricted until the question is settled. Kipwise's employee onboarding page describes assigning onboarding material, making company knowledge searchable, and tracking progress. Place the charter inside that flow, linked to the tasks and sources where the employee will use it.

Limit what the assistant can retrieve

A charter holds more sensitive context than its authors expect: customer names, investigations, approval limits. The allowlist question is which fields the assistant must see to answer "what do I own?", and everything else is excluded before search, because an instruction in the prompt not to reveal private fields is weaker than a field that cannot be retrieved. People Operations can pick up the vocabulary for that conversation from the Learning Center on NIST's voluntary Privacy Framework page, which collects videos and other resources. The hire sees their own confirmed charter and the sources they need. Peers see the role's public outcomes and contact route. People Operations sees confirmation history. Interview notes, manager impressions, accommodation details and performance commentary never enter the charter.

Serving the answer

The resolver selects the employee's active charter, filters outcomes by permission and effective date, and returns the approved boundary with its source:

def answer_role_question(employee, question, now):
    charter = charters.active_for(employee.id, now)
    if not charter or charter.status != "confirmed":
        return escalate("No confirmed role charter")

    outcomes = enforce_permissions(employee, charter.outcomes)
    matches = semantic_rank(question, outcomes)

    if len(matches) != 1 or matches[0].confidence < ACCEPT_THRESHOLD:
        return ask_to_choose(outcomes)

    outcome = matches[0]
    source = knowledge.open_current(outcome.evidence_source, employee)
    if not source:
        return escalate("Governing source is unavailable")

    return explain_boundary(
        expected_result=outcome.expected_result,
        decision_right=current_right(outcome, charter),
        approval_owner=outcome.approval_owner,
        consulted_teams=outcome.consulted_teams,
        source=source,
        effective_from=charter.effective_from,
        escalation_route=outcome.escalation_route,
    )

When ranking cannot settle on exactly one outcome, the code above calls ask_to_choose. We recommend showing the hire their own outcome list and letting them pick, then logging the chosen outcome_id, in place of both a best guess and an escalation to a human. A charter is deliberately short, so a pick-list is easy to read, and the answer then rests on the hire's choice, not on a similarity score, in the one place where a wrong boundary means acting without approval.

A good answer names what the employee owns, the authority that applies now, who else takes part, the governing source, the effective date and the escalation route. For example: "You prepare the renewal risk recommendation. Until your verification case is recorded, the Revenue Director approves the response. Consult Customer Success and Finance, then record the decision in the renewal process. This comes from role charter version 3 and the current renewal risk procedure. Use Revenue Operations Help if the customer tier or approver is unclear." If a required fact is missing, the answer names the missing field and opens a repair task.

Cases the resolver must handle

• With no confirmed charter, show the manager and People Operations route and never synthesize responsibilities from the job title.
• With two active versions, block a definitive answer and ask the charter owner to close the conflict.
• If the hire cannot open a governing source, report that and route an access request or a source repair. Do not paraphrase hidden content.
• If a manager instruction and the source disagree, show the conflict and route it to the source owner. Do not pick whichever text ranks highest in search.
• If an expectation changes, create a new effective version, explain the change to the hire and keep the earlier confirmation.
• If the hire disputes a boundary, record the question and the accountable reviewer, and keep the private discussion out of the searchable charter.

The charter records approved expectations and work routes, and it never counts how often the hire asks questions.

Prove it with work

A signed page does not prove that a hire can connect an outcome to authority. For each high-consequence outcome, build one low-risk synthetic scenario that cannot touch a customer, a payment or a production system, and ask the hire to use the company brain and explain the expected result, their current decision right, the approver or consulted team, the governing source and where to escalate if one fact changes. A pass is what moves the right up a step. Then test the negatives: remove source access, activate a second charter version, mark an owner absent and ask a question that crosses two outcomes. Each must end in the pick-list or an escalation, never in invented authority.

Review the charter after the first month, after a manager or role change, and whenever an attached source changes materially. Each review edits the work agreement itself, and extending the review date does not count as one. To start, take the responsibility that causes the most handoffs or conflicting instructions, rewrite it as an observable outcome with one decision right, attach the governing source and the approver, and have the manager and the hire test the answer together before you expand the charter.