116 lines
4.3 KiB
Markdown
116 lines
4.3 KiB
Markdown
# INTENT
|
|
|
|
> Status: Draft
|
|
|
|
## Purpose
|
|
|
|
`role-engine` exists to define reusable organizational and operational roles in
|
|
one coherent, versioned repository.
|
|
|
|
The repository replaces the tentative one-repository-per-role model. A role is
|
|
a governed definition within this repository, not a repository boundary of its
|
|
own. This keeps shared concepts consistent, makes roles easier to compare and
|
|
maintain, and avoids multiplying repositories for closely related documents.
|
|
|
|
The first definition is the
|
|
[Community Manager — Coulomb Society](roles/community-manager.md) role.
|
|
|
|
## Primary utility
|
|
|
|
`role-engine` should give people, teams, and automation agents a clear contract
|
|
for what a role is expected to accomplish and where its authority stops.
|
|
|
|
Role definitions may describe:
|
|
|
|
- purpose and intended outcomes;
|
|
- responsibilities and recurring activities;
|
|
- required competencies and expected behavior;
|
|
- decision rights and escalation requirements;
|
|
- interfaces with people, teams, systems, and other roles;
|
|
- success criteria and evidence of effective operation.
|
|
|
|
The definitions should be useful for role design, recruitment, onboarding,
|
|
delegation, agent prompting, operating reviews, and organizational change
|
|
without being coupled to one execution platform.
|
|
|
|
## Core principles
|
|
|
|
### One model, many roles
|
|
|
|
Roles share a repository and, as the catalog matures, a common vocabulary and
|
|
structure. A genuinely independent product or service may still warrant its own
|
|
repository; a role definition alone does not.
|
|
|
|
### Roles are not identities
|
|
|
|
A role describes expected authority and behavior. It does not identify the
|
|
person, team, or agent currently filling it. Assignments and identity records
|
|
belong in the systems that govern people, agents, and access.
|
|
|
|
### Roles are not permissions
|
|
|
|
Decision rights in a role definition express organizational intent. They do not
|
|
grant technical authorization. Access remains subject to the relevant identity,
|
|
policy, and authorization systems.
|
|
|
|
### Definitions before machinery
|
|
|
|
The repository begins as a documentation-first catalog. Schemas, validation,
|
|
rendering, APIs, or automation should be introduced only when real consumers
|
|
make their requirements clear.
|
|
|
|
### Context remains explicit
|
|
|
|
Some roles are reusable across organizations; others are specific to a domain,
|
|
community, or operating environment. Definitions should state that context
|
|
rather than pretending every role is universal.
|
|
|
|
## Initial scope
|
|
|
|
The initial repository should own:
|
|
|
|
- the role catalog under `roles/`;
|
|
- guidance for writing and reviewing role definitions;
|
|
- shared terminology and structure once repeated patterns are demonstrated;
|
|
- version history for substantive changes to role purpose, authority, or
|
|
responsibilities;
|
|
- links between related roles where coordination or escalation depends on them.
|
|
|
|
## Out of scope
|
|
|
|
`role-engine` should not initially own:
|
|
|
|
- personnel records, hiring decisions, or employment contracts;
|
|
- live assignment of people or agents to roles;
|
|
- authentication, authorization, credentials, or permission enforcement;
|
|
- task management, scheduling, or workflow execution;
|
|
- performance surveillance or individual activity tracking;
|
|
- a runtime service merely to justify the word `engine`;
|
|
- separate repositories for each role.
|
|
|
|
## Evolution direction
|
|
|
|
The next useful step is to learn from the Community Manager definition and any
|
|
second role before standardizing a schema. If multiple consumers later need
|
|
machine-readable definitions, the repository may add stable identifiers,
|
|
structured metadata, validation, rendered views, and compatibility rules while
|
|
keeping the human-readable role contract authoritative.
|
|
|
|
## Success criteria
|
|
|
|
The direction is working when:
|
|
|
|
- adding a role is normally a focused file change, not repository creation;
|
|
- related roles use consistent language for responsibility, authority,
|
|
interfaces, escalation, and success;
|
|
- a reader can distinguish a role definition from an assignment or permission;
|
|
- role changes have clear reviewable history;
|
|
- people and agents can reuse the definitions without depending on a particular
|
|
workflow or identity system;
|
|
- additional machinery is added in response to demonstrated needs rather than
|
|
speculation.
|
|
|
|
## Guiding statement
|
|
|
|
`role-engine` maintains clear, reusable role contracts while leaving identity,
|
|
assignment, authorization, and execution to the systems that own them.
|