role-engine/INTENT.md

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 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.